Re: Defining First and Third Party Cookies

Mike West <mkwst@google.com> Thu, 21 January 2016 09:30 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E571A1B87 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Jan 2016 01:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.38
X-Spam-Level:
X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM9f2TPYLkro for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Jan 2016 01:30:38 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2AB1A1B85 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 Jan 2016 01:30:38 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aMBWh-0007Mp-BS for ietf-http-wg-dist@listhub.w3.org; Thu, 21 Jan 2016 09:27:35 +0000
Resent-Date: Thu, 21 Jan 2016 09:27:35 +0000
Resent-Message-Id: <E1aMBWh-0007Mp-BS@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mkwst@google.com>) id 1aMBWd-0007M2-S7 for ietf-http-wg@listhub.w3.org; Thu, 21 Jan 2016 09:27:31 +0000
Received: from mail-lf0-f45.google.com ([209.85.215.45]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <mkwst@google.com>) id 1aMBWa-0002AS-Mo for ietf-http-wg@w3.org; Thu, 21 Jan 2016 09:27:31 +0000
Received: by mail-lf0-f45.google.com with SMTP id h129so22904954lfh.3 for <ietf-http-wg@w3.org>; Thu, 21 Jan 2016 01:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xmQpy/B7qGq5Q99gbaMYrWLU1XSxM3UE2a2Ci2vkzUY=; b=UJcU5aZi4ENIQTnzPbPHdxZdkLerToocekEF3aWAybTDEUw2TH0AK3+0eR3Z5/Jyyv mpCDQDM/dS/ppiro5V4EfQA6VG5xzfMdJlIAiw/tg9ZWS6jBDog3VmWCwsDEROqbrL3K 0a8GTmjSLjtzSYRMXYTs1/V4CK5nLBM8dpEF6Sb1E5RL/xJhndQu+cXQDhs9MX6yDnFp ATXBTTLd3Q0jS8uPD5WfZMCoBMGCp9l5RfmB4QJb1MiDUgLRpp5PfQzSc2SgUDn7y/td Q/x0JIfCHrNNOojqYK8mf0Dl/hdUO/7ACbeFdALsDiya49zZ62VtdmbtDkQWo+GMqo9i KdzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xmQpy/B7qGq5Q99gbaMYrWLU1XSxM3UE2a2Ci2vkzUY=; b=DzMgEa+K1jBhQKurQUL6KjAiqMFmK/QTEWRFZs0Dd9pk6hskZeQzI4ODC+Z9DU7rRt XoeKHkSN0I9lAXJNGTOgyk5ywNpmVRtIEUVKAJsZW0r1yLicxqisr6D4HVmepcUu6BTe ItXrH3tDjl8NdZjw/kerR1JmPjsE98Rb9pBGTxwqSmCWtgmt3SRfjaDgdGUycN8nF040 EOPpqQ6/umnpKpovHSygGc7/jKoUadhSpDh1bWLP6NJcm+QJia59VzBBGxsL4hMWUtsn 5qQtPhrXbPQV2KaMtHpWeq6K++UUJRZ7FN2cDhTK2MEmJLfJ+v62DB2ZOF/K64fmTc9L 4P4Q==
X-Gm-Message-State: ALoCoQnFtmYUes7KDxdGqPzJK+sr5roNnJTSMlwXLOOirj84YJ14x+5WXWuvvBdxChIFSePDoHRHeMkYgBKviLPJtfFIhII5GujMgYtsr6ggUcsL/f5FmXU=
X-Received: by 10.25.152.148 with SMTP id a142mr14826332lfe.139.1453368421510; Thu, 21 Jan 2016 01:27:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.42.20 with HTTP; Thu, 21 Jan 2016 01:26:41 -0800 (PST)
In-Reply-To: <778F0006-6CD9-4832-837C-0423B7A64C7D@gbiv.com>
References: <0F099912-9E26-4EEF-A5E7-9D01DE045377@mnot.net> <8B504522-E2A9-4357-9DCF-BB353CCC5971@gbiv.com> <CAKXHy=dBZOd1KFqrgCuA7Fy=s760V3xLcH5MLAq9-HR3f2NPfw@mail.gmail.com> <778F0006-6CD9-4832-837C-0423B7A64C7D@gbiv.com>
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>
Content-Type: multipart/alternative; boundary="001a114014467e4b8d0529d4b401"
Received-SPF: pass client-ip=209.85.215.45; envelope-from=mkwst@google.com; helo=mail-lf0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.841, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aMBWa-0002AS-Mo 0e33b7f7726c74eac9af2e6f20a01d8f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Defining First and Third Party Cookies
Archived-At: <http://www.w3.org/mid/CAKXHy=evN0KJGRrfvA0ia7qWcQGjzqW7owy5=R1KNaww4gn8gA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30993
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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