Intent to Implement: Slight tightening of 3rd-party cookie definition.

117 views
Skip to first unread message

Mike West

unread,
Apr 13, 2015, 11:53:02 AM4/13/15
to blink-dev
Hello, blink-dev! (and security-dev@ on BCC)!

I'd like to make a small change* to the definition of "first-party" that we use for third-party cookie blocking: we currently look only at the top-level origin to determine the first-party origin for a request. I'd like to start walking the whole ancestor chain of a frame.

https://codereview.chromium.org/1075163002/ adjusts `Document::firstPartyForCookies` in the way I'm suggesting. At the moment, that value is only used way up in the network stack, and only for those users who have chosen to "block third-party cookies and site data".

The motivation is consistency with First-Party-Only cookies, which I believe will need to support this definition of "first-partyness" in order to mitigate some risks (maliciously purchased ads, for instance, make it completely viable to create `target.com` -> `adnetwork.com` -> `target.com` nestings). I believe that these instances should be fairly uncommon in practice, and so should have fairly limited effect on non-malicious sites.

I plan to add a runtime flag for the behavior change so that we can evaluate the effect. I fear that the evaluation is going to have to be subjective, however; blocking third-party cookies already breaks specific things in a number of ways (intentionally). It's not clear that we can gather metrics about meaningful breakage vs. blocking cookies in accordance with user wishes (suggestions welcome!).

Thanks!

-mike

*so small that I'm not even using the template. :)

Mike West

unread,
Apr 15, 2015, 6:06:18 AM4/15/15
to blink-dev, Yan Zhu
On Mon, Apr 13, 2015 at 5:52 PM, Mike West <mk...@chromium.org> wrote:
I'd like to make a small change* to the definition of "first-party" that we use for third-party cookie blocking: we currently look only at the top-level origin to determine the first-party origin for a request. I'd like to start walking the whole ancestor chain of a frame.

On Twitter, Yan (CC'd) noted that this matches Firefox's behavior: https://twitter.com/bcrypt/status/587992825091899392. In light of that existence proof of the change's web-compatibility, I'd like to shift from intending to implement to intending to ship. What say ye, API OWNERS?

*I still think this change is too small to justify a chromestatus entry, but I'm happy to add one if folks think otherwise.

-mike

Alex Komoroske

unread,
Apr 15, 2015, 9:15:20 AM4/15/15
to Mike West, blink-dev, Yan Zhu
I think it's worth filing one, just for bookkeeping purposes. Entries there drive a lot of other processes around blog posts, outreach, support, etc. 

-mike

Mike West

unread,
Apr 16, 2015, 3:23:44 AM4/16/15
to Alex Komoroske, blink-dev, Yan Zhu

Philip Jägenstedt

unread,
Apr 17, 2015, 9:43:13 AM4/17/15
to Mike West, blink-dev, Yan Zhu
LGTM. I think you're right that it would be difficult to measure the impact, but if Firefox already does this it seems low-enough risk. The A -> B -> A nesting looks like it should be a rare occurrence, too. If these hunches are wrong, hopefully someone will notice the breakage in time to revert.

Philip 

TAMURA, Kent

unread,
Apr 21, 2015, 4:43:46 AM4/21/15
to Philip Jägenstedt, Mike West, blink-dev, Yan Zhu
LGTM2 to ship.

--
TAMURA Kent
Software Engineer, Google


Jochen Eisinger

unread,
Apr 21, 2015, 7:38:04 AM4/21/15
to TAMURA, Kent, Philip Jägenstedt, Mike West, blink-dev, Yan Zhu
lgtm3

Mike West

unread,
May 12, 2015, 3:00:58 AM5/12/15
to Jochen Eisinger, TAMURA, Kent, Philip Jägenstedt, blink-dev, Yan Zhu
I reverted this from M44, as it ends up diverging a bit from Firefox's behavior. In particular, when the chain is `plus.google.com` -> `talkgadget.google.com`, Firefox sends `google.com` cookies along with the latter request (see https://crbug.com/482812). Chrome bases this on the PSL (see StaticCookiePolicy::CanGetCookies), I assume Firefox does the same.

I can see arguments on both sides of that behavior, and though I prefer the stricter setting (and I think it's more consistent with the intent of "block third-party cookies and site data"), I don't want to break the experience of the ~1.2% of Chrome's users who turn on the setting.

I plan on adjusting the spec (https://tools.ietf.org/html/draft-west-first-party-cookies-02#section-2.1.1) and Chrome's implementation to account for the above. I don't think that will make the upcoming branch point, though, so I'm bumping https://www.chromestatus.com/features/5592111340584960 to M45.

-mike

-Mike

Mike West

unread,
May 18, 2015, 4:10:30 AM5/18/15
to Jochen Eisinger, TAMURA, Kent, Philip Jägenstedt, blink-dev, Yan Zhu
On Tue, May 12, 2015 at 9:00 AM, Mike West <mk...@chromium.org> wrote:
I reverted this from M44, as it ends up diverging a bit from Firefox's behavior. In particular, when the chain is `plus.google.com` -> `talkgadget.google.com`, Firefox sends `google.com` cookies along with the latter request (see https://crbug.com/482812). Chrome bases this on the PSL (see StaticCookiePolicy::CanGetCookies), I assume Firefox does the same.

...

I plan on adjusting the spec (https://tools.ietf.org/html/draft-west-first-party-cookies-02#section-2.1.1) and Chrome's implementation to account for the above. I don't think that will make the upcoming branch point, though, so I'm bumping https://www.chromestatus.com/features/5592111340584960 to M45.

I've documented the "registerable domain" behavior common to Chrome and Firefox in the -03 draft (https://tools.ietf.org/html/draft-west-first-party-cookies-03#section-2.1.1), and updated Blink's behavior in https://codereview.chromium.org/1133223002. If no one objects, I'd like to carry over the M44 LGTM's to re-land this feature. The patch to do so is up for review at https://codereview.chromium.org/1141303002.

-mike
Reply all
Reply to author
Forward
0 new messages