Celtic Burn Digital Security Policy

@Rachel Liberty Thanks so much Rachel! You're on my mental list.

I am also in favor of #3, for reasons listed above, and willing to take turns as an admin, though will request guidance about what to look for in applicants' "public profile pictures and bio" in order to make a good choice about letting them in or not. (In other words, I have zero experience with online security or gatekeeping, even of the most gentle and inclusive sort.) And yes, warm thanks to those of you who've worked on this thus far! xx

@Sprite Thank you Sprite and totally understood! I think it's quite useful and empowering for us all to learn some basic digital security skills - lord knows this is not my forte and fox has had to correct me on terminology several times hahaha. But as I'm sure you'd agree that's half of the point - that our digital security is in all our hands and the more we do to support that collectively, the more stable our system is. So much appreciate "non-techies" being willing to step up ❤️

I have 2 reasons to strongly support option 3.

1. First, I have experienced the option :)

   "admin approving" entrance was unpleasant. Currently, admin approval for joining a group chat is not a common practice in messengers worldwide, so it took me by surprise when it happened. It gave me the impression of a closed group where I am being judged for only wanting to join, which felt elitist and unwelcoming. I dont wish that entrance experience for others. I would rather feel welcomed first and then judged :)

2. Additionally, my approach to inclusion is to start with openness and trust. If something feels unsafe/insecure, I talk, and if necessary, close the door as a way to communicate boundaries. I see it as a chance for a person to show their best :)

@Darya you start your comment by writing that you strongly support option 3 ("switch to requiring admin approval to join"), and then you give arguments against that option, which seem rather to support option #1 ("leave it as open and welcoming as it is currently"). So it is unclear whether you are in favour of option 3 or option 1.

For context it's worth noting that Darya is so far the only person to experience entering the group using the link which requires admin approval (a feature which we only recently discovered); all other current members of the group were either directly added or used the open join link, which is still the widely available one.

@Darya Hello, and thank you for sharing your thoughts and experience from the "entering telegram" side ❤️. Some thoughts:

1. I'm sorry to hear that you found the admin approval jarring. (I'll assume as fox did that rather than suporting option 3 you're saying you have issues with it, correct me if I'm wrong). I personally tend to feel safer when I experience these temporary security checks in groups that may contain sensitive data - like the group has their shit together and is taking my security seriously - but it's important for me to hear that not everyone interprets it that way. I'm wondering if an explanation of why we do it, and a reassurance that people are welcome and it's just a check to protect them and everyone else, would be helpful, for example on the website, perhaps both right next to the join link and whithin the newbies guide.

2. I love this approach, in life in general. I want us to be trusting and welcoming to strangers while also taking some basic precautions. When scaled up and digitized, I think some things usually need to shift. But this does not mean that we think all people who join the telegram group are bots, spammers, or jealous exes looking for ammo, but rather that just as I would not hand my house keys to someone I'd spoken to for 5 minutes, we have some checks and balances, and make sure we offset it with kindness and warmth. Hope that makes sense.

A question I wanted to bring here, as this has been discussed on Telegram lately and we're working out access to email addresses in practice:

Regarding the questions "...how long and where such data is held. Should it be destroyed after a set time?" / "Do we want a policy for how long old data can be stored before it’s time to wipe it? If so, what?":

I'm in favour of getting people's consent to keep their email permanently, so that we can let them know about future Celtic Burns (essentially like a very infrequent "newsletter") - I think most people would appreciate that.

This has already happened with a recent email that was sent to all the existing emails, asking people to let us know if they want to unsubscribe from the list. I'm up for working on this and maintaining a mailing list going forward.

@Isabelle  Thank you for volunteering your time to do that - I see no issue with doing so as long as it's regularly updated and maintained, and with your efficient self in charge I'm sure it would be.

One question that does arise is whether we maintain given names and other details in attachment of these email lists, or whether other data besides email address is deleted after a year (just picking that time frame as based on the survey it was the general time for holding of identifying info that people seem to prefer)? I would assume the latter; what do you think?

Edit: Sam had a relevant suggestion in his reply below, which sounds good to me: what do you think?

And regarding the Telegram question:

I'd be fine with option 1 and 3, and with how things are currently going with option 1, I don't see any problem continuing with it. It's not a lot of admin work to send people welcome messages after they arrive (at the current rate of new people joining).

The question above is whether 1) it's secure enough?

I think it is, as long as a) we get in touch with new members straight after they arrive (which we do - there is never a long time of someone floating around in the group unwelcomed, unknown).

And b) We have clarity about what we do, if a new member never responds to welcome messages, and also doesn't otherwise interact in the chat, giving us as a community no chance to get to know them.

