Subject: Re: Defining First and Third Party Cookies

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Feb 2016 15:26:53 +1100

<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?

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?

Cheers,

> On 21 Jan 2016, at 8:26 PM, Mike West <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote:
>> 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]> 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
> 
> 

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

---

From: Mike West <[email-masked]>
Date: Mon, 22 Feb 2016 13:45:13 +0100

On Mon, Feb 22, 2016 at 5:26 AM, Mark Nottingham <[email-masked]> 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