EFF Relaunches Surveillance Self-Defense Guide

It would be great to have a zine-length brief of this with urls and QR codes for the website to be able to distribute it in print. At 250 pages the whole thing is too long to hand out.

We plan on doing a static, offline version of SSD soon, but we want to make sure that we can convey to its readers that its contents can become inaccurate very quickly. The wording on the Web site does not always convey this, because we expect to update it regularly.

Thanks again! - danny@eff

Security-wise Jitsi might be awesome, but I can't rely on it and I can't recommend it.

Namely their storage of plaintext passwords in your ~/

Then the ssd.eff.org page feels just like an empty shell, a nice logo, a bunch of empty space then a footer with links to workaround the lack of relevance of the page. Then I turned on javascript and it was the same but with an unnecessary and quite useless animation in the middle of the page.

Then I found a guide from and found it less readable and usable than the old one, though I like the bigger fonts.

To me the whole thing feels like an amateurish website and makes me think the content is on par with the design. IMHO eye candy should be left out of a project aiming at conveying important information about a subject that matters, especially when it gets in the way as it does here.

The rest of the software collection remains Free Software.

I wrote most of this section

https://ssd.eff.org/en/module/problem-mobile-phones

which is about threats and risks which in many cases we don't have good ways to mitigate, and I tried to be fairly thorough. For example, we don't have an unambiguously good and convenient way to mitigate handset location tracking, burner phone detection, or compromise of baseband processors. So I hope people will read those parts too and get a sense of perspective!

I also tried to make sure that the sections about PGP mention unprotected metadata, unprotected subject lines, and the lack of forward secrecy (compromising your private key will let someone go back and read your old messages). The PGP sections still need another editing pass to unify the content better across platforms, but a lot of those risks do get mentioned somewhere.

If you can think of other analogous sections we should write about risks that are hard to mitigate, I'm glad to write them! And if you can find things in the existing document that you feel give people a false sense of security, please let us know and we can try to fix them.

I realize that there's a pretty serious risk that any security guide will make people feel like they "did the right thing" and are communicating safely, then still get compromised. We are always struggling with the pull of "privacy nihilism" that would lead people to simply use plaintext communications over the Internet and GSM network because there are (for example) vulnerabilities in their OS or baseband, or because most encryption tools don't protect metadata. It's challenging to know what to say about risk when surveillance is a multi-billion-dollar industry and a lot of very smart people have made an entire career out of it.

One point of view is that a lot of the mitigations really need to come from the platform developers, so desktop and mobile OSes need to ship with more crypto out of the box, turned on by default, in the default communication tools, etc., and hire a lot more vulnerability researchers. If you favor that point of view, I definitely encourage you to try to push things along from that direction too!