Introduction

This is the first in a series of post trying to give a few pointers and share a bit of knowledge on securing your online presence and activism, targeted at leftists.

The motivation behind this series is my own observation of the lack of technical security education and/or interest in leftists circles in the US, and the anxious feeling that it’s direly needed.

These posts are to be considered in the current political context, and also taken with a grain of salt, as I’m not a security professional and while I do have some security knowledge, it is not my primary field of expertise.

Anyway, here goes

OPSec

So, OpSec (operation security) is a very generic concept referring to identifying what information is important or even critical to the security of your operation, how it is potentially exposed to your adversary, how to protect it from that adversary, and finally putting all of that into practice by changing the organization of your operation to reduce the exposure to your adversary.

That’s all pretty abstract so far, but basically you can think about it like this:

• Who’s my enemy
• What must they absolutely not know
• How can they currently learn that
• How can I prevent them from doing that
• Fix the issue, rinse and repeat

Who’s my enemy

The purpose of this question isn’t to point at specific people, but rather to understand what the scope of the potential attacks you’re facing are. If you’re organizing a tenant union, your enemy is the landlord, and there’s not much they can do to attack your organization. If you’re planning revolutionary action on the US government, your enemy is the entire US government and all of its defense branches, which can definitely come after you, in depth, and they will, and you’d better be ready — if it’s even possible to be ready for that situation, lots of revolutions have failed even without having the full attention of the American empire…

But the point is that the degree to which you’re exposed, and the type of response you’ll need to take, depends a lot on who your adversary is and what kind of resources they have access to (and are willing to use against you).

What must they absolutely not know

This one should be obvious. If your adversary knows this, your operation is a bust, all your efforts were for nothing, and you might be facing repercussions. To keep going with the examples from the previous point, if the landlord knows you’re the one who’s organizing the tenant union, they’ll find a pretext to evict you, and then you’ve been organizing for nothing and you’re out of a place to sleep. Of course the other example has worse outcomes (i.e. torture or death) but the concept is the same.

Sometimes though, your adversary knows your identity and your organizing against them is public, yet they can’t do anything from just these informations. There are still things that they can learn that would compromise your efforts. Find out what they are.

The answers to these two questions (“who’s my enemy” / “what must they absolutely not know”) is known as your threat model, and it’s what you’re going to use to tighten your security by identifying what are your current problems and what measures are necessary to fix these.

How can they currently learn that

How are you exposed? That’s a trick question, of course, because if you knew you’d have fixed it already, but there a few avenues of exposure that are easy to explore and hopefully solve.

First of all, you could have an involuntary leak. Someone wasn’t careful enough about where they were talking about something, or published something they shouldn’t have, and now it’s been exposed (and by that I don’t mean your adversary knows it for sure, I mean it has been exposed in a place where your adversary could have seen it. That’s enough to be considered a leak). That’s human error, and while it will always exist, there’s ways to reduce the probability of it happening. This is the most common type of leak.

Second, you could have a member of your organization voluntarily leaking information. It could be because they’re being blackmailed, corrupted, or they’ve just been flipped, or it could be someone who’s infiltrating your org… either way, these are harder to work around, because… well, because they’re actively hostile. This is way less common, and mostly happens if you have powerful adversaries (like always, your threat model should tell you what to worry about)

Finally, you could have a leak that’s not within your organization. The company you’re using to chat got hacked and all your messages are suddenly public. Your storage space got broken into and documents are missing. Your Internet service provider is just giving all of your data to the government. These things happen, and you can fight them by running your own tech services and securing your data properly, but this is honestly the least common avenue for an adversary. Once again, trust your threat model.

How can I prevent them from doing that

The first and most effective line of defense against potential information leaks in your organization is to not give the information in the first place. Always think of OPSec in two layers: there’s your opsec as an individual, and then there’s your organizational opsec. If you found that your name is compromising, then use a nickname or a fake name in your organization. If your address is compromising, don’t tell people where you live, and don’t take them back there! Of course, this means not giving anyone access to any online profile where your real name or address is, never letting anything slip, not letting anyone see your ID, etc.

This is basically creating a new, separate identity, which you will use exclusively in the context of the organization. This isn’t always easy, but it can be necessary in some cases, and it’s always very effective.

