Subject: Defining First and Third Party Cookies

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jan 2016 13:52:48 +1100

It doesn't look like there's enough interest in Mike's first-party cookie draft to consider a CfA for it yet.

However, I'm wondering if it would be useful to pull the definitions of first and third party cookies out of that and into CookieBIS, since they're currently not defined anywhere normatively.

Specifically:
  https://tools.ietf.org/html/draft-west-first-party-cookies-04#section-2.1

What do people think?

--
Mark Nottingham   https://www.mnot.net/

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 18 Jan 2016 13:04:04 +1000

On 18 January 2016 at 12:52, Mark Nottingham <[email-masked]> wrote:

> However, I'm wondering if it would be useful to pull the definitions of
> first and third party cookies out of that and into CookieBIS, since they're
> currently not defined anywhere normatively.
>
> Specifically:
>
​It would be good to have it defined somewhere, if it isn't already. The
section referenced above doesn't disagree with the Wikipedia page [1]
(which I take as the general understanding shared by most of the web) so it
works for me.

[1]: https://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie​

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

---

From: Mike West <[email-masked]>
Date: Mon, 18 Jan 2016 07:38:51 +0100

> draft to consider a CfA for it yet.

I do plan to ship an implementation of first-party-only in Chrome in the
relatively near future; I think it's a solid measure against CSRF, and
folks like GitHub are already experimenting with Chrome's flagged
implementation. I'm hopeful that Mozilla will find time to do the same.
+mgoodwin in the hopes that he can pass on Mozilla's perspective.

> https://tools.ietf.org/html/draft-west-first-party-cookies-04#section-2.1

I think that's a pretty reasonable suggestion if there's not enough
interest in the rest of the proposal.

-mike

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 18 Jan 2016 10:56:19 -0800

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.

Changing the technical terms has no impact on the technology or the algorithms. It just shortens the arguments and avoids some unfortunate conflicts.

....Roy

> On Jan 17, 2016, at 6:52 PM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Mike West <[email-masked]>
Date: Mon, 18 Jan 2016 21:11:49 +0100

On Mon, Jan 18, 2016 at 7:56 PM, Roy T. Fielding <[email-masked]> 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?

-mike

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 19 Jan 2016 08:52:17 +1000

On 19 January 2016 at 06:11, Mike West <[email-masked]> 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.
>>
> 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.
>
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

---

From: Mike West <[email-masked]>
Date: Tue, 19 Jan 2016 13:13:56 +0100

On Mon, Jan 18, 2016 at 11:52 PM, Matthew Kerwin <[email-masked]>
wrote:

> means many things to many people.)
>

I think most words are going to carry some baggage, "internal", "external",
"local", and "remote" included. I mean, all cookies are "external" in the
sense that they're sent out there to the public internet, and all cookies
are "local" in that they're stored on my hard drive. We can define those
terms in this context to mean something else, certainly, but we could also
solidify the definition of "site" as it applies to cookies.

> That means the definition we write will be the first/true one.
>

Except insofar as the world has already settled on
"first-party"/"third-party". :) Colloquial usage of those terms is fairly
pervasive (see Chrome, Firefox, and Edge's settings pages, as well as
RFC6265 itself). Lawyers aside, those are the "first" and "true"
definitions that exist status quo.

Safari is the only browser I know of that avoids the "*-party" terminology,
settling for "Cookies from this website" and "websites I visit", which lead
me to "site" as a potentially viable option which has similar connotations
to the verbose-but-accurate "same-registrable-domain".

-mike

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 20 Jan 2016 07:41:10 +1000

>
>
> I think most words are going to carry some baggage, "internal",
"external", "local", and "remote" included. I mean, all cookies are
"external" in the sense that they're sent out there to the public internet,
and all cookies are "local" in that they're stored on my hard drive. We can
define those terms in this context to mean something else, certainly, but
we could also solidify the definition of "site" as it applies to cookies.

Fair enough.

>
> Safari is the only browser I know of that avoids the "*-party"
terminology, settling for "Cookies from this website" and "websites I
visit", which lead me to "site" as a potentially viable option which has
similar connotations to the verbose-but-accurate "same-registrable-domain".

That makes sense. I'll happily go with whatever is settled on, I think I
like 'site'.

By the way, what happened to "second party" cookies?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Jan 2016 13:53:35 -0800

> On Jan 18, 2016, at 12:11 PM, Mike West <[email-masked]> wrote:
> 
> On Mon, Jan 18, 2016 at 7:56 PM, Roy T. Fielding <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <http://example.com/>` -> `sub.example.com <http://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?

I meant domain as in the thing you pay to register (others would be subdomains), but I agree
that same-site would do just as well.  For DNT, I had to use the even more vague "same context";
I don't recommend that here.

....Roy

---

From: Mike West <[email-masked]>
Date: Thu, 21 Jan 2016 10:26:41 +0100

I've uploaded an -05 draft, running with the 'same-site'/'cross-site'
naming convention:
https://datatracker.ietf.org/doc/draft-west-first-party-cookies/.

It doesn't, however, actually align with what browsers are doing for "Block
third-party cookies". Having poked at Chrome's implementation, I can safely
say that those features are riddled with carveouts and exceptions. I think
they'd be valuable to define in one way or another, but they aren't as
straightforward as "cross-site".

-mike

-mike