This is a follow-up to bug 645063. The bug summary and mockup in that bug specify changes we would like to make to the cookie prefs, but there is still some work to be done to decide exactly what language to use (see bug 645063 comment 3).

goal with the design is to create two sections, one that covers privacy out on the network, and one that covers local privacy on the machine. At the moment cookies are more network level privacy, but they appear amongst local things, like the list of downloads and form autofill. This would move cookies into a group called "tracking," because fundamentally cookies are way of having sites track you over time Mockup here: https://bug645063.bugzilla.mozilla.org/attachment.cgi?id=521850 The one concern that I have is that turning off first party cookies kind of breaks the browser. Eventually when we get site preferences all working well, we might want to change this command to "manage preference cookies (same site)" so that users can control this on a site by site basis. Mockup of the site prefereneces UI here: http://people.mozilla.com/~faaborg/files/firefox4Mockups/prefPaneWebSites-i2.png

This is a rather complex widget, and the patch was much more work than expected. But I like having all cookie-related options and commands tightly together, except for the "Keep until" menu, which you have to open to see the current value. We don't have menuitems type "checkbox" or type "radio" yet in preferences UI, and neither work out of the box. I made the former work in general, and used onsync{from|to}preference for the latter - not sure if it's worth moving that to preferences.xml. Since the Cookie button is outside the History box, its settings don't affect the remember/dontremember/custom state anymore, so you're still in "remember" mode even if you changed some of the cookie prefs, and manually checking "remember" doesn't reset the cookies prefs to accept all/keep forever anymore. The only exception is that the "Keep until" menu is disabled in dontremeber mode or when the start-in-private-browsing checkbox is checked (in updatePrivacyMicroControls). Downside is that the menu doesn't display the current state ("keep until I close") anymore. I could leave the menu enabled, and only disable the "keep until they expire" and "ask me every time" menu items. The Cookies button is below the "do not track" checkbox and not indented like in the mockup. Prefwindow tests pass locally.

Does this patch handle the dependency of the "Keep until" menu entries to the chosen status for permanent private browsing correctly?

Yes, at the end of updatePrivacyMicroControls(): The "Keep until" menu is disabled if either the privateBrowsingAutoStart checkbox is selected, or cookies are disabled (network.cookie.cookieBehavior pref == 2). No need to select the "keep until I close Firefox" value in that menu since you can't open the menu anyway. The network.cookie.lifetimePolicy pref isn't changed in private browsing autostart mode, but that doesn't happen in the current, unpatched state of the code either. I'll add accesskeys to the "Keep until" menu, and remove the dump() in the next version of the patch.

By the way, try builds are available from http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/steffen.wilberg@web.de-78eb9982c97d/

we have had a long standing bug open to integrate storage UI controls with cookies since they can act as another form of cookie. Now would be a good time to address that bug as well. See: [Bug 449981] storage UI should look and act alot like cookie UI

the site preference mock up at http://people.mozilla.com/~faaborg/files/firefox4Mockups/prefPaneWebSites-i2.png accommodates the idea of moving storage preferences near to cookies; but like DNT, its a kind of thing and would be good to keep it separate. we so we have things the browser stores that provide better interaction with sites to allow "personalization" of the content you recieve from the site like: first party cookies (the site you are visiting) storage (additional data from the the site you are visiting) third party cookies (from advertisers that place ads on sites you visit) Alex mentioned "The one concern that I have is that turning off first party cookies kind of breaks the browser." but that's true of all these things. its all true that "fundamentally all these things are way of having sites track you over time" that's the education and choice that we need to surface to the user. On the other hand, DNT is a "new thing". Its a beacon, alerting websites and advertisers that users don't want to be tracked. Its a way of telling sites and advertisers to provide a good experience when visiting a site, but "don't break the experience", while doing everything necessary preserve the privacy of the user.

it might also be an interesting exercise to do a bit of brainstorming about how the features of ad block plus could be tightly integrated into all this in case we also wanted to move in the direction of providing a service like that. This would save us from having to redesign this area again.