In that scenario, I would be in favour of removing them from the group (as that's the only thing that, in my eyes, could be seen as a security risk - that we don't know someone's intention in this this case, and also, as mentioned to me by others as a concern - someone may not actually be a human being, but a bot??) I don't know much about such things....

But yeah, as one of the current admins, I'm otherwise happy with both the security and the workload of 1)

@Isabelle Thanks again for your input on this. I would like to correct you on the assumption that nobody is missed by current admins (myself included) - I have spoken directly to people who floated for several weeks in the telegram group after first joining, before being contacted. One of them was in fact never contacted and just rocked up to CB after a month😂 I say this not to cast aspersions on the hard work of current admins but to disabuse you and others of the illusion that human error doesn't play a big part in the current system.

I think one thing to consider is that we don't have to commit long-term to option 3; we could trial it for a set period and reassess. It is my informed opinion that with the amount of groups, messages, debates, info exchanges etc on telegram, we could benefit from removing human error from the process of joining it, and that the benefits would outweigh the drawbacks.

Thanks Zoe and others for gathering this AP together.

Thoughts:

1) Telegram: I don't mind 1/2/3. I don't think we should be sharing sensitive data in telegram. I'm in favour of Wrike and separate groups for organising.

2) spreadsheet: I don't think we need a master spreadsheet. I'd prefer to see separate spreadsheets manages by individual teams (welcoming, kitchen, welfare etc). I'd prefer to see them nestled in Wrike. I prefer this because it's a bottom up decentralised approach, asking the question of past approaches.

3) digital wipe: sheets just kind of live on in drives year on year. Good idea to keep templates but clear data after each burn. The cleanup.

4) mail list: I think better to keep a separate (from tickets) email list that people actively have to join. This makes it easier to compartmentalise why this data is being kept and used.

It would be good to include a paragraph on Loomio and Wrike. Current Loomio is: Anyone can view past content. For edit access you need to join with a short text why you want to join and I approve.

@Sam Lee Hiya, thanks for your thoughts! I'l respond one by one:

1. While I agree with you that we should prob not be exchanging sensitive data on telegram (I'm thinking I will add a note on this in the DSP - emphasize that it's impossible to fully secure and suggest anyone in a high-risk position uses an alias etc), I think it's also impossible to fully police what people talk about and share, and will become more difficult to do so as our group grows in age and size. Hence hoping we can tweak security somewhat in that area.

2. Sounds like a plan worth trialling! This DSP doesn't cover how we organise, so I'm totally open to that and have no informed opinion (tho my ADHD brain completely despises changing apps/platforms: it took me at least 4 months to face creating a loomio account hahaha). I do think it's still relevant to have a rule of thumb about shared spreadsheets in general, whether CB25 has one in the end or not.

3. Agree on digital wipe, will clarify language in DSP.

4. Yes, also very agree on this, and will refer Isa to the suggestion since she is volunteering herself as holder of the email keys.

I like Sam's points and resonate with them in general. However I'm in favour of option 3 for Telegram and id be happy to help out as an admin (temporary or long term). As Carl said below, gravity will likely pull sensitive information back into Telegram because it'll be convenient for people.

I am probably feeling option 2 or 3. I don't think 1 is secure enough, and 2 is probably too much admin but is likely the most secure.

I think we should accept that security and inclusion are in direct conflict, and that we are trading one for the other for the good of the group. We don't allow just anyone into a burn if they are not a participant, similarly Telegram is our online space so should only have people involved or honestly interested in becoming involved.

I think that the 'exclusiveness' would depend more on the reception that the new person gets from the admin than the mechanism, most people understand that online spaces should be moderated in some form. A friendly and engaging admin will probably far outweigh the brief delay in being admitted, and probably go some way to introducing them a little more gently than "here's 100 people you don't know in a chat". I would be up for being one of these admin people.

With option 3, is it possible for an admin to chat with the applicant before admitting them? It's probably going to be quite hard to deny someone just on the form, we would want to chat with them first.

I agree that it might be a good idea to move some info out of Telegram, though I suspect force of gravity will pull things / links to things back in to it, so probably focusing on limiting Telegram is probably a best beginning defence.

Thanks for all the work. I'm in favor of option #3.

OK, time to conclude this thing. Thank you to everyone who participated and supported. It seems that generally we are in favour of trying option 3 for telegram security, and that several people have very kindly offered to help out as admins to disperse the responsibility a bit. Thank you to all who stepped up!

Decision is to trial the DSP with option 3 for the next 6+ months, in the lead up to CB25. We can revisit at that time if people deem necessary. I will add elements about wiping spreadsheets/held data as well as reception deets, and about email lists, to our DSP, and I'll publish it on our bulletin board. I will add explanations about digital security and our reasoning behind having a closed telegram group, to the website copy. I'll also try to plan an admins meeting soonish (before the end of this year, at the latest), so people can get familiar with what they need to do and how to do it.

This AP is now closed.