
Service Workers: an Introduction - mnazim
https://developers.google.com/web/fundamentals/getting-started/primers/service-workers
======
Animats
W3C: "Service workers create the opportunity for a bad actor to turn a bad day
into a bad eternity."[1] With service workers, cross-site scripting
vulnerabilities are forever.

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...](https://www.w3.org/TR/service-workers/#security-
considerations) [2]
[https://alf.nu/ServiceWorker](https://alf.nu/ServiceWorker)

~~~
asutherland
2 quick hopefully informative nits:

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](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](https://bugzilla.mozilla.org/show_bug.cgi?id=1220747)
if you want to follow-along, but start re-training your muscle memory now! :)

~~~
Animats
So Mozilla is making it harder for end users to find and kill service workers?

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.

~~~
asutherland
> So Mozilla is making it harder for end users to find and kill service
> workers?

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](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](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.

------
gfaure
Chrome also has chrome://serviceworker-internals.

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?

~~~
untog
> 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.

------
SimeVidas
Note that this is the low-level API. For most people, I think, the recommended
approach is to use libraries instead. Google itself has released sw-toolbox
and sw-precache. There’s also a web-push server module for push messages.

------
throwaway98237
You gotta see the humor in Google being of the opinion that a "service worker
is a script". I mean, we've all kinda expected that Larry Page is under the
assumption that we're all just subroutines running in his "matrix", but now
it's official.

~~~
gaur
I clicked the link half-expecting to find an article about pink-collar jobs,
but nope, just another badly named technical concept.

------
jonaf
This seems like a security nightmare. I sincerely hope there's a way to just
turn off "offline experience" in Chrome before service workers become
widespread. The browser is a dangerous place to execute software. I suppose
native apps can be just as insecure, but I worry about an ecosystem with many
neighbors (web apps, extensions, plugins, add-ons, etc) running in the same
process. It's much more likely one web app can steal my passwords from
LastPass, for example, without knowing it. The chain of vectors just feels
really dangerous.

~~~
chris_st
I think the line:

> 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.

------
cproctor
Oops. I thought this might be an attempt at rapprochement with their
janitorial staffs. Perhaps the wrong nomenclature for our new era.

------
Eun
Regarding HTTPs: there is [https://test.bi](https://test.bi)

~~~
voltagex_
Isn't this an egregious violation of most of the TOS / agreements for paid SSL
certs?

------
crudbug
I haven't read the specs, can you spawn multiple service workers on a single
page ?

If yes, what are the security measures to stop a rogue site to blow up your
browser ?

~~~
Klathmon
Only one service worker per scope, the newest kicks out any older ones.

------
voltagex_
How can I protect my browser against these things?

------
z3t4
this seems unnecessary as you need a html file and browser to bootstrap
anyway. There is more to it though, it can continue to run after the browser
has exited and intercept push mesages.

