3 ms·

Which is why encryption should be something that the browser handles internally. This is something I proposed recently: http://wiki.appleseedproject.org/doku.

Which is why encryption should be something that the browser handles internally. This is something I proposed recently: http://wiki.appleseedproject.org/doku.php?id=future:encryption:client-side_encryption http://wiki.appleseedproject.org/doku.php?id=future:encrypti... (Note, originally in this proposal, I support the idea of using a browser plugin, although now I think it should be functionality baked directly into the browser) By adding an encryption="" attribute to the html markup, and the user instructing the browser on how to utilize a private key on their system, you can encrypt and decrypt data in the browser, without requiring a trusted server.

starwed 15y ago
Something like that seems horribly hard to get right. Forget about cross domain scripting attacks, now you can't trust JS from the point of origin. Yet at the same time, you'll probably want it to be able to do all sorts of fancy AJAX-y stuff on the decrypted content. (Certainly on other parts of the page.)
- michaelchisari 15y ago
  You're right, in order to get the security right, you wouldn't be able to access the decrypted content with javascript. The browser would prevent that from happening. Yes, potential functionality would be lost, but that's always part of the trade-off for security. But I don't think the trade-offs would be detrimental, from a usability standpoint.
  - jbri 15y ago
    From a user perspective, how would you identify "safely" encrypted elements, in a way that can't by spoofed by the page rendering a nonencrypted element with appropriate styling?
    - michaelchisari 15y ago
      Could be the same way the browser identifies "safely" implemented HTTPS (ie, popup, icon, etc). A nonencrypted element with appropriate styling would not have the same browser-level indications that an encrypted element had.
thristian 15y ago
I haven't read your proposal, but your description sounds a bit like this: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/La...
- michaelchisari 15y ago
  Interesting, I wonder when that proposal first went up (mine was first posted to lists in February). Could be a case of synchronicity.
  - starwed 15y ago
    http://daviddahl.blogspot.com/2011/02/behold-domcrypt-extension.html http://daviddahl.blogspot.com/2011/02/behold-domcrypt-extens...

starwed 15y ago

Something like that seems horribly hard to get right. Forget about cross domain scripting attacks, now you can't trust JS from the point of origin. Yet at the same time, you'll probably want it to be able to do all sorts of fancy AJAX-y stuff on the decrypted content. (Certainly on other parts of the page.)

michaelchisari 15y ago
You're right, in order to get the security right, you wouldn't be able to access the decrypted content with javascript. The browser would prevent that from happening. Yes, potential functionality would be lost, but that's always part of the trade-off for security. But I don't think the trade-offs would be detrimental, from a usability standpoint.
- jbri 15y ago
  From a user perspective, how would you identify "safely" encrypted elements, in a way that can't by spoofed by the page rendering a nonencrypted element with appropriate styling?
  - michaelchisari 15y ago
    Could be the same way the browser identifies "safely" implemented HTTPS (ie, popup, icon, etc). A nonencrypted element with appropriate styling would not have the same browser-level indications that an encrypted element had.

thristian 15y ago

I haven't read your proposal, but your description sounds a bit like this: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/La...

michaelchisari 15y ago
Interesting, I wonder when that proposal first went up (mine was first posted to lists in February). Could be a case of synchronicity.
- starwed 15y ago
  http://daviddahl.blogspot.com/2011/02/behold-domcrypt-extension.html http://daviddahl.blogspot.com/2011/02/behold-domcrypt-extens...