RE: action-334, issue-112, a summary on sub-domains for exceptions

David,

I'm not sure the value of hosting the information in the same-party array (suffixes) versus allowing direct calls - but let's move past that.  The important issue for me is that there be only a single same-party array, not one array per origin, as that would become a nightmare to manage operationally.  I believe your approach does require an array per origin though, correct?

- Shane

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Friday, January 04, 2013 10:36 AM
To: Shane Wiley
Cc: Mike O'Neill; public-tracking@w3.org
Subject: Re: action-334, issue-112, a summary on sub-domains for exceptions


On Jan 4, 2013, at 9:24 , Shane Wiley <wileys@yahoo-inc.com> wrote:

> I disagree with attempts to over-architect the exception API to provide false security against bad actors that will be fully discoverable and addressed if misuse occurs (not expected - it would be beyond stupid for a bad actor to do this).  I stand by the original point of view that having appropriate wild-card options for both sub-domain and domain suffixes is fair.  Additionally, as long as the exception request is coming from the origin domain (1st party), it should be able to provide exceptions for other domains within its 1st party family of domain names (yahoo.com can request an exception for flickr.com).  The more hurdles we place in-front of legitimate good actors in these misguided attempts to block bad actors, who won't honor DNT anyway, is wasteful and will limit implementation of DNT.
> 
> - Shane

Shane

I am indeed trying to make it possible for the legitimate actors to operate, without getting into excessive difficulties.  I sense you disagree with the summary, but both Mike and I outline a solution which covers the use-case you describe, so I am not sure what you want that is different.  

Specifically, again:

* if the call is made from document origin x.y.com, make it apply to all domains q.x.y.com etc. (optionally controlled by a parameter, though I am not sure it's needed)
* allow provision of the same-party array at the time of call, or a parameter that requests the UA to fetch it, and add all those hostnames (again, possibly as suffixes as well) to the exception call.

This makes the API quite a bit more complicated, and makes answering the question "does <this> exception still stand?" rather harder, but they seem manageable.

> 
> -----Original Message-----
> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
> Sent: Friday, January 04, 2013 7:55 AM
> To: 'David Singer'
> Cc: public-tracking@w3.org
> Subject: RE: action-334, issue-112, a summary on sub-domains for 
> exceptions
> 
> Hi David,
> 
> That's a good summary. I think option 4 would be best i.e. 
> same-parties too
> + all subdomains of document origin, but we should have the subdomain 
> + option
> called for by a new API parameter (as Nick Doty suggested), for where 
> subdomains identify totally different entities like att.webmail.com 
> and bt.webmail.com, and webmail.com needed its own exception
> 
> Mike
> 
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 03 January 2013 23:51
> To: public-tracking@w3.org
> Subject: Re: action-334, issue-112, a summary on sub-domains for 
> exceptions
> 
> This thread went dormant without much of a conclusion in November, as I perceive.  The issue is around the use of wild-cards in the exception API.
> 
> There are two places that host-names occur in the APIs:
> 
> * the 'implicit' parameter, the site making the call, and that will 
> become the first of the two host-names in the remembered record 
> [top-level, target]
> * the explicit 'target' parameter for site-exceptions.
> 
> Wild-carding the second is easily handled; we already allow the request to be for the entire web ("*"), and even if it is not, we allow the user-agent to make it so.  So allowing the explicit parameters to include wild-cards (e.g. *.adservice.net) is clearly harmless, as it's more restricted than a plain "*" which it could be converted to.
> 
> 
> We're left with the problem of the implicit parameter.  What issues come up?
> 
> A.  Some parties have reasonably large numbers of hostnames/sites. Sometimes they are related in name, sometimes not.  Movie studios, for example, often create a new site for each movie they release (e.g.
> http://www.skyfall-movie.com/site/ or http://yimg.com, as well as http://developer.apple.com). This list of sites is sometimes dynamic (changes over time).
> 
> B.  We don't want to allow a site to register an exception for a "public suffix", and thereby grant an exception to unrelated parties.  For example, if someone asked for a site exception for anything embedded on *.com, then huge numbers of unrelated parties would be getting an exception.
> 
> C.  We don't want to have to check the public suffix database (http://publicsuffix.org, which is huge and unwieldy) at all if possible, and at most on the API call and not when headers are sent.
> 
> D.  We don't really want to do a fetch on the "same-party" array at the time of the call, and we cannot possibly fetch it each time we generate an HTTP header.
> 
> E.  We have to watch where the wild-card asterisk goes; for example, with ICANN generating TLDs like water, we don't want to have yahoo.* registered, or we'll run into the same "unrelated parties" problem as before. It's not clear who would register such a mistake, however ("cui bono?") but a lack of motive doesn't mean we should allow such an obvious mistake.
> 
> 
> Here are some possibilities:
> 
> 1 allow the APIs to indicate a top-level domain which has the form *.<rest>, where *.<rest> must match the domain making the call (the document origin of the script), and <rest> must not be a public suffix.  That allows scripts.google.com to supply a script that asks for an exception for *.google.com.
> 
> 2 allow the APIs to ask for the exception for "myself" (the document origin of the script) "and all my same-parties too" (a fetch at API time of the same-party array).
> 
> 3 say that the document-origin of the script should be a site with a short hostname, and allow the exception to apply to sites with that as a suffix (e.g. make the call from google.com, and then the exception applies to *.google.com). That avoids the public suffix issue, but not the unrelated site-names issue.
> 
> 4  combine 3 with 2, and say that if blah.com is declared as a same-party, then the exception applies to *.blah.com.
> 
> 
> I cannot see a way to avoid having sites that dynamically create unrelated site-names (e.g. the skyfall site above) from calling the API again to apply to that site.  There's no way we can do the check of same-party dynamically, from the user-agent.
> 
> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Monday, 7 January 2013 19:36:52 UTC