- From: David Singer <singer@apple.com>
- Date: Mon, 14 Jan 2013 08:35:08 -0800
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: "'Roy T. Fielding'" <fielding@gbiv.com>, wileys@yahoo-inc.com, 'Tracking Protection Working Group' <public-tracking@w3.org>
On Jan 12, 2013, at 10:27 , Mike O'Neill <michael.oneill@baycloud.com> wrote: > The user-agent wouldn't have to check every time (for mutual referencing > same-party array entries) , just the first-time the same-party site is > visited. For example webmail.com has a same-party array containing > ["att.webmail.net",bt.webmail.co.uk","*.webmail.org",---] and executes the > exception API. The user-agent stores exception status for all *.webmail.com, > as well as att.webmail.net, bt.webmail.co.uk and all *.webmail.org but sets > a "check_same_party" flag for all domain origins other than those that match > *.webmail.com > > The first time it visits, say, att.webmail.net ( or any *.webmail.org) if it > finds an exception and "check_same_party" is true it checks that its > same_party array contains an entry that matches *.webmail.com. If it does it > clears the flag and sets DNT:0, otherwise it removes the exception. > > The extra round trip (to the TR) would be negligible. Yes, I expect that regular UAs will only check sometimes, if at all. I just think it ought to be logically possible to do sanity and consistency checks, and it is. > > Also I think we should have another name for joint-controllers so we don't > cause confusion. Maybe joint_party or something similar. Yes, agreed. I think these three have different characteristics: a) same party; this is bi-directional and inclusive "a and b are in the same party" means also "b and a are in the same party" and if "b and c are in the same party" then "a, b and c are in the same party" b) joint ownership: "the joint owners of c are a and b" does not say anything else about the relationship between a and b (other than that one presumes they are not the same party, because then the declaration would not be needed) c) service provision: "a is providing service to b" is clearly not reversible, and it's not inclusive, in that if "a is providing service to c", we still know nothing about the relationship between b and c. As usual, in the cases where hostnames or partial non-public-suffix hostnames are shared, certain conclusions/implications might be drawn without explicit declaration. peace > > Cheers > > > Mike > > -----Original Message----- > From: David Singer [mailto:singer@apple.com] > Sent: 12 January 2013 00:19 > To: Roy T. Fielding > Cc: Tracking Protection Working Group > Subject: Re: action-334, issue-112, a summary on sub-domains for exceptions > > > On Jan 11, 2013, at 15:05 , "Roy T. Fielding" <fielding@gbiv.com> wrote: > >> On Jan 11, 2013, at 10:00 AM, David Singer wrote: >>> 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. >> >> The current same-party definition is for an array of domains inside >> the first party's TSR. We could change that to a link (pointer), but >> that means managing yet another resource on the first party site and >> needing yet another request to get that information. Right now, the >> API (as I understand it) doesn't require any additional network >> requests to work because the javascript already knows what domains for >> which it needs an exception. >> >> Someone else does not say they are part of Yahoo! Yahoo's site says >> the following domains are part of me, and if the UA wants to verify >> that they can simply look at Yahoo's site tracking status resource. >> >> In short, I see no value to this new design and plenty of extra cost. > > OK, it was an attempt at a minor optimization. > > As it is, which is OK, if you want to confirm, you visit site fooey.com, and > fetch its same-party resource. It says "yahoo.com, barree.com, yahoo.com". > You wonder if this is all true, and you visit those other two sites to get > their same-party resources, and they contain fooey.com. It's a little more > complex than comparing "are they the same pointer?" or "are they the same > strings?" (because they may have the site names in a different order, or > yahoo may claim more same-party sites than the subsidiary sites need to > mention), but it's do-able. > >> >> ....Roy >> > > David Singer > Multimedia and Software Standards, Apple Inc. > > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Monday, 14 January 2013 16:35:45 UTC