Skip to content

Instantly share code, notes, and snippets.

@jakearchibald
Last active November 17, 2017 06:15
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jakearchibald/755326a20c51c23e1b21 to your computer and use it in GitHub Desktop.
Save jakearchibald/755326a20c51c23e1b21 to your computer and use it in GitHub Desktop.

My reply to https://helloanselm.com/2016/open-service-worker-questions/, which sets a new record for false statements per word.

The first thing I noticed after making sure that Service Worker are enabled (Chrome is behind flags)

No they're not. They've been in stable for over a year now.

was that I found no user setting or any hint in the developer tools about service workers

There's a service worker panel in the sources tab and in the resources tab. There's also chrome://serviceworker-internals/. The script also appears in the context dropdown (as iframes do). The script itself also appears in the sources panel. You can also type navigator.serviceWorker.controller into the console to inspect the controlling service worker for the page.

You would have found out about all this with very little effort.

It's slightly annoying that there's this amount of FUD already.

I had expected to either get a notification (as it’s being done for geolocation or other APIs)

Permission for what? When you register for a service worker it start up a script in another thread. In terms of privacy and security this is the same as new Worker and new SharedWorker.

The service worker can intercept requests, but that's no different in terms of privacy and security because the page itself can already make requests wherever it wants.

The cache API is entirely independent, you don't need a service worker to use it. But even then, it can't store anything different to IndexedDB except opaque responses, which aren't a security or privacy issue. The cache API is just storage that's optimised for matching and streaming.

or at least being able to debug it and see contents and details in the developer tools

"Cache Storage" is right there in the resources panel, along with all of the other storages.

As a user I expected to be notified about a page wanting to store things for offline or later usage on my machine

Between appcache, localstorage, indexeddb, cookies, even http caching, that ship sailed years ago.

As a user I expected to be able to delete the cache of Service Workers and with it the Service Workers itself

It can be cleared at a granular level within devtools, or you can clear it using the usual "clear browser data" dialog.

As a developer, I expect to be able to debug it and see Service Worker content in the developer tools in a dedicated view

This is already there, as I said.

there’s interest in making Web Notifications available to Service Workers

Not only interest, this has been developed and shipped in both Chrome and Firefox. It's been shipped for months.

Currently, both Chrome and Firefox seem (I have no evidence on that, sorry) to use the generic browser cache for Service Workers.

They don't. What makes it seem like this? Why would it matter?

you can only control Service Workers by deleting your entire browser cache

Not true. They're all over devtools and chrome://serviceworker-internals/. As durable storage lands and matures, we'll be able to explain to users which origins they have indicated desire to keep.

You can keep track of Service Workers by typing in this URL into Chrome: chrome://serviceworker-internals/.

Wait, you knew this? Why did you just say it wasn't surfaced?

Let’s just add a little detail on both of the internal browser control pages: None of them contains useful or semantic, let alone accessible markup here.

It's an internal debug page intended for Chrome developers. Sure it'd be nicer if were better design in terms of markup and visual, but the friendly face of this stuff is devtools.

So as the two big browser vendors that have implemented Service Workers so far agreed on using the generic browser cache for it

A fact you made up, with no evidence…

a user is out of control on what is stored on his/her device

Storage usage appears in the site data menu.

which is exactly what I’ve done to prevent Service Workers eating up my storage.

Service workers have no special rights to storage over indexeddb, localstorage etc. If storage limits are hit, origin storage is cleared across sites (unless the origin is marked as durable).

There seems no limit what Service Workers can register to store offline per Service Worker

Untrue. Goes in the same bucket as all origin storage (IDB, localstorage etc).

Ad providers or any malicious site can store JavaScript in Service Workers and might be able to track me and serve malicious code to me.

Already true with indexeddb, localstorage, cookies, http cache etc etc.

If someone compromises a usually trustworthy website, the attacker of course will register a service worker to be as persistent as possible in the user’s browser and can therefore alter the content of the website even if the server is not under his control anymore

This is why we have strict rules regarding the location and serving of the service worker. It needs to be same origin, have a valid JS content type, and it cannot control anything outside of the path it's contained in.

Service worker script requests also have a header (step 8) so they can be identified in logs, so you can deal with it if the worst happens. If that happens, all these shitty planets align, and it's served with a max-age of > 1 day, that service worker will live for one day at most.

Of course, this is only a vague assumption without any evidence here.

At last, a true statement.

I really hope that no mobile browser will implement Service Worker without providing more control to the user here

Oh no, back to the untruths. Already implemented and shipped in Chrome, Firefox, Opera.

@jakearchibald
Copy link
Author

This is very funny. In one sentence you point me to this resource to debug things and here you say it’s for Chrome developers only while there is no other chance besides emtpying all caches to remove all(!) service workers. DevTools afaik are page-related.

Yes there is. They're cleared by "Clear browsing data". If there's a browser not doing this. File a bug.

@jakearchibald
Copy link
Author

Storage usage appears in the site data menu.

Yes, thanks I know. I talked about CONTROL.

Yes you can control it there too. Please take a look.

@jakearchibald
Copy link
Author

I don’t understand why you can’t agree on this

I don't understand how you made a load of statements without even the basic fact checking. I guess we're incompatible. I also cannot understand how "Would you like this web page to run a service worker" would be useful in this case. You don't know if the site has been XSSd or not.

But yay, at least we have a log for it

Good use of sarcasm, but think about it for a second, if you know the source of the SW you can serve code to unregister it. Then you absolutely should fix the page XSS, and the method the attacker used to upload JS to your site.

@jakearchibald
Copy link
Author

I really hope that no mobile browser will implement Service Worker without providing more control to the user here

Oh no, back to the untruths. Already implemented in Chrome, Firefox, Opera.

Yes, on that’s definitely all mobile browsers etc

You said no mobile browser, I refuted that, and now you pretend you said all mobile browsers? I don't see how you think you can get away with that since the text is right there. You did this earlier too, you moved the goalposts from "developer" to "user".

I thought at first this was just laziness, but based on the above I can only conclude you're deliberately trying to waste my time.

bq3v771iqaaoy__

@WebReflection
Copy link

@anselmh I think Jake spent months (if not years) of effort to finalize and promote SW that maybe some little extra effort from your side to better document yourself, before writing such post, would have been better also as possible feedback.

Maybe this free online course could be a starting point: https://www.udacity.com/course/offline-web-applications--ud899

It's already explained in there how to debug, use it, the why the when and the how while this is the universally known place to quickly verify availability http://caniuse.com/#feat=serviceworkers

Best Regards

@jakearchibald
Copy link
Author

@WebReflection the annoying thing is I'd have answered everything if asked, even the easily searchable stuff. Really shitty to go with an open letter of "Here's something that just popped into my head that I'm going to present as fact…"

https://www.youtube.com/watch?v=wEolSjlcqng

@localnerve
Copy link

Thank you for the delightful amuse-bouche.

@gregorynicholas
Copy link

Lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment