Bug 88055 – Support Do Not Track HTTP Header.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit BlackBerry

[Jason Liu]

Every major browser has support for do not track, except Chrome and they've
committed to adding it this year.

Main site: http://donottrack.us/

Basically involves the user allowing/disallowing tracking, and the HTTP header
is added and value set appropriately.

[Jason Liu]

Created attachment 145525 [details]
Patch

[WebKit Review Bot]

Comment on attachment 145525 [details]
Patch

Attachment 145525 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12895230

New failing tests:
fast/dom/navigator-detached-no-crash.html

[WebKit Review Bot]

Created attachment 145535 [details]
Archive of layout-test-results from ec2-cr-linux-02

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Jason Liu]

Created attachment 145542 [details]
Patch

[Rob Buis]

Comment on attachment 145542 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=145542&action=review

The code looks good to me. But I think we need to make sure chromium folks like this as well, and that nobody is doing duplicated work on this feature?

> Source/WebCore/platform/network/blackberry/NetworkManager.cpp:79
> +    request.initializePlatformRequest(platformRequest, frame.loader() && frame.loader()->client() && static_cast<FrameLoaderClientBlackBerry*>(frame.loader()->client())->cookiesEnabled(), static_cast<FrameLoaderClientBlackBerry*>(frame.loader()->client())->doNotTrackEnabled(), isInitial, redirectCount);

Maybe by now you can store frame.loader()->client() in a temp variable since you reference it a lot, also might be able to get rid of the static_cast that way.

[WebKit Review Bot]

Comment on attachment 145542 [details]
Patch

Attachment 145542 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12902233

New failing tests:
fast/dom/navigator-detached-no-crash.html

[WebKit Review Bot]

Created attachment 145587 [details]
Archive of layout-test-results from ec2-cr-linux-04

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[George Staikos]

(In reply to comment #6)
> (From update of attachment 145542 [details])
> Attachment 145542 [details] did not pass chromium-ews (chromium-xvfb):
> Output: http://queues.webkit.org/results/12902233
> 
> New failing tests:
> fast/dom/navigator-detached-no-crash.html

Is this crash really due to this patch?

[Adam Barth]

> > New failing tests:
> > fast/dom/navigator-detached-no-crash.html
> 
> Is this crash really due to this patch?

The problem is that you've updated the -expected.txt file for all ports even though you've only implemented this feature on a subset of ports.

[Adam Barth]

Comment on attachment 145542 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=145542&action=review

Please email webkit-dev before adding new features, as explained at http://www.webkit.org/coding/adding-features.html

> Source/WebCore/page/Navigator.idl:42
> +        readonly attribute boolean doNotTrack;

This feature should be behind an ENABLE macro so that ports can decide whether they wish to implement this feature.

[Ian Fette]

The DNT spec is a lot more than just "Send DNT:1". There's a whole section on allowing the user to grant exceptions to DNT for specific sites or third parties, as well as reading the server response to DNT which will state whether the server is or is not tracking and have a pointer to policy.

I'm a bit worried that a port simply enables what this patch proposes and thinks the now support DNT. DNT is far more complex than this.

[Jason Liu]

(In reply to comment #11)
> The DNT spec is a lot more than just "Send DNT:1". There's a whole section on allowing the user to grant exceptions to DNT for specific sites or third parties, as well as reading the server response to DNT which will state whether the server is or is not tracking and have a pointer to policy.
> 
> I'm a bit worried that a port simply enables what this patch proposes and thinks the now support DNT. DNT is far more complex than this.

Thanks for your information.
Do you know a test site with exceptions?

[Ian Fette]

There are no test sites at the present time to my knowledge, and the format for exceptions has not yet been clearly locked down. For that matter, the scope of exceptions is also under continued debate. That is, whether you have to explicitly list out all third parties that get an exception on a given first party site, or whether it's simply "all third parties on this site". Similarly under debate is the question of "if you explicitly list third parties, are the exceptions transitive? e.g. do exceptions follow redirects".

Given that there are so many open questions, I don't believe anyone has yet made a test site.

[Jason Liu]

(In reply to comment #13)
> There are no test sites at the present time to my knowledge, and the format for exceptions has not yet been clearly locked down. For that matter, the scope of exceptions is also under continued debate. That is, whether you have to explicitly list out all third parties that get an exception on a given first party site, or whether it's simply "all third parties on this site". Similarly under debate is the question of "if you explicitly list third parties, are the exceptions transitive? e.g. do exceptions follow redirects".
> 
> Given that there are so many open questions, I don't believe anyone has yet made a test site.

So I want to just implement the header DNT:1 and navigator as Firefox.
And add the exception after it is locked down.
Do you agree with me?

[Ian Fette]

Speaking as an individual, no, I do not agree. Firefox's implementation was done well before the standards process started. It is nowhere near compliant, and the meaning of DNT continues to be verymuch up in the air. As it is, implementing "just send DNT:1" is very asymmetric -- easy for someone to set DNT for sites, impossible for sites to request an exception, and that's not good. There's also a lot more than just sending DNT:1, there's the response headers (if you want to see if the server accepted your DNT request), etc, all of which is still highly in flux.

Just picking and choosing one super small part of the spec doesn't seem like a good idea.

[Basuke Suzuki]

Created attachment 338689 [details]
[WIP] PATCH

[EWS Watchlist]

Attachment 338689 [details] did not pass style-queue:


ERROR: Tools/MiniBrowser/win/MiniBrowserLibResource.h:0:  No copyright message found.  You should have a line: "Copyright [year] <Copyright Owner>"  [legal/copyright] [5]
Total errors found: 1 in 22 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Don Olmstead]

Working group has disbanded and ITP is being used