Re: Comments on Web Tracking Protection W3C Member Submission 24 February 2011

Adrian, Andy,

Here the feedback, as you requested in 
http://lists.w3.org/Archives/Public/public-tracking/2011Sep/0015

Please be sure to start new appropriate thread for things which matter.
Thanks.


Le 19 sept. 2011 à 14:53, Karl Dubost a écrit :
> I have comments on 
>    Web Tracking Protection
>    W3C Member Submission 24 February 2011 
>    http://www.w3.org/Submission/web-tracking-protection/


How to read
* quotes are spec text.
* my comments under each quotes


> "A filter list contains parts of third-party URIs 
> that a browser may access automatically when 
> referenced within a web page a user deliberately visits."

It assumes that tracking is made only through 3rd party uris.


> A third-party URI [URI] is a URI with a (second-level) domain name that differs from that of the top-level containing document.


The sentence is not very clear and might need to be rephrased. Maybe something like.

    When a user agent is sending an HTTP request 
    to a URI [URI], the server sends back a response 
    possibly containing further URIs. Among these URIs, 
    those with a different second-level domain name are 
    considered, in that document, third-party URIs.


> A user agent must evaluate any URIs that indicate a sub-document—such as an iframe or any URIs defined in any sub-documents—as third-party with respect to the topmost document.


not testable. This need to be framed as something implementable.
"MUST evaluate" doesn't mean anything in that context.



> A user-agent must apply a filter list to third-party URIs only.

not testable. Apply a filter list is not an operation in this case.


> When a user agent issues a request for a webpage and receives an HTTP status code that returns a document, and the user or user agent has chosen to apply a filter list, all third-party URIs that can generate a download request must be evaluated against this filter list.

incorrect sentence. Maybe something along the following paragraph will be the real implementable requirement

   (When the user and/or user agents have activated the 
   filter list mechanism,) for each HTTP response sent 
   by server, a user agent MUST drop any subsequent HTTP 
   requests according to the rules defined in the filter 
   list.


> When a user agent blocks a download, that user agent should fire any events pertaining to a download error, if applicable.

not defined. not testable.
What kind of events? It would be possible to initiate for example a value. For example, it could be possible to say something like

    For each blocked URI, a FILTER_BLOCK_URI exception and 
    the URI value SHOULD be fired in the error console.

This should be commented by people implementing the browser.


> Until this feature becomes standardized, vendors may use a prefix. For example, the Microsoft implementation uses msFilterList.

I would discourage any vendor prefixes. They do not work in an open distributed network. They are being deployed, forgotten and create legacy code that browser vendors have to maintain for a long time. It would work if the code was released in developer version of the browser, but that would be unlikely the case.


> 4.3 Settings

Format about the settings doesn't define what the browser should do with the spaces. There is plenty of things to define here to make it implementable by browsers. Specifically in terms of error recovery or draconian mode. 


> The value of n must be an integer between 1 and 30.

The value seems arbitrary. Is there any rationale behind this range?


> Expires

what is happening when no value is defined for expires. Is there a default value? Is the document invalid and should be ignored?



> For allow rules, the user-agent must evaluate the string specified in the domain part of the allow rule against the target URI, starting from the topmost domain label.

Not really testable. 



> The following allow domain rules fail to match and therefore fail to allow the URI,http://www.subdomain.example.com/file.html.

Interesting but… what is the purpose of allowing something if there is no disallow rules for the same domain before.  Or maybe is it implied? In this case there is a need for an example with the two: block and allow.


> 6.1 User Agents

It is not clear if you may have filter rules without having to send the DNT header. I think it should be orthogonal. The DNT header is a shout to the community, but not a protection. The filter list is a way to block. Users should not have to say why they are blocking this and that, specifically for privacy reasons.


> Websites that track users across multiple first-party websites must check for the presence of the Do Not Track user preference.

Not usefully testable. MUST is not appropriate. It might need to be reformulated. A MUST is for a software to do something with it.



> If a website detects that this preference is enabled, it must disable any tracking code or collection of data that can be used for tracking purposes, regardless of the level of identification of the user.

Not testable.
I guess it should be something along: 

    A tracking protection conformant server MUST @@do something@@ 
    with the "DNT: 1" HTTP header in each client HTTP request.
 

The issue is that I'm not sure what it is supposed to do and it is why it is not testable. 

* Record the log in HTTP logs? Too late it is already done by then. 
* Analytics software have been already activated into the Javascript. 
* Does that mean for example that the HTML page sent by the server should remove all javascript tracker codes in the page? 
* Should remove all transparent gifs before sending the response to the client?



Nothing is said in the document about intermediairies and proxies.



-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

Received on Tuesday, 20 September 2011 00:18:03 UTC