1390160 - Show that a WebExtension is managing how cookies are handled

Status: NEW

(WebExtensions :: Frontend, enhancement, P3)

Description

[Mark Striemer [:mstriemer]]

When an extension is controlling how the cookie settings or handled the user should see the name of the extension controlling it and be provided an option to disable the extension.

Mocks: https://mozilla.invisionapp.com/share/6HCITJKP8#/screens/242994351

Comment 1

[Mark Striemer [:mstriemer]]

We don't seem to implement anything that would prevent the user from changing these settings.

It looks like `privacy.websites.acceptThirdPartyCookies` would be the primary API but it isn't implemented in Firefox. There's another API `privacy.websites.firstPartyIsolate` which affects cookies but I don't see a related preference for that in about:preferences.

An extension could manually modify how cookies are managed using the `webRequest` and `cookies` APIs. I don't think there's any way we could detect this and reflect the status to the user.

The mocks show "Accept cookies from sites" being disabled, but there doesn't appear to be a related API for that preference on MDN or the Chrome developers docs.

Comment 2

[Bob Silverberg [:bsilverberg]]

This might end up being needed once bug 1363860 lands, so making that a blocker.

Comment 3

[Bob Silverberg [:bsilverberg]]

Attachment: Cookies preferences and two different settings

Comment 4

[Bob Silverberg [:bsilverberg]]

Thanks for the mockup Markus. There's a problem however.

