So, one of the difficulties w/ web-apps is that the 'code' is dynamic.
   You cannot implement a secure system if your attacker can change the
   code at any point in time. As is the threat model with backends, which
   attest to their 'trust me' security (a la lavabit, hushmail and so on)
   - so is the problem with client side code. If you build a web-app which
   does in-browser encryption and never sends the encryption key to the
   backend your attacker can simply modify the static JS source, DOM
   inject and XSS their way to your sweet sweet encrypted keys. Even if
   you audit your code at one point in time, you aren't certain it doesn't
   change with every request to the server.
   SO
   The first hurdle here is allowing users to reason about 'versions of
   web-app client assets' - if any part of the 'web-app client' relies on
   dynamic / non static JS, the application cannot effectively be
   'versioned' (unless those sub-components are similarly versionable). A
   subset of HTML and JS is defined (safe javascript language subsets are
   a fail) AND the JS VM is modified to 'lock in' its object defns after
   loading.
   So, then you can take the set of client side assets (html, js, images
   so on) hash each, add some version metadata and sign it. Version 1.
   Now, users with the browser mod / plugin can then see version 1 of the
   site. I can go out and post to CPunks statements like, Version 1 of
   el8notes never sends your plaintext password to the server and all of
   your communiques are encrypted before being sent to the server, and
   have them hold true both now and in the future.
   If you trust version 1 of el8notes, or you trust my assessments of
   el8mailer you can then tell your sweet plugin: Version 1 of el8notes,
   signature whatever is a-ok in my book.
   Of course, this might not even require the participation of content
   producers. Such a plugin could, in theory, create its own versioning
   for web assets & distribute those observations to a P2P network.
   -Travis

   On Wed, Sep 30, 2015 at 4:52 PM, Alfie John <[1]alfiej@fastmail.fm>
   wrote:

     On Thu, Oct 1, 2015, at 01:50 AM, Travis Biehn wrote:
     > What would be solid is if there were a browser module that did
     several
     > things: Eliminated JavaScript dynamic calls (eval, new function(),
     > setTimeout, setInterval, so on.) Eliminate 3rd party assets.
     Allowed
     > web assets to be signed. Allowed sets of web assets to be
     versioned
     > (and attested to by 3rd parties.)
     >
     > The combination of signing, versioning and lack of dynamic
     features
     > paves the way for uninjectable, client-side in browser
     > encryption/decryption. Something AFAIK we cannot do today. Is
     anyone
     > working on it?
     So Nginx has a built-in module "ngx_http_gzip_module" which does the
     following (if "Accept-Encoding: gzip" was part of the request
     headers) :
       - Sees request for "foo.html"
       - Checks if "foo.html.gz" exists
       - If so, serves that in place of the "foo.html"
       - If not, gzips "foo.html" on the fly
     What would be nice is an Nginx module which did the same type of
     thing,
     but for hashing the body:
       - Sees request for "foo.html"
       - Checks if "foo.html.sha256" exists
       - If so, serves "foo.html" along with "Content-Hash: <sha256>"
     header,
         taken from contents of "foo.html.sha256"
       - If not, serves "foo.html" along with "Content-Hash: <sha256>"
         header, but calculated on the fly
     This would be a cheap and easy way to get some form of content
     hashing.
     Thoughts?
     Alfie
     --
       Alfie John
       [2]alfiej@fastmail.fm

   --
   [3]Twitter | [4]LinkedIn | [5]GitHub | [6]TravisBiehn.com | [7]Google
   Plus

References

   1. mailto:alfiej@fastmail.fm
   2. mailto:alfiej@fastmail.fm
   3. https://twitter.com/tbiehn
   4. http://www.linkedin.com/in/travisbiehn
   5. http://github.com/tbiehn
   6. http://www.travisbiehn.com/
   7. https://plus.google.com/+TravisBiehn