Last year danigm, which is a good friend of mine told me about this new project he was going to undertake, that he will present to CUSL (Free Software University Contest). It’s GECO (Password Manager), which will allow you to store your passwords online so that you can sync them in different computers.
Of course, storing all your passwords must be done in a very secure way if you don’t like surprises. The connection with the server must be secure (SSL?) so that no one else can see your passwords. But what’s more, are you going to upload your passwords in clear? No way buddy, that’s too risky. I wouldn’t trust all my passwords not even to my best friend, and even if so, what if the server gets compromised?
So the thing is, GECO is designed to have both a web and desktop client. The problem here is that current web browsers like Firefox don’t provide a standard framework to cipher and decipher data on the client. You’ve got SSL, but that only ciphers communications with the server, and that doesn’t solve the problem.
So what did my friend danigm do? He will be using Slow AES, a free software implementation of AES both in Javascript and python. Because he not only needs to be able to cipher and decipher text in the client via Javascript, but he also needs to ensure that when he uses the gnome desktop client developed in python, exactly the same AES algorithm implementation is used, so that what is ciphered using the web client can be deciphered in the desktop client and vice-versa.
The penalty of this is that this AES implementation is, as it name shows, slow. That’s not much a problem for ciphering small text strings like passwords. But I’m using his project as an example of what I think is coming next in the future. Because web applications are becoming common in our daily Internet life. There’s Gmail for example, which is an astonishing piece of software, and I’m tempted of using it replacing the good old KMail, but there’s one big feature that I’m missing: GPG.
I’ve tried the GPG Firefox plugin for Gmail, but it doesn’t work very well and besides, it doesn’t in other web browsers, like our all times favourite Konqueror. I’ve even used sometimes the Gtalk chat Gmail’s feature, which connects via Jabber to my IM contacts but also with my email contacts that use Gmail, which is handy sometimes, but being me an avid user of Kopete’s OTR plugin, I miss the security it provides. Finally, there are also some web services which provide online data
storage, an online hard disk if you want to name it like that. Google itself seems to be playing with idea of launching the Google Drive. Storing more
and more data online will make yourself much more exposed to potential privacy loss risk unless they are stored encrypted.
As a consequence, I think SSL is not enough any-more as a way to protect your privacy online: we need a comprehensive, well-designed framework for encrypting and decrypting data in the web browser. The next question is, then, how should be such a framework?
I have some ideas about that too: it should use standard implementations of well-known algorithms, like GPG and RSA. Probably a Javacript binding of lybcrypto should be fine. But we need also a way to ensure users that the clear data is not going anywhere else, meaning that the Javascript code is not playing tricks like copying the clear data and sending it to the web server, and the web server will only get the ciphered data and not in clear.
Now, there’s no easy way to solve that. In order to accomplish that last point we need to isolate the part of the page that deals with the ciphered data from the part of the page which deals with the clear data, creating a software jail for the later. The idea is having special html tags or tags with special attributes, which:
- Can be stylized using css (remember? it’ not 1999 anymore)
- Ciphered data can be processed securely and transparently in the web browser without compromising its security.
So normal Javascript code would see this data ciphered, and would be able to communicate with the server via usual ways: either sending a form via POST/GET or using AJAX. In the other hand, the Javascript code that deals with the encrypted data would see the data in the clear, but would not be allowed to communicate
with anyone, to send the data anywhere. That code is in jail. And for various purposes like updating the encrypted data, some information would be allowed to flow from the normal Javascript code to the jailed Javascript code, but not in the opposite direction; information would flow only in one way: from insecure code to secure code, not compromising security.
Of course, if such framework gets developed, standardised and deployed in most web browsers, even then some sites won’t make use of it at least for a long time. It’s not in Google’s best interest to let you cipher easily your email and IM conversations if they want to be able to show contextual ads, for example. But other services like GECO, or other kind of services we can’t even think of yet, will surely make good use of such a framework, and that’s the idea. I think the potential use of a Web Encryption Framework (or WEF for friends) is not only in common-place web applications and web services, but also in business web applications where security is a must.
Don’t get me wrong, I haven’t thought the actual details of this proposal. What you see here is all I’ve got at the moment. This is only one idea that I wanted to write about so that you people tell me what do you think about it, so now it’s your turn.
.
and I will be able to see face to face nice people with which I’ve been in contact with for a long time already.
. Tenemos la GPL en un altar y ésto nos puede llevar a confusión cuando no comprendemos realmente la licencia.
