5 ms·

What contexts are they not permitted? I know that not all browsers support them, but are there other limitations?

by cash22 4y ago

chrismorgan 4y ago
One particularly interesting context here is that force reloading deliberately bypasses service workers. Try pressing Shift+F5 or Ctrl+Shift+R, and all of a sudden the button stops working until you do a regular, non-forced reload. Beyond that, I don’t know, but I would expect things like some lower-powered and -storaged devices rejecting service workers, and maybe privacy modes too, though in that case they could possibly be allowed with just background stuff neutered.
- jhugo 4y ago
  Given that the spec requires Service Workers to be optional, future Web specs & implementations may build upon that requirement, so writing your software to assume they always load is both brittle today and subject to unexpected breakage in future.
  - chrismorgan 4y ago
    De jure they’re optional, but if they are implemented everywhere or close enough to everywhere, they will de facto become mandatory, as has happened many times before. This is a large part of the reason why a large part of me wishes browsers wouldn’t provide service workers in Private Browsing/Incognito/whatever modes.
    - panzerboiler 4y ago
      I really don't understand your point. Since ServiceWorkers provide an offline experience and can be inspected from the client, they should be better than no ServiceWorker with respect to privacy.
      - chrismorgan 4y ago
        The main purposes of service workers are offline support and persistent background stuff. These are typically irrelevant in Private Browsing windows, which are designed for short-term use, and so service workers are almost always pure waste. (Not always, but almost always, and in line with the intended purpose and semantics of Private Browsing windows, though you can certainly use it in somewhat different ways.) It’s similar to a large part of the reason why Local Storage and Indexed DB were historically disabled in Private Browsing: why store stuff when it’s only going to be deleted immediately? Browsers have mostly headed in the direction of removing distinguishing features from their Private Browsing modes, partly to thwart detection of that mode, and partly because many things started to carelessly depend on the gated functionality. Firefox still doesn’t allow writing to Indexed DB (and only made Local Storage work far later than Chromium), and I’ve definitely encountered sites that just assumed it would work, and so fell over in early initialisation. And so for this specific subthread: it’s ossification at work. If something is supposed to be able to change but never actually changes, you find when you try to change it that you can’t do so any more because people have built too much stuff that assumed it wouldn’t change.
        panzerboiler 4y ago
        I don't agree that private browsing is for short-term use. You can use a temporary storage for how long it is needed (in my case up until the operating system or the browser crashes, aka almost never).
        chrismorgan 4y ago
        It is designed for that.
        panzerboiler 4y ago
        Where can I find such design specification? All I can find is https://w3ctag.github.io/private-mode/ https://w3ctag.github.io/private-mode/ and https://www.w3.org/2001/tag/doc/private-browsing-modes/ https://www.w3.org/2001/tag/doc/private-browsing-modes/ that tell nothing about the short duration of a private session. Some emphasis is put on the necessity that private mode and normal mode should be transparent to the user (i.e. not breaking any normal feature). It should be not possible to tell the two modes apart. If you break a feature like ServiceWorker you are providing a way to detect a private browsing session, and that is a bad thing, worse than anything a SW could provide, in my opinion.

What contexts are they not permitted? I know that not all browsers support them, but are there other limitations?

by cash22 4y ago

What contexts are they not permitted? I know that not all browsers support them, but are there other limitations?

One particularly interesting context here is that force reloading deliberately bypasses service workers. Try pressing Shift+F5 or Ctrl+Shift+R, and all of a sudden the button stops working until you do a regular, non-forced reload. Beyond that, I don’t know, but I would expect things like some lower-powered and -storaged devices rejecting service workers, and maybe privacy modes too, though in that case they could possibly be allowed with just background stuff neutered.

jhugo 4y ago
Given that the spec requires Service Workers to be optional, future Web specs & implementations may build upon that requirement, so writing your software to assume they always load is both brittle today and subject to unexpected breakage in future.
- chrismorgan 4y ago
  De jure they’re optional, but if they are implemented everywhere or close enough to everywhere, they will de facto become mandatory, as has happened many times before. This is a large part of the reason why a large part of me wishes browsers wouldn’t provide service workers in Private Browsing/Incognito/whatever modes.
  - panzerboiler 4y ago
    I really don't understand your point. Since ServiceWorkers provide an offline experience and can be inspected from the client, they should be better than no ServiceWorker with respect to privacy.
    - chrismorgan 4y ago
      The main purposes of service workers are offline support and persistent background stuff. These are typically irrelevant in Private Browsing windows, which are designed for short-term use, and so service workers are almost always pure waste. (Not always, but almost always, and in line with the intended purpose and semantics of Private Browsing windows, though you can certainly use it in somewhat different ways.) It’s similar to a large part of the reason why Local Storage and Indexed DB were historically disabled in Private Browsing: why store stuff when it’s only going to be deleted immediately? Browsers have mostly headed in the direction of removing distinguishing features from their Private Browsing modes, partly to thwart detection of that mode, and partly because many things started to carelessly depend on the gated functionality. Firefox still doesn’t allow writing to Indexed DB (and only made Local Storage work far later than Chromium), and I’ve definitely encountered sites that just assumed it would work, and so fell over in early initialisation. And so for this specific subthread: it’s ossification at work. If something is supposed to be able to change but never actually changes, you find when you try to change it that you can’t do so any more because people have built too much stuff that assumed it wouldn’t change.
      - panzerboiler 4y ago
        I don't agree that private browsing is for short-term use. You can use a temporary storage for how long it is needed (in my case up until the operating system or the browser crashes, aka almost never).
        chrismorgan 4y ago
        It is designed for that.
        panzerboiler 4y ago
        Where can I find such design specification? All I can find is https://w3ctag.github.io/private-mode/ https://w3ctag.github.io/private-mode/ and https://www.w3.org/2001/tag/doc/private-browsing-modes/ https://www.w3.org/2001/tag/doc/private-browsing-modes/ that tell nothing about the short duration of a private session. Some emphasis is put on the necessity that private mode and normal mode should be transparent to the user (i.e. not breaking any normal feature). It should be not possible to tell the two modes apart. If you break a feature like ServiceWorker you are providing a way to detect a private browsing session, and that is a bad thing, worse than anything a SW could provide, in my opinion.