erosman commented 3 months ago

Proposal: Incognito parameter in userScripts API

Background

There are occasions that userscript developers might want to limit their userscript to non-incognito tabs.

More importantly, users would benefit greatly from the ability to limit a userscript to non-incognito tabs, which improves the overall security of a userscript.

Firefox in MV 2 supported incognito control via cookieStoreId in contentScripts.register() & userScripts.register() APIs.

Replacement APIs in MV3 i.e. scripting.registerContentScripts() & chrome.userScripts do not support the parameter (yet).

FireMonkey has been supporting this option since 2021. Please note the following post for the use-case scenarios. (User Metadata is the feature of FM to set/unset/override parameters set in a userscript) See Also: [FireMonkey] should honor current container cookies

The feature has been requested of other userscript manager as well. See Also: [Feature] Ability to disable scripts in and out of Private/Incognito mode

While Firefox has been supporting incognito via cookieStoreId along with container support, for the sake of consistency between browsers, it might be simpler to add an extra incognito parameter to the aforementioned APIs.

Keyword

Use incognito in line with tabs.Tab

Proposal

Add optional boolean incognito which defaults to true

  incognito?: boolean,
  // if `false`, don't inject into incognito tabs
  // defaults to true

Rob--W commented 3 months ago

This feature sounds useful to not just the userScripts API but also the scripting API.

Although the proposal suggests a boolean incognito, there are actually three potential states of interest (could still be mapped to booleans with null, true, false):

Run everywhere (default)
Run in incognito / private browsing mode only.
Do not run in incognito / private browsing mode (only regular, i.e. non-private browsing mode).

While Chrome only recognizes "incognito" and "non-incognito", in Firefox the "non-incognito" case can be separated in even more cases ("container tabs"). Firefox enables extensions to identify separate cases by cookieStoreId, and there is already an issue tracking the addition of the cookieStoreId property in the scripting API at https://bugzilla.mozilla.org/show_bug.cgi?id=1764572.

xeenon commented 3 months ago

Similar to #611.

oliverdunk commented 3 months ago

I discussed this with the Chrome team. We're supportive, although feel quite strongly that this should be an enum ("INCOGNITO_ONLY", "DEFAULT_AND_INCOGNITO", "DEFAULT_ONLY" for example).

erosman commented 3 months ago

enum

1. Keyword

From the contextual point of view, using enum for incognito property might seem rather confusing i.e.

incognito = INCOGNITO_ONLY
incognito = DEFAULT_AND_INCOGNITO
incognito = DEFAULT_ONLY

It might be more logical to use an alternative keyword e.g.

context = "DEFAULT_AND_INCOGNITO"

2. Type

There can be 2 approaches:

string: One of "INCOGNITO_ONLY", "DEFAULT_AND_INCOGNITO", "DEFAULT_ONLY" _defaults to "DEFAULT_ANDINCOGNITO"
array: Any of "INCOGNITO", "DEFAULT" defaults to ["INCOGNITO", "DEFAULT"] in case of missing or falsy property, or empty array []

3. Case

As mentioned in #563, a consensus on case would be beneficial as modern APIs (as well as developers) tend to favour lower_snake_case e.g. ["incognito", "default"]

Permission

In any case (enum or boolean), since incognito script injection often requires a specific permission, browsers should have a fallback (instead of a hard throw) in case permission had not been not granted.

w3c / webextensions