Open oliverdunk opened 1 month ago
tabUserData
tabUserActivityData
tabNavigationData
The current permission system mixes multiple purposes:
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:
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
.
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
2. Private
3. General
Similarly, history
permission can be further clarified, since history operations carry various degree of access (similar to the separation in clipboardRead
& clipboardWrite
).
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).
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.
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.
In most cases, permissions correspond to the namespace they grant access to. For example, the
scripting
permission is required to call functions in thebrowser.scripting
namespace likebrowser.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 thetabs
permission. However, this is not needed for most calls and rather grants access to sensitive properties like a tab'surl
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 thetabs
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
ortabs.sensitiveData
(seems slightly less desirable because this isn't a method).