Re: action-317, discussion of the service-provider flag and the same-party resource

Before you read all the long email, realize that Roy points out that the new first-party resource tells a system both (a) that my first-party is someone other than me, which is what the qualifier indicated, and (b) who that is, which the qualifier relied on something else for.  So it may well be true (pending reading the text) that the qualifier is not needed.


On Jan 22, 2013, at 12:22 , "Roy T. Fielding" <fielding@gbiv.com> wrote:

> This message completes ACTION-354 and regards ISSUE-137 ...
> 
> On Nov 28, 2012, at 4:07 PM, David Singer wrote:
> 
>> This discussion started in <http://www.w3.org/mid/43B85F59-7BD8-43D7-80B3-20F8FF1DEB1A@apple.com>.  This is the reference I was searching for on the call today.
>> 
>> 
>> I want to remind people we're not talking about 'all' kinds of service provision here.  We're specifically not talking about ISPs, hosting, content authoring, or anything EXCEPT services which are distinct end-points of HTTP transactions.
> 
> Why?  

Because the UA is talking only 'to' the end-points.  It can send requests or exceptions to end-points, but other service provision is invisible.  The privacy aspects of intermediaries that look at requests etc. will have to be handled differently, I regret.

> 
>> The basic problem we're trying to avoid is having a sensitive user and/or user-agent flag a site as suspiciously claiming rights it doesn't seem to have -- either first-party status when it's not the first party, or consent when it doesn't appear to have 3rd-party-with-consent status.
> 
> Again, why?  If we thought that was an actual problem, wouldn't the
> service providers be the ones wanting to address it?

Well, we are trying to give them and their first parties such a means.

> Why would a
> suspicious party be trusted just because they send an "s"?

They don't "just send an s", they indicate who they are serving, and the tracking status of that party can also be checked. That also makes it possible for that party to confirm or deny the relationship, if it wishes.

> 
>> Let's take a simple hypothetical example.
>> 
>> VisitCounter.com offers a 'basic' and a 'pro' service. They provide 3 levels of service; free, basic, and pro.  Free service gives you an widget iFrame you can embed, that visibly counts visitors.  Contract for basic, and they will provide you a report on your visitors -- silo'd, and so on -- but the domain is  still theirs.  Pro, and they'll register under visits.<yourdomain>, and also provide cookie analysis, and so on.
>> 
>> For the basic service, they look like a different site, different party.  And they appear under that name on multiple sites, say examplebank.com and examplenews.com.
>> 
>> examplenews.com and examplebank.com could add them into their same-party array, but if they add both examplebank and examplenews into their same-party array, that appears to be a claim that those two are 'the same party', which is not true.  If they don't add them, we have no indication or back-pointer.  Even if they add dynamically, somehow detecting where they are embedded, the risk remains, I think, that someone will join these later.
> 
> I can't follow your argument here.  Who is "they"?

rewritten inserting names for all "they":

VisitCounter.com offers a 'basic' and a 'pro' service. VisitCounter.com provide 3 levels of service; free, basic, and pro.  Free service gives you an widget iFrame you can embed, that visibly counts visitors.  Contract for basic, and VisitCounter.com will provide you a report on your visitors -- silo'd, and so on -- but the domain is  still VisitCounter.com's.  Pro, and VisitCounter.com will register under visits.<yourdomain>, and also provide cookie analysis, and so on.

For the basic service, VisitCounter.com looks like a different site, different party.  And VisitCounter.com appears under that name on multiple sites, say examplebank.com and examplenews.com.

examplenews.com and examplebank.com could add VisitCounter.com into their same-party arrays, but if VisitCounter.com adds both examplebank and examplenews into their same-party array, that appears to be a claim that those two are 'the same party', which is not true.  If VisitCounter.com doesn't add them, we have no indication or back-pointer.  Even if VisitCounter.com adds dynamically, somehow detecting where VisitCounter.com is embedded, the risk remains, I think, that someone will join these later.

> In the current draft, examplenews.com would have a tracking status
> resource (TSR) on its own site. If examplenews.com's same-party array
> includes VisitCounter.com, this means that examplenews.com claims
> that data collected via the references from examplenews.com to
> VisitCounter.com remains under the exclusive control of examplenews.com
> (i.e., VisitCounter.com is either the same party or a service provider
> acting as that same party, and thus subject to the data controls that
> give VisitCounter.com permission to track with siloing).

Yes, but same-ness is transitive: if a is the same as b, b is the same as a.  They are the same organization.

Service provision is a one-way relationship.

