Last Comment Bug 628198 - Implement UI for do-not-track HTTP header
: Implement UI for do-not-track HTTP header
Status: VERIFIED FIXED
[strings][softblocker][fx4-fixed-bugday]
: user-doc-needed, ux-jargon
Product: Firefox
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: Firefox 4.0b11
Assigned To: Sid Stamm [:geekboy or :sstamm]
:
Mentors:
Depends on: DNT
Blocks: 630166 630270 765398 1042135
  Show dependency treegraph
 
Reported: 2011-01-23 21:05 PST by Sid Stamm [:geekboy or :sstamm]
Modified: 2014-07-22 10:06 PDT (History)
48 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
final+


Attachments
proposed patch (2.50 KB, patch)
2011-01-23 21:05 PST, Sid Stamm [:geekboy or :sstamm]
no flags Details | Diff | Review
advanced prefs screenshot (62.36 KB, image/png)
2011-01-23 21:07 PST, Sid Stamm [:geekboy or :sstamm]
no flags Details
Top billing in the privacy pref pane (probably future work) (708.59 KB, image/png)
2011-01-24 13:25 PST, Alex Faaborg [:faaborg] (Firefox UX)
no flags Details
proposed patch (3.78 KB, patch)
2011-01-27 14:19 PST, Sid Stamm [:geekboy or :sstamm]
mbeltzner: review-
faaborg: ui‑review-
Details | Diff | Review
proposed patch (3.86 KB, patch)
2011-01-28 10:47 PST, Sid Stamm [:geekboy or :sstamm]
gavin.sharp: review+
faaborg: ui‑review+
Details | Diff | Review
proposed patch (3.75 KB, patch)
2011-01-28 12:43 PST, Sid Stamm [:geekboy or :sstamm]
mozbugs: review+
mozbugs: ui‑review+
Details | Diff | Review
proposed patch (3.71 KB, patch)
2011-01-28 13:44 PST, Sid Stamm [:geekboy or :sstamm]
mozbugs: review+
mozbugs: ui‑review+
Details | Diff | Review

Description Sid Stamm [:geekboy or :sstamm] 2011-01-23 21:05:31 PST
Created attachment 506304 [details] [diff] [review]
proposed patch

The technical guts to send users' choice to opt-out of tracking for
behavioral ads is covered by bug [xxx], but to make it actually work
there has to be some discoverable UI.

Attached is a proposed patch that adds a checkbox to the "Advanced"
option panel so users can ask ad networks to stop tracking them.  Also
attached is a screenshot with my proposed UI location and a first whack
at a (en-US) label: "Ask advertising networks to stop tracking me across
sites."
Comment 1 Sid Stamm [:geekboy or :sstamm] 2011-01-23 21:07:11 PST
Created attachment 506305 [details]
advanced prefs screenshot
Comment 2 Julian Reschke 2011-01-24 04:55:48 PST
This header *really* should not have an "X-" prefix, and potentially be discussed in the IETF websec Working Group.
Comment 3 Mike Shaver (:shaver -- probably not reading bugmail closely) 2011-01-24 05:16:49 PST
I don't understand either of those pieces, Julian: it's not a standardized header, so I thought that wanted the X-, and it has nothing to do with security, so I don't understand what it would be at the websec WG for.  Clue me!
Comment 4 Mike Shaver (:shaver -- probably not reading bugmail closely) 2011-01-24 05:29:33 PST
Wording-wise, I'd prefer something a little stronger: "Tell 3rd-party sites not to track my browsing activity."
Comment 5 Julian Reschke 2011-01-24 05:35:18 PST
Mike, contrary to popular belief, "X-" isn't special in header fields (per spec). See <http://tools.ietf.org/html/rfc3864>. 

There *is* a provisional registry (which just requires a spec that can be cited), but it use the same names (no prefix), so that a name can later be moved into the permanent registry.

You are right that it's not strictly in the area of the IETF websec WG, but I would expect that the people over there are likely be interested in this topic.
Comment 6 Giorgio Maone [:mao] 2011-01-24 05:48:35 PST
Wouldn't it better fit in the "Privacy" section?
Comment 7 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-24 06:41:43 PST
Sid poked me and asked where this would best fit. The answer depends on whether or not we're trying to contain this in an already-locking-down release vehicle or talking about the ideal for the future.

Without a minor-to-major reswizzling of the Privacy prefpane, there's not really a good place to put it. It doesn't fit with options about what Firefox remembers, nor does it really fit in the "Location Bar" section. Obviously we can rework that pane to make a sensible place for it, but that expands the scope of work.

