Re: [w3c/ServiceWorker] Preventing server-forced updates (#822)

MicahZoltu left a comment (w3c/ServiceWorker#822)

> FWIW, there is some parallel work happening on [Web App Integrity, Consistency and Transparency (WAICT)](https://waict.dev/) ([draft specs](https://github.com/waict-wg)) to address the underlying topic. Since this is being driven by Mozilla (among other parties) and has an experimental implementation in Firefox Nightly, it seems more viable as a path forward to me.

I don't think this solves the same problem.  With that proposal you are still trusting a remote third party to check the authenticity of your files.  At best, this turns a page into a 2/2 multisig scheme where an attacker needs to compromise both the verification file supplier and the server distributing the app.  This *is* strictly better than having 1/1, but not by much since a deployment compromise likely enables an attacker to deploy both the new app *and* update the verification file.

What I believe is being asked for here is the ability for a web app to have a trust model that is similar to installed software, where you trust the distributor at the time you download some installer/package, and then you never have to trust that distributor again.  You can frontload your authenticity verification at install time, checking with your extended trust network, auditing the code yourself if you have the ability to do so, etc. and then you can rely on that one-time verification to be durable over time.

Currently, the web largely doesn't support this, especially with `file://` being locked down and treated like an insecure context in many scenarios.  Modern browsers do not *allow* a user to do a one-time trust operation when using an app, they require a continuous trust model.  The only way to switch that to one-time is run your own localhost fileserver and download and serve apps from it.  This of course is not a reasonable user experience.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/822#issuecomment-4729052100
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/822/4729052100@github.com>