At the beginning of 2009 I posted a story in this very same blog where I proposed the creation of a web encryption framework to add support for end to end encryption in the web browser.
As it turns out, in 2010 I did my Computer Science final project about this subject, successfully implementing an HTML extension in KHTML that fixed what during one talk I was giving on the subject I coined to be the Server in the middle problem (project memory in spanish, code in github).
The solution I developed is just a proof of concept and not a final proposition. It basically extends the div element and input type=text element by adding two attributes, encryption=”gpg” and encryption-key=”<keyid>”, so that a div containing a gpg ascii encoded encrypted text is automatically decrypted shown the plaintext, and when a form with an encrypted input type=”text” element is sent, the data is automatically encrypted.
The key point about this proposition is twofold:
- It’s easy to implement as an HTML extension that could be standardized.
I have spent this weekend updating the code to work in recent KDE versions and creating an ready-to-go usb live opensuse-based  appliance called “Server in the middle” that shows Sweeetter, a microblogging application that allows users to exchange messages using the aforementioned HTML extension. Check it out! it’s for you to test it =)
SSL was the first step for securing the web. End to end encryption is the next, and it will allow cloud applications like web chats, web mails, and even office apps in the cloud with privacy being orthogonal to the servers used. When you chat using gmail with your peers using HTTPS, there’s someone else listening: it’s Google. It’s the server that is in the middle by design. When a Los Angeles employee sends an email to another peer using Gmail, it ain’t Google’s business. Perhaps if an end-to-end encryption scheme as proposed was available as a standard, Google would offer it in Gmail for businesses and for geeks like us ;-), and certainly other service providers would.
I will say it again: what I proposed is just a proof of concept. We could perhaps encrypt whole forms in a similar manner, or use a secure sandbox inside which plaintext data can be freely manipulated, but whose details are well known to the browser, are being recorded and the user can see in a details dialog, similar to the details of HTTPS connections in current web browsers, and the data going out from the sandbox is encrypted in a controlled and secure way.
The issue of privacy in the web will arise sooner or later. All the applications are jumping to the web wagon and some applications just need to be secure. It’s not only cryptonerds that need to take this seriously. Big companies that need their data to be secure will either continue using old-fashioned software, or request something better than we have now. This has already happened sooner than you might think (1999). Thus, we need to take this seriously, and begin standardizing and developing similar solutions to the one proposed for the shiny future that is about to come.
 BTW, SUSE Studio rocks!