Re: first party resource

On Apr 10, 2012, at 11:58 PM, Nicholas Doty wrote:
> On Apr 10, 2012, at 5:00 PM, Roy T. Fielding wrote:
> 
>> I am unsatisfied by all of the first-party definitions because I don't consider
>> them to be implementable (e.g., neither "can infer with high probability that the
>> user knowingly and intentionally" nor "the party that owns the Web site or has
>> control over the Web site" can be determined programmatically).
> 
> Is there some reason that this specification can only be implemented if a user agent can determine programmatically the breadth of a first-party?

One of the use cases described is a user agent that colors elements
based on indicated compliance.  I would expect that to include
first/third party distinctions, since the compliance expectations
are so different.

> Your 5-step list also seems to include non-programmatically-determinable definitions ("share sufficient context ... such that the user has a reasonable expectation that data ... might be shared or combined").

Those are for compliance.

> Is your concern just that based on whatever definition of first-party we decide on, parties should assert their claims about their own breadth in the machine-readable tracking status resource? (That sounds like a laudable aim to me, and much what we had in mind for the dnt-sites list proposal from Brussels.)

Yes, having both a broad allowance for affiliates and a listing
of those specific domains considered first-party will satisfy the desire
to limit the scope of first party without trying to define that scope
in some universal legal way that might apply to all possible business
models or site branding.

>> I suggest that we simply state:
>> 
>> 1) A first-party resource is a resource that has been designed for direct
>>    interaction with a user.
> 
> Is this more programmatically determinable or more reasonable than the "meaningful interaction" test in the Compliance Editor's Draft? (The "Discoverability" alternative also refers to widgets "with which a consumer interacts".)

Yes, it avoids the debate about user intentions or awareness, or misuse
of the resource by third-party portals, and instead makes it a factor of
how the resource owner designed and makes use of that resource.  In other
words, that doesn't have to be determined programmatically.  I should
have mentioned also that it assumes the resource owner is not designing
for first-party use while also encouraging third-party use of the same
resource.

> If a Facebook Like button embedded on a newspaper website has been designed for direct interaction with a user but hasn't yet been clicked, should it get first-party privileges to track the request that loaded it?

A button is a UI element, not a resource.  The Facebook Like button consists
of a dozen or so different resources, most constructed by javascript obtained
from another couple resources.  Only the resource designed for direct user
interaction (the click handler) would be first party for a button on some
site other than facebook's own properties.

>> 2) When a user interacts with a given first-party resource, all subrequests
>>    made to that first-party's domain or to any of the domains listed in the
>>    same-party array within the first-party's tracking status resource are
>>    also considered first-party resources; all other subrequests are considered
>>    third-party resources.
>> 
>> 3) The same-party array MUST be limited to domains that are owned or controlled
>>    by the same legal entity that owns or controls the first-party as well as
>>    domains that qualify as third parties acting on behalf of this first party.
>> 
>> 4) The same-party array SHOULD be limited to domains that share sufficient
>>    context with the first-party, such that the user has a reasonable expectation
>>    that data provided to any of these domains might be shared or combined with
>>    data provided to the other same-party domains.
> 
> These sound to me like nice summaries of the affiliates and user expectations definitions, respectively. (With the notable difference that outsourcing parties seem to be defined as the same party in your text.) Are you proposing that first parties have a hard requirement to meet the affiliates rule and a soft suggestion to meet the user expectations rule?

SHOULD is not a soft suggestion. It is a requirement for which there might be
some exceptions, but only for a very good reason that we have not enumerated.

>> 5) Data provided to first-party resources is subject to first-party compliance
>>    requirements; data provided to third-party resources is subject to third-party
>>    compliance requirements.

....Roy

Received on Wednesday, 11 April 2012 14:56:44 UTC