[the8472]

And the usual caveats for in-browser encryption apply. Namely that the trust model is no different from temporarily handing the encryption keys to the server.

In the latter case you trust the server to discard the keys after them being used. In the former case you trust the server to not transiently serving you javascript that exfiltrates the keys. In both cases this trust has not just to be extended once (which would make things auditable) but during every single transaction.

[jstanley]

> Namely that the trust model is no different from temporarily handing the encryption keys to the server.

True in this case, but not necessarily true. IPFS[0] allows you to ensure that the content you're receiving is correct (if you run a local gateway, which you should), because the URL is basically a content hash.

Therefore if you know the code is secure in the first place, you can always visit the same URL and know that you're getting "safe" code that doesn't exfiltrate the keys or plaintext. This then presents the same trust model as running code locally, except you don't need to install anything: you just visit the correct URL, and the code is running, with all the same trust as it would have if you downloaded it and kept it safe from modification.

[0] https://ipfs.io/

[AgentME]

Things get a little better if you use the new Web Crypto APIs. They can act kind of like a virtual hardware security module from a web page's point of view: with the web crypto API, you can create and use an encryption key (symmetric or asymmetric) whose key material can never be exposed to javascript. The browser keeps the key material completely private from the web page, but lets the web page use the key for certain crypto operations.

This means that if a website uses this and generates a key through the Web Crypto API on the first access, the user only needs to trust the site on the first access (to serve javascript that actually uses the Web Crypto API) in order to trust that the key material stays safe. (However, if the website admin turns evil and wants one of the user's files to be decrypted, they could serve javascript to the user that silently makes them decrypt the file for the admin, so the problem isn't completely solved.)

[emagdnim2100]

This is far from true. Client-side crypto at least gives you the ability to inspect outgoing network traffic. This should help to keep site operators honest.

The site operator can of course nefariously and randomly serve JS that exfiltrates keys, but users at least have the _ability_ to audit every single transaction.

[EGreg]

The Web is terrible for secure crypto, the best you can do is session secrets. However, they're working on a new standard that will finally allow you to store private keys securely. Until then, write your own native apps with webviews and browser extensions with local js that can be audited.

[lewisl9029]

> However, they're working on a new standard that will finally allow you to store private keys securely.

Could you link to some more reading on this?

[the8472]

That I assuming that every type network request is covered by available monitoring tools and that they are user-friendly. What if web browsers allow you to trigger DNS lookups without HTTP requests? That could already be used to exfiltrate data.

[JetSpiegel]

> What if web browsers allow you to trigger DNS lookups without HTTP requests?

Just include hidden links in the page, most browsers have some sort of pre-fetch optimization that does exactly that. I think they make HTTP connections on hover even.

[anonacct37]

Meta DNS prefetch tags allow this.

[twiss]

I've been working on using Service Workers to solve that problem: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...

I'm planning on making a library to make it easy to make a web app trust-on-first-use. The main blocker is https://github.com/w3c/ServiceWorker/issues/1208 (which would fix the non-critical but less-than-ideal issue described under "Service Worker lifecycle" in the blog post).

[projectant]

Trying to achieve the trust you are is very interesting.

I put up a simple, installable, progressive offline app of this crypto here: https://semocracy.com/

This app doesn't yet contain the mediations you talk about of checking the sw code against a 3rd-party reference and warning when an update doesn't match the reference.

Even considering the limitation you discuss when the new worker terminates async requests of the old worker, checking a public log is useful -- do you have any code or boilerplate I could plug in to achieve that?

Also, would the following be useful? The worker stores the 3rd party log / reference at intervals in local storage, and then when updatefound occurs, it doesn't need to make a network request, it can check (not perfectly) if the new sw code matches the stored reference. Sometimes there will be false negatives because the reference updated before the sw checked, but I think there would be no false positives. As long as the new worker can't get to localstorage before the old one checks, could be okay.

[twiss]

> do you have any code or boilerplate I could plug in to achieve that?

My implementation is at [0]. It basically fetches a list of files and hashes from GitHub, based on the commit in the X-GitHub-Commit response header (but you could just fetch master instead). You'd have to replace that github url at the top with [1], and update the two functions near the top. (If you're gonna fetch from master, also make the caching in getGitHubResponse less aggressive.)

Also take a look at main.js and main.css in that commit, it contains code to notify the user.

> it can check (not perfectly) if the new sw code matches the stored reference

The problem is that currently, there is no way to get the new service worker code without a request. Even if the sw.js file is in cache, there is still a race condition between the cache responding and the new sw terminating the old one, and more often than not, the new sw wins. That's why I was talking in [2] about an alternative solution of adding a property somewhere that gives you the new sw code.

What you can also do, and which I'm doing, is to fetch the sw.js file in the updatefound event of the page, and not of the old service worker. However, it's not strictly guaranteed that there is a (visible) page, for example, a third-origin website could embed yours in an iframe, triggering an update. [3]

[0]: https://github.com/airbornos/airborn-server/commit/a740276b#...

[1]: https://api.github.com/repos/dosyago-coder-0/dosycrypt-progr...

[2]: https://lists.w3.org/Archives/Public/public-webapps/2017JulS..., near the bottom

[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=773307, haven't filed a spec issue for this yet because https://github.com/w3c/ServiceWorker/issues/1208 hasn't gotten any replies yet