702380 - Provide interface to allow control of do-not-track signal on a per-site basis

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[JMF]

Right before the do-not-track header was implemented in bug 628197, extensions such as NoScript and AdBlock Plus were already capable of sending or experimenting with that header.

The developers of both extensions also provided some way of specifying exceptions, so that while having the feature enabled, the header would not be sent to some specified sites.

When the developer of ABP presented the feature in the extension blog, he said "Adblock Plus approach is more flexible [than the one in Firefox] and allows sending Do Not Track to particular servers only (right now it is not clear whether this flexibility will be necessary)."
While it was not clear then, it is known that the DNT header breaks the admin pages of some routers (bug 662151).
Also, there may be some sites where for some reason a user may want to be tracked.

While turning off DNT in Firefox and using ABP to manage the sending of DNT headers potentially solves bug 662151, the navigator global object do-not-track signal added in bug 629535 is not defined by extensions.
This creates a situation where you can either control DNT header per site but not navigator.doNotTrack, or you have both but for all sites.

My suggestion is that Firefox should provide an interface that extensions can use to override the donottrackheader preference.
This interface would allow extensions to define navigator.doNotTrack and whether the DNT header would be sent, according to current site.

Comment 1

[Sid Stamm [:geekboy or :sstamm]]

Rules dictating per-site DNT-header sending won't line up with rules for the navigator global object in bug 629535. Third-party tracking scripts rarely run in the context from which they were served.

For example, content.com may load scripts from tracker.com, but the tracker.com scripts will run in the context of content.com -- so tracker.com will see the global object DNT value for content.com.  If one is whitelisted and the other is not, we get a different HTTP header value than navigator global object value.

Unless someone has an idea of how to reconcile this conflict, it's looking like we have to either have the navigator global object (bug 629535) *or* per-site DNT (this bug).

This feature request does not block 662151: there are other ways to fix that.
This feature request does not depend on bug 629535: they may in fact not be compatible with each other.

Comment 2

[JMF]

Thank you for your answer and for clarifying the issue.

Concerning the blocking of 662151, it seems obvious to me now. I just wanted to add it as a reference, because that bug that could be solved by this.
Since there is no feature like "Solves: 662151" I incorrectly used block.

For the dependence on 629535, I would argue that this suggestion depends on the existence of that navigator global object, just as 629535 was dependent on 628197 - Implement do-not-track HTTP header...
This bug is not meant to replace 629535, but to add features to it.


About your example with content.com and tracker.com... I see the issue there, and I think it has a few similarities with the situation in bug 629535, comment 3, and the followup comments 4 and 5.

In your specific example, do you mean a case where content.com is whitelisted and tracker.com is not?
In this case, tracker.com would run in the context of content.com and wouldn't be presented with navigator.doNotTrack="yes", right? But I guess that since the user has agreed to be tracked by content.com, it could be considered implicit that the agreement extends to tracker.com just for this particular site...

Also, how is a similar situation dealt with when using geolocation? Do scripts loaded from tracker.com have access to geolocation info allowed for content.com, even if it is supposedly blocked for tracker.com?
By the way, not dismissing the suggestion of exposing the control of DNT features to extensions, the per-site control of DNT in Firefox could be configured in another entry in about:permissions, just like the options for geolocation and cookies are.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We could make the DNT property on the navigator inaccessible to third party iframes.  Not sure if that's desirable though.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #3)
> We could make the DNT property on the navigator inaccessible to third party
> iframes.  Not sure if that's desirable though.

It probably wouldn't help (scripts in those iframes are in the same context as the document hosting them).  The real problem is third-party scripts (served from a different domain).

(In reply to JMF from comment #2)
> In your specific example, do you mean a case where content.com is
> whitelisted and tracker.com is not?
> In this case, tracker.com would run in the context of content.com and
> wouldn't be presented with navigator.doNotTrack="yes", right? 

Sure.  Or the other way around... both are confusing because the third party script gets one signal in the HTTP header and a different one in the DOM.

> But I guess
> that since the user has agreed to be tracked by content.com, it could be
> considered implicit that the agreement extends to tracker.com just for this
> particular site...

I'm not convinced that's what users expect, nor what the tracker.com site expects.  What does the site do when they get mixed messages?  The HTTP request comes with a "DNT:1" flag, but navigator.doNotTrack is set to "no"... what are they supposed to do?  This mismatch confuses the signal.

> Also, how is a similar situation dealt with when using geolocation? 

Geolocation information is not provided via an HTTP header.  It's only DOM-based, so it doesn't have the mismatched contexts like third party embedded scripts.

> By the way, not dismissing the suggestion of exposing the control of DNT
> features to extensions, the per-site control of DNT in Firefox could be
> configured in another entry in about:permissions, just like the options for
> geolocation and cookies are.

I agree that is a good place for the DNT whitelist UI if we implement it.

Comment 5

[Tom Lowenthal]

I would suggest against active development in this area while the W3C working group still has so many details up in the air. Let's wait for a more concrete technical spec, then start optimizing our response to it

Comment 6

[Aleecia]

Actually -- this might be a good point for Mozilla to help the W3C group create a sane, implementable standard. I agree with Tom that devoting dev time is premature, but sitting down to talk through what the standard should look like could be very helpful. I have nothing to contribute to that discussion, but if you do meet I'd like to sit in to get up to speed.

Comment 7

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.