Re: TPE last-call issues on my plate, summary [2]

Where I think we are with the LC issues.  The debate with Anne is ongoing, and I am just the editor; decisions are the WG’s.



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 -> effective script origin, so it now reads

> If domain is supplied and not empty then it is treated in the same way as the domain parameter to cookies and allows setting for subdomains. 
> 
> If the effective script origin would not be able to set a cookie on the domain following the cookie domain rules [COOKIES] (e.g. domain is not a right-hand match or is a TLD) then the duplet must not be entered into the database and a SYNTAX_ERR exception should be thrown.

But Anne responds:

> No, effective script origin is wrong. That takes document.domain into
> account, we most definitely do not want to do that for new features.
> I'm not sure what you mean by target, is there an updated editor's
> draft available?
> 

I have not edited the draft, waiting for consensus.  A target is where we’re about to send an HTTP request to, and we’re trying to work out whether an exception (site-wide, or, web-wide) applies and hence whether to send DNT:0.

OK, if we don’t want to take document.origin into account, what is the alternative?  We want a script hosted by a library to be usable by a service, and for the origin checking to be related to the service, not the library. Effective script origin says that, doesn’t it?

also

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.

I am just the editor; the WG needs to debate and decide.

On Oct 9, 2014, at 12:03 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> If the problem is enumeration we do have the same-party property in the TSR (where a controller/site can declare its other domains). If we used that then we would not be restricted to subdomains.

we had long discussions over enumerated lists, as I recall, and we were not able to get consensus.  the same-property list in the TSR is informative etc., rather than driving API operation.  we also can’t fetch it at every moment we want to send a DNT header; that decision needs to be fast.


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

> 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. 

> 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.

> 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.

agreed.  still need help on how to write this (or an example). Robin?

> 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>

> We generally avoid things like
> "explanationString" or "siteName" as they are open to abuse. Also,
> putting "String" in the member name seems redundant.

agreed, these will be removed from the bag.


David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 14 October 2014 17:23:59 UTC