- From: Standards <singer@apple.com>
- Date: Wed, 10 Dec 2014 09:17:42 -0800
- To: Tracking Protection Working Group <public-tracking@w3.org>
1. <http://www.w3.org/2011/tracking-protection/track/issues/243> terminology agreed top-level origin -> top-level browsing context as defined in <http://www.w3.org/TR/html5/browsers.html#browsing-context> a target is the Host part of an HTTP URL as defined in <http://tools.ietf.org/html/rfc3986#page-18> from which a resource is requested document origin of a script -> is the effective script origin definitions edited, as using these external forms throughout is cumbersome: + <li><strong>top-level origin</strong> is a <strong>top-level + browsing context</strong> as defined in [[!HTML5]]</li> + <li>A <strong>target</strong> site is the Host part of an HTTP + URL as defined in [[!RFC3986]]</li> + <li>The <strong>document origin</strong> of a script is the + <strong>effective script origin</strong> as defined in [[!HTML5]]</li> On Oct 9, 2014, at 10:05 , Anne van Kesteren <annevk@annevk.nl> wrote: > To be clear, cookies and document.domain and friends depend on > publicsuffix.org. That is bad. We don't want to increase the amount of > things that depend on that unless there's a very compelling reason. > Anything new we've done for the last decade or so has been based on > origins. There is a difference of philosophy here. The obvious problem: roughly, you need to be able to set an exception for a group of properties (hosts) from one of them (e.g. from dnt-center.yahoo.com, for all yahoo.comhosts), but obviously not see/set/cancel exceptions for properties that are not ‘yours’. The API operation, and the decision on whether a recorded exception applies in this case (i.e. the decision on what DNT header to send), both need to have a model that achieves this. The cookie model does, in fact, suffice, so we model it exactly (so the same code can be used). The WG prefers to have this spec fit into cookie processing. 2. <http://www.w3.org/2011/tracking-protection/track/issues/255> > 1. This API needs to be on window.navigator. No further polluting of > the global object. (This is also how it appears to be implemented.) agreed: + with read access to the Navigator object to determine what <a>DNT</a> + <dl class="idl" title='partial interface Navigator'> > 2. It needs to return an string enum rather than a string. (With > values "", "yes", and "no" or some such.) not agreed. It should be documented at this level as being whatever would be sent in a DNT header, if anything, including extensions (which are permitted by the spec. but not controlled at this level). > 3. It should not return null. No need to vary type. Not agreed. The meaning is that it is exactly what would be present in an HTTP DNT header. If any string (including an empty string) is returned, then a DNT header with that value would be sent. The special value NULL indicates that no DNT header would be sent. There is a difference between no DNT header and “DNT:” as a header. Note added: + <p class="note"> + Note that the value includes not only the "0" or "1", but also + any DNT-extension; if no DNT header is sent, the return value is + <code>null</code>, not an empty string (which would indicate that + a header is sent with no <a>DNT-field-value</a>). + </p> > 4. It should be exposed in workers. Agreed. Moving it (point 1) achieves this. 3. <http://www.w3.org/2011/tracking-protection/track/issues/256> > They need to allow for an asynchronous permission > check. In other words, return a promise. Not agreed. The call is synchronous from the point of view of the caller. We change the advice to say that a ‘confirm’ check is only needed for subsequent visits to the site; at the time of the call to store, the site has just obtained consent from the user, and can proceed knowing that, so even if the UA is ‘slow’ or checks with the user, there is no need to call the Confirm API at the time of the Store call. (possible issue: as the user moves from page to page, if the UA hasn’t done an immediate update, it may be that the HTTP headers don’t reflect the exception. This seems unlikely; the UA is allowing navigation while still thinking about storing the exception?) added: + <p>Nonetheless, at the time of the call the site has acquired the user's + consent, and can proceed on that basis, whether or not the user-agent + has stored the exception immediately. It is not necessary to call the + confirm API at the time of consent.</p> and changed - <p>Sites can call the 'Confirm' APIs to enquire whether a specific to + <p>On other visits, sites can call the 'Confirm' APIs to enquire whether + a specific exception has been granted and stands in the user agent. This is the call to make to determine whether the exception exists, and hence to control access to the function or operation; if it fails (the exception has been > within platform APIs we call "URI” URL Not agreed. DNT is an HTTP extension. URI is the correct term. > You have not defined cookie-like domain string. It is the cookie-domain defined in 5.2.3 of RFC 6265 <http://tools.ietf.org/html/rfc6265#section-5.2.3> + <dd>a cookie-domain as defined in [[!RFC6265]], + to which the exception applies.</dd> > We generally avoid things like > "explanationString" or "siteName" as they are open to abuse. Also, > putting "String" in the member name seems redundant. not agreed, we will document these as saying “the site claims” and add a note warning of the possibilities that the site may try to mislead, and the UA should present these carefully (if at all) added: + If user-agents present this to the user, it should be clear that + they are claims by the site, and might be written to mislead. 4. I added Mike’s expiry parameters, as written by him. David Singer Manager, Software Standards, Apple Inc.
Received on Wednesday, 10 December 2014 17:18:18 UTC