4 ms·

The normal complaint about crypto in JS is that, as a user, I cannot tell what JS is going to be delivered to me this time. Perhaps a security letter forced an

by cjg 9y ago

The normal complaint about crypto in JS is that, as a user, I cannot tell what JS is going to be delivered to me this time. Perhaps a security letter forced an update to broken crypto.

twiss 9y ago
In Airborn.io, I've solved this by installing some code in a Service Worker, which verifies all updates: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... The SW stays installed for when you open the web app the next time, in essence making it a trust-on-first-use scheme. I'm working on a library: https://github.com/airbornio/signed-web-apps https://github.com/airbornio/signed-web-apps It would be cool if other web apps (including Graphite?) could implement it too.
tasn 9y ago
Shameless plug: I created a browser extension to solve just that: https://github.com/tasn/webext-signed-pages/ https://github.com/tasn/webext-signed-pages/ It lets devs PGP sign their web apps and verifies those signatures. We use it for the EteSync (https://www.EteSync.com https://www.EteSync.com) web client.
saas_co_de 9y ago
This is solved: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... If you really care you can check the integrity hash on your scripts before using every time. That gives you more security than the update in your OS or Browser so they are a weaker link.
- peterwwillis 9y ago
  From https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... "OK, THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE FROM THE SAME SERVER SO THE CODE CAN VERIFY ITSELF." "This won't work." Your comment that "That gives you more security than the update in your OS or Browser" is patently false, I don't know why you'd suggest that.
  - saas_co_de 9y ago
    > THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE 1) Javascript is open source and you can audit the code you are running. 2) You can save the HTML of a page and run your local copy so that you know the JS can't change or check the hash every time Can you audit the code of your OS or Browser? In theory, if you are on Linux, but in practice it is too complex and voluminous for one person to do. A browser based app is usually in the thousands of lines of open source code running in a sandbox that is very easy to debug. The browser environment is the most secure and most easily user auditable environment there is. Unless you expect all of your users to build your app from source on linux that they built from source you can't really get better security. "Javascript Cryptography Considered Harmful" is old FUD. It was barely coherent when first published and the only legitimate arguments it had have been fixed.
    - deleted 9y ago
      [deleted]
    - webmaven 9y ago
      > Unless you expect all of your users to build your app from source on linux that they built from source You forgot to tack on "using compilers, etc., that they also built from source".

by cjg 9y ago

The normal complaint about crypto in JS is that, as a user, I cannot tell what JS is going to be delivered to me this time. Perhaps a security letter forced an update to broken crypto.

twiss 9y ago

In Airborn.io, I've solved this by installing some code in a Service Worker, which verifies all updates: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... The SW stays installed for when you open the web app the next time, in essence making it a trust-on-first-use scheme. I'm working on a library: https://github.com/airbornio/signed-web-apps https://github.com/airbornio/signed-web-apps It would be cool if other web apps (including Graphite?) could implement it too.

tasn 9y ago

Shameless plug: I created a browser extension to solve just that: https://github.com/tasn/webext-signed-pages/ https://github.com/tasn/webext-signed-pages/ It lets devs PGP sign their web apps and verifies those signatures. We use it for the EteSync (https://www.EteSync.com https://www.EteSync.com) web client.

saas_co_de 9y ago

This is solved: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... If you really care you can check the integrity hash on your scripts before using every time. That gives you more security than the update in your OS or Browser so they are a weaker link.

peterwwillis 9y ago
From https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... "OK, THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE FROM THE SAME SERVER SO THE CODE CAN VERIFY ITSELF." "This won't work." Your comment that "That gives you more security than the update in your OS or Browser" is patently false, I don't know why you'd suggest that.
- saas_co_de 9y ago
  > THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE 1) Javascript is open source and you can audit the code you are running. 2) You can save the HTML of a page and run your local copy so that you know the JS can't change or check the hash every time Can you audit the code of your OS or Browser? In theory, if you are on Linux, but in practice it is too complex and voluminous for one person to do. A browser based app is usually in the thousands of lines of open source code running in a sandbox that is very easy to debug. The browser environment is the most secure and most easily user auditable environment there is. Unless you expect all of your users to build your app from source on linux that they built from source you can't really get better security. "Javascript Cryptography Considered Harmful" is old FUD. It was barely coherent when first published and the only legitimate arguments it had have been fixed.
  - deleted 9y ago
    [deleted]
  - webmaven 9y ago
    > Unless you expect all of your users to build your app from source on linux that they built from source You forgot to tack on "using compilers, etc., that they also built from source".