This bug should not address anything else besides the cookie controls. Other improvements can be handled in their own bugs.

Comment on attachment 524902 [details] [diff] [review] patch v1 > prefsForDefault: [ > "places.history.enabled", > "browser.download.manager.retention", > "browser.formfill.enable", >- "network.cookie.cookieBehavior", >- "network.cookie.lifetimePolicy", I don't think this change is correct. Please read the comments before the array declaration. This breaks the correct initialization of the remember history settings combo-box. >- // select the accept cookies option >- document.getElementById("network.cookie.cookieBehavior").value = 0; >- // select the cookie lifetime policy option >- document.getElementById("network.cookie.lifetimePolicy").value = 0; These changes are correct according to the mockup, but conflict with what I said above. :( > // select the clear on close option > document.getElementById("privacy.sanitize.sanitizeOnShutdown").value = false; > break; > case "dontremember": > pref.value = true; > break; > } > }, > > /** > * Update the privacy micro-management controls based on the > * value of the private browsing auto-start checkbox. > */ > updatePrivacyMicroControls: function PPP_updatePrivacyMicroControls() > { >+ let disabled = this._autoStartPrivateBrowsing = >+ document.getElementById("privateBrowsingAutoStart").checked; >+ > if (document.getElementById("historyMode").value == "custom") { >- let disabled = this._autoStartPrivateBrowsing = >- document.getElementById("privateBrowsingAutoStart").checked; >- this.dependentControls >- .forEach(function (aElement) >+ this.dependentControls // might be wrong for keepCookiesUntil, but we'll >+ .forEach(function (aElement) // correct that below > document.getElementById(aElement).disabled = disabled); Nit: please move the comment to the line before the statement. > >- // adjust the cookie controls status >- this.readAcceptCookies(); >- document.getElementById("keepCookiesUntil").value = disabled ? 2 : >- document.getElementById("network.cookie.lifetimePolicy").value; >- > // adjust the checked state of the sanitizeOnShutdown checkbox > document.getElementById("alwaysClear").checked = disabled ? false : > document.getElementById("privacy.sanitize.sanitizeOnShutdown").value; > > // adjust the checked state of the remember history checkboxes > document.getElementById("rememberHistory").checked = disabled ? false : > document.getElementById("places.history.enabled").value; > document.getElementById("rememberDownloads").checked = disabled ? false : > this.readDownloadRetention(); > document.getElementById("rememberForms").checked = disabled ? false : > document.getElementById("browser.formfill.enable").value; > > if (!disabled) { > // adjust the Settings button for sanitizeOnShutdown > this._updateSanitizeSettingsButton(); > } > } >+ >+ // adjust the keepCookiesUntil state even in remember/dontremeber mode >+ let cookiePref = document.getElementById("network.cookie.cookieBehavior").value; >+ let keepCookiesUntil = document.getElementById("keepCookiesUntil"); >+ dump("disabled: "+disabled+" cookiePref: "+cookiePref+"\n"); >+ if (disabled || document.getElementById("network.cookie.cookieBehavior").value == 2) >+ keepCookiesUntil.disabled = true; >+ else >+ keepCookiesUntil.disabled = false; And here you're making the keep until box dependent on the value of the remember history combo-box... I think this patch really needs to receive a full UI-review before being submitted for code review. I'm not sure if all of the UI interactions are implemented correctly. I'll f- for now, not having read the rest of the patch. BTW, any chance you could do this in multiple patches? This patch is extremely hard to review, especially the test changes. Could you do this across several patches, each containing one logical change? That would make it much easier to review. :-)

(In reply to comment #10) > Comment on attachment 524902 [details] [diff] [review] > patch v1 > > > prefsForDefault: [ > > "places.history.enabled", > > "browser.download.manager.retention", > > "browser.formfill.enable", > >- "network.cookie.cookieBehavior", > >- "network.cookie.lifetimePolicy", > > I don't think this change is correct. Please read the comments before the > array declaration. This breaks the correct initialization of the remember > history settings combo-box. That's by design, at least if I understand the design correctly... Moving Cookies out of the History section means that Cookies are pretty much independent of the global Remember menu list. For example, if cookies are disabled, the Remember menu list will still show Remember if the remaining setting (history, downloads, search and form history) are at their default (enabled) settings. Somewhat different is the global dontremember setting: you can still enable/disable cookies independently, but the Keep Cookies menu is disabled, because cookies will be removed at the end of the session; that's because dontremember means private browsing autostart, as you can see when you switch to custom: the privateBrowsingAutoStart checkbox is selected. There's no change to Firefox 4 in this regard (set dontremember, then custom: you can still twiddle the cookie settings, but the keep until menulist is disabled). > I think this patch really needs to receive a full UI-review before being > submitted for code review. I'm not sure if all of the UI interactions are > implemented correctly. Yep, I'll pester the mockup creator with that ;-) > BTW, any chance you could do this in multiple patches? This patch is extremely > hard to review, especially the test changes. Could you do this across several > patches, each containing one logical change? That would make it much easier to > review. :-) The changes are somewhat hard to disentangle. I could split 1. moving all cookie options, but keeping the checkboxes, buttons, and menulist; 2. changing that into the button. The first patch would still contain the extensive changes to disentangle cookies from the global menu list. Most of the test changes are a result of this disentanglement! The second patch would be rather small, containing all the preferences.xml changes plus changes from e.g. 'control.checked' to 'control.hasAttribute("checked")' because of the menulist to menu change.

Note that the original design meant for the "Remember" entry to show when the default settings for Firefox are in effect, "Don't Remember" to show when the default settings for permanent PB are in effect, and "Custom" to show in other cases...

Sure, and that's because in the original (still shipping in Firefox 4) design, the cookie prefs are inside the History section and below the global remember/dontremember/custom menulist. This global menulist would still rule the cookie prefs if the new Cookie button was to be in the same place as the old cookie controls. But since the Cookie button is not only torn out of the History section, but is now located above it in the Tracking section, I would find it surprising if the menulist would still magically twiddle with the cookie prefs. Also see the top left image of the mockup: the menulist is set to remember, and the description says: "Minefield will remember your browsing, download, form and search history". The current "and keep cookies from Web sites you visit" has been removed. That's because you can now set your cookie prefs independently from the global menulist.

>That's by design, at least if I understand the design correctly... >Moving Cookies out of the History section means that Cookies are pretty much >independent of the global Remember menu list. Hm, I wonder if we shouldn't move the "perament private browsing" mode option up in the hierarchy since it really does control both local privacy and to some extent network privacy. New mockup coming that shows that change. >I would find it surprising if the >menulist would still magically twiddle with the cookie prefs. yep, but check box at the highest level would then make sense for effecting the two sections below it.

(In reply to comment #14) > >That's by design, at least if I understand the design correctly... > >Moving Cookies out of the History section means that Cookies are pretty much > >independent of the global Remember menu list. > > Hm, I wonder if we shouldn't move the "perament private browsing" mode option > up in the hierarchy since it really does control both local privacy and to some > extent network privacy. I don't think so. Network privacy has never been the goal of PB, and the current implementation doesn't provide that. > >I would find it surprising if the > >menulist would still magically twiddle with the cookie prefs. > > yep, but check box at the highest level would then make sense for effecting the > two sections below it. The current privacy pane kind of reflects what happens implementation wise. I think that we're trying to move out of that model without changing the underlying implementation. This will lead to surprising results for our users, I'm afraid. :/

>I don't think so. Network privacy has never been the goal of PB, and the >current implementation doesn't provide that. While we don't want to tell users that we are giving them full network privacy (we aren't), there are a number of network privacy decisions we can make while the user is in private browsing mode to enhance their overall level of privacy. For instance, we currently turn off access to existing cookies (right?).

This moves permanent private browsing mode back to the highest level control (since it effects all controls below it). Also, this changes the titles to "Online Tracking" and "Local History" to reinforce the online/local distinction with the groups.

some comments on the mock-up. whats the evidence that anyone wants "permanent private browsing mode" ? I'd suggest anyone that wants something like this wants the tor extension, and the private browsing as a feature is for people that want to intermittently use it? also, can you describe in some very simple steps how some one would enable DNT? if we create a world wide campaign to get people to enable DNT would that be easy to explain, and get users to sign up for?

>whats the evidence that anyone wants "permanent private browsing mode" ? based on usage of the previous option to clear personal data on exit. Use cases range from people who just want to have a completely clear browser on their own machine, to people who are setting up Firefox on a shared computer. >I'd suggest anyone that wants something like this wants the tor extension I would very much like for us to have a tor option under online tracking, but in the meantime it isn't the case that the lack of tor changes our current definition of what private browsing means (and users can inspect that definition simply by seeing which options get toggled when they turn private browsing mode on in the prefpane). >if we create a world wide campaign to get people to enable DNT would that be >easy to explain, and get users to sign up for? The interface, sure: options > privacy > tell web sites I do not want to be tracked. But the overall concept that web sites are doing behavior advertising, how that works, and why you should individually care, that is considerably harder to get people to wrap their heads around.

(In reply to comment #16) > >I don't think so. Network privacy has never been the goal of PB, and the > >current implementation doesn't provide that. > > While we don't want to tell users that we are giving them full network privacy > (we aren't), there are a number of network privacy decisions we can make while > the user is in private browsing mode to enhance their overall level of privacy. > For instance, we currently turn off access to existing cookies (right?). That is done to make it harder for websites to be able to correlate a user's private session with their non-private session.

(In reply to comment #19) > >whats the evidence that anyone wants "permanent private browsing mode" ? > > based on usage of the previous option to clear personal data on exit. Use > cases range from people who just want to have a completely clear browser on > their own machine, to people who are setting up Firefox on a shared computer. mconnor also once said that given some data they gathered for sync, a surprising number of users have that setting turned on (don't remember the exact number).

(In reply to comment #17) > Created attachment 526429 [details] > --> https://bugzilla.mozilla.org/attachment.cgi?id=526429 > New mockup of the privacy prefpane So, there are a bunch of things which need some clarification here: 1. If you select "custom" under local history, is the permanent PB checkbox supposed to disappear? 2. Are we going to maintain the "never" mode under local history? 3. What should happen (UI-wise) as a result of checking the permanent PB checkbox option? Specifically, should enabling that change the presented values for the cookies and local history comboboxes (as happens in the current interface)?

>>if we create a world wide campaign to get people to enable DNT would that be >>easy to explain, and get users to sign up for? > > The interface, sure: options > privacy > tell web sites I do not want to be > tracked. does options > privacy > tell web sites I do not want to be tracked mean turn on the DNT header, and the link explain that? or does that empty my amazon shopping cart (doesn't allow cookies to amazon.com or first pary sites), as well as set the enabling of DNT which might inhibit associated press from knowing about any article that I read on any one of their hundreds of syndicated news outlets? I want my amazon shopping cart. I just don't want any organization tracking everything I do across all the the sites that I visit on the web. how can we make the UI enable this simple idea to be possible?

And more questions: 3a. If you select the permanent PB checkbox, the Local History menulist is supposed to switch to "never" automatically. Should the menulist also be disabled as a result? Or should the menulist be enabled, so that setting it to "remember" clears the permanent PB checkbox? 4. Do we still need the Local History menulist to hide the remaining 4 checkboxes in "remember" mode, and show them in "custom" mode? It's easier to understand what happens when you select the permanent PB checkbox, if these 4 checkboxes get unselected and disabled automatically as a result (like in the current interface in "custom" mode). 5. Permanent PB means that a new, empty cookie database is used, and not saved to disk. But the user can nonetheless enable or disable cookies; only the "Keep until" menulist is disabled and displays "until I close Firefox". With the new Cookie button, how are we supposed to show that? If we disable the "Keep until" menu item, its sub-menu isn't displayed, so you can't see the "until I close" setting. We could leave the "Keep until" menu item enabled, and only disable the "until they expire" and "ask me" items of the sub-menu.

The "Keep until" item is incorrectly grouped with tracking cookies. That setting applies to ALL cookies. The simplest fix with the mockup in attachment 526429 [details] would be to move it below the separator and group it with Exceptions and Show Cookies. Then drop the separator between site and tracking cookie options.

(In reply to comment #21) > mconnor also once said that given some data they gathered for sync, a > surprising number of users have that setting turned on (don't remember the > exact number). The number was a little over 4%, based on new user signups vs. ability to sync. I don't think we want to get into the game of "private browsing" vs. network privacy. That's a hard promise to make to users, and really means "build Tor" or something close to it, and we explicitly chose to not attempt to pull that off. Last, renaming to "permanent Private Browsing mode" vs. "never remember history" changes the semantics there. We kept those concepts separate, in that we don't act like private browsing mode is on when the latter is true. If we're going to change all of that, we'll also need to revisit how Sync works in that context.

>If we're going to change all of that This doesn't change the current string (which is currently located inside of the history area), but rather moved the pref, but I get what you are saying. >I don't think we want to get into the game of "private browsing" vs. network >privacy. Yeah, if we want to turn on DNT when the user is always launching in private browsing mode, that does start to conflate the issues in ways that could lead to much greater confusion. If the user for some reason feels that DNT == Tor (because we had a higher level checkbox that said private), then that's obviously a serious problem.

(In reply to comment #27) > >If we're going to change all of that > > This doesn't change the current string (which is currently located inside of > the history area), but rather moved the pref, but I get what you are saying. > > >I don't think we want to get into the game of "private browsing" vs. network > >privacy. > > Yeah, if we want to turn on DNT when the user is always launching in private > browsing mode, that does start to conflate the issues in ways that could lead > to much greater confusion. If the user for some reason feels that DNT == Tor > (because we had a higher level checkbox that said private), then that's > obviously a serious problem. In fact, I think that the association of DNT with Private Browsing in any way is something that we want to strongly avoid implying.

the objective was to infer user intent and perhaps also bump up the DNT numbers a bit, but I agree that we should make them isolated choices.

(In reply to comment #26) > Last, renaming to "permanent Private Browsing mode" vs. "never remember > history" changes the semantics there. We kept those concepts separate, in that > we don't act like private browsing mode is on when the latter is true. If > we're going to change all of that, we'll also need to revisit how Sync works in > that context. I don't understand. The "never remember history" mode is merely a representation of permanent PB mode and unchanged default prefs: Selecting "never remember history" enables permanent PB mode, see updateHistoryModePrefs(). And the privacy pane will open in the "never remember" mode next time you open the prefwindow, if the other dependant prefs are at their default values, see initializeHistoryMode().

I understand that, on a technical level, PB and "never remember history" are one and the same. (I wrote the spec.) What I am saying is that users are currently unaware of how those interact, and that a user who chooses "never remember history" is not told they are in private browsing mode. Toggling that pref doesn't impact your current session, the UI doesn't say you're in private browsing, and some features (i.e. tab sync) work in that mode, but not in the user-triggered "Private Browsing" mode. Given how that 4% of users reacted ("I'm not using private browsing, why can't I sync?") I am pretty sure users of this pref are not thinking of it as "private browsing" mode.

Comment on attachment 524902 [details] [diff] [review] patch v1 sorry, based on discussion I'm now going to have to awkwardly turn down my own proposal. The overall concern is that the user will conflate private browsing mode with something like TOR, and even though I would like to have permanent private browsing mode as the highest level pref, placing it above tracking will likely lead to people forming the wrong conclusion of what it does. thanks for working on this, and sorry about wasting your time with the patch.

Setting to wontfix since we don't want to accidentally conflate local privacy with online privacy.