There are going to be two different settings that can control cookie behaviour, which are represented by three controls on about:preferences. The one we plan to implement for bug 1363860 will control both the "Accept cookies from websites" checkbox and the "Accept third-party cookies" select box (labelled together as #1 on the attachment). The "Keep until" select box (labelled as #2) is controlled by a different preference. We don't have a plan to give extensions access to that at this time, but might in the future. Regardless, those two things (#1 and #2) can be controlled independently, so disabling that whole group if an extension is controlling #1 doesn't make sense.

I think it would be wise to consider that we might allow extensions to control #2 in the future, and therefore might need two separate messages about extensions being in control for #1 and #2 on the about:preferences screen.

Comment 5

[Markus Jaritz [:designakt] (UX)]

Why are we separating those? What do people using Firefox gain from that? 
(I do not understand why that granularity is needed, and I fear users might not understand that either...)

What sort of extensions do we expect to use those APIs... are there any examples? If not in Firefox, maybe in Chrome?

In the current UI it looks like #2 depends on #1. -> As soon as I unchecked the checkbox in #1, #2 is disabled. 
- Would that mean if an extension controls #1, it could block #2?

- Would #1 or #2 also control the button on it's right side, or the options behind it?

Comment 6

[Bob Silverberg [:bsilverberg]]

(In reply to Markus Jaritz [:designakt] (UX) from comment #5)
> Why are we separating those? What do people using Firefox gain from that? 
> (I do not understand why that granularity is needed, and I fear users might
> not understand that either...)

They control different things. One controls which cookies can be accepted, while the second one controls when accepted cookies expire. I suppose the reason they are linked in the UI is that if one disables cookies entirely via #1, then #2 doesn't actually do anything. I.e., it doesn't matter how long you allow cookies to stick around if cookies are disabled anyway. But I think we need to give extensions the granularity to control both #1 (which types of cookies are accepted) and #2 (when cookies expire), independently.

> 
> What sort of extensions do we expect to use those APIs... are there any
> examples? If not in Firefox, maybe in Chrome?
> 

Bug 1363860 (which introduces the WebExtension APIs to control these) was first opened to support Web Developer and QuickJava, but I imagine there are a number of "cookie management" and/or privacy-related extensions that would be interested in these. Maybe mconca can comment further on this.

> In the current UI it looks like #2 depends on #1. -> As soon as I unchecked
> the checkbox in #1, #2 is disabled. 
> - Would that mean if an extension controls #1, it could block #2?

I wouldn't design it that way. I think that two different extensions can control #1 and #2 independently. If the extension that controls #1 sets to to accept no cookies, then it renders the setting by the other extension redundant, but doesn't really break it.

> 
> - Would #1 or #2 also control the button on it's right side, or the options
> behind it?

No, this is similar to the Tracking Protection UI, where the buttons on the right are not really connected to the controls on the left.

Comment 7

[Mike Conca [:mconca]]

Some context - there are many extensions that manage(d) cookies: QuickJava, Self-Destruction Cookies, Cookies Manager+, and more. In addition, there are dozens of extensions that manage "privacy" in general, providing tools to manage trackers, ads, cookies, proxies, and more.  All told this represents many thousands of users of these types of add-ons.

Comment 8

[Mike Conca [:mconca]]

Based on the comments in bug 1363860 (https://bugzilla.mozilla.org/show_bug.cgi?id=1363860#c31):

It is true that the cookie behavior and cookie lifetime can be controlled independently. Making this clear to the user in about:preferences without turning it into spaghetti UI is tough, but this might only be a short-term issue as a redesign of the add-ons manager would take care of this.

Therefore, after talking to Markus, we feel an acceptable short-term solution is to display a generic "Extension XYZ controls your cookies" message that disables the entire control group, regardless of whether the extension controls cookie behavior or cookie lifetime.

In the unlikely case where two different extensions control each setting independently, the UI should pick one to display. If that one is uninstalled/disabled, display the other. Note that this case is extremely unlikely both logically (users generally only have a single extension to control cookies/privacy) and empirically (only 44 extensions out of ~8,000 on AMO even request the privacy permission today).

Comment 9

[Bob Silverberg [:bsilverberg]]

Thanks for the feedback, Mike. I had been thinking about this too, as well as bug 1363860, and I think the best thing to do is something similar to what Shane and I discussed for proxy settings. Instead of having two separate settings for controlling cookies (one for the behaviour and one for the lifetime), I suggest we have a single setting, which can control both of those. A consumer would pass an object into the API call which could indicate values for both of those things. This way, we can ensure that one extension has control over both things, which removes the complications for the about:preferences UI.

What do you think of that idea?

Comment 10

[Mike Conca [:mconca]]

(In reply to Bob Silverberg [:bsilverberg] from comment #9)
> Thanks for the feedback, Mike. I had been thinking about this too, as well
> as bug 1363860, and I think the best thing to do is something similar to
> what Shane and I discussed for proxy settings. Instead of having two
> separate settings for controlling cookies (one for the behaviour and one for
> the lifetime), I suggest we have a single setting, which can control both of
> those. A consumer would pass an object into the API call which could
> indicate values for both of those things. This way, we can ensure that one
> extension has control over both things, which removes the complications for
> the about:preferences UI.
> 
> What do you think of that idea?

I like it!

Comment 11

[Bob Silverberg [:bsilverberg]]

I've been working on this and I found a new wrinkle for which I need some UX advice. There's a select box above the rows which control cookies labelled "Nightly will", with options for "Remember history", "Never remember history" and "Use custom settings for history". When an extension overrides cookie behaviour, this select box shows the correct value, which is "Use custom settings for history", but if a user chooses "Remember history" from this select box it basically undoes the values set by the extension, but the extension still thinks it's in control, which is a problem.

I think, to follow the model we've used this far, the "Nightly will" select box needs to be disabled when an extension is controlling cookies, to prevent a user from manually changing pref values that are currently set by an extension. The challenge is that when an extension is controlling cookies, we only need to disable 3 of the items that are indented underneath the "Nightly will" select box, as shown on the invision mockup.

We disable the rows for "Accept cookies from websites", "Accept third-party cookies" and "Keep until", but we don't disable any other rows (e.g., we don't disable "Remember my browsing and download history", "Clear history when Nightly closes", etc.).

So, how can we best show that an extension is controlling the cookies, and also disable the higher-level select box for "Nightly will"? We can just disable it and still keep the message about an extension controlling cookies right above the row for "Accept cookies from websites" as in the mockup, but then a user doesn't know why the higher-level "Nightly will" select box is disabled, nor how to get control of it back.

Markus, please let me know what ideas you have.

Comment 12

[Markus Jaritz [:designakt] (UX)]

My assumption on that was, that on install, we would switch to "custom settings", but if the user changed that, we would also follow this intent to set the settings to what they pick. 
I agree that this might end in an awkward state for the extension which I have not considered. But I do think that we can not force custom on all history settings, just because an extension controls cookies.
I would hope that if the user switches back to custom, we could restore the settings they had in custom before... meaning back to what the extension set.

I would prefer to keep the extension active, but not let it change the cookie settings, if the user switched away from custom.

Comment 13

[Bob Silverberg [:bsilverberg]]

(In reply to Markus Jaritz [:designakt] (UX) from comment #12)
> My assumption on that was, that on install, we would switch to "custom
> settings", but if the user changed that, we would also follow this intent to
> set the settings to what they pick. 
> I agree that this might end in an awkward state for the extension which I
> have not considered. But I do think that we can not force custom on all
> history settings, just because an extension controls cookies.
> I would hope that if the user switches back to custom, we could restore the
> settings they had in custom before... meaning back to what the extension set.
> 
> I would prefer to keep the extension active, but not let it change the
> cookie settings, if the user switched away from custom.

The current model we use for a similar situation, which is extension controlled search engine, is that if a user manually changes the value then the extension is not disabled, but does loose control of the setting, permanently. 

In this example that would mean that a user can choose "Remember" from the "Nightly will" drop down when an extension is controlling cookies. If they do that, then the preference values will be reset to reflect the "Remember" choice, and the extension will lose control. This does mean that if a user switches back to "Custom" that the extension _will not_ automatically get control back - i.e., the prefs will not be reset to what the extension had previously set them to. That's the current model, and is doable with the code we have in place to deal with this situation. If we want the extension to regain control to the extent that the prefs revert to the values they had when it previously had control that will mean some more hoops we'll have to jump through. It's not impossible, but I wanted to raise the issue and see what we think is best.

In the current scenario, if a user disabled and then re-enabled the extension it would regain control, but that's not something an average user would think to do.

Comment 14

[Bob Silverberg [:bsilverberg]]

Another comment about this: I'm not sure we want to reinstate the extension's prefs if the user switches back to "custom", as that might not be expected by the user. They may have installed the extension ages ago and then switched to "remember", which changes the options away from what the extension set. If they switch back to "custom", perhaps because they want to change something else, they might not expect their cookie settings to be automatically changed to what they were when the extension was first installed.

Comment 15

[Markus Jaritz [:designakt] (UX)]

Attachment: Firefox-Preferences-CustomCookieSetting-notRemembered.gif

Tina can you please comment on that behavior in preferences:
I noticed that all custom settings are reset, if one changes to remember/never, and then back to custom.
Is it intended that custom history settings are reset once a person switches away from custom and back? Or should the custom settings be restored to what the person had set them previously?

Bob: If the current setting behavior is the desired behavior for preferences, we can align with that... which would mean it is intended that the extension does not get control back. (And probably should be disabled.) - Which we should expose to the user.

In extensions we have so far been operating under a model of: going back to what has been set before. i.e. If one disables a new Tab extension, new Tab is set to what it was before. (and not to it's default) That is why I thought this logic should apply here too... even if it is a setting being changed here.
(Let's see what Tina says)

Comment 16

[Stephan Sokolow]

Is there some technical reason that a distinction between "Custom" and "Extension-controlled" couldn't be made visible to the user?

That seems like the most intuitive option.

While, as a technical user, I'd prefer fine-grained control, the simplest improvement to the current direction discussion has been going would be to add another entry to the dropdown. Something like "Delegate history control to an extension" with a message appearing below it when selected to indicate which extension is in control.

Comment 17

[Markus Jaritz [:designakt] (UX)]

(In reply to Stephan Sokolow from comment #16)
> Is there some technical reason that a distinction between "Custom" and
> "Extension-controlled" couldn't be made visible to the user?
> 
> That seems like the most intuitive option.
> 
> While, as a technical user, I'd prefer fine-grained control, the simplest
> improvement to the current direction discussion has been going would be to
> add another entry to the dropdown. Something like "Delegate history control
> to an extension" with a message appearing below it when selected to indicate
> which extension is in control.

That might indeed be a simple solution. We would need to change a lot of the structure for it, as with this option, an extension only controls the cookie part of history settings... and I don't think we would want to hide the remaining options when an extension is in control of cookies.

Comment 18

[Stephan Sokolow]

(In reply to Markus Jaritz [:designakt] (UX) from comment #17)
and I don't think we would want to hide the
> remaining options when an extension is in control of cookies.

Agreed. That's why I began with " While, as a technical user, I'd prefer fine-grained control,"

It just seemed like a lot of discussion was happening around the assumption of magic behaviour for "Custom".

As a starting point for brainstorming on a proper solution, would it be possible to turn checkboxes for extension-controlled settings into tri-state checkboxes where the third state causes a puzzle piece icon to be added to the end of the label?

Comment 19

[Bob Silverberg [:bsilverberg]]

Attachment: Bug 1390160 - Show that a WebExtension is managing how cookies are handled

Work in progress! Not ready for review!


The latest version disables the setting if mode is changed away from custom, but has a couple of issues:
1. The re-enable extension message is displayed when this happens, because the pref was changed and we're currently on the screen.
2. It doesn't deal with reinstating the prefs if a user switches back to "custom".

Review commit: https://reviewboard.mozilla.org/r/214594/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/214594/

Comment 20

[Bob Silverberg [:bsilverberg]]

Comment on attachment 8944397 [details]
Bug 1390160 - Show that a WebExtension is managing how cookies are handled

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214594/diff/1-2/

Comment 21

[Bob Silverberg [:bsilverberg]]

I created a document for discussion of some of the UX issues raised about this, which can be found at https://docs.google.com/document/d/1rsMq5GhqMBOGnUn17p4lcfAnU9gdzWad3rKlWM3mBOE/edit?usp=sharing.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.