1320796 - Support ServiceWorkers in Private Browsing Mode

Status: NEW

(Core :: DOM: Service Workers, enhancement, P3)

Description

[Zach Lym]

The MDN entry mentions that Service Workers are blocked in private browsing mode but does not state the reasoning.

Private browsing Shared Workers do not spawn per-tab instances and localStorage is shared across tabs.  Data stored in localStorage appears to persistent even when I close all of the tabs for a given origin.  What is special about Service Workers that would allow them to bypass the protections offered by private browsing mode?

I work on decentralized web polyfills and with Shared Workers being all-but-deprecated[0], Service Workers are the only viable alternative for some scenarios (such as decentralized web).  Maintaining a Firefox specific work around is irritating.

[0]: https://github.com/whatwg/html/issues/315

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Private browsing is designed not to write anything to disk.  As far as I know localStorage should not work in private browsing mode and if it does its probably a bug.  For example, neither Cache API nor IndexedDB work in private browsing mode.

Service workers are disabled in private browsing mode because they are impossible to use without setting up state tied to the origin and URL scope.  This inherently requires writing to disk.

We've discussed ways to use a memory "store" in private browsing mode, but it would be a high complexity cost for minimal pay off.  It hasn't been a priority yet.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

It appears localStorage works by virtue of existing http cache support for memory caching.  That doesn't work for our other storage targets like Cache API, though.

Comment 3

[Zach Lym]

Place everything in a temporary directory and wipe it when the private browsing session ends.  You could even encrypt the storage and keep the key in-memory, preventing recovery even if the machine shuts down unexpectedly and the file is extracted manually.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

The tentative plan is indeed to use temporary disk storage that's encrypted so that in the event of a browser crash the data will remain unreadable. We're starting with IndexedDB support for this mode of operation and bug 1639542 is the meta-bug for that. This is a longer term effort.

Comment 8

[xilonic]

Thanks Mozilla for giving web devs an easy way of identifying the private mode! Turns it it is as simple as if ('serviceWorker' in navigator).

Comment 9

[Matt Bierner]

Just chiming in with another motivating example: VS Code. On web, VS Code uses service workers sort of like virtual servers which power our webviews, so they are a core part of our product and not just a nice to have capability.

You can see this issue in VS Code for web by following these steps:

1. In a private window
2. Go to https://vscode-web-test-playground.azurewebsites.net
3. Open the image file in the explore (file.jpg) and see that nothing is shown. The root cause is that service workers are unavailable.

We don't believe there is a workaround for cases were service workers are unavailable, so we instead show an error message to users suggesting that they switch out of private/incognito mode

Comment 10

[Al Marks]

Adding another example, quite similar to the VSCode one in the previous comment.

For https://github.com/google/playground-elements (used at e.g. https://lit.dev/playground/) we use Service Workers to host a virtual server for live previews of code written by the user.

One of the advantages to using a Service Worker for this kind of use case, as opposed to a traditional backend, is that it doesn't require any of the user's input to leave the browser. It's unfortunate (and a bit ironic) that we may need to implement a fallback traditional server that would require sharing more user data, only for the incognito case.

Comment 11

[Al Marks]

Also note https://bugzilla.mozilla.org/show_bug.cgi?id=1601916 appears to be a duplicate of this issue.

Comment 14

[Daniel Roesler]

This is possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=1755167

In non-private mode, when the "Delete cookies and site data when Firefox is closed" is checked, service workers also fail to register (though curiously, navigator.serviceWorker is still present).

Comment 15

[Yannick Majoros]

This is an important feature: service workers are everywhere now, the lack of it in private mode makes firefox less relevant for browsing.

For OIDC authentication, service workers are a pretty secure solution (probably the most secure one), and this bug is really getting in the way.

Can the priority be raised?

Comment 16

[Yannick Majoros]

FYI, there is now a "known issue" added for Firefox at https://caniuse.com/serviceworkers . This is a serious issue, SWs are used on a lot of sites.

Comment 17

[Julien]

Hello, my 2 cents, I want my users to use Cache API so they can store some personal data on their device instead of storing those informations on my server. (which means more privacy and control for them)

It works fine on Chrome/Edge/Safari private modes even if it less performant than in regular mode as the cache needs to be rebuild from scratch every time they close the site.
But with Firefox, it does not work at all and I don't want to use localstorage which is too limited.

So for now, I advise my users to use another browser if they want private mode (and explain them what private mode is about)