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

On Jan 10, 2013, at 17:09 , Shane Wiley <wileys@yahoo-inc.com> wrote:

> David,
> 
> You hit my core concern with "preferably by using a shared list" as it appeared the way Mike had described the interaction that the "shared list" would be bound by same origin requirements and this would require a list per domain variation.  As long as we're okay that the domain flagging "include these related domains" not require a same origin for storage of said list, then we should be okay.  I believe it would be a requirement that the domain pointing at the shared list exist in the list themselves as a sanity check is appropriate.  Agreed?

I think we are converging.  What I was saying was that it's easiest if the 'same-party' pointer at the various sites actually is the same URL, and includes all those sites.  So then it's clear that

fooey.com -> http://www.example.com/resources/same-party.txt
example.com -> http://www.example.com/resources/same-party.txt
and that file contains
example.com
fooey.com

Then it's clear that fooey.com and example.com are indeed part of the same party.  We need to avoid someone saying "I'm part of Yahoo!" when Yahoo! does not agree, or at least have that case detectable and flaggable.


> 
> - Shane
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com] 
> Sent: Monday, January 07, 2013 4:58 PM
> To: Shane Wiley
> Cc: Mike O'Neill; public-tracking@w3.org
> Subject: Re: action-334, issue-112, a summary on sub-domains for exceptions
> 
> Since I am not sure I understand you, I have a sneaky suspicion you might not understand me.  Let me see if I can be clearer, and then maybe fogs will disperse.
> 
> Currently, both calls to establish exceptions (site and web-wide) take an 'implicit parameter' of the document origin of the calling script.  Basically, the script is asking for an exception for 'me', where 'me' is implicitly identified.
> 
> The suggestions are two-fold:
> 
> a) make it either automatic, or possible via a boolean parameter, to say "and also include my sub-domains". That means that if a script's document origin is example.com, www.example.com, images.library.example.com, and so on, would all be included.
> 
> Since this doesn't solve the problem of parties with sites that have un-related hostnames, we also consider:
> 
> b) make it either automatic, or possible via a boolean parameter 'and also include every other site in my party', or via an explicit list of sites, to include unrelated site-names.  That means that if boringthemovie.com and terriblethemovie.com are owned by badstudios.com, then if all three claim (preferably by using a shared list) that they are the same party, then a call from say badstudios.com to set up an exception could or would include setting it up as if boringthemovie.com and terriblethemovie.com had also made the call, at the same time as badstudios.com did.
> 
> In case (b) I think the UAs might want to make sure that the lists obey certain sanity checks (that the two parties both claim each other as the same party, that the list includes the site making the call, and so on).  That would also mitigate against someone claiming (for example), "com" is 'same party' with me, as there won't be a same-party list at "com" (or any other public suffix).
> 
> I think if (a) says "include sub-domains" and (b) says "include same-parties", then you'd also get subdomains of the same parties (images.badthemovie.com) and so on.
> 
> Clearer now?
> 
> I fear this is complex, and would love to see a simpler idea that nonetheless addresses the issues, so if you have a better idea, or places where this still doesn't address the issues, tell us...
> 
> 
> On Jan 7, 2013, at 11:24 , Shane Wiley <wileys@yahoo-inc.com> wrote:
> 
>> 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.
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 11 January 2013 18:01:14 UTC