> 
>> Adding the 'I am a service provider' flag to their response, however, can help make it clear that they stand in a *service provider* relationship with some or all of the sites in the same-party array.
> 
> I think this is the source of confusion.  The same-party array is
> at examplenews.com and examplebank.com.  

and visitcounter.com

> The contents of the same-party
> array at VisitCounter.com would only be relevant if VisitCounter.com
> subcontracts its own services under the service provider rules;
> it would never contain examplenews.com and examplebank.com.

the contents of the WKR at any site are relevant.

> 
>> Big sites can afford to pay for 'pro', so the argument that the flag discriminates in favor of the large doesn't hold.
>> 
>> What am I missing?
> 
> The only possible reason to use a flag to indicate that a service provider
> is involved in the provision of services is to perform some form of
> automated discrimination against service providers.  

Since I nowhere proposed that or showed how or why it could happen, I don't agree.

> A flag provides
> no data transparency to the user.  What we already have in the draft
> is better than an "s" flag.

No, it's vaguer. That is not better, unless your preference is to be vague.

> 
> Let's consider your scenario above, but without any "s" flag.
> 
> The user agent sees a reference to VisitCounter.com on a page at
> examplenews.com.  Since it is in paranoid mode, it wants to verify
> that all links will adhere to DNT.  It probably already has a cached
> copy of the TSR for examplenews.com and sees that it either
> 
>  a) does list VisitCounter.com under same-party

But it's not the same party at all.

>  b) does not list VisitCounter.com under same-party
> 
> If (a), then examplenews.com is claiming to have control over data
> collected by VisitCounter.com.  If (b), no information is gained.

and visitcounter.com is probably spuriously claiming first-party status

> 
> The UA then requests the TSR for VisitCounter.com.  It will either
> decline to implement DNT or eventually provide a tracking status
> value (TSV) that applies to the link used at examplenews.com to
> reference its service.  That final TSV will be one of
> 
>  !) same as declines to implement DNT;
>  C) it is a third party that has the user's consent to track;
>  3) meaning that it is obeying the requirements on a third party
>     regardless of what examplenews.com said; or,
>  1) meaning that it is either the first party for this designated
>     resource or a service provider acting as a first party.
> 
> The UA then looks at the new "first-party" member in the TSR for
> VisitCounter.com.  

That helps.  That points at the first-party, and if it's not me, that diagnoses the same as the 's' flag.

> That member is one of:
> 
>  e) not provided
>  f) a link to a resource that says VisitCounter.com is the
>     data controller
>  g) a link to a resource that says examplenews.com is the
>     data controller
> 
> Now, let's break it down by the options listed above for this
> particular designated resource at VisitCounter.com:
> 
>  If (!), VisitCounter.com can't be trusted regardless.
>  If (3), it is a third party that adheres to DNT.
>  If (C), it can do whatever was consented by the user.
>  Hence, only (1) matters.
> 
>  If (1) and (e)/(f), then VisitCounter.com considers itself to be
>  the first party, which should be a concern for the UA regardless
>  of what is claimed by examplenews.com in (a) or (b).  In fact,
>  it might be a service provider (good news), but is contractually
>  prevented from claiming that it provides service on behalf of
>  examplenews.com -- they'll just have to live with the lost traffic
>  from concerned UAs.

OK

> 
>  If (1) and (g), then VisitCounter.com is claiming to be acting
>  as a first party on behalf of examplenews.com.  Hence, it is
>  claiming to be a service provider for examplenews.com.
>  But is it lying?  Well, if (a) is the case, then we have a
>  confirmation from examplenews.com that it considers its links
>  to VisitCounter.com to be the same party.  If (b) is the case,
>  then one of the following is true:
> 
>    y) VisitCounter.com is a service provider, but examplenews.com
>       is either unwilling or too lazy to advertise its own service
>       provider relationships in same-party; or
> 
>    z) VisitCounter.com is lying about being a service provider to
>       examplenews.com.
> 
>  The only way for the user to find out if (y) or (z) is true is
>  for the user to ask examplenews.com via some non-automated means.

agreed

> 
> Note that having an "s" flag doesn't change any of the above cases.

No, the 's' flag is providing part of the same information as the new first-party resource.  

> It is not useful since we added the policy link, which has now been
> replaced by an even clearer first-party link.  The scenario you are
> trying to address has already been addressed with a mechanism that
> provides actual transparency to the user, to the extent that it is
> allowed by the first party.


yes, I think so.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 22 January 2013 11:54:10 UTC