Skip to content

Instantly share code, notes, and snippets.

@jakearchibald
Last active November 17, 2017 06:15
Show Gist options
  • 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.

@anselmh
Copy link

anselmh commented Feb 4, 2016

Nice, thanks. While you indeed cleared up a few things for me (thanks here) I find it incredibly sad to see such a bad-worded, emotional reaction here. My post clearly pointed out questions and it’s really sad to get replies that let me seem to be the dumb person while you don’t even try to understand my point of view or position as a user here.

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.

So, you still don’t tell me a place for the user but claim I’m spreading "FUD" here.
Speaking as developer here, I had expected a dedicated tab in the DevTools panel and no, getting the information via console is not what I expect (I require that actually). As you say, chrome://serviceworker-internals/ is not for public but internal usage and does not provide much value to a developer. What I expected was a tab that shows me the Service Worker script and the cached objects. But this one is really a minor concern of my article. – You haven’t removed any of my "FUD" here, whatever that means for you.

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

That is not entirely true. As described in my article, Firefox for example shows me a detailed list and asks me for permission for localStorage. And while we’re here. So from your point of view it’s okay that Service Workers are failing as well regarding user experience just because previous APIs do so. Fine, that’s your point of view but please in this case don’t invalidate my point of view.

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

Wrong. This is only true for Chrome (maybe also for Opera or other Chromium forks).

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?

I can only guess here because no one provides me a better explanation here. I assume this, because I can only empty it with the generic cache AS A USER. A USER doesn’t open the DevTools and empty single SWs here.

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.

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.

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

Storage usage appears in the site data menu.

Yes, thanks I know. I talked about CONTROL.

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.

Nice but it doesn’t fix the issue that is described here. But yay, at least we have a log for it. I don’t understand why you can’t agree on this being a problem and this making a point why a user choice (wheter it’s a browser setting or a confirmation notification – I don’t care) could make sense.

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. What’s your point here? That I have not researched every single aspect? Yes, that is what I wrote in the beginning of my post. My post just shares an OPINION and EXPERIENCE as a user. Do you think you make my experience better by saying I’m wrong and by mis-reading my sentences? I just don’t get what I’ve done to you personally to deserve such a bad written, offending answer. I’m out here.

@jakearchibald
Copy link
Author

Nice, thanks. While you indeed cleared up a few things for me (thanks here) I find it incredibly sad to see such a bad-worded, emotional reaction here.

Pretty much every sentence in your post was untrue, so it was difficult to see it other than a troll. Especially given a simple search would have led to the correct answer. Some of the sections seemed almost like a parody "Chrome does x. I have no evidence for this. Here are a number of follow-up statements based on this".

it’s really sad to get replies that let me seem to be the dumb person while you don’t even try to understand my point of view or position as a user here

You know my email address, you follow me on Twitter. If you had doubts for any of this you could have asked and I would have answered. Instead you wrote a public letter like you were blowing the lid of some conspiracy. You brought the emotion-cannon first :D

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.

So, you still don’t tell me a place for the user but claim I’m spreading "FUD" here.

Because I was replying to your statement about "developer tools", why would I bring up user tools? I do later bring up user tools when you ask about user tools. Can you see why I think you're being deliberately ignorant here?

@jakearchibald
Copy link
Author

As described in my article, Firefox for example shows me a detailed list and asks me for permission for localStorage.

http://jsbin.com/papucimebi/edit?js,console - just ran this in Firefox. No permission asked.

And while we’re here. So from your point of view it’s okay that Service Workers are failing as well regarding user experience just because previous APIs do so. Fine, that’s your point of view but please in this case don’t invalidate my point of view.

"failing" is your emotional opinion and is not generally held. If you had a general issue with origin storage, why was your post all about service worker?

Wrong. This is only true for Chrome (maybe also for Opera or other Chromium forks).

Yes, also true in Opera. Please direct your specific browser requests at the specific browsers.

I can only guess here because no one provides me a better explanation here. I assume this, because I can only empty it with the generic cache AS A USER. A USER doesn’t open the DevTools and empty single SWs here.

Right! It would be nonsense to say to users "Hey do you want to clear indexeddb storage? What about the service worker cache API?" - these mean nothing to the vast majority of users. As best we can, without confusing users, we allow them to clear everything, or deal with things on an origin basis.

@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