765398 - Implement three-state UI for DNT (do not track me, okay to track me, decline to state)

Status: RESOLVED FIXED

(Firefox :: Settings UI, enhancement)

Description

[Sid Stamm [:geekboy or :sstamm]]

The W3C tracking preference expression (TPE) draft standard is pretty stable in a few areas, and we should start thinking about implementing the part that lets users consent to tracking (see URL field for this bug).

Right now, the UI is a checkbox and either the DNT header is not sent (checkbox off) or "DNT: 1" is sent (checkbox on).  The TPE draft defines a third state, where "DNT: 0" is sent -- a state that means the user consents to tracking. We should implement a UI and a little pref tweak to allow users to voice not only disdain for tracking via the DNT header, but also consent.

There are three parts to this change: 
1.  (UI) around a three-state thing (no comment, track me, don't track me)
2.  (pref) to store which preference the user has when they've made a choice
3.  (netwerk) tweaks -- back-end to support sending multiple values in the DNT header

Most of the work is in the UI and pref parts, and only a little in netwerk.

Comment 1

[Sid Stamm [:geekboy or :sstamm]]

Attachment: UI example 1: checkbox and drop-down

(UI): first UI proposal.  User checks the box to enable the "send my opinion" feature, then selects which opinion he/she wants to transmit.

Comment 2

[Sid Stamm [:geekboy or :sstamm]]

Attachment: UI example 2: radio buttons

(UI): second UI proposal.  User selects a radio button with the message he/she would like to share with sites.

Comment 3

[Justin Dolske [:Dolske]]

Sid and I talked about this for a bit.

The tl;dr is I think we should go with the 3-radio-button UI (ala attachment 633706 [details], wordsmithing TBD).

To a degree this really isn't about UI design. Usually when we approach UI for features we'd go along a path like:

 1. Does this need any preference at all? Will a sensible default work for
    almost everyone?
 2. Can we pick a default, and allow a change of preference by way of about:config
    or an addon?
 3. What are the choices (options) we expect will cover the use-cases for most
    users, and what is the most simple/minimal UI to accomplish that?

Because of the nature of DNT, #1 and #2 are insufficient. So we're at #3.

I would argue, in a hypothetical bubble of perfection, that a simple checkbox -- as we have today -- is all that's needed. It can not express an explicit "please track me" choice, but I'd argue that's ok because I can't imagine any significant number of users actually wanting that choice. I would assume that most users will fall into a "don't care or don't understand" bucket, and a small-but-significant number of users concerned about privacy will choose "do not track". In short, I do not believe the existence of unicorns, leprechauns, snuffleupaguses, or mythical "please do track" users.

And that's the real issue at hand for this UI... Sid tells me that the advertising industry posits that there are actually legions of these users, and given the choice swarms of them will gleefully choose to say "YES! DO TRACK!" in order to synergize their online experience to its maximal extent (tm).

Perhaps they're right. A good way to find out would be to present all options in our UI, in neutral wording and on equal footing. Users can choose as they wish. And then we can look at what real users are choosing, consider that data, and make any UI adjustments to better fit user needs. (Related: http://blog.mozilla.org/ux/2012/06/firefox-heatmap-study-2012-results-are-in/)

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

Attachment: patch for UI 2

Dolske: here's a patch for UI 2 (three radio buttons).  What's the best mechanism for testing this (since it's mainly just front-end code and I'm used to developing back-end stuff)?

Comment 5

[Dão Gottwald [:dao]]

(In reply to Sid Stamm [:geekboy] from comment #0)
> Right now, the UI is a checkbox and either the DNT header is not sent
> (checkbox off) or "DNT: 1" is sent (checkbox on).  The TPE draft defines a
> third state, where "DNT: 0" is sent -- a state that means the user consents
> to tracking. We should implement a UI and a little pref tweak to allow users
> to voice not only disdain for tracking via the DNT header, but also consent.

The connection between "the spec defines" and "we should implement a UI" isn't clear to me. The spec just says: 'The DNT field-value sent by a user agent must begin with the numeric character "0" (%x30) if a tracking preference is enabled and the preference is to allow tracking', but as with most other preferences, we should only expose it if we believe enough users will want to enable it.

Comment 6

[Sid Stamm [:geekboy or :sstamm]]

(In reply to Dão Gottwald [:dao] from comment #5)
> The connection between "the spec defines" and "we should implement a UI"
> isn't clear to me. [...] we should only expose it if we believe enough users
> will want to enable it.

How many is "enough"?  When we deployed DNT the first time, we didn't know how many people would want to use it.  It's still not even a quarter of our users who tick the "do not track" box, but  we still ship the preference.

We should allow users to ask for more personalization if they can ask for none; many ad networks provide a way for users to provide specific information about themselves for better ads (e.g., "I like: cars, fishing, cooking").  Just like "do not track me" can be a trigger to show users an opt-out interface on web sites, "do personalize me" can be a trigger to show users a personalization interface.  To the web sites who we want listening to this feature, it is a far more convincing feature to implement than just a "no" button.  I think we're more likely to see widespread site compliance with a three-state than with just a "no" button.

Comment 7

[Sid Stamm [:geekboy or :sstamm]]

A few lingering design questions after talking with jaws:

* In what order should we present the options?  {neutral, yes, no} or {yes, neutral, no}?
* What should the options' wording be?  The text in the screenshot/patch is just a first whack.
* We should include a "learn more" link of some sort, but it should be a question.  How about "What does this do?"

Comment 8

[Dão Gottwald [:dao]]

(In reply to Sid Stamm [:geekboy] from comment #6)
> (In reply to Dão Gottwald [:dao] from comment #5)
> > The connection between "the spec defines" and "we should implement a UI"
> > isn't clear to me. [...] we should only expose it if we believe enough users
> > will want to enable it.
> 
> How many is "enough"?

I would need to make up a concrete number, but it would probably be higher than what I think we can expect here...

> When we deployed DNT the first time, we didn't know
> how many people would want to use it.  It's still not even a quarter of our
> users who tick the "do not track" box, but  we still ship the preference.

A quarter would be an exceptionally high opt-out rate.

> We should allow users to ask for more personalization if they can ask for
> none; many ad networks provide a way for users to provide specific
> information about themselves for better ads (e.g., "I like: cars, fishing,
> cooking").  Just like "do not track me" can be a trigger to show users an
> opt-out interface on web sites, "do personalize me" can be a trigger to show
> users a personalization interface.

Won't they want to show that interface anyway (i.e. in the "tell websites nothing about my tracking preferences" case), as it allows them to monetize the user better?

Comment 9

[Asa Dotzler [:asa]]

While I don't think we're obliged to do anything here, I do think we should provide the opt in and not just the opt out.  

The major point of DNT is to give voice to user intent, no matter how small that group of users is. (If DNT opt in was 1% of our users, we'd consider that valuable because it's giving voice to that 1% who want to and know how to assert an opinion.)

Right now we're not offering some set of our users the opportunity to express their intent. It may well be that it's a small number. That's OK. The 6% we have saying "no" with DNT is a small number too. 

I could also imagine a world where it wasn't small (apparently I do believe in unicorns :-) If the feature was worded "Please personalize ads I see in the browser" vs "Please serve me generic ads with no personalization" and "I don't care what kind of ads you serve me" I'll bet a good number would opt for personalization. 

I'm not suggesting we word it like that -- that's far to narrow a description of what's happening, but I think my point stands. If users really truly understood this feature, some of them would quite reasonably opt for the personalization that comes with tracking and a tool that is sincere about giving voice to users, even the tiny number that will ever access the DNT prefs, should offer the opt in as well as the opt out (and the "no intent signaled")

Comment 10

[Justin Dolske [:Dolske]]

Comment on attachment 634065 [details] [diff] [review]
patch for UI 2

Review of attachment 634065 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry, totally didn't realize this was sitting in my queue. Looks fine, let's polish it up and get it in.

::: browser/components/preferences/privacy.js
@@ +126,5 @@
>  
>    /**
> +   * Update the Do Not Track preferences based on controls.
> +   */
> +  updateDntPrefs: function PPP_updateDntPrefs()

Nit: I'd suggest just calling this & co something like "updateTrackingPrefs" -- DNT doesn't abbreviate nicely for camelCaps, and the literal "DNT" part isn't really relevant outside of of the actual text shown to the user and, perhaps, the actual pref names.

::: browser/components/preferences/privacy.xul
@@ +94,5 @@
> +        <radiogroup id="doNotTrackSelection" orient="vertical"
> +                    oncommand="gPrivacyPane.updateDntPrefs()"
> +                    preference="privacy.donottrackheader.value"
> +                    onsynctopreference="gPrivacyPane.updateDntPrefs()" 
> +                    onsyncfrompreference="gPrivacyPane.updateDntUI()">

Since the control depends on 2 prefs, ideally changing either pref should update the control appropriately. <preference onchange="updateDntUI()"> and init/close glue. I think there are some existing examples in the prefs code.

Not really sure it's worth doing all that, though, TBQH. It's pretty edge-case stuff.

Another option would be to just migrate to a single pref, with a special value (-1?) to indicate the disabled state. That makes the <prefpane> code simpler at the cost of some pref churn.

Oh, and bonus points if you update the incontent pref stuff! (See browser/components/preferences/in-content/)

::: netwerk/protocol/http/nsHttpHandler.cpp
@@ +166,5 @@
>      , mPromptTempRedirect(true)
>      , mSendSecureXSiteReferrer(true)
>      , mEnablePersistentHttpsCaching(false)
>      , mDoNotTrackEnabled(false)
> +    , mDoNotTrackValue(-1)

'1' might be safer? Shouldn't matter, since it should always pick up the pref value, but seems like it should have a default that's a valid value. Especially since it's a uint. :)

@@ +1196,5 @@
> +        val = 1;
> +        rv = prefs->GetIntPref(DONOTTRACK_HEADER_VALUE, &val);
> +        if (NS_SUCCEEDED(rv)) {
> +            mDoNotTrackValue = val;
> +        }

This should probably be clamped to a valid range/values. Is this header likely to support other values soon? if not, I'd suggest simply making the pref a boolean, and map it to 0/1 here. Dealing with other values can be done later (and eliminates any worries about someone setting it to "3" today).

Comment 11

[Justin Dolske [:Dolske]]

(In reply to Sid Stamm [:geekboy] from comment #4)

> Dolske: here's a patch for UI 2 (three radio buttons).  What's the best
> mechanism for testing this (since it's mainly just front-end code and I'm
> used to developing back-end stuff)?

I think if we can keep the pref-munging code simple, straight-up manual verification would be sufficient. (We don't really test much in the prefs anyway.) If it gets gnarly, it wouldn't be hard to make a test to open prefs, select a flavor, apply, and check the resulting pref values.

Comment 12

[Matej Novak [:matej]]

I think we need to keep the user in the wording of the pref ("I do not...") so it's clear that they're indicating their intent. Otherwise it could be misleading and people could think that by enabling DNT, sites definitely won't track them. I also prefer the {yes, neutral, no} order, though I'm sure I haven't thought through all the implications of both options (I think it would be interesting to test {yes, neutral, no} vs. {no, neutral, yes} to see if people are more likely to click the first option, regardless of what it is).

Anyway, the following is based on the current wording. I'm just not sure about the neutral state. Do the below options make it sound like we'll still be sending a pref to sites? Maybe "Nothing about my tracking preferences" is best there.

Tell websites:
I do not want to be tracked
I don't care one way or the other / I don't care about tracking
I want to be tracked

Comment 13

[Sid Stamm [:geekboy or :sstamm]]

Thanks Matej.  I've been hearing arguments that "tracking" has a stigma and "nobody in their right mind would say they want to be tracked".  Do you have any thoughts on how to better capture that tracking may lead to more customization and a more personalized experience?

It's a pretty complex issue: we want users to know that these companies are building a profile of the sites they visit, but there are some users who are okay with that.  We'd like those users to pick the "I want" option.

The middle option is interesting too -- if it's selected, then Firefox won't say anything to sites.  So I'm hoping we can capture something along the lines of "don't say anything to sites".  Thoughts?

Comment 14

[Dão Gottwald [:dao]]

(In reply to Sid Stamm [:geekboy] from comment #13)
> The middle option is interesting too -- if it's selected, then Firefox won't
> say anything to sites.  So I'm hoping we can capture something along the
> lines of "don't say anything to sites".  Thoughts?

The neutral option shouldn't sound like you're safe because you're not telling anyone about your preference. In order to not mislead users, it should make it clear that it's effectively the same as the "I want" option, i.e. you're likely going to be tracked.

Like the rhetorical question I asked in the last part of comment 8, I guess it boils down to this: exposing all three states to the user isn't going to make much sense no matter how you look at it.

Comment 15

[Sid Stamm [:geekboy or :sstamm]]

(In reply to Dão Gottwald [:dao] from comment #14)
> (In reply to Sid Stamm [:geekboy] from comment #13)
> > The middle option is interesting too -- if it's selected, then Firefox won't
> > say anything to sites.  So I'm hoping we can capture something along the
> > lines of "don't say anything to sites".  Thoughts?
> 
> The neutral option shouldn't sound like you're safe because you're not
> telling anyone about your preference. In order to not mislead users, it
> should make it clear that it's effectively the same as the "I want" option,
> i.e. you're likely going to be tracked.

I want to be clear that this feature is not about enabling/disabling tracking -- not at all.  It's about _telling_ sites what you want.  You can elect to tell a site nothing, and that's different than telling a site you want tracking.  And I maintain it's not clear you're gonna be tracked if you don't send a DNT:1 signal: what sites do in absence of rejection/consent is up to social norms and laws.  It's possibly different depending on who and where you are.

> Like the rhetorical question I asked in the last part of comment 8, I guess
> it boils down to this: exposing all three states to the user isn't going to
> make much sense no matter how you look at it.

If I follow your line of reasoning a little bit farther, I'm led to the argument that we shouldn't ship the DNT feature at all since very few companies actually listen to the DNT signal.  I disagree heavily with this point of view that there's no value in allowing consumers to be explicit about how they communicate with sites.

We should probably move this conversation out of the bug so we don't end up burying the engineering work in policy discussions.  Lets take it over to dev-privacy (I'll post a message there).

Comment 16

[Sid Stamm [:geekboy or :sstamm]]

relevant thread for discussion:
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.privacy/dtcMaCGklHQ[1-25]

Comment 17

[Dão Gottwald [:dao]]

(In reply to Sid Stamm [:geekboy] from comment #15)
> (In reply to Dão Gottwald [:dao] from comment #14)
> > The neutral option shouldn't sound like you're safe because you're not
> > telling anyone about your preference. In order to not mislead users, it
> > should make it clear that it's effectively the same as the "I want" option,
> > i.e. you're likely going to be tracked.
> 
> I want to be clear that this feature is not about enabling/disabling
> tracking -- not at all.  It's about _telling_ sites what you want.  You can
> elect to tell a site nothing, and that's different than telling a site you
> want tracking.

Right, I was cutting it short. You're telling the site hoping that it will in some cases make a difference and disable tracking or enable personalization, respectively. Phrasing it like this doesn't really seem to make a difference for the point I was trying to make.

> And I maintain it's not clear you're gonna be tracked if you
> don't send a DNT:1 signal: what sites do in absence of rejection/consent is
> up to social norms and laws.  It's possibly different depending on who and
> where you are.

Are you thinking of some specific countries or is this purely hypothetical? Would it make sense to postpone this bug until social norms and laws have changed? Or maybe you're hoping to encourage that change with this UI?

> > Like the rhetorical question I asked in the last part of comment 8, I guess
> > it boils down to this: exposing all three states to the user isn't going to
> > make much sense no matter how you look at it.
> 
> If I follow your line of reasoning a little bit farther, I'm led to the
> argument that we shouldn't ship the DNT feature at all since very few
> companies actually listen to the DNT signal.  I disagree heavily with this
> point of view that there's no value in allowing consumers to be explicit
> about how they communicate with sites.

No. I'm asserting that sites want to track users / personalize content for them and that they won't stop that for the (I'm guessing) >80% of users who won't bother making a decision here. They may however stop doing it for the <10% who say they don't want to be tracked.

I really don't want to start a discussion on DNT beyond this bug's scope.

Comment 18

[Matej Novak [:matej]]

This is definitely tricky. While I agree that some people may want to allow tracking, playing up only the "benefit" may make it more appealing to people who don't understand all the implications. I've tried some variations below to get your reactions. 

The first two are pretty similar to each other and to comment 12:

Tell websites:
I do not want to be tracked
Nothing about my tracking preferences
I want more personalized content

Tell websites:
You don't want them tracking you
Nothing about your tracking preferences
You want to receive personalized content


This is a lot longer, but it clearly spells out the options and what they mean (it would be great if the copy in parentheses only showed up on hover or click, but I'm guessing that's not possible here):

Tracking options:
Enable Do Not Track (tell sites you don't want them tracking you)
Do nothing (don't send any tracking preference to sites)
Enable tracking (tell sites you want to receive personalized content)


This one is mostly here for another way to look at the neutral option, that basically sites will take it like an invitation to track you anyway:

Tell websites:
I do not want to be tracked
They can track me if they like
I would like them to track me

Comment 19

[chris hofmann]

When we set out on a path it was to give users a voice in the privacy debate that was dominated by industry players.  That voice was missing.

I like the first to parts.




The part about:

   I want more personalized content

is not completely accurate.   I haven't seen anything where DNT seeks to reduce or removed "personalized content" that is served by the site I'm visiting.  DNT is more about opting out of the "targeted content" provided by third party adverstising sites.   We should try and make that part of the language here.
The difference with "personalized content", and "targeted content" I my mind is pretty clear, but may deserve more explanation and common understanding.  when gmail or a site provides me with content based on my past use of that site that's personalized content.   when I see ads targeted at me based on my use of the web across many independent sites that's "targeting."

Maybe something like:

   Tell websites:
    - I do not want to be tracked (or my my personal data retained by websites)
    - I'm ok with third part sites retaining personal data and serving targeted content to me.

Captures what DNT is trying to achieve.

I don't understand what we are trying to achieve with the third option of

   They can track me if they like
   Do nothing (don't send any tracking preference to sites)
   Tell sites nothing about my tracking preferences

Can someone provide more clarification there?  Seems like just leaving both of the two buttons on the "Tell sites" unchecked conveys the user preference that to no make either of these choices, either because they don't have an understanding of the issues or interest in the topic of web tracking.

Comment 20

[Sid Stamm [:geekboy or :sstamm]]

The third one is necessary as a default state -- radio buttons can't really be "unchecked".  Your thinking lines up with the UI example 1 (see attachment) but the Fx team (and I) want to go with three radios (option 2, see attachment) because it's more quickly and directly actionable.

Comment 21

[Matej Novak [:matej]]

Thanks for the input, chofmann. That's very helpful. I do, however, think that the distinction you make between "customization" and "targeting" is fairly nuanced for the average user. It also seems to set up "targeting" as something inherently bad and I'm not sure everyone would feel the same way. That said, I do think the distinction is important and worth considering.

As for your suggestion:

   Tell websites:
    - I do not want to be tracked (or my my personal data retained by websites)
    - I'm ok with third part sites retaining personal data and serving targeted content to me.

I don't think "I'm OK with" captures it correctly. To me, "I'm OK with" is the neutral state where a user doesn't share a preference, but they're not saying they definitely do or do not want it. I think the language has to be stronger in terms of saying very definitely that "yes, I want sites to retain my personal data and serve targeted ads to me."

I do like the added clarity, though. How do people feel about these being longer? And then what would we do in mobile?

Comment 22

[Sid Stamm [:geekboy or :sstamm]]

We should also put in a "learn more" link or something for people who want to learn more about the option.

Comment 23

[Sid Stamm [:geekboy or :sstamm]]

Attachment: Proposed UI: radio buttons and "learn more" link

Comment 24

[Sid Stamm [:geekboy or :sstamm]]

Attachment: proposed patch

(In reply to Justin Dolske [:Dolske] from comment #10)
> ::: browser/components/preferences/privacy.xul
> @@ +94,5 @@
> > +        <radiogroup id="doNotTrackSelection" orient="vertical"
> > +                    oncommand="gPrivacyPane.updateDntPrefs()"
> > +                    preference="privacy.donottrackheader.value"
> > +                    onsynctopreference="gPrivacyPane.updateDntPrefs()" 
> > +                    onsyncfrompreference="gPrivacyPane.updateDntUI()">
> 
> Since the control depends on 2 prefs, ideally changing either pref should
> update the control appropriately. <preference onchange="updateDntUI()"> and
> init/close glue. I think there are some existing examples in the prefs code.

Done.

> Oh, and bonus points if you update the incontent pref stuff! (See
> browser/components/preferences/in-content/)

I love bonus points.  Done.

> @@ +1196,5 @@
> > +        val = 1;
> > +        rv = prefs->GetIntPref(DONOTTRACK_HEADER_VALUE, &val);
> > +        if (NS_SUCCEEDED(rv)) {
> > +            mDoNotTrackValue = val;
> > +        }
> 
> This should probably be clamped to a valid range/values. Is this header
> likely to support other values soon? if not, I'd suggest simply making the
> pref a boolean, and map it to 0/1 here. Dealing with other values can be
> done later (and eliminates any worries about someone setting it to "3"
> today).

I don't want to clamp it because there's a few add-ons that do things with DNT and I'd like to allow them to easily experiment with changing the header's value to something like 3.  There's also potential for it to change in the future to have more values based on context, so I want to make sure it's easy to have the flexibility (and experiment by just changing the pref).

I took care of the rest of your comments.  Flagging you for review since you've already digested this code.

Comment 25

[Sid Stamm [:geekboy or :sstamm]]

Although... two lingering questions:
1.  Is the order of the radios right?  The default is on the bottom which is kinda weird, but somehow it ended up there.
2.  The learn more link opens our DNT FAQ site.  Is that a reasonable spot for it?  I'd like to include it there somewhere.

Another possible thing we could do is add text under the selection that explains what effect the user should expect.  Not sure adding moar text to the window itself is a good idea.

Comment 26

[Asa Dotzler [:asa]]

(In reply to Sid Stamm [:geekboy] from comment #25)

> Another possible thing we could do is add text under the selection that
> explains what effect the user should expect.  Not sure adding moar text to
> the window itself is a good idea.

I've been thinking about this for a while. I think users are more likely to interact with and get the results they want if there's more (con)text. Adding more text to explain the options usually works really well when you're dealing with just one issue. Here, though, DNT is part of a larger set of options (the rest of what the Privacy Panel in Preferences/Options window is trying to do.) Because there's unrelated content surrounding DNT in preferences, adding more text may end up as too much visual clutter and so not help as much.  

This feels like a question for user research and their answers will depend heavily on what our intent is for this setting. Do we want everyone to engage with this questions? Just those people who stumble upon it when poking around in Preferences/Options? People who have been directed there by outside contexts?

That being said, let's not let perfect be the enemy of good enough. We can always put more context in later, or even move the question to some sort of stand-alone location where we can be more helpful to users. In the mean time, I think the changes we've already agreed on are worth making.

Comment 27

[Justin Dolske [:Dolske]]

Comment on attachment 660538 [details] [diff] [review]
proposed patch

Review of attachment 660538 [details] [diff] [review]:
-----------------------------------------------------------------

I don't understand how updateTrackingUI() can be working. Possible I'm just missing something dumb? Otherwise just a few small nits.

::: browser/components/preferences/in-content/privacy.js
@@ +155,5 @@
> +
> +  /**
> +   * Update the Tracking controls based on prefs
> +   */
> +  updateTrackingUI: function PPP_updateTrackingUI()

I'm confused. This function doesn't seem to have any side-effects, how is the UI actually updating from the places this is being called?

::: browser/components/preferences/privacy.js
@@ +124,5 @@
>  
>    /**
> +   * Open up the DNT "learn more" link.
> +   */
> +  openTrackingSite: function PPP_openTrackingSite()

Can we call this openTrackingInfoSite / openDntInfoSite? :)

@@ +142,5 @@
> +  updateTrackingPrefs: function PPP_updateTrackingPrefs()
> +  {
> +    let dntRadioGroup = document.getElementById("doNotTrackSelection"),
> +        dntvalpref = document.getElementById("privacy.donottrackheader.value"),
> +        dntenabledpref = document.getElementById("privacy.donottrackheader.enabled");

Nit: camel case would be a bit clearer: dntValuePref, dntEnabledPref.

@@ +146,5 @@
> +        dntenabledpref = document.getElementById("privacy.donottrackheader.enabled");
> +
> +    // if the selected radio button says "no preference", set on/off pref to
> +    // false and the value pref to default.
> +    if (document.getElementById("dntnopref").selected) {

I suppose you could check |dntRadioGroup.selectedItem.value == -1| for consistency with the code a few lines down... I don't care strongly though.

@@ +148,5 @@
> +    // if the selected radio button says "no preference", set on/off pref to
> +    // false and the value pref to default.
> +    if (document.getElementById("dntnopref").selected) {
> +      dntenabledpref.value = false;
> +      return dntvalpref.defaultValue;

Hmm. Shouldn't change the DNT value when disabling DNT. It doesn't really matter if the user is only using our pref UI, but if they use about:config or some addon that exposes (the implemention detail of) multiple prefs, they would be fairly surprised that the number changes.

::: browser/locales/en-US/chrome/browser/preferences/privacy.dtd
@@ +1,5 @@
>  <!-- This Source Code Form is subject to the terms of the Mozilla Public
>     - License, v. 2.0. If a copy of the MPL was not distributed with this
>     - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
>  
> +<!ENTITY tracking.label                 "Tracking Preference">

I don't think "Preference" needs to be here -- no other section in the prefs does, and it's already clear these are, well, preferences.

Comment 28

[Matej Novak [:matej]]

(In reply to Justin Dolske [:Dolske] from comment #27)
> 
> ::: browser/locales/en-US/chrome/browser/preferences/privacy.dtd
> @@ +1,5 @@
> >  <!-- This Source Code Form is subject to the terms of the Mozilla Public
> >     - License, v. 2.0. If a copy of the MPL was not distributed with this
> >     - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
> >  
> > +<!ENTITY tracking.label                 "Tracking Preference">
> 
> I don't think "Preference" needs to be here -- no other section in the prefs
> does, and it's already clear these are, well, preferences.

+1

Comment 29

[:Gavin Sharp [email: [e-mail]]]

(In reply to Justin Dolske [:Dolske] from comment #27)
> > +  updateTrackingUI: function PPP_updateTrackingUI()
> 
> I'm confused. This function doesn't seem to have any side-effects, how is
> the UI actually updating from the places this is being called?

The one call in doNotTrackSelection's onsyncfrompreference handler has an effect, but yeah, the other callers are no-ops AFAICT. If this is meant as an onsyncfrompreference handler only, it could use a better name.

Comment 30

[Sid Stamm [:geekboy or :sstamm]]

gavin, dolske, matej, thanks for the feedback.  My front-end-fu is not strong, clearly, but I'll take a whack and post another patch soon.

Comment 31

[Sid Stamm [:geekboy or :sstamm]]

Attachment: proposed patch

Addressed review comments (and suggestion from Gavin).

Comment 32

[Justin Dolske [:Dolske]]

Comment on attachment 699507 [details] [diff] [review]
proposed patch

Review of attachment 699507 [details] [diff] [review]:
-----------------------------------------------------------------

You need to update .../preferences/in-content/privacy.xul with the changes you made to .../preferences/privacy.xul. Oddly, you got the JS changes right in both spots. Oops. :)

r+ with that fixed.

Comment 33

[Sid Stamm [:geekboy or :sstamm]]

Attachment: proposed patch

Thanks, Dolske, I made those changes (totally spaced on that last time, good catch).  Carrying over r=dolske.

Comment 34

[Sid Stamm [:geekboy or :sstamm]]

Try looks good https://tbpl.mozilla.org/?tree=Try&rev=abf190c0c7b9

Comment 35

[Sid Stamm [:geekboy or :sstamm]]

Inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/a26f703d6be8

Comment 36

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

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

Comment 37

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 705928 [details] [diff] [review]
proposed patch

Review of attachment 705928 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/http/nsHttpHandler.h
@@ +380,2 @@
>      bool           mDoNotTrackEnabled;
> +    PRUint8        mDoNotTrackValue;

Please note: we haven't used PR integer types since August. Please adjust your habits.

Comment 38

[Sid Stamm [:geekboy or :sstamm]]

Ms2ger: yeah, oops.  The first rev of the patch that added that was created back in June, so it must've just slipped by.  I will try to fix it in the follow up that's already filed.

Comment 39

[Arloo]

When you start up Firefox for the first time will you get asked if your choice (want to be tracked, don't want to be tracked, don't care) or will it just default to "don't care" and then you have to change it to your choice in the settings?

Comment 40

[Ton [:Tonnes]]

Would anybody be so kind to provide a patch or file a bug in order to remove the end stops for the 3 DNT options (Sid)? As with any GUI option/preference, those should never have been introduced.

Comment 41

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Ton from comment #40)
> Would anybody be so kind to provide a patch or file a bug in order to remove
> the end stops for the 3 DNT options?

I filed bug 874046.

Comment 42

[Matej Novak [:matej]]

Checking in here. Is everyone happy with the current wording or do we want to revisit it at some point?