Re: Defining First and Third Party Cookies

On 19 January 2016 at 06:11, Mike West <mkwst@google.com> wrote:

> On Mon, Jan 18, 2016 at 7:56 PM, Roy T. Fielding <fielding@gbiv.com>
> wrote:
>
>> I appreciate the value of such a technical definition from the
>> perspective of a browser, but that doesn't make it an accurate definition
>> of first party for the user or for the services in question.
>>
>> The problem is that the draft is equating the notion of "party" (a legal
>> term) with the technical ideal of same-domain, but the fact is that a
>> single party often owns many domains that a user expects to be the same
>> party but won't be under this definition. Likewise, a party might control
>> other domains for the sake of providing that same service, and a single
>> domain often hosts services for multiple parties.
>>
>> These are important distinctions because they are present in most modern
>> privacy regulations and data protection laws. Hence, the draft's
>> definitions conflict with the defined terms of DNT, since DNT was written
>> with respect to those laws.
>>
>> There is no feasible technical mechanism for a browser to determine what
>> is a first-party. My preference would be to use a different term for this
>> new definition that isn't loaded with legal baggage. IMO, what the draft
>> defines would be better called same-domain or same-ancestor or "within the
>> document domain", since domain ancestry really has nothing to do with the
>> legal definitions of first or third party.
>>
>
> Fair. I have _very_ little interest in getting into arguments with
> lawyers. The browser deals with origins, and I'm happy not to claim
> anything more.
>
> That said, note that the definition in the document isn't really
> "same-domain", as it relies on notions of public suffixes and registrable
> domains that browsers have adopted for compatibility with the web (e.g.
> Chrome and Firefox's "block third-party cookie" options both allow `
> example.com` -> `sub.example.com` chains to send cookies to both origins,
> Safari's sends any which would be sent to the top-level origin (which has a
> similar effect, as cookies are nuts)). Perhaps "same-site" or something
> equally vague would be appropriate?
>
>
Yeah, a legal morass is best avoided. If a quick coat of paint on the bike
shed can help, then so be it. I'll make two suggestions, to see if they
resonate:

* local / remote cookies
* internal / external cookies

The English words are pretty open, and AFAIK they're not really used in
this domain, so there's hopefully less chance of them carrying particular
arbitrary definitions for folk who encounter them (unlike "site" which
means many things to many people.) That means the definition we write will
be the first/true one.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/