After Firefox 4 ships, I'm sure that the UX team will be able to collate and rationalize all the privacy options and refactor the panel in a sensible way. I've added the team to this bug to give them a heads up.

The least risky / minimal impact option is, I feel, what I recommended to Sid. A single string addition to Advanced > Browsing.

Shaver: on wording, I agree. That captures the intent pretty clearly.
Comment 8 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 11:40:58 PST
Where are we on string freeze?  A few quick thoughts:

-"3rd party" seems unesssarly (are Mozilla sites first party?), how about just Web sites.

-Seems like this phrase needs to contain "do not" in it, for ease of press/support sentence writing and nice parallel structure (you can turn on "Do Not" Track by going to "not to" feels clunky)
Comment 9 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 11:43:07 PST
Ok, just figured out that third party means outside of the site you are on.

Perhaps, "Tell Web sites that I do not wished to have my browsing activity tracked between different sites I visit."
Comment 10 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 11:44:06 PST
Or

"Tell Web sites that I do not wished to have my browsing activity
tracked and shared."

the ("and shared" meaning 3rd party)
Comment 11 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 11:45:26 PST
wished/wish

want? wish seems kind of weak
Comment 12 Mike Shaver (:shaver -- probably not reading bugmail closely) 2011-01-24 11:46:07 PST
3rd party I think is important, because we're going to be sending it for 3rd-party requests initially.  Also, "3rd-party cookies" is part of the relevant lexicon.  "Do not" is a little wooden in UI, IMO, and I'd prefer "don't", but you're the UX guy.

I don't think that parallelism with the press message is as important as you do, I think, so that's probably most of the difference in preference. :-)
Comment 13 Mike Shaver (:shaver -- probably not reading bugmail closely) 2011-01-24 11:46:24 PST
Tracking: [x] DO NOT WANT
Comment 14 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 11:49:31 PST
I really think we should make this the top item in the Privacy prefpane.  We went for the mask icon to represent privacy (because it is cool and kind of sexy, and allows us to use the color purple for the concept across the product), but we've up until now not really backed up the metaphor.  A mask means you don't want people to see you, and this is (while opt-in by the site), the closest we've gotten to actually shipping a mask, so it seems wrong to hide it away under a gear.
Comment 15 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 11:50:32 PST
>Tracking: [x] DO NOT WANT

exactly :)

I'll put together a quick mockup with a few options
Comment 16 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 13:25:45 PST
Created attachment 506496 [details]
Top billing in the privacy pref pane (probably future work)

We'll probably want to just hold onto this mockup for use later, and there might be some debate over if we want to give this pref top billing initially, when it requires sites to opt in (as opposed to a considerably more powerful control).

