W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Defining First and Third Party Cookies

From: Mike West <mkwst@google.com>
Date: Thu, 21 Jan 2016 10:26:41 +0100
Message-ID: <CAKXHy=evN0KJGRrfvA0ia7qWcQGjzqW7owy5=R1KNaww4gn8gA@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
I've uploaded an -05 draft, running with the 'same-site'/'cross-site'
naming convention:

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".



On Tue, Jan 19, 2016 at 10:53 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Jan 18, 2016, at 12:11 PM, 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?
> 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
Received on Thursday, 21 January 2016 09:27:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC