Service Workers: an Introduction(developers.google.com) |
Service Workers: an Introduction(developers.google.com) |
Service workers install by drive-by, which is troubling. In Firefox, check "about:serviceworkers" to see what you have installed. Take a look. You probably have far more service workers active than you thought. There are supposed to be enough cross-site scripting restrictions to keep service workers contained to their origin domain, but some holes have been found. There was a successful service worker attack on Dropbox, since fixed. "If you run a site that serves user files with secret URLs from a shared domain, you need to look out for the Service-Worker: script HTTP header; if you see it, run for the hills."[2]
If an attacker can get one page loaded from a site being attacked, they then own all traffic between the user and the site. This has lots of attack potential.
[1] https://www.w3.org/TR/service-workers/#security-consideratio... [2] https://alf.nu/ServiceWorker
It's better to consult the living standard of the editor's draft over the TR ("TR is for the TRash" as they say). The security section has been fleshed out a lot, for example: https://w3c.github.io/ServiceWorker/#security-considerations
In Firefox, about:serviceworkers is in the process of being replaced by about:debugging. The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1220747 if you want to follow-along, but start re-training your muscle memory now! :)
The main difference between the TR and the suggested document is a weak "privacy" section, suggesting that the data stored by service workers locally should be flushed on user request. Mozilla currently does not allow service workers to run in incognito windows, which sort of complies with that.
I have no idea why Hampton Farms saw it fit to install a service worker. Furthermore, this isn't gated by a permission dialog like location services or plugin access?
No. The justification is that you'd need to prompt for additional permissions to do almost anything with a service worker, other than react to fetch event.
> It's a JavaScript Worker, so it can't access the DOM directly. Instead, a service worker can communicate with the pages it controls by responding to messages sent via the postMessage interface, and those pages can manipulate the DOM if needed.
gives me some hope that it's intended to be isolated from all other tabs (including the one that started it!).
There will be bugs, of course, but it looks to me like they're starting from a secure position, which gives me hope.
If yes, what are the security measures to stop a rogue site to blow up your browser ?
about:serviceworkers was added as a hacky debugging/introspection tool with the expectation that the developer tools team would integrate the functionality into more full-featured, supported tooling. about:debugging is that tooling.
For example, about:debugging's "Workers" tab (on nightly): - Displays all registered Service Workers as well as whether they are stopped, enables starting them if desired, and attaching a debugger to them. - Also displays any open (Dedicated DOM) Worker instances as well as SharedWorker instances and provides debugging support. - Listens for changes and updates the UI in real-time covering whether the ServiceWorker is stopped/running/installing/etc. (about:serviceworkers renders in a single snapshot).
I'm parsing your underlying concern to be that ServiceWorkers are a powerful new capability for websites and that you want to make sure they're not being brushed under the rug as a "don't worry about it, nothing could possi-blye go wrong" (https://frinkiac.com/caption/S06E04/442491) situation.
It's indeed the case that ServiceWorkers are powerful and they open up new avenues of potential misbehavior. While the fundamental event-driven design of SW's where they're only spawned by explicit user action (browsing the site providing the service worker) or user-approved site actions (push notifications which require explicit user approval), there's still the potential for bad actors. Implementers share these concerns, which is where efforts like https://github.com/beverloo/budget-api and (potential? not sure if this is actually implemented?) heuristics like Chrome generating a (desktop) notification if a ServiceWorker gets woken up by a push and doesn't generate its own notification come from.
And I believe it's in these goals of having browsers proactively inhibit bad behavior and make users aware of the behavior of sites they have implicitly or explicitly granted permissions to, that the best defense of users is found. Which is to say, there will always be UI that helps users find and kill service workers, but the design goals are likely to center around a) debugging, b) performance/"what on earth is making my browser/computer run so slow!", or c) storage/"where did all my disk space go?" rather than one of manual gardening of service workers like they are weeds that spring up and users are responsible for cleaning up after.