Not giving information isn’t only a tool to protect yourself, though. It can also be a tool inside your organization. The group that works on action A doesn’t necessarily need to know about action B. Segment information, it keeps everyone safer. Keep groups small: if you need to, coordinate multiple small groups rather than making a large one, with a single person in each group in charge of coordination. That way, no-one knows everyone. Take whatever precautions are warranted by your threat model.

Of course, some information you need to share as a matter of running your org. In these cases, the next step in defending against potential information leaks in your organization is its cohesion. If everyone is close to everyone else, not only will everyone be more careful (which is important for accidental data leak), but it’ll also be very hard to corrupt/blackmail/flip one of your members, and even harder to infiltrate your organization. Remember, OPSec is not a tech concern, it’s a social concern. Find out who in your movement is vulnerable, and take care of them. Think about your onboarding process, how much you evaluate potential members, and how you start sharing information with them. Without falling into paranoia, not telling every detail of your actions at meetings with people you don’t know might be a good idea, depending on your threat model (like everything else).

Your next line of defense should be making it hard to fail. Your processes need to make it clear when sharing information is OK, and who with. You need to establish clear communication lines inside your organization that are safe and dedicated to a subgroup/action. Once again, this isn’t about tech, the best encryption won’t help you if someone who works for your adversary is added to the group chat about your action plan. At any point, it should be clear for anyone in your organization how they can communicate with other members, and what they can say on which channel. Separate messaging groups for different projects are a good start, but there needs to be enforcement of the separation (meaning reminding people when they start talking about sensitive stuff on the misc channel), and deliberation before including someone in the group.

Finally, there’s damage control. Once something has been leaked, you need to have provisions in place to keep your operation going as well as possible. If the leak is the date and place you were planning to have your action, you have to be able to change that, and quickly, while making sure everyone involved knows (i.e. not only have the technical possibility of sending a message to people, but having a mechanism to make sure it’s read in a defined amount of time and getting acknowledgment that it has been. Picture having to reschedule two hours before and work from there). If it’s someone who’s been added to the wrong chat group, or someone who talked in the wrong place, make sure it’s clear it shouldn’t have happened, do your best to scrub the information from there (disappearing messages with a short-ish lifetime are great for this), and change details if necessary. Sometimes you can’t do much, going back to our tenant union example, if your identity leaks before you’re ready, you’re pretty much done, all you can do is hope and share your knowledge/resources with other members of your org.

All of these might be way too much for your threat model! If you’re only fighting to have a new bike lane installed in your neighborhood, nobody’s going to try and coerce the members of your organization into giving up your name. They might try and find when your next action is, though, by walking into one of your meetings. If you’re organizing a tenant’s union, you probably don’t need to organize segmented groups who only communicate through one member: your landlord isn’t going to torture anyone to know the names of the co-conspirators… But you might want to be careful about where you organize your meetings, keep the “security” cameras in the building in mind when you’re putting up rent strike posters, and maybe don’t give your name and unit number to other members even if it’s not that risky (they don’t really need it anyway!). Your threat model really is what determines the measures you should take.

Fix the issue, rinse and repeat

Well, this part really depends on what you found out in the previous steps. Fixing the issue, however, means not only fixing this particular instance but rather changing the system within your org as best you can to make sure that problem doesn’t show up again. Some of these you can’t fix definitely, as they’re inherent to the system outside your organization, but you can orient your group so that they’re less likely to happen. Some are entirely your responsability, and you can fix them with a bit of effort, structuring your organization correctly, and never letting your guard down.

Conclusion

That’s it for this post! Always keep in mind: OPSec is something you need to have before you actually need it. Like everything else in security, it’s a process, not a state: it’s basically impossible to tell if you’re secure, all you can reliably know is if you’re insecure, and most of the time it’s because you suddenly have handcuffs, or are being evicted from your appartment. It can require constant vigilance, discipline, and every error can be extremely costly… But it gives you a semblance of security and a fighting chance against your adversaries.

I hope this post has at least provided a few pointers, and has made you reflect on your organizational and personal OPSec. Don’t think it’s too late: it’s always better to have at least a little bit of OPSec than none at all. And if you don’t implement it for yourself, you should at least do it for other and future members.

Finally, there are more posts like this one coming on other topics, including how to communicate securely, which tools to use, what is effective, what isn’t, and how to escape tech-based surveillance, and I hope you’ll come back to take a look at these.

Good luck out there