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: Mon, 22 Feb 2016 13:45:13 +0100
Message-ID: <CAKXHy=e2EYaxXkwquBonvV3Wt_n9seo4BjO1b_z9WF3Krwyj1w@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>, Anne van Kesteren <annevk@annevk.nl>
Cc: Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Feb 22, 2016 at 5:26 AM, Mark Nottingham <mnot@mnot.net> wrote:

> <https://tools.ietf.org/html/rfc6265#section-7.1> already talks about
> "third-party cookies." So we need to figure out what to do about that. It'd
> be awfully awkward to have both "same-site" and "third-party" as supposedly
> complementary terms.
> We could either change "third-party", or clarify that we're using
> technical terms about the scope of cookies, not ownership (as it is in
> DNT's definition).  IMHO the latter is more straightforward; new
> terminology for existing concepts has trouble getting traction (as we've
> seen with the rebranding of conneg methods).
> Thoughts?

It starts to get a little bit complicated when you look at the current
behavior of today's browsers. I'll talk about Chrome here (and use
"first-party" and "third-party" terminology, as that's what Chrome's code
uses), but my understanding is that other browsers have similar concepts
and behaviors:

1.  Requests have a "first-party for cookies" and an "initiator", which
both begin with a value more or less exactly equal to the "site for
cookies" concept defined in
somewhere near [1]).

2.  During top-level navigations (including redirects), Chrome updates the
request's "first-party for cookies" to be the URL the user is navigating
_to_ (code somewhere near [2]).

3.  The "initiator" never changes.

This means that when "https://example.com/" requests a subresource (script,
image, etc) from "https://not-example.net/", that request has a
"first-party for cookies" of "https://example.com/" (which makes it a
"third-party" request), and an "initiator" of "https://example.com/" (which
makes it not "same-site").

If a user navigates the top-level window from "https://example.com/" to "
https://not-example.net/", that navigation has a "first-party for cookies"
of "https://not-example.net/" ("first-party"), and an "initiator" of "
https://example.com/" (not "same-site").

If a user navigates the top-level window from "https://example.com/" to "
https://not-example.net/", which 302's the user to "
https://another-example.org/", then two requests are generated with a
"first-party for cookies" of "https://not-example.net/" and "
https://another-example.org/" respectively (both "first-party"), and an
"initiator" of "https://example.com/" (not "same-site").



Also, Mike - I find myself wondering about the relationship between your
> definition of determining third-party and how Origin is computed. Looking
> at the specs involved (Origin Concept, HTML5 and Fetch), it appears that
> most of the logic for determining the calling context for Origin is in
> HTML/Fetch, with the Origin RFC being pretty handwavy about it <
> http://tools.ietf.org/html/rfc6454#section-7.2>:
> """
> When included in an HTTP request, the Origin header field indicates the
> origin(s) that "caused" the user agent to issue the request, as defined by
> the API that triggered the user agent to issue the request.
> """
> Given that, it seems odd to have such precision about computing Cookie
> scope in the cookie spec; if feels like the way that you compute calling
> context for both is going to be about the same, and so should be specified
> in the same place. Or am I misunderstanding something?

I think we need precision somewhere. I'm fairly agnostic about where that
somewhere might be. Adding Anne, who might be interested in defining terms
like these in Fetch?

Received on Monday, 22 February 2016 12:46:03 UTC

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