Closed Bug 1662329 Opened 9 months ago Closed 9 months ago

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

Categories

(WebExtensions :: General, enhancement, P3)

Product:
WebExtensions
Component:
General
Type:
enhancement

Tracking

(firefox82 fixed)

Status:
RESOLVED FIXED
Milestone:
82 Branch
Tracking Flags:
Tracking Status
firefox82 --- fixed

People

(Reporter: julianhofstadter, Assigned: michelle, Mentored)

References

Details

(Keywords: good-first-bug)

Attachments

(1 file)

Bug 1662329 - Drop cookie permission requirement for cookieStoreId r=robwu
47 bytes, text/x-phabricator-request
Details | Review

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.

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

Status: UNCONFIRMED → RESOLVED
Closed: 9 months ago
Resolution: --- → INVALID

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.

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.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---

(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.

(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?

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.

  1. 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.

(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.

  1. 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.

(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.

Severity: -- → N/A
Priority: -- → P3
Mentor: rob
Keywords: good-first-bug

(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?

Flags: needinfo?(rob)

(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:

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

Flags: needinfo?(rob)
Assignee: nobody → michael
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/eebe3c8164b9
Drop cookie permission requirement for cookieStoreId r=robwu

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

Status: REOPENED → RESOLVED
Closed: 9 months ago → 9 months ago
status-firefox82: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
Regressions: 1665781
Summary: Add `container` property to Tabs.tab → Drop cookie permission requirement for receiving the cookieStoreId property as part of the tab details
You need to log in before you can comment on or make changes to this bug.