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 Friday, 4 January 2013 17:36:34 UTC