1892524 - Mv3 add-on's request to always access a site is persisted even if requested wrt a site in Private Browsing

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Daniel Veditz [:dveditz]]

This was originally reported to our security alias:

My understanding of a Private Browsing windows is that traces of my browsing will be erased when the window is closed. I also understand that if I allow an extension to run in Private Browsing, the extension might persist and leak information. See https://support.mozilla.org/en-US/kb/extensions-private-browsing.

However, I find it surprising that the browser will persist permissions granted to extensions while in Private Browsing mode, which appears to be the case.

To reproduce

1. Install uBlock Origin Lite, without granting access to all site
2. Enable uBlock Origin Lite in Private Browsing
3. Open a Private Browsing window and navigate to example.
4. Select "complete" protection in uBO Lite [ed. from the toolbar button]
5. Grant permission for uBO Lite accessing example.com data
6. Close the Private Browsing window
7. Check the Permissions tab of uBO Lite in Add-ons Manager

This is an API associated with Manifest v3 extensions. There's confusion about who is asking for what, in which context. The reporter's expectations are reasonable, but don't match the internal model of what is happening.

There's an interesting point about step 4 depending on where the uBOL button is. If the uBOL button is left in the extension panel:

• when you open the panel the item says "Permission needed to read and change data"
• as you hover over the uBOL panel entry it says "Run for this visit only"
• clicking opens the uBOL control panel for that site

This "run once" permission is the one the browser knows is associated with a private window.

if the uBOL button is pinned to the toolbar most of that messaging is missing. When you hover (if you hover) it will say "Permission needed" under the name of the add-on. People would figure out the "run once-ness" because the green "attention required" dot will be back next time they visit

The action in step 4 is an interaction with the extension itself, which runs in a separate context outside any web page or concept of "Private Browsing". For most purposes, it's up to the extension to take care whether they are interacting with a private or non-private user context. In this case, though, the permission.request() extension API offers no way for an extension to request permissions "for a session", or "for this host in private mode".

Since the limitation appears to be in the Web Extension API I was not surprised that these results could be reproduced in Chrome.

Looks like we'd need to work on an API change and negotiate with other browsers, and then socialize it to extension authors to use the capability before this could work the way a normal person might assume.

Comment 1

[Daniel Veditz [:dveditz]]

Naively a user might expect that if the browsers know enough to attach the permission prompt to a Private Browsing/Incognito window then we should be able to infer that it's intended to be a temporary request. Or, even if you note that segregating similar-mode tabs into a "private window" was just a convention and not required by any specification, the extension action button is invoked in the context of a specific active tab that is or isn't private.