28 ms·
I remember writing about Hushmail for Wired over 13 years ago (http://www.wired.com/techbiz/media/news/2000/03/34610?currentPage=all http://www.wired.com/techbi
by declan 13y ago
I remember writing about Hushmail for Wired over 13 years ago (http://www.wired.com/techbiz/media/news/2000/03/34610?currentPage=all http://www.wired.com/techbiz/media/news/2000/03/34610?curren...).
Don't you think technology has advanced a tiny bit since then? I'm thinking of Ajax, CSS, XHTML, XMLHttpRequest, DOM, JSON, HTML5, Chrome, Firefox, etc. The tools available today (and the platforms, and the machines) are far more capable.
Your second point is more interesting. Hushmail was ahead of its time in ~2000 when turning to client-side encryption via Java. But nobody really loves Java in the browser. So about five years later the company began to offer a webmail service with server-side encryption. Well, duh. That's vulnerable to a court order allowing the intercept of someone's passphrase the next time they log on. Which is what happened.
So you're right to say that Hushmail was vulnerable. But that was because of their server-side decision, and is unrelated to the vulnerability of properly implemented client-side encryption.
- superuser2 13y agoThe issue is that the client can be bugged. A provider can have a solid client-side encryption solution, but silently switch the client distributed to users of interest to an identical version which also phones home with their passwords. It's possible to verify that your code was signed with your provider's certificate, but how do you know it's the right client? How do you know it's the same one that's been peer-reviewed? We'd need a bulletproof way for the browser to check the hash of JavaScript before executing it. Unless you're going to copy/paste and MD5 the source for GMail every time you check it. The tools to be sure of the executable you're running really only exist for desktop software right now.