RE: TPE last-call issues on my plate, summary [3] (also issue-262)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David,

As I understand it, in HTML5 the "effective script origin" of a document is the same as the document's "origin" unless the attribute document.domain is changed. Changing document.origin allows you to set the effective origin of the script (i.e. which determines the scope of variables etc. ) to a value that removes subdomains, i.e. if a document has an origin https://subdomain.example.com:443 you can set the effective script origin to https://example.com:443. You cannot add subdomains, i.e. you cannot set the effective script origin to https://yetanother.subdomain.example.com: 443.

The src attribute of a library script tag does not have anything to do with the effective script origin. This just says where the script resource is located and may be loaded from.

I don't know why Anne says document.domain should be avoided for new features, though I take his word for it. Maybe he can explain?

As I said I don't think assigning exceptions to subdomains is much of an advantage anyway. It would be better to have a secure way to enumerate same party or service provider owned domains.

One way I thought of was to leverage the Content Security Policy work in the webapps security WG. We could ask for a new policy directive i.e. dntpermission-src which would be checked the first time a page was loaded to see if there is a match with the origin that initiated the exception. If there is no match the exception is discarded.

So to be concrete, script in origin http://publisher.com makes a call to storeSiteSpecificTrackingException with  StoreSiteSpecificExceptionPropertyBag.domain set to http://adex.com (i.e. we remove the cookie rule restriction). It does not matter for this example what is in arrayOfDomainStrings.

The UA stores a "tentative" exception which is checked the next time a request to http://adex.com is sent (with DNT:1 because it is tentative but not validated. This could also be done immediately using a prefetch)

If the http://adex.com response contains a CSP policy directive of:

Content-Security-Policy: <other policy directives> dntpermission-src publisher.com;

the tentative exception is validated and made real (so DNT:0 is sent in subsequent requests). If it does not the exception is discarded.

A confirm API call for this domain would return false until the exception was validated. Because we have removed the cookie like restriction another bonus is that ad exchanges can directly confirm if their contractees have web-wide exceptions. 

This is similar to CORS (it supports the spirit of the SOP) in that it requires both origins to refer to each other.

I think this could be made to work for CSPs in dynamic meta tags also.

Mike







> -----Original Message-----
> From: David Singer (Standards) [mailto:singer@apple.com]
> Sent: 11 November 2014 23:22
> To: Tracking Protection Working Group
> Cc: Anne van Kesteren
> Subject: Re: TPE last-call issues on my plate, summary [3]
> 
> 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.
> 
> I believe that there are two concerns left: Anne objects to taking
> document.domain into account (see below, but as of yet I am not sure what the
> alternative is), and he feels we haven’t captured all his replies (though at the
> moment I can’t work out what we haven’t captured).
> 
> 
> * * * * *
> 
> 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.
> 
> [Unresolved]
> 
> OK, if we don’t want to take document.domain 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, including extensions (which are permitted by
> the spec.)
> 
> > 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUY3EgAAoJEHMxUy4uXm2JrqEIAJDstpG+S57IHqKjZYJ//PRM
z+6quhDFlLibq030W/UZKN8YrCv3x+AE8kzs6KJkFzXvX8BzeAyxcDhhP2vCcVuT
vFjt11Pr8fDt18Kq6V/QDjo29X0HjeH+B1woGsxMBTCYQxk1fJXU9P+d8ItdK4zI
WtkDJHI3St46b4wypHT4q91/WD6mC1eiK9kSk5l9AY/xfYet5wgfPcug59ZUtYEe
qF4YdWBg8/c1hCzgsH53U3wXCV4IVY71buRhuMlkdjKc4o89NVfvgzlDEaE3+nRD
0AAvFQnR5uTL4mzUUBcknC/BcRjygyaCUzSzBZXBJqJEKbbeFFO54u7JKLRNruo=
=p475
-----END PGP SIGNATURE-----

Received on Wednesday, 12 November 2014 14:41:00 UTC