Skip to content

Issue 34349 additional incognito key advice #44358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rebloor wants to merge 1 commit into
base: main
Choose a base branch
from
+16 −1
Open

Issue 34349 additional incognito key advice #44358

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion files/en-us/mozilla/add-ons/webextensions/manifest.json/incognito/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,22 @@ This is a string that can take any of these values:

- "not_allowed": private tabs and windows are invisible to the extension.

## Example
## Privacy considerations

If your extension needs to maintain the privacy expectations of the private browsing mode, omit the `incognito` key from your `manifest.json`. Omitting the key preserves the default behavior where the extension doesn't run in private browsing windows.

@Rob--W Rob--W Jun 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The blanket advice is not to delete the incognito key. The deletion of the key is conditional on the extension having implemented proper separation of private and non-private browsing data as needed.

The only reason for deletion of the property is if it is set to "spit" mode. In Chrome that results in stronger separation, but Firefox doesn't support "split", so we fall back to spanning behavior with the extension being disabled in private browsing mode (as already documented in the article).


If your extension uses `"spanning"` mode to access private and non-private windows, take care not to leak state from private to non-private browsing sessions. A common mistake is sending data from a content script running in a private browsing tab to an external server with a network request made from the background page. Because the background page shares cookies with the main browsing session, this can make private browsing activity linkable to the non-private session.

To avoid this, use [`credentials: "omit"`](/en-US/docs/Web/API/RequestInit#credentials) and [`cache: "no-cache"`](/en-US/docs/Web/API/RequestInit#cache) in any `fetch()` calls from the background page that may involve data originating from private browsing windows:

```js
fetch(url, {
credentials: "omit",
cache: "no-cache",
});
```

## Examples

```json
"incognito": "spanning"
Expand Down