One of the things I like most about Firefox Sync is that all my browsing data is encrypted before anything leaves my computer. This wasn’t easy to do, there is a ton of engineering effort involved in scaling servers, maintaining all the crypto code for the client, and most of all, in making the experience smooth and inclusive of all types of users. The last one is especially hard since average users find it hard to grok the concept of two passwords (one that the server knows and another that only they know, which means if they lose or forget the latter we really can’t help them). I can’t think of any major services out there that offer the same feature (it is clear now that Dropbox does not encrypt user data in an irrecoverable manner EDIT: Peter points out in the comments that Chrome does allow you to encrypt your passwords), and for good reason: it is damn hard to pull off. All the more reason to be very proud of the Mozilla Services team.
The question of why we should bother doing all this has come up now and then. Users readily trust a lot of services with their personal data. Google could read your email if they wanted to, but they have a reputation to maintain and therefore have strict internal policies on who has access to what. Every other service that allows access to your data via a web interface operates in the same way. Surely, Mozilla is just as trustworthy, (if not more) than all of them. Why not get rid of client-side encryption to make the user experience really awesome and save many valuable hours of engineering and operations effort?
Additionally, if programs on the server-side (not humans) had access to unencrypted browser data, there are many more interesting services one could offer. If these services are compelling enough, until homomorphic encryption becomes usable commercially, they are a good argument for why you may not want to encrypt user data in a way that not even the server can read it. However, doing this also has some drawbacks…
between PSN and Dropbox, lots of reminders about why Firefox Sync feels like the solution we want to provide
—
Mike Connor (@mconnor) April 27, 2011Running production-quality servers is no walk in the park. There are so many ways in which a small misconfiguration can open up your service to all sorts of attacks. But what makes it even harder is a 0-day exploit in the web/application server you happen to be using, because then you have to wait for upstream to fix it. And then you have to make a judgement call, do you take your service down until a fix is released? Many would blame Sony’s technical “incompetence” for the PSN data leaks, but the fact remains that servers are run by humans, and humans make mistakes.
Keeping the user’s data encrypted provides everyone with an extra layer of protection. Not from the folks running the service, users probably already trust them, but from everyone else. And that doesn’t just include groups like Lulzsec or Anonymous.
Unfortunately, whether we like it or not, it is ridiculously easy for the government to strong-arm a technology company (especially one that isn’t giant enough to generate press) into releasing data for individuals, even for frivolous reasons. There has certainly been a lot of precedent for these kinds of “requests” from the government, and not all companies (Twitter, most famously) respond to them with user data, but that is harder to do for companies that don’t have that much money to spend on lawyers. In the real world, there are laws that require the government to obtain a search warrant before they are able to gain access to your physical belongings, and until we have the equivalent of a search warrant for an individual’s digital data; encryption provides a fine compromise.
If you can make your application work entirely client-side, using the cloud merely as a storage mechanism, you should. It’s worth the extra week you put into working out the crypto. JS is rapidly becoming fast enough to do a lot client-side, and with things like DOMCrypt, this realm is poised to get better with time.
Anant:
Great post! I also wanted to point out the DOMCrypt spec https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
Also, here is the Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=649154 and the WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=62010
Cheers,
David
“I can’t think of any major services out there that offer the same feature”
What, Chrome’s sync feature doesn’t count? You can elect to client-side encrypt all your data with that too. http://www.google.com/support/chrome/bin/answer.py?answer=1181035&hl=en-US
(I agree with the rest of your article, I just want us Chromium developers to get some credit for trying to let users do the right thing too.)
Peter, thats not all your data, thats passwords only, and the procedure is complicated and not default. Please correct me if I’m wrong there, but it seems to me that Chrome-ium does the bare minimum, gives a complex option for passwords as its relatively important and reserve itself the right to pick in your bookmarks, etc, for Google’s analysis.
With Firefox sync everything is encrypted and there is no other choice. Its not protected by a password mozilla knows either (chrome default for passwords.) there is no way around it. It is the right thing to do.
There’s also the issue of abuse by those who have so-called “restricted” access to your data. I seem to recall there being some fairly well-known cases of Facebook and Google employees abusing access to stalk people. Similarly, health-care employees peeking into records of famous people who came through their facility, and law-enforcement officers using access for malicious non-duty purposes. Sure, these people lost their jobs, but they’re almost certainly just the tip of the iceberg — the ones who didn’t get caught or got quiet wrist-slaps that the public doesn’t hear about.
I think it would be fascinating to collect a running list of these kinds of problems. Too often people think they don’t need to worry, because they’re not doing anything wrong or secret.
Sorry, but one more followup. You edited your post to note my prior comment (thanks!), but in at least Chrome 14 (haven’t checked whether this is in Chrome 13 also), we actually allow you to encrypt all your data client-side, not just passwords, which I think is important.
“If you can make your application work entirely client-side, using the cloud merely as a storage mechanism, you should. ”
I don’t think we’ve done this with Sync, though. It doesn’t “work” for lots of people. It’s complicated and different and difficult. That’s not “working” in my book.
Yes, I’m proud of our attempts to “do the right thing” here, but they fall short of what I consider a working application. Technically, it works. For users, it doesn’t really work that well. I’m a sophisticated users — there aren’t many in the world more intimate with browsers that I am (and you are) and even I have difficulty with the complicated sync setup.
I know there’s more we are doing to improve this, but it’s still more complicated than the “just works” of most other solutions out there and in the end, users will opt for what works for them over what’s best for them.
You raise some really interesting points, however I think there is one thing you missed, and it is actually quite pertinent. You said the following:
“and for good reason: it is damn [sic] hard to pull off.”
When in fact it should have been “…damned hard…”
Let me explain. “Damn” in itself is actually a verb. I damn you, and you damn me, etc. For some reason I consistently find it being used as an adjective without any kind of modification at all. Though I understand that this is due to the common usage and the overall loss of the -d suffix, like in “Iced Cream” and how it becomes “Ice Cream”. The cream has been Iced, people. However, Anant, I am certainly correct in saying that you call it “Mashed Potatoes” rather than “Mash Potatoes”, so just for the sake of total consistency, you should most likely call it “damned hard”. By the way, what the hell is your damned post about?