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

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