5 ms·

> What if this is my first time loading? Like I said, it's trust-on-first-use. This is no different from installing a desktop app. > How do I know you're not

by twiss 9y ago

> What if this is my first time loading? Like I said, it's trust-on-first-use. This is no different from installing a desktop app. > How do I know you're not serving up new files that don't contain checks to be visitors? The Service Worker is installed on your own computer, and is still there the next time you open the web app. > How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly. https://developer.mozilla.org/docs/Web/API/Service_Worker_API https://developer.mozilla.org/docs/Web/API/Service_Worker_AP...

deleted 9y ago
[deleted]
jimktrains2 9y ago
You're assuming the old version of the service worker will be there and running. That isn't a good assumption. It will normally be there, but it doesn't have to be. There will always be circumstances where I'm downloading it for the first time, even in the same browser and computer. Also, step 7 on https://w3c.github.io/ServiceWorker/#update-algorithm https://w3c.github.io/ServiceWorker/#update-algorithm says that updating the service worker bypasses the service worker. How do you then validate that new service workers haven't been meddled with?
- twiss 9y ago
  That's blocked on https://github.com/w3c/ServiceWorker/issues/1208 https://github.com/w3c/ServiceWorker/issues/1208. However, there's also an alternative option to make updating the Service Worker unnecessary, by making a "stub" Service Worker which downloads, validates and executes the rest of the SW code. Then, whenever the "stub" Service Worker updates, it's likely a breach and we can warn the user accordingly.
  - jimktrains2 9y ago
    Code you can't update is normally an expensive liability in the case that it's not perfect. Also, then the stub service worker is subject to the same problem it's attempting to solve. I'm still left in a situation where I need to trust you don't mess up. You even say it yourself: > (Of course, we can't prevent the update, but we can at least try to convince the user to close the web app before it steals their private keys.) At that point, the game is up.

by twiss 9y ago

deleted 9y ago

[deleted]

jimktrains2 9y ago

You're assuming the old version of the service worker will be there and running. That isn't a good assumption. It will normally be there, but it doesn't have to be. There will always be circumstances where I'm downloading it for the first time, even in the same browser and computer. Also, step 7 on https://w3c.github.io/ServiceWorker/#update-algorithm https://w3c.github.io/ServiceWorker/#update-algorithm says that updating the service worker bypasses the service worker. How do you then validate that new service workers haven't been meddled with?

twiss 9y ago
That's blocked on https://github.com/w3c/ServiceWorker/issues/1208 https://github.com/w3c/ServiceWorker/issues/1208. However, there's also an alternative option to make updating the Service Worker unnecessary, by making a "stub" Service Worker which downloads, validates and executes the rest of the SW code. Then, whenever the "stub" Service Worker updates, it's likely a breach and we can warn the user accordingly.
- jimktrains2 9y ago
  Code you can't update is normally an expensive liability in the case that it's not perfect. Also, then the stub service worker is subject to the same problem it's attempting to solve. I'm still left in a situation where I need to trust you don't mess up. You even say it yourself: > (Of course, we can't prevent the update, but we can at least try to convince the user to close the web app before it steals their private keys.) At that point, the game is up.