Celtic Burn Digital Security Policy
Zoe Ironstone
Public
Seen by 78
AP concluded 01/11/2024. Decision taken to proceed with admin-approval links for joining telegram, and also as standard to wipe all data/spreadsheets after one year. We will hold a separate email list for people to join and maintain that info independently (Isa volunteers as tribute). All other DSP aspects confirmed.
Hi all! The aim of this AP is to finalise our Digital Security Policy before we put up the new Celtic Burn website and start recruiting for CB25, as some of these decisions will affect how we manage certain things.
The main thing we really need to hash out is our policy around Telegram. This is important because a lot of information is currently shared within the main telegram group, including spreadsheets and identifying information.
Most other questions haven't been that controversial, but of course I am including the preliminary policy in its entirety here (attached: "Celtic Burn Preliminary Digital Security Policy"), both for transparency and to give people a final chance to comment.
BACKGROUND INFO HERE; FEEL FREE TO SKIP TO "CURRENT OPTIONS"
As you hopefully know, we have been gathering opinions and data on digital security within Celtic Burn, after there was a small issue in May that highlighted the need for an assessment and structured policy, to make sure we are balancing our needs for security, inclusion and confidentiality thoughtfully. This and the meetings were open to all, though surprisingly not many people chose to be super active in the exciting discussion of what piece of binary code should be allowed to go where. An overview of the meetings and initial assessment are attached in the file marked: "CB Data Security Initial Overview".
We then created and ran a survey on the relevant questions, also attached for transparency ("Report: CB Data...."). After going through this and the comments that were left, we came up with a preliminary policy. Most of this is fine.
HOWEVER, I miscommunicated the options re: telegram. Most people opted for having a bot to check on new people, AND having admins back up the bot. The problem is, the bot would basically just ask an automated question to check if people are human, and let them in. Then it's still up to our (currently very few) active admins to find the new people and check on them and their intentions by asking a couple of friendly questions. The issue with this is that it is rather open to human error, allows newly added members to float in the telegram group until noticed/addressed by admins, and also puts a lot of pressure on said admins.
CURRENT OPTIONS RE: TELEGRAM SECURITY
Have a "welcome" topic, within the main SB group, where we pin the security policy and some basic explanations of how the group works. People who join can start there by introducing themselves, and also have access to the info that all new members need to know. If they don't do that within a certain time frame, they need to be checked on as with the existing procedure. Which would be clearly stated in the welcome topic. This has already been enacted, the question is whether it's secure enough.
-
As above, but the welcoming is done in a separate group, as a sort of sandbox. Once people introduce themselves, or if friends already in the group introduce them, they are allowed straight into the main SB group. Permissions would be set so that a very large number of us were "admins" in that group, and could just greet, chat, and add to main group when we see new people. It spreads the logistical load, while maintaining tighter security. However, is the most complicated of the options and some worry that it comes across as exclusionary.
It is possible to set the invite link to require admin approval. From Telegram's release notes: "When a user opens a link with Admin Approval turned on, they will see a button to send a join request that admins can manage from a new bar at the top of the chat. From there, admins can view an applicant's public profile pictures and bio, then approve or dismiss their request." Essentially similar to how a moderated subreddit or a private facebook group works. This would be simpler than the above, and much safer than the current open-door policy, but also may require a few more admins to make it run smoothly.
CONCLUSIONS/ADDITIONAL THOUGHTS
Pretty much any upgrade to Telegram security requires more admins, and more involvement from said admins. It's not fair for us to decide on a policy that requires just a few others to do a lot more work, and it's not very do-ocratic either. So if you are going to call strongly for one of the more labor-intensive processes, please also check in with yourself about whether you are able to provide some of your own time or energy to make that happen. This also has the benefit of supporting decentralisation on a logistics level.
Some solutions for this are to have a "rolling admin helm", or to have an open sign-up for people who can offer admin support specifically for a certain task, or around certain times. Open to suggestions and thoughts.
In general, it's everyone's responsibility to keep an eye on the group's security and either message people directly, or pass info to admins to check up on. It's also emphasised in the current DSP that your digital security is in your own hands, and that informed consent and personal responsibility are foundational, as with most other burn-adjacent things.
*********************************************************************************
Due to the low engagement in previous discussion on this topic, and the amount of time that has already passed for people to add to the discussion in various ways, I intend to keep this AP short. I also encourage you to read through the attached documents before commenting on anything not mentioned in the spiel above - please save me from having to endlessly paraphrase myself!!
We'll wrap up in 2 weeks, unless something unforseeable happens. Looking forward to hearing your thoughts!
Rachel Tue 15 Oct 2024 9:40PM
Really impressed with all the work done on this topic by everyone. Thank you Zoe for summarizing and creating this AP.
Given the data leak that happened previously this year, I don’t feel it would be unreasonable or exclusionary to have admin approval of each new member in order for them to see telegram content. It’s a very common requirement which most online communities have. People are used to this on facebook communities and it helps keep bad actors/bots from disrupting a community.
I don’t think that it would be a common reaction for people to experience aversion and dismay to a simple delay in entering the community. I am a pretty avid champion for inclusion and always hate the idea of excluding anyone, but if admin approval is given just on the basis that we know we’re dealing with a genuine human then I see no exclusion here.
I also feel that option 3 is more efficient and I am happy to be a rolling admin should that be needed.
Also, I find it strange to be less worried about inclusivity than fox 😂
Rachel Tue 15 Oct 2024 9:47PM
Oh and final note… option 1 already resulted in issues with folks who joined and didn’t respond to fox’s welcoming greeting. And a pinned note on policies in a welcome group won’t solve that. Also it’s unnecessarily complicated to give people a time frame to introduce themselves and have to keep track of when they joined.
ermias worku Wed 16 Oct 2024 1:09PM
Thank you, Zoe, for all the hard work you’ve put into this. I really appreciate the thought and effort that has gone into creating this policy. Given the data leak earlier this year, I think it’s entirely reasonable to implement admin approval for new members before they can access the Telegram group. This is a common practice in many online communities, and it’s effective in preventing bots or bad actors from joining.
I don’t think most people would have an issue with a short approval delay, as it’s a necessary step to ensure we’re interacting with real individuals, not creating exclusion. I also agree that option 3 is the most efficient way forward, and I’m happy to offer my support as a rolling admin if that helps.
Isabelle Thu 17 Oct 2024 5:27PM
@ermias worku When you say "Given the data leak earlier this year...", you're referring to people who are not part of the community finding the Master Spreadsheet online after CB24, which was open access to anyone at the time? Or are you referring to some other incident?
I'm just checking - as the Telegram "request to join" feature and the access rights we choose for our Google docs are 2 separate decisions...
Rachel Thu 17 Oct 2024 7:13PM
@Isabelle Hi Isa, actually I used that terminology first. Apologies if it’s inaccurate, but yes I was referring to data being available to folks not a part of the Celtic burn community.
Zoe Ironstone Thu 17 Oct 2024 7:13PM
@Isabelle As Ermi was part of the discussion since the beginning, what I guess he means is that the leak both highlighted that we need to be more circumspect generally, and also that we should take any sensitive (i.e. identifying) info off the spreadsheets, which basically means keeping things like rideshare discussions and exchanges of personal details in Telegram... which means we have to be sure our Telegram data security and practices are as good as can reasonably be expected. It all connects. (All this is in the attached docs, though cause-effect might not be immediately obvious, understandably)
Isabelle Mon 28 Oct 2024 3:34PM
@Zoe Ironstone It's good that you mentioned how you see the two things connected (spreadsheets and Telegram), because i didn't get that from reading the documents - thanks :-)
I don't think the logic should be:
We need to find a new place for sharing somewhat sensitive personal info
-> let's choose Telegram as that new place
-> now we need to therefore make Telegram more secure and more closed.
I think it would make more sense to approach it the other way round:
We already have various other ways of communicating with all different levels of security (Google docs, good old emails, phone numbers, Wrike etc.),
so we should choose the most appropriate one for each task.
I don't know what the security measures would need to be that would make a chat group like Telegram suitable for sharing anything that people would consider half-sensitive or personal (I'm pretty sure those measures would need to be more than options 1, 2 or 3 described here!)
In my humble opinion, we shouldn't even attempt that! But just keep Telegram as our most non-sensitive, welcoming and open channel as it currently is - because that in itself is a valuable thing to have.
ermias worku Sun 20 Oct 2024 8:37AM
Yes, I was referring to the Master Spreadsheet. I’m not aware of any other incident. I also agree with @Rachel and @Zoe Ironstone comments, which have provided further clarifications.
Rachel Liberty Mon 21 Oct 2024 2:02PM
Thank you so much for all the work the team have put in considering this, presenting it, and making it so clear. I am in favour of option 3. I am also willing to be an admin for it.
fox of light · Tue 15 Oct 2024 5:27PM
foxy thoughts:
Strongly against option #2- Unnecessarily complicated, entails significant extra faff for everyone involved, would make our community feel gated and exclusionary. Hard pass.
Comparing options #1 & #3: In my opinion option #3 would not actually require more or less admin work than option #1- if anything it might feel like a bit less work, because there are will be no floating as-yet-ungreeted users to keep track of.
Option #3 does however present more 'fencing' towards the newcomer, and so may feel more exclusionary than we would like to be experienced as, as a Radically-Inclusive burner community.
I dislike the 'require admin approval to join' option (#3) because it makes it so that the first thing the newcomer sees when they try to join us is a wall.
We tested it last month, to check technical feasibility, with a friend who wasn't in the group at the time. The test went fine, but the friend's reaction to it was one of aversion and dismay. She had experienced this set-up [send a join request; wait for admin approval] as exclusionary, and I can see why she did.
So while I personally dislike option #3, I do see it as a 'lesser evil' than option #2, and will not veto its use if it ends up being chosen over option #1.
Final foxy advice: Option #1