1662329 - Drop cookie permission requirement for receiving the cookieStoreId property as part of the tab details

Status: RESOLVED FIXED

(WebExtensions :: General, enhancement, P3)

Description

[JulianHofstadter]

AFAICT, there is no way to identify a tab as a container tab. Please add Tabs.tab.container, which would hold identifying information about the container.

Comment 1

[Tom S]

The cookieStoreId is used for this. You can use browser.contextualIdentities.get the user exposed information about a container.

Comment 2

[JulianHofstadter]

Ugh... this means we have to ask the user for another level of security, and even more intimidating, "cookies" at that. Would it be a security risk to just expose the name of the container in a Tabs.tab? This would allow filtering of tabs by container name.

Comment 3

[Shane Caraveo (:mixedpuppy)]

I feel like it's worth some consideration whether it is a problem to expose the IDs if the addon has contextual identities, rather than requiring both permissions. Cookies would not be usable without the cookie API. We'd need to have security input of course. Reopening for discussion.

Comment 4

[Rob Wu [:robwu]]

(In reply to JulianHofstadter from comment #2)

Ugh... this means we have to ask the user for another level of security, and even more intimidating, "cookies" at that. Would it be a security risk to just expose the name of the container in a Tabs.tab? This would allow filtering of tabs by container name.

The cookies permission does not trigger any permission warnings in Firefox. The cookieStoreId property requires the cookies permission because the ability to change cookieStoreId (with tabs.create and tabs.update) would enable extensions to change cookies of arbitrary container tabs.

The opaque value of cookieStoreId itself is not really sensitive, and comparable to incognito IMO. I'd be fine with exposing (read-only) cookieStoreId (i.e tabs.Tab and tabs.query(), NOT tabs.create()/tabs.update()) with the tabs permission instead of the cookies permission (either of those for backcompat).

But this feature request isn't just about cookieStoreId. It's asking for access to the name of containers. That's a valid request, and Piro has previously written a good comment about the need for a read-only version of the contextualIdentities API at https://bugzilla.mozilla.org/show_bug.cgi?id=1386673#c15 .

I would reject the specific request here (adding a "container" property to the tabs API), but I'm positive towards allowing extensions to access metadata of containers without permission warnings.

Comment 5

[JulianHofstadter]

(In reply to Rob Wu [:robwu] from comment #4)

The cookies permission does not trigger any permission warnings in Firefox.

Yes, I see now that this is true, and that surprises me. 1) I think as a user I would want to know about that 2) Why are they "permissions" if we are not asking permission from the user?

Comment 6

[Rob Wu [:robwu]]

We discussed this feature request with the team, and are willing to drop the cookies permission requirement for read-only uses of the cookieStoreId (e.g. tabs.Tab.cookieStoreId, tabs.query, webRequest events).

For tabs.create, we are inclined to require the cookies permission since the API can be used to change cookies of a specific container.

(In reply to JulianHofstadter from comment #5)

(In reply to Rob Wu [:robwu] from comment #4)

The cookies permission does not trigger any permission warnings in Firefox.

Yes, I see now that this is true, and that surprises me. 1) I think as a user I would want to know about that

In order to read or write cookies through the cookies API, the extension must have host permissions for that site, which does already trigger permission warnings. There is no need for an additional prompt.

2. Why are they "permissions" if we are not asking permission from the user?

Limiting the available APIs by default reduces the impact of unintentional security issues in extensions.
Having a fine-grained permission model with opt-in features, even without user-facing permission warnings, allows us to more efficiently identify extensions that use those APIs.

Comment 7

[JulianHofstadter]

(In reply to Rob Wu [:robwu] from comment #6)

In order to read or write cookies through the cookies API, the extension must have host permissions for that site, which does already trigger permission warnings. There is no need for an additional prompt.

2. Why are they "permissions" if we are not asking permission from the user?

Limiting the available APIs by default reduces the impact of unintentional security issues in extensions.
Having a fine-grained permission model with opt-in features, even without user-facing permission warnings, allows us to more efficiently identify extensions that use those APIs.

Makes sense, thanks for explaining all that.

Comment 8

[JulianHofstadter]

(In reply to Rob Wu [:robwu] from comment #6)

We discussed this feature request with the team, and are willing to drop the cookies permission requirement for read-only uses of the cookieStoreId (e.g. tabs.Tab.cookieStoreId, tabs.query, webRequest events).

Thank you much.

Comment 9

[JulianHofstadter]

(In reply to Rob Wu [:robwu] from comment #6)

We discussed this feature request with the team, and are willing to drop the cookies permission requirement for read-only uses of the cookieStoreId (e.g. tabs.Tab.cookieStoreId, tabs.query, webRequest events).

Just to be clear, this means no special permissions will be needed (eg, contextualIdentities) for read-only use of cookieStoreId id, correct?

Comment 10

[Rob Wu [:robwu]]

(In reply to JulianHofstadter from comment #9)

(In reply to Rob Wu [:robwu] from comment #6)

We discussed this feature request with the team, and are willing to drop the cookies permission requirement for read-only uses of the cookieStoreId (e.g. tabs.Tab.cookieStoreId, tabs.query, webRequest events).

Just to be clear, this means no special permissions will be needed (eg, contextualIdentities) for read-only use of cookieStoreId id, correct?

Yes. Changing this is easy, are you interested in submitting a patch? The following files need to be updated:

• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/ProxyChannelFilter.jsm#312
• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/parent/ext-tabs-base.js#665
• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/webrequest/WebRequest.jsm#268
• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/test/xpcshell/test_ext_webRequest_userContextId.js#18,48-78

To get started, see https://wiki.mozilla.org/WebExtensions/Contribution_Onramp

Comment 11

[JulianHofstadter]

(In reply to Rob Wu [:robwu] from comment #10)

Yes. Changing this is easy, are you interested in submitting a patch? The following files need to be updated:

• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/ProxyChannelFilter.jsm#312
• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/parent/ext-tabs-base.js#665
• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/webrequest/WebRequest.jsm#268
• https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/extensions/test/xpcshell/test_ext_webRequest_userContextId.js#18,48-78

To get started, see https://wiki.mozilla.org/WebExtensions/Contribution_Onramp

I'm sorry, I'll need to pass on this.

Comment 12

[Michelle Goossens [:masterwayz]]

Attachment: Bug 1662329 - Drop cookie permission requirement for cookieStoreId r=robwu

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eebe3c8164b9
Drop cookie permission requirement for cookieStoreId r=robwu

Comment 14

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/eebe3c8164b9