Open freddyb opened 12 years ago
Way to go, freddyb! I think the functionality offered by your bookmarklet should be considered separately from one's opinion of the trustworthiness of the author of the code or the maintainer of the server. Instead think: regardless of my predictions about the behavior of that guy, this bookmarklet makes it so that I can run only this particular version of the code in my browser. That's potentially very useful!
Maybe the ZeroBin project should adopt the bookmarklet and suggest it to users.
Once you've delegated decryption (and perhaps other key steps) to your own bookmarklet, isn't every pastebin-like service (or indeed wiki-like page) a potential home for confidential pastes?
(For such a universal bookmarklet, you'd probably want your trusted code to make sure there's no other latent code in the page that can't wake up later and reveal your decrypted text or keys. That may be a quite hard check for code that arrives later via a bookmarklet.)
gojomo: yes, you are right from a security perspective. From a software engineering perspective, though, it is interesting how freddyb supplied the hash-comparing bookmarklet and sebsauvage supplied the encryption JS page and the two can work together to serve the user. Also very interesting is that freddyb's bookmarklet can work just as well with any JS page. It doesn't even have to abide by any API or coding conventions! So the user's ability to mix-and-match code from makers of code-authenticating-bookmarklets and makers of JS-web-pages is unimpeded.
IMHO, I think the best thing to do is to write a simple javascript script that test a ZeroBin installation. For example, call JavaScript function and check if their return value match with the exepected value. Also, we would think about monitoring ajax call when testing the function with a JavaScript code like this:
var oldSend = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.send = function() {
console.log(arguments);
oldSend.apply(this, arguments);
};
What do you think about my suggestion?
sidarape: if someone were substituting malicious code, they could make their malicious code pass any test while still leaking the user's plaintext. Tests are not sufficient to detect malicious code.
just as I was going to suggest running 256bit+ hashes on each routine individually...(to check which routine got hooked / updated changed) . :) I have looked at the code and compared it to what I know about DOM and wonder about key material or intermediate products being accessible after decryption being available to other more hostile javascript and wondering if practical or even possible to implement keyburns somehow ?
gwen
ps Hi Zooko!!
I like the idea, but better than bookmarklet will be userscript (if it can block "original" js if it detect something weird with page it will be perfect).
Hi,
I just had a small discussion on IRC regarding trustworthiness and code integrity. Entrusting ZeroBin with my ciphertext is a good step regarding improved confidentiality. This step revokes ZeroBin the authority to read my plain texts. That's good. However, ZeroBin hosters are still involved as a party that delivers me the code to decrypt the ciphertext. This means they are still empowered to intercept my private data, by hooking in the decryption function.
There are several possible steps to go on from here:
Extreme Paranoia: Use my own client to encrypt and decrypt data. ZeroBin is degraded to nothing but a storage provider, making all your nice UI work useless :(
Moderade Paranoia: The maintainer of ZeroBin is a pretty trustworthy guy, being nice about releasing cool software into the open source community, yadda yadda. I want to trust the maintainer, but not any random domain/server owner who hosts an installation of ZeroBin.
For Extreme Paranoia, I suggest using something completely different :P
For Moderate Paranoia I have written a simple JavaScript snippet (bookmarklet). The snippet retrieves the JavaScript source codes which are linked from the ZeroBin page and computes a SHA256 sum. If some external JavaScript is added or the existing JavaScript is modified, the bookmarklet will give a warning.
You can find the minified version here (for use in a bookmarklet, just add a new bookmark, enter 'javascript:' into URL and paste the rest afterwards.).
Here's an uncompressed version for code reviews/patching etc.
P.S.: Obviously, the SHA256 sum has to be changed for each version. Storing multiple hashes across versions is left as an exercise for the reader ;)