But either way, I think this is the direction we want to eventually head in, separating controls for local machine privacy and network privacy, and putting both under the metaphor of the mask.
Comment 17 Sid Stamm [:geekboy or :sstamm] 2011-01-24 13:28:03 PST
(In reply to comment #16)
> Created attachment 506496 [details]
> Top billing in the privacy pref pane (probably future work)

+1.  Minor nit: tracking restrictions should not be limited to cookies (re: "Tracking Cookies" category).  I think users who check this box want out of all tracking.
Comment 18 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 13:33:16 PST
>"3rd-party cookies" is part of the relevant lexicon.

Ok, one more quick thought before I disappear to other bugs, I would like us to change our lexicon to this:

3rd party = "other sites"
cookies = "tracking cookies"
3rd party cookies = "sharing my browsing activity with other sites"

we can't actually remove the term cookies, because it is everywhere, but I think we need to add to it so that by itself it remains descriptive.  For instance:

user: what are cookies?
manual: cookies are used to track you

user: what are tracking cookies?
manual of tautologies: tracking cookies are used to track you
user: duh, that's in the name, what else do they do...
Comment 19 chris hofmann 2011-01-24 16:03:37 PST
> user: duh, that's in the name, what else do they do...

the orginal intent of cookies was to provide a mechanism to save state of browsing across sessions, and in many paces it still holds to exclusively this meaning.  when you are able to start up the browser and get back to gmail, or bugzilla, or other accounts that's often cookies working in the background on your behalf.

it wasn't until later that cookies were used for tracking though construction and use of 3rd party cookies.
Comment 20 chris hofmann 2011-01-24 16:15:14 PST
if we are looking for a manual to help users understand what cookies are, and are not here is a good place to start.

http://en.wikipedia.org/wiki/HTTP_cookie#Uses

but Sid's point still holds.

>  I think users who check this box want out of all tracking.

so this shouldn't be about cookies, or css :visited, or any current or future techniques that web sites and ad networks might dream up to try and track your movements.  this should be about express your intent (and hoping the site honors that intent) that they will not track or retain information about your visit.
Comment 21 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 16:19:23 PST
yeah, I still consider shopping carts and log-ins fundamentally a type of tracking, but Sid points out that "tracking" has a negative connotation that isn't necessarily fair for those types of uses.

Overall I think we need to rename cookies throughout the UI so that it is more than just an extremely abstract metaphor.  Another idea:

1st party: "preference cookie" [switch icon]
3rd party: "tracking cookie" [being tagged in the wild]
Comment 22 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-24 16:24:38 PST
>if we are looking for a manual

what I meant was that all information should be conveyed in the name itself, without the need for additional sources of information.

>this should be about express your intent

yeah, I totally agree, I just want us to get all of the network privacy stuff grouped together in one area of the interface.
Comment 23 chris hofmann 2011-01-24 16:42:28 PST
(In reply to comment #21)
> yeah, I still consider shopping carts and log-ins fundamentally a type of
> tracking, but Sid points out that "tracking" has a negative connotation that
> isn't necessarily fair for those types of uses.
> 
> Overall I think we need to rename cookies throughout the UI so that it is more
> than just an extremely abstract metaphor.  Another idea:
> 
> 1st party: "preference cookie" [switch icon]
> 3rd party: "tracking cookie" [being tagged in the wild]

in the cases of shopping carts, session management, and personization cookies there is a direct connection with the site I think I'm interacting with

amazon -> my amazon shopping cart
gmail -> my gmail login

yes, cookies used for these purposes might be considered tracking, but the tracking is limited to within the same origin or clearly connected to the site I'm interacting with.  These generally have been used to create better interaction with a single site.

On the contrary "third-party cookies", CSS :visited, and other techniques have been used to track movements of users across unrelated sites.  Depending on your point of view these techniques are being used to improve your experience across the web as a whole with things like targeted ads, or they are trying to violate the "same origin" policies on which the web is founded.   Users need to understand both sides of this argument to make an informed decision.  In a lot of ways this do-not-track setting is more of a vote, than an actual control in the browser, at least in the early implementation and adoption of the feature.
Comment 24 Sid Stamm [:geekboy or :sstamm] 2011-01-27 14:19:57 PST
Created attachment 507661 [details] [diff] [review]
proposed patch

Update for proper location of the string.  The checkbox in this patch says "Tell web sites I don't want to be tracked"
Comment 25 Alex Faaborg [:faaborg] (Firefox UX) 2011-01-27 18:37:30 PST
Comment on attachment 507661 [details] [diff] [review]
proposed patch

Let's go with "do not" since this is in the user's voice (I do not) and it seems more forceful and direct.  Also creates direct mapping to the commonly known name of the feature.

Can you attach a screenshot of the string location.
Comment 26 Sid Stamm [:geekboy or :sstamm] 2011-01-27 19:42:43 PST
Thanks Alex, I'll update the string.  The location is the same as in attachment 506305 [details] (just has a different string).
Comment 27 Jonathan Mayer 2011-01-28 00:48:34 PST
The first party vs. third party distinction seems important to communicate, otherwise users might believe the feature is intended to preserve privacy on the sites they visit.  That said, I agree with Alex that "third party" is jargon-y.  How's this for a balance: "Tell advertisers and other third parties I do not want to be tracked"?
Comment 28 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-28 07:14:08 PST
It's not just advertisers, though - I think we want to keep the string as short simple as possible, and educate users elsewhere about what's meant by tracking. Note that this hasn't really been decided by the industry itself.

I agree with faaborg's ui-review.

Upgrading to softblocker.
Comment 29 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-28 07:36:44 PST
Comment on attachment 507661 [details] [diff] [review]
proposed patch

Sid, when you update the patch, please also observe the following nits:

+<!ENTITY donottrack.label                "Tell web sites I don't want to be tracked">

should be camelcaps ("doNotTrack.label") and should also have:

<!ENTITY doNotTrack.accesskey "d">

and add &doNotTrack.accesskey to the checkbox in the XUL.
Comment 30 chris hofmann 2011-01-28 08:36:34 PST
>  How's this for a balance: "Tell advertisers and other third parties
>  I do not want to be tracked"?

In this case the advertisers *are* the "3rd Parties"

        -> website  <->
  you   -> website  <->  adveritising networks   
        -> website  <->

you interact with websites, and websites interact with the ad networks to track you and serve up targeted content.

  "Tell websites *and* ad networks that you don't want to be tracked" is most complete but I agree that that is pretty long winded.

The whole point of this feature is about education and communication.  education about what's happening as you use the web and visit sites, and eduation about how this feature is a first step where users can express a desire not to be tracked.  Can we have a [learn more about this]  near the UI with a link to a page that explains what this setting is trying to do?

Rightfully, the user could ask the question if I change this setting, what should I expect to see that's different?  The answer to that is complicated and deserves a help page.
Comment 31 Sid Stamm [:geekboy or :sstamm] 2011-01-28 10:47:25 PST
Created attachment 507907 [details] [diff] [review]
proposed patch

Updated to add access key, fix camel caps, wording to be "do not".
Comment 32 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-01-28 11:30:19 PST
Comment on attachment 507907 [details] [diff] [review]
proposed patch

>diff -r 98aae05d1141 browser/components/preferences/advanced.xul

>+      <!-- Tracking Preference -->
>+      <preference id="privacy.donottrackheader.enabled"
>+                  name="privacy.donottrackheader.enabled"
>+                  instantApply="true"
>+                  type="bool"/>

Why instantApply="true"? Doesn't seem like this needs to override the default behavior. (I'm not sure the comment is particularly useful either)

>+            <checkbox id="privacyDoNotTrackPrefs"
>+                      label="&doNotTrack.label;"
>+                      accesskey="&doNotTrack.accesskey;"
>+                      flex="1"
>+                      preference="privacy.donottrackheader.enabled"
>+                      accesskey=""/>

Duplicate "accesskey" attribute, so this doesn't work. Also I don't think you need the flex="1".

Otherwise this looks good, r=me with those addressed.
Comment 33 Mike Beltzner [:beltzner, not reading bugmail] 2011-01-28 12:30:39 PST
(I'd told Sid to copy-n-paste from the bit above, so thanks for the nits, Gavin!)
Comment 34 Sid Stamm [:geekboy or :sstamm] 2011-01-28 12:43:17 PST
Created attachment 507974 [details] [diff] [review]
proposed patch

This patch addresses the nits, thanks Gavin.  Carrying over the r+ and ui-r+.
Comment 35 Reed Loden [:reed] (use needinfo?) 2011-01-28 12:59:37 PST
Comment on attachment 507974 [details] [diff] [review]
proposed patch

>+            <checkbox id="privacyDoNotTrackPrefs"
>+                      label="&doNotTrack.label;"
>+                      accesskey="&doNotTrack.accesskey;"
>+                      flex="1"
>+                      preference="privacy.donottrackheader.enabled"/>

The flex="1" is still there... Is that actually needed?
Comment 36 Sid Stamm [:geekboy or :sstamm] 2011-01-28 13:44:27 PST
Created attachment 507985 [details] [diff] [review]
proposed patch

Oversight on my part... forgot to remove the flex attribute.  This patch should fix that (thanks reed).
Comment 37 Dão Gottwald [:dao] 2011-01-29 02:44:10 PST
String changes need explicit approval.
Comment 38 Axel Hecht [:Pike] 2011-01-29 04:57:19 PST
Land this please.
Comment 39 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2011-01-30 00:11:47 PST
Pushed http://hg.mozilla.org/mozilla-central/rev/7e2774d22116
Comment 40 Mike Shaver (:shaver -- probably not reading bugmail closely) 2011-01-30 07:08:26 PST
Then it's FIXED, no?
Comment 41 [:Cww] 2011-02-01 14:01:27 PST
(In reply to comment #30)
 
>Rightfully, the user could ask the question if I change this setting, what
should I expect to see that's different?  The answer to that is complicated and
deserves a help page.

I'm writing the help page :)  We'll make sure to link to it from the help page accessible from the question mark on that panel of the options dialog.
Comment 42 Matt Wilkinson 2011-02-04 11:18:27 PST
I have verified that this bug is fixed on Firefox 4 Beta 11 on Linux x86_64.
Comment 43 Alex Faaborg [:faaborg] (Firefox UX) 2011-03-25 10:28:20 PDT
Follow up bug 645063 for moving this over to the privacy prefpane in Firefox 5.
Comment 44 Vlad [QA] 2011-04-04 04:37:57 PDT
Verified on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre

The text appears as intended.

Note You need to log in before you can comment on or make changes to this bug.