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.
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 ~/
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.
>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.
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.
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.
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."
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.
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.
I think knowing that the NSA has some influence on NIST means you have to treat all actions by NIST as possibly the result of NSA pressure, and thus treat everything NIST does as suspect.
The only part that is not free anymore in GPG Suite is the Apple Mail plugin. So yeah, a plugin for a proprietary, closed-source mail client became proprietary.
The rest of the software collection remains Free Software.
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
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.
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):
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.
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.
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.
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.
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.
Also, if the site's dev is reading this, your print stylesheets still show the feedback link overlayed on the copy.