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.
Created attachment 145525 [details] Patch
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
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
Created attachment 145542 [details] Patch
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.
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
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
(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?
> > 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.
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.
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.
(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?
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.
(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?
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.
Created attachment 338689 [details] [WIP] PATCH
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.
Working group has disbanded and ITP is being used