1291841 - Implement contentSettings API for cookies

Status: NEW

(WebExtensions :: General, task, P5)

Description

[azrdev]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160630070928

Steps to reproduce:

I'm the author of a fennec addon that allows to whitelist websites for setting cookies (assuming cookies are disallowed by default by the user). The addon uses JS, no XUL, but for getting/setting the cookie permission I have to access nsIPermissionManager via chrome.

This API has no JS wrapper in the SDK, and apparently none in WebExtensions either. From the methods of nsIPermissionManager [1], I'd need at least testPermission() and add(), plus the appropriate constants from Ci.nsICookiePermission (and automatic type conversion, currently I have to mess with nsIURI objects).

Thanks for aswan on IRC pointing out what to report here!

Links to the addon:
<https://github.com/azrdev/firefox-cookie-whitelister/tree/sdk> (I rewrote it using the SDK, but still using chrome. master branch has the non-SDK bootstrap version)
<https://addons.mozilla.org/android/addon/cookie-whitelist-for-fennec/>

[1]: <https://developer.mozilla.org/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIPermissionManager>

Comment 1

[Andrew Swan [:aswan]]

As discussed on IRC, I think that general access to nsIPermissionManager is inconsistent with the security/permissions model of webextensions, but doing something more limited for cookie permissions seems reasonable (with a well thought out model for the extensions permissions of course)

Comment 4

[Todd Eddy]

I am the author of Permit Cookies 2[1] (source code[2])and also in need of a way to access cookie permissions.  Currently it's still using XUL overlays but wanted to port it to WebExtensions.  It looks like chrome.contentSettings[3] is the way to go in WebExtension API.  It's mentioned on Are We WebExtensions Yet[4] but don't see any mention of active bug reports on it.

[1] Permit Cookies 2: <https://addons.mozilla.org/en-US/firefox/addon/permit-cookies-2/>
[2] Source code: <https://github.com/vrillusions/permit-cookies>
[3] chrome.contentSettings doc: <https://developer.chrome.com/extensions/contentSettings>
[4] Are We WebExtensions Yet mention: <http://arewewebextensionsyet.com/#contentSettings>

Comment 5

[Caitlin Neiman [:caitmuenster]]

To be discussed at Jan 10 WebExtensions Triage meeting. 

Agenda: https://docs.google.com/document/d/18K97o1juaHSeYEkes1iMz8AayjuVkUuIK844ErGaa-c/edit#

Comment 6

[Kris Maglione [:kmag]]

We're agreed that implementing this portion of the contentSettings API makes sense. We'll consider implementing other portions as the need arises.

Comment 7

[The 8472]

To add details to the desired features: The cookie monster extension exposes several different site permission levels for cookies:

- default (whatever is set in about:preferences)
- deny
- allow temporarily (permission and cookies expire when browser is closed)
- allow session (permission persists, but cookies expire)
- allow

Since a default-deny policy in preferences currently cannot be overridden via extensions on a per-site level in firefox 57 this essentially makes the default-deny option unusable.

Comment 8

[Tony]

So how can a user set cookie settings on a per-site basis, after FF 57?

Comment 9

[blk]

Looking forward to the implementation of this. There is at least one extension (the 'CookieMonster' one listed above) I'd like to port to WebExtensions if given the chance.

Comment 10

[Alexander Dietrich]

I also wrote an extension that manages per-site cookie permissions through the permission manager. In addition, it manipulates the preferences "network.cookie.cookieBehavior" and "network.cookie.lifetimePolicy" in order to allow session cookies from any site temporarily. Both things are not possible with WebExtensions, as far as I can tell.

Comment 11

[Bob Silverberg [:bsilverberg]]

Are we still looking at implementing this, or is it going to be covered by bug 1363860, which will allow an extension to set the default permission for cookies, and then the user can interact with the permissions manager via the Firefox UI to grant or deny permissions for individual sites?

Comment 12

[Alexander Dietrich]

(In reply to Bob Silverberg [:bsilverberg] from comment #11)
> Are we still looking at implementing this, or is it going to be covered by
> bug 1363860, which will allow an extension to set the default permission for
> cookies, and then the user can interact with the permissions manager via the
> Firefox UI to grant or deny permissions for individual sites?

Using the Firefox UI for managing individual cookie permissions is a huge PITA, which is why (at least in my case) extensions were created to make it tolerable.

Comment 13

[The 8472]

Attachment: video comparing cookie monster vs. default UI

Seconded, the default UI for permission management is difficult to reach in comparison to the one or two-click approaches that extension actions or panels offer. I'm counting 8+ clicks to set a site permission in the standard UI vs. 2 clicks via cookie monster or 1 click with the extension mentioned in comment 0

Note that managing privacy options for individual sites can take more than one permission. For example if one has noscript + umatrix + a cookie manager installed one often has to configure all 3 for a site (ideally one would have those talk to each other, but that's a different story). So making those individual steps as low-friction as possible is important. And the standard UI simply will not offer that.

Extensions can also offer additional convenience for example reloading the site when necessary.

Comment 14

[Bob Silverberg [:bsilverberg]]

Fair enough. It sounds like it would be nice to be able to support extensions setting permissions for cookies on a domain-specific basis, which is what contentSettings is all about. Mike, do you want to take a look at this and see where it fits into your roadmap for the next few releases?

Comment 15

[Mike Conca [:mconca]]

I think that managing cookie permissions via a WebExtensions API still makes sense. I will keep it on the roadmap, but am not in a position to saying exactly when this will get implemented.

Comment 16

[blk]

[Tracking Requested - why for this release]: Any chance such an API could make it into Firefox 58/59 (basically ASAP)? Anyone who relied on old cookie-managing extensions like Cookie Monster or Self-Destructing Cookies has had their add-on go up in smoke with the release of 57 today.

Comment 17

[Kris Maglione [:kmag]]

No, there's no way this will make it into 58, and it doesn't qualify for tracking for 59.

Comment 18

[flack]

I've create #1434067 which it turns out is similar to what is described here, just wanted to add my two cents:

I'm one of the users who had a cookie manager until 57. All the permissions I have set with the extension are still working today (they are listed in the cookie exceptions). So browsing sites I regularily visit still works fine. However when I try a to a new service or app, I often find myself switching to another browser these days, because it's just too tedious to set up all the necessary permissions in FF just to try something out. So at least in my case, not having this feature lowers my FF usage