5 ms·

So the question becomes one of modifying the browser Javascript delivery mechanism to allow a more secure & discrete versions channel that would require user in

So the question becomes one of modifying the browser Javascript delivery mechanism to allow a more secure & discrete versions channel that would require user intervention. Or could there be another possible way?

bradleyjg 13y ago
There's already a mechanism in place for that in the form of javascript plugins/extensions/scripts which have to be explicitly installed. There's still problems because downloaded javascript can run in the same context and subvert the installed javascript. I believe tptacek has written a blog post elaborating on the problems with that. In a larger sense, I would push back against the web browser as a general purpose OS. We already have a few battle tested OSes who designers have put great thought and effort into these problems. If you insist on javascript, there's even node.js programs, albeit generally installed outside of the usual OS specific mechanisms. If you insist on HTML/css for layout and javascript for programming, I believe there are toolkits based on webkit, chromium and IE that let you create a standalone program embedding the respective browser engines. You can even do what mailpile is doing and embed a web sever in your client application and use your web browser as a client to the client acting as a server (though this last seems a little Rube Golderg-esque to me). But in any event downloaded and installed like a full fledged program rather than treating the exercise as though you were going to a special website.
- deleted 13y ago
  [deleted]
- mistercow 13y ago
  Web mail is one of those things that really, really makes sense though. I don't use it on my computer, but I'm glad it's there when I need to check my mail from any other device.
  - jrochkind1 13y ago
    And if I understand it right, the mailpile kind of 'webmail', you can't actually do that, it's not webmail at all, it's just running on your local computer, and the mail is stored on your local computer.
josh2600 13y ago
I'm just gonna leave this here... http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
- singold 13y ago
  I'm just gonna pick it up...
mistercow 13y ago
It seems like what we need is code signing for web pages and their assets. If you sign the app, you still have to trust the people making it, but you don't have to trust the server it comes from. This puts you in no worse of a position than an update to your non-web mail client. And if a web site suddenly switches to a new public key, the browser should do the same kind of thing as it does for expired SSL. It should be relatively easy to create a browser extension that does this in the meantime. Then what I'd like to see is a mail service that sends its source unminified, and then publishes the same code (with signature) on its server. That way you could easily verify that you were getting the canonical version of the code (and not a special compromised version that an attacker inserted for users on a special list), and anyone could look and see if it was doing something fishy (or broken).

bradleyjg 13y ago

There's already a mechanism in place for that in the form of javascript plugins/extensions/scripts which have to be explicitly installed. There's still problems because downloaded javascript can run in the same context and subvert the installed javascript. I believe tptacek has written a blog post elaborating on the problems with that. In a larger sense, I would push back against the web browser as a general purpose OS. We already have a few battle tested OSes who designers have put great thought and effort into these problems. If you insist on javascript, there's even node.js programs, albeit generally installed outside of the usual OS specific mechanisms. If you insist on HTML/css for layout and javascript for programming, I believe there are toolkits based on webkit, chromium and IE that let you create a standalone program embedding the respective browser engines. You can even do what mailpile is doing and embed a web sever in your client application and use your web browser as a client to the client acting as a server (though this last seems a little Rube Golderg-esque to me). But in any event downloaded and installed like a full fledged program rather than treating the exercise as though you were going to a special website.

deleted 13y ago
[deleted]
mistercow 13y ago
Web mail is one of those things that really, really makes sense though. I don't use it on my computer, but I'm glad it's there when I need to check my mail from any other device.
- jrochkind1 13y ago
  And if I understand it right, the mailpile kind of 'webmail', you can't actually do that, it's not webmail at all, it's just running on your local computer, and the mail is stored on your local computer.

josh2600 13y ago

I'm just gonna leave this here... http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/

singold 13y ago
I'm just gonna pick it up...

mistercow 13y ago

It seems like what we need is code signing for web pages and their assets. If you sign the app, you still have to trust the people making it, but you don't have to trust the server it comes from. This puts you in no worse of a position than an update to your non-web mail client. And if a web site suddenly switches to a new public key, the browser should do the same kind of thing as it does for expired SSL. It should be relatively easy to create a browser extension that does this in the meantime. Then what I'd like to see is a mail service that sends its source unminified, and then publishes the same code (with signature) on its server. That way you could easily verify that you were getting the canonical version of the code (and not a special compromised version that an attacker inserted for users on a special list), and anyone could look and see if it was doing something fishy (or broken).