Re: Defining First and Third Party Cookies

[Mike West <[e-mail]>]

On Mon, Feb 22, 2016 at 5:26 AM, Mark Nottingham <[e-mail]> 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
https://tools.ietf.org/html/draft-west-first-party-cookies-06#section-2.1.1
(code
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").

[1]:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.cpp&q=Document::firstPartyForCookies&sq=package:chromium&l=4163

[2]:
https://code.google.com/p/chromium/codesearch#chromium/src/net/url_request/url_request_job.cc&l=944

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?

-mike