Wouldn’t it be possible for the 1st party to request the sub-domain breadth of site-specific exception that meets the 1st party definition in the argument of the request?
Site-Wide Exception (one domain, all subs): *.exampledomain.com
Site-Wide Exception (one domain, single sub): sub.exampledomain.com
Site-Wide Exception (one domain, multiple subs): [list].exampledomain.com
This somewhat follows the multi-domain list concept in the TPE.
Most websites will rely on the first structure and the 2nd two structures can be collapsed to the [list] approach (example #2 could be supported by a list of one entry).
This does create a window of opportunity to “over request” for an exception but we can hold the 1st party accountable for an inappropriate request. I don’t want to be hampered by the fear of misuse by bad actors in creating a solution that appropriately matches the real-world.
I don’t believe an exception would need to branch at the protocol level (HTTP vs. HTTPS) – does anyone have a real-world example where the secure element of a sub/domain pair is not owned & operated by the same 1st party of the non-secure element?
- Shane
From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Thursday, July 26, 2012 7:04 PM
To: ifette@google.com
Cc: public-tracking@w3.org Group WG
Subject: Re: ACTION-201 (ISSUE-112)
On Jul 25, 2012, at 8:36 AM, Ian Fette (イアンフェッティ) wrote:
"How are sub-domains handled for site-specific exceptions?" - from a browser standpoint, I don't wish to further propagate the notion of "registry controlled domains" which is an unfortunate reality that we currently have with cookies, where browsers try to keep a list of what is a "public suffix" (contains multiple unrelated entities beneath it, such as .com). We have ~6,800 entries in there so far (http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1) - this is only getting worse now that ICANN has, in a rather questionable move (personal opinion), decided to make the top-level domain namespace a wild west.
So, I don't want to say "all subdomains" because we have no idea what that means.
Rather, I would prefer to say "A site can request a site-wide exception for its own origin and any other origins that it considers to also be in the same party, e.g. http://www.example.com<http://www.example.com/> could request a site-wide exception for http://www.example.com, https://www.example.com<https://www.example.com/>, https://example.com<https://example.com/>, https://mail.example.com<https://mail.example.com/>, https://www.example.de, http://www.example.de<http://www.example.de/>"
Sadly, I fear this is going to become nightmarish as sites add and delete origins over time ("Hey, now we're http://search.google!" or "Hey, we just launched example.az<http://example.az/>" or "newproduct.example.com<http://newproduct.example.com/>"). That said, I've got nothing better to offer...
I certainly agree this could get nightmarish. What if we indicate that as a semantic matter, an exception is requested for the effective script origin (a la [0]) and then note that user agents might provide users with the option to automatically extend/persist such permissions on other affiliated origins? We could note the use of the "same-party" field in the tracking status resource (or, for that matter, OUR-HOST [1]) and if browsers implement this technique, that would provide an incentive for sites to document their party relationships.
It sounds like there's agreement that exception requests should not extend to sub-domains, given the uncertainty over what a sub-domain implies.
Thanks,
Nick
[0] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0104.html
[1] http://www.w3.org/P3P/2004/03-domain-relationships.html