Open Bug 1320796 Opened 6 years ago Updated 23 days ago

Support ServiceWorkers in Private Browsing Mode


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





(Reporter: zachlym, Unassigned)


(Blocks 3 open bugs)


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.

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.
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.
Priority: -- → P3
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.
See Also: → 1608512

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.

Type: defect → enhancement
See Also: → idb-private-browsing
Summary: Service Workers Blocked in Private Browsing Mode → Support ServiceWorkers in Private Browsing Mode
Ever confirmed: true

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

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

For (used at e.g. 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.

Also note appears to be a duplicate of this issue.

Blocks: 1742344

This is possibly related to

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

Blocks: 1758442
See Also: → 1756974
No longer blocks: 1742344

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?

FYI, there is now a "known issue" added for Firefox at . This is a serious issue, SWs are used on a lot of sites.

Severity: normal → S3

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)

Blocks: 1807891
You need to log in before you can comment on or make changes to this bug.