Privacy discussion of PB mode

NEW
Unassigned

Status

()

Toolkit
WebExtensions: General
P5
normal
4 months ago
4 months ago

People

(Reporter: jkt, Unassigned)

Tracking

({privacy, sec-want})

56 Branch
privacy, sec-want
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 months ago
Currently our web extensions span across all normal tabs, PB mode and containers.

The risk is converting an extension from Chrome would have side effects like storing PB mode history without intentionally expecting to.

Some common extension types are likely all to be vulnerable (and not limited to):
- Tab management, suspending, reopening etc
- History showing extensions

Essentially by default content scripts are injected into all contexts, cookie APIs work in all contexts etc. This means without even meaning to game the user it would be easy to store PB mode websites much after the window is shown.

As the user isn't prompted about running in this mode and likely isn't aware of the shared nature this is an issue.

Following the email discussion regarding the exposure of PB mode and containers I was advised by the security assurance team I should raise a bug anyway.

Currently our extensions essentially run in "spanning" mode: https://developer.chrome.com/extensions/manifest/incognito However I would propose we try and move to "split" mode by default.

Other solutions would be:
- Isolate even further than chrome, preventing settings to be shared across storage.local/sync
- Provide a global toggle to turn off extensions in incognito (this could be the default to be off and an interim solution for 57)
- Require the user to manually opt in each extension into being "spanning" by default be "not allowed"

Sure there are privacy advantages to let extensions protect against PB mode, however "spanning" has little advantages from what I can see besides authing into a remote server. Privacy badger for example would take advantage from being "spanning" too where the list would only ever be stored for public tabs.

Making our default "spanning" lends itself to privacy leaks without intention, as mentioned by Andy this isn't a good direction to require review be the solution.
> As the user isn't prompted about running in this mode and likely isn't aware of the shared nature this is an issue.

When we built the site-assignment feature of the Containers add-on, we decided to warn users with a prompt which can be dismissed.

So, until we can implement "split" mode, isolate further than Chrome, or require the user to manually opt in each extension, I propose we first help the user understand that *ALL* extensions can access Regular, Private, *and* Container data.
This discussion doesn't need to be hidden. Extension authors need to be part of this. Originally the idea seemed that we exposed whether a given tab was private or not (or which container) and trusted the extension to do the right thing. With Legacy extensions that can do anything anyway that's all we _could_ do, and addons that didn't take private mode into account were considered buggy.
Group: toolkit-core-security
Keywords: privacy, sec-want

Updated

4 months ago
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.