EFF Relaunches Surveillance Self-Defense Guide(eff.org)
eff.org
EFF Relaunches Surveillance Self-Defense Guide
https://www.eff.org/deeplinks/2014/10/eff-relaunches-surveillance-self-defense
9 comments
Thanks for doing this! Can I ask a favor? Could you put today's date on the first or cover page, and a small warning that the content may be out of date, and the reader should check https://ssd.eff.org/ if they can?
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
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
I couldn't change the hosted file in place and I couldn't edit my above comment, but here's a new link to a dated copy.
https://cl.ly/1V2E1s3Z0q1i
https://cl.ly/1V2E1s3Z0q1i
Hi Danny, can you drop me a mail at the address in my profile? We would love to use some of the material in the app we are building.
Thankyou, this is very useful.
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.
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.
I wish they would recommend alternatives to Pidgin or Adium. (Because they are graphical interfaces to libpurple, which wasn't written with security in mind, to put it nicely.) Gajim and Jitsi are both free software IM clients, cross-platform, implement OTR, and are written in high-level languages. Please contribute time to both these projects, if you can.
Why, out of interest, do you care about privacy when you are sending all of your messages to a third party system? Unless you encode the text itself that you send (been possible for a very long time with pidgin plugins etc) then the debate from 5-6 years ago that you are presumably referring to deals with your assertion.
Namely their storage of plaintext passwords in your ~/
Namely their storage of plaintext passwords in your ~/
Pidgin and Adium are discussed in the guide specifically because they can do OTR. The trouble is that both clients are probably quite vulnerable to remote code execution bugs arising from things like memory corruption. Hence using them might protect you quite a bit from someone recording your IMs, but also expose you to someone who knows about a specific unpatched vulnerability and can send you messages taking over your computer.
The authors of the guide are very aware of this concern and will definitely be considering it further.
The authors of the guide are very aware of this concern and will definitely be considering it further.
>Namely their storage of plaintext passwords in your ~/
Personally, I don't see this as terribly bad. An attacker with physical access can do a lot more damage than just discovering your XMPP credentials, and if that's all they were looking for, they could just replace the Pidgin binary to send the credentials in plaintext to Moldova the next time you launched it. You need full-disk encryption to really not be affected by this.
However, libpurple is a sea of zero-days. It's a library made to deal with input over the network written in C, which is really enough to be damning. There's far, far worse in libpurple than storing plaintext passwords.
Personally, I don't see this as terribly bad. An attacker with physical access can do a lot more damage than just discovering your XMPP credentials, and if that's all they were looking for, they could just replace the Pidgin binary to send the credentials in plaintext to Moldova the next time you launched it. You need full-disk encryption to really not be affected by this.
However, libpurple is a sea of zero-days. It's a library made to deal with input over the network written in C, which is really enough to be damning. There's far, far worse in libpurple than storing plaintext passwords.
I, and others, have found Jitsi to fail in real-life situations on the simplest task: XMPP. The software looks great, seems to work nicely, but at the critical point of exchanging messages has failed me during training sessions.
Security-wise Jitsi might be awesome, but I can't rely on it and I can't recommend it.
Security-wise Jitsi might be awesome, but I can't rely on it and I can't recommend it.
I used to like the SSD guide. Not anymore.
Old website was nice and readable, the new one is terrible, in a misguided attempt to be "modern".
Even at its front page, I had no idea where to click to actually read the guide.
Old website was nice and readable, the new one is terrible, in a misguided attempt to be "modern".
Even at its front page, I had no idea where to click to actually read the guide.
I agree that the announcement doesn't make it clear where to click to access the guide. I jumped back to HN's comment to find it.
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.
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.
I thought the gigantic hyperlinks that underline on hover was a good hint.
Not on a touchscreen device.
hdparm --secure-erase-enhanced run from any Linux install .iso is faster than DBAN or dd. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
That is the only NIST-approved method for erasing a drive securely. http://security.stackexchange.com/a/5784/3714 Trying to overwrite data yourself will miss data in areas of the drive reserved for various reasons by the firmware, and you don't have control over caches etc. ATA Secure Erase is your best bet for clearing all of those.
I think there's a problem that at least one drive claimed at an ATA level to implement Secure Erase, and then didn't actually perform an erase of the drive medium. I'll try to find the reference to that.
Wei et al. (FAST '11), discussing solid-state drives:
"Drive B’s behavior is the most disturbing: it reported that sanitization was successful, but all the data remained intact. In fact, the filesystem was still mountable. Two more drives suffered a bug that prevented the ERASE UNIT command from working unless the drive firmware was recently reset, otherwise the command would only erase the first LBA. However, they accurately reported that the command failed.
The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted to properly sanitize the drive."
https://www.usenix.org/legacy/events/fast11/tech/full_papers...
"Drive B’s behavior is the most disturbing: it reported that sanitization was successful, but all the data remained intact. In fact, the filesystem was still mountable. Two more drives suffered a bug that prevented the ERASE UNIT command from working unless the drive firmware was recently reset, otherwise the command would only erase the first LBA. However, they accurately reported that the command failed.
The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted to properly sanitize the drive."
https://www.usenix.org/legacy/events/fast11/tech/full_papers...
There's a good stack exchange post about ATA secure erase pitfalls too, how if you just do --secure-erase and not enhanced option then some SSDs will just compress the data and not actually wipe anything.
Found it: http://security.stackexchange.com/a/64480
Found it: http://security.stackexchange.com/a/64480
Who cares if it's NIST-approved? The NSA owns NIST entirely; if something is NIST approved it's probably a good reason to not use it.
The safe bet may be a line from authority itself: "Trust, but verify" as they say.
Right now, the only antidote to systemic weakening (potential or actual, intentional or through incompetence) of security is an auditing of code along with these standards and practices.
It's been mentioned before here and many places elsewhere, but the fork of OpenSSL by the OpenBSD folks and their complete scuttling of cruft, including FIPS 140-2 which required the backdoored Dual_EC_DRBG algo, is a good sign that at least some people are taking a proactive approach to security. In lieu of blindly following existing procedures, seeing what breaks in your work when subjected to extreme duress leads to better software and better practices.
Right now, the only antidote to systemic weakening (potential or actual, intentional or through incompetence) of security is an auditing of code along with these standards and practices.
It's been mentioned before here and many places elsewhere, but the fork of OpenSSL by the OpenBSD folks and their complete scuttling of cruft, including FIPS 140-2 which required the backdoored Dual_EC_DRBG algo, is a good sign that at least some people are taking a proactive approach to security. In lieu of blindly following existing procedures, seeing what breaks in your work when subjected to extreme duress leads to better software and better practices.
Also, DBAN doesn't touch sectors marked as bad.
I don't know why mumble/murmur doesn't get more love. I self host and that is how I keep up with friends from all over the world...
has anyone else noticed that HTTPSEverywhere does not appear to be available through addons.mozilla.org to Firefox users anymore?
It never was.
wow, my mistake in that case but i could have sworn i had found it there previously a year or two ago.
in that case, it seems a bit odd that HTTPS Everywhere isn't available via addons.mozilla.org but Privacy Badger is...
in that case, it seems a bit odd that HTTPS Everywhere isn't available via addons.mozilla.org but Privacy Badger is...
Since AMO doesn't do code signing, EFF says it's more secure to serve it from their own site. https://lists.eff.org/pipermail/https-everywhere/2014-April/...
makes sense and perhaps it's just an artifact of release schedules, but nonetheless interesting that privacy badger got the nod for AMO while HTTPSEverywhere did not
Was it ever?
I think that this would make people think they're secure while they are not...
You only fuckup once like the grugq says
You only fuckup once like the grugq says
I worked on this project and we've been quite concerned with this issue. I definitely hope people will come away with a clear sense of their risks and of what the tools do and don't do.
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!
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!
Regarding tracking mobile phones and privacy there is some good info in these IRC logs related to multilateration and U-TDOA, and that the precision of locating a mobile phone signal is comparable to that of GPS (given enough towers):
http://infobot.rikers.org/%23neo900/20140904.html.gz http://infobot.rikers.org/%23neo900/20140910.html.gz
http://infobot.rikers.org/%23neo900/20140904.html.gz http://infobot.rikers.org/%23neo900/20140910.html.gz
"DocScrutinizer05: note that a cellular device that's logged in to network doesn't need any fancy GPS to locate your postion down to 1m precision"It's a curious set of things you've chosen to communicate to users about the security of mobile phones. For instance, it's important to your page to tell users that phones make it harder to "replace the operating system". That's true, but from the vantage point of security, operating system replacements are mostly a tool for attackers, not defenders.
That entirely depends on your threat model.
If you are defending against somebody capturing your credit card number when you buy something online, replacing the OS is mainly done by the attacker.
If you are defending against a NSA-like agency flagging political discourse and discovering you and your friends, the most usual method for defending against those starts by replacing your OS.
If you are defending against somebody capturing your credit card number when you buy something online, replacing the OS is mainly done by the attacker.
If you are defending against a NSA-like agency flagging political discourse and discovering you and your friends, the most usual method for defending against those starts by replacing your OS.
It might be more accurate, though confusing for lay readers, to explain that replacing the operating system can both increase--by keeping more up to date than official updates might allow--and decrease--by deactivating security features that also prevent rooting--your security, even for a single given threat model.
I'll think some more about how we talk about that issue. If you have other comments on that page, I'd be happy to hear them too.
Thank you for your efforts on this guide. Hopefully, it will help those who want to preserve what's left of their privacy.
The site is not loading for me at all https://ssd.eff.org Wonder if the load is too high too soon.
Edit: Oops, now showing 504 Gateway Time-Out (nginx)
Edit2: It's back. Looks very well put together.
Edit3: Wow, this is extremely well put together. I especially like that the scenarios are crafted for each situation and isn't just "do this and you're fine". This is really a walkthrough rather than tutorial and I appreciate that a lot.
Edit: Oops, now showing 504 Gateway Time-Out (nginx)
Edit2: It's back. Looks very well put together.
Edit3: Wow, this is extremely well put together. I especially like that the scenarios are crafted for each situation and isn't just "do this and you're fine". This is really a walkthrough rather than tutorial and I appreciate that a lot.
I think it's been fixed now.
I'm rather color blind and have a hard time seeing the links. For example, I had to move my mouse over the text randomly until I found the link was "Surveillance Self-Defense".
When I'm reading the text on the detail pages, I also can't see where the links are.
For example, on this page I cannot see any links and have to search for them by moving my mouse over text until found. https://ssd.eff.org/en/module/introduction-threat-modeling
When I'm reading the text on the detail pages, I also can't see where the links are.
For example, on this page I cannot see any links and have to search for them by moving my mouse over text until found. https://ssd.eff.org/en/module/introduction-threat-modeling
A well-raised point. Not colourblind here, but as someone who remembers the days when visual cues were used, I feel your pain.
FWIW, I find using `tab` to bounce around links in the main text helps. Further than that, if you use `vi` on sundays, both pentadactyl and vimperator have a "hints" mode to navigate links by keyboard, which also helpfully highlights them.
It would be nice if web designers weren't such idiots about accessibility, but these options make fending for yourself a bit less frustrating.
FWIW, I find using `tab` to bounce around links in the main text helps. Further than that, if you use `vi` on sundays, both pentadactyl and vimperator have a "hints" mode to navigate links by keyboard, which also helpfully highlights them.
It would be nice if web designers weren't such idiots about accessibility, but these options make fending for yourself a bit less frustrating.
note to self, check if site is on hacker news front page before purging stale caches!
Also, if the site's dev is reading this, your print stylesheets still show the feedback link overlayed on the copy.