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

On Oct 9, 2014, at 0:31 , Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Oct 8, 2014 at 6:16 PM, Sid Stamm <sstamm@mozilla.com> wrote:
>> Adding Anne van Kesteren since he is not subscribed to the mailing list and had concerns about some of this.
> 
> Thanks Sid.
> 

Indeed.  I had just sent it to the wg and was about to send it to you but Sid beat me to it.

Note that I am trying to just accumulate the views of the working group and edit…you are right, I make no claims to be a modern javascript expert, and I don’t have much/any skin in this game.

But I think there may be an overall difference of philosophy here. When we were designing this, there was some doubt over whether (a) DNT will get traction and (b) whether sites will want or use this API.

Given that, the group tried to minimize difference from existing techniques, notably cookie and script cross-origin, so as to re-use as much as possible (concept and code).  I get the sense that you’d prefer a more modern design that represents an improvement on cookies, cors, and the like. I am not sure the group agrees; simple/compatible to implement is actually desirable.  (That’s why I hesitate about promise returns, for example, and I am pushing back gently on expiration parameters).

(For now, no detailed responses.)

> 
>> On Oct 8, 2014, at 9:04 AM, David Singer (Standards) <singer@apple.com> wrote:
>>> 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
> 
> 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?
> 
> 
> 
>>>> 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.
> 
> Sure, but that can still be done as an enum. Just needs to consist of
> "1" and "0" then. But it seems somewhat bad practice to compromise the
> legibility of the API due to size concerns over the HTTP header.
> 
> 
>>>> 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.
> 
> The empty string is not a valid value. If there's only three valid
> states, returning different types makes for a very cumbersome API. Did
> you talk to any JS developers?
> 
> 
>>>> 4. It should be exposed in workers.
>>> 
>>> Agreed.  Moving it (point 1) achieves this.
> 
> I guess this is not yet done in the editor's draft?
> 
> 
>>>> within platform APIs we call "URI” URL
>>> 
>>> Not agreed.  DNT is an HTTP extension.  URI is the correct term.
> 
> HTTP, at least in browsers, uses the same URL implementation as APIs
> do. I guess I don't really care what you decide to call it now,
> although it seems somewhat confusing with the other documents the W3C
> publishes, but you'll be wrong long 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>
> 
> That seems like a bad idea. We should not propagate the broken model
> of cookies further. New APIs must be origin-bound.
> 
> 
> -- 
> https://annevankesteren.nl/

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 9 October 2014 17:00:43 UTC