Re: Input to ISSUE-137 (service provider flag)

On Aug 27, 2012, at 4:34 AM, Matthias Schunter (Intel Corporation) wrote:

> Hi Folks,
> 
> 
> I'd like to make progress towards resolving ISSUE-137.
> 
> SCENARIO UNDER CONSIDERATION
> 
> I believe we are considering the following use case:
> 1 - A user with DNT;1 visits a site
> 2 - The site sends back its own content (e.g., usually marked with Tk:1 header that says that the policies for 1st parties have been implemented)
> 3 - Embedded content from third parties is marked with "3" (following 3rd party policies; no concern there)
> 4 - Some embedded content that is marked with "1" but is coming from a different domain 
> 
> Now the user agent may like to distinguish the following cases for the content in (4):
> A) The content in (4) is just part of the site hosted under a different domain name (e.g. ibm.com pulling in lotus.com content) that is part of the same first party
> B) The content in (4) is comming from a service provider where the 1st party remains responsible for following the policies set for the 1st party (e.g., a content 
>      distribution network)
> C) Someone has accidentally embedded content intended for 1st party use that is now accidentially or maliciously used in a 3rd party context
> 
> SOLUTION IN TODAYS DRAFT
> 
> I believe that the case (C) must be distinguishable from cases (A+B) since it poses a privacy risk if a third party element implements the less constrained 1st party policies.
> Today, in the current draft, this is achieved by this field at the well-known URI:
>> An OPTIONAL member named same-party MAY be provided with an array value containing a list of domain names that the origin server claims are the same party, to the extent they are referenced by the designated resource, since all data collected via those references share the same data controller.
>> 
>> same-party    = %x22 "same-party" %x22
>> same-party-v  = array-of-strings

To clarify, the tracking status resource for the first party site
may include a list of same-party domains, which would confirm that
the first party's references to those domains remains within the
scope of their first party control (owned by them or operated by a
service provider acting on their behalf within the constraints in
compliance).  The tracking status resource for the embedded content's
domains might also have a same-party array, but I would not suggest
using that information for widening first party scope.

> - In cases (A) and (B) the 1st party needs to declare the URLs that are part of the same party and that it claims to be part of the same party.

Just the domains (the URLs are whatever is referenced by the
first party site with those domains).

> - As a consequence, a user agent can mark content that uses the "1" response while not being in this list as suspicious (the case (C)).
> 
> DISCUSSIONS
> 
> I believe that we may discuss the following questions:
> 
> 1 - Do we agree on this procedure that content responding with "1" (intended for 1st party use) that is not specified in the "same-party" field 
>   is suspicious and the user agent handle on it? (this sort-of makes the same-party field mandatory if you pull in content from different domains).

I would consider it an optional way of green-lighting some embedded
requests, along the same lines as whitelisting.

> 2.  Do we want to be able to further distinguish cases (A) and (B)? I.e., whether content comes from a domain controlled by the site itself or from a service provider's domain?
>     I believe in EU language: Do we need to know whether the content comes from the data controller itself or from a data processor that is processing data on behalf
>     of the controller.
> 
> I suspect that we agree on (1). For (2), the important question to ask ourselves is 
> -  What specific actions may a user agent perform with this information?
> Remember that the goal of this protocol is to inform the user agent, i.e., we should not transmit information unless we understand how it might be useful to the user agent receiving the information.

As mentioned previously, I object to requiring that service providers
acting as a first party be required to behave differently than a first
party would, unless there is a compelling (and agreed) privacy need
that is being protected.

....Roy