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."
This header *really* should not have an "X-" prefix, and potentially be discussed in the IETF websec Working Group.
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!
Wording-wise, I'd prefer something a little stronger: "Tell 3rd-party sites not to track my browsing activity."
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.
Wouldn't it better fit in the "Privacy" section?
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.
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)
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."
Or "Tell Web sites that I do not wished to have my browsing activity tracked and shared." the ("and shared" meaning 3rd party)
wished/wish want? wish seems kind of weak
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. :-)
Tracking: [x] DO NOT WANT
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.
>Tracking: [x] DO NOT WANT exactly :) I'll put together a quick mockup with a few options
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.
Attachment #506496 - Attachment description: Top billing in the privacy pref pane → Top billing in the privacy pref pane (probably future work)
(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.
>"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...
> 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.
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.
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]
>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.
(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.
Update for proper location of the string. The checkbox in this patch says "Tell web sites I don't want to be tracked"
blocking2.0: --- → ?
Whiteboard: [strings] → [strings][d?]
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.
Attachment #507661 - Flags: ui-review?(faaborg) → ui-review-
Thanks Alex, I'll update the string. The location is the same as in attachment 506305 [details] (just has a different string).
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"?
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.
blocking2.0: ? → final+
Whiteboard: [strings][d?] → [strings][softblocker]
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.
Attachment #507661 - Flags: review?(gavin.sharp) → review-
> 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.
Updated to add access key, fix camel caps, wording to be "do not".
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.
Attachment #507907 - Flags: review?(gavin.sharp) → review+
Attachment #507907 - Flags: ui-review?(faaborg) → ui-review+
(I'd told Sid to copy-n-paste from the bit above, so thanks for the nits, Gavin!)
This patch addresses the nits, thanks Gavin. Carrying over the r+ and ui-r+.
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?
Oversight on my part... forgot to remove the flex attribute. This patch should fix that (thanks reed).
String changes need explicit approval.
Land this please.
Then it's FIXED, no?
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(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.
I have verified that this bug is fixed on Firefox 4 Beta 11 on Linux x86_64.
Status: RESOLVED → VERIFIED
Whiteboard: [strings][softblocker] → [strings][softblocker][fx4-fixed-bugday]
Follow up bug 645063 for moving this over to the privacy prefpane in Firefox 5.
Verified on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre The text appears as intended.
You need to log in before you can comment on or make changes to this bug.