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.

Received on Friday, 4 January 2013 14:55:28 UTC