Proposal: Add alias for tabs permission

[oliverdunk]

In most cases, permissions correspond to the namespace they grant access to. For example, the scripting permission is required to call functions in the browser.scripting namespace like browser.scripting.executeScript().

The second most commonly used API namespace (based on some rough data I scraped before joining Google) is browser.tabs, which leads to many extensions requesting the tabs permission. However, this is not needed for most calls and rather grants access to sensitive properties like a tab's url in Chrome and Firefox. In Safari, host permissions are required.

To avoid this, I propose adding an alias for the tabs permission which can be preferred going forward. Long term, we can gradually work to deprecate the tabs permission through small interventions like adding warnings when it it used. Shorter term, there is immediate benefit since we can use the alias in documentation.

The hardest part of this is naming. I don't have a preferred option yet, but options could include sensitiveTabData or tabs.sensitiveData (seems slightly less desirable because this isn't a method).

[tophf]

• tabUserData
• tabUserActivityData
• tabNavigationData

[hanguokai]

The current permission system mixes multiple purposes:

1. Web Store review
2. Namespace availability
3. Self-meaning
4. Warning users

For example, the tabs and webNavigation permission have the same warning message ("Read your browsing history"), but they are two different permissions at present. And the history permission has a similar warning message ("Read and change your browsing history").

The tabs permission is used to:

1. Web Store review ✔️
2. Namespace availability ❌ (but it can mislead beginners)
3. Self-meaning: inaccuracy (we want to fix it)
4. Warning users ✔️

The tabs permission is used to obtain basic information (url,pendingUrl, title, favIconUrl) of the tab, but cannot access or modify the content of web pages, so it is less capable than host permissions.

I prefer tabSensitiveData or tabSensitiveProperties.

[erosman]

From experience, users often misunderstand the concept of tabs as an overall object, versus tab content.
Messages & warnings about tabs are often interpreted as tab content by users.

Tab Sensitive Data is often seen as user/password entered in tab content and the warning is seen as an extension attempting to collect such sensitive data.

IMHO, it would be good to have a consensus on the terminology (for both the APIs and warnings) that would be more descriptive and informative (e.g. sensitive, private, etc).

1. Sensitive

• login data, ...etc

2. Private

• url (although some old sites might pass user/pass via URL), pendingUrl, title, favIconUrl
• Incognito/Private mode

3. General

• All other trivial data

Similarly, history permission can be further clarified, since history operations carry various degree of access (similar to the separation in clipboardRead & clipboardWrite).

• delete all/some history items
• add history item
• Search history

Among above operations, only the "Search" enables the extension to read all history content which has the highest sensitivity factor.
Adding or deleting (without searching first) doesn't involve having similar access to the sensitive data (e.g. the whole content of the history).

[carlosjeurissen]

Very much agree the tabs permission can lead to confusion. However as @hanguokai and @erosman mention the different purposes of permissions are very diverse and the tabs permission is far from the only one with ambiguous meaning. Take for example private window access, which is not even controlled with a permission currently. Preventing extension authors to request access to private windows.

This topic seems a good fit for a next manifest version, even though the idea of a next manifest version is controversial due to all controversies related to mv3, I believe it is the way forward for more breaking changes like this. In any case, very much advocating for the tabs permission to not be dropped inside mv3 and delay removal of the tabs permission to mv4.

[oliverdunk]

Thanks @carlosjeurissen for calling those things out.

In any case, very much advocating for the tabs permission to not be dropped inside mv3

Just to be clear, we definitely have no plans to do this on the Chrome side. For now the only thing we are proposing is introducing an alias (which would not generate new permission warnings) so developers can start getting used to a new permission and it's one less surprising change if we do decide to remove tabs in the future.

However as @hanguokai and @erosman mention the different purposes of permissions are very diverse and the tabs permission is far from the only one with ambiguous meaning.

For sure - this is the most common one I see but open to adding aliases for other permissions if we can make a similar case.