- From: Mike West <mkwst@google.com>
- Date: Thu, 21 Jan 2016 10:26:41 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKXHy=evN0KJGRrfvA0ia7qWcQGjzqW7owy5=R1KNaww4gn8gA@mail.gmail.com>
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 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