Ancestors count towards first-partyness.

Ancestors count towards first-partyness.

We currently set requests' "firstPartyForCookies" property based on the
top-level document's URL. We ought to harden this property to account
for good.com -> evil.com -> good.com ancestor chains.

The top-level 'good.com' should be considered a first-party context.
The nested 'good.com' should not.

This CL adds this behavior behind a runtime flag. If the intent to ship
at [1] is approved, I'll remove the flag in a followup CL.

[1]: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ZvMEJMSU6po/wKWAfpIe6vUJ

BUG=459154
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=193884

[Mike West, 2015-04-10 09:27:26]

mkwst@chromium.org changed reviewers:
+ jochen@chromium.org

[Mike West, 2015-04-10 09:27:27]

Hey Jochen, this is more or less what I was pinging you about this morning. If
it's something you feel like you could live with, I'll send an intent to
blink-dev@ and write some tests.

[jochen (gone - plz use gerrit), 2015-04-10 12:21:44]

hum, not sure about this one

can we estimate what the impact of this change is?

[Mike West, 2015-04-10 19:50:30]

On 2015/04/10 at 12:21:44, jochen wrote:
> hum, not sure about this one
> 
> can we estimate what the impact of this change is?

A bit more than ~1% of users turn on third-party cookie blocking. Some subset of
those users probably visit sites in which they're currently sending cookies to a
subframe.

Getting metrics will be a bit difficult; we don't use the value until we're in
the net stack, and we don't have any concept of the frame tree there. We don't
know whether 3p cookies are blocked here. I suppose we could pipe one or the
other in one or the other direction.

Assuming we could get them, what metrics would you need in order to be
comfortable with this change?

[jochen (gone - plz use gerrit), 2015-04-13 13:01:25]

On 2015/04/10 at 19:50:30, mkwst wrote:
> On 2015/04/10 at 12:21:44, jochen wrote:
> > hum, not sure about this one
> > 
> > can we estimate what the impact of this change is?
> 
> A bit more than ~1% of users turn on third-party cookie blocking. Some subset
of those users probably visit sites in which they're currently sending cookies
to a subframe.
> 
> Getting metrics will be a bit difficult; we don't use the value until we're in
the net stack, and we don't have any concept of the frame tree there. We don't
know whether 3p cookies are blocked here. I suppose we could pipe one or the
other in one or the other direction.
> 
> Assuming we could get them, what metrics would you need in order to be
comfortable with this change?

maybe we can make it a runtime enabled feature and use it ourselves for a while?
if nothing egregious happens, we can turn it on by default.

[Mike West, 2015-04-13 13:37:48]

On 2015/04/13 13:01:25, jochen wrote:
> On 2015/04/10 at 19:50:30, mkwst wrote:
> > On 2015/04/10 at 12:21:44, jochen wrote:
> > > hum, not sure about this one
> > > 
> > > can we estimate what the impact of this change is?
> > 
> > A bit more than ~1% of users turn on third-party cookie blocking. Some
subset
> of those users probably visit sites in which they're currently sending cookies
> to a subframe.
> > 
> > Getting metrics will be a bit difficult; we don't use the value until we're
in
> the net stack, and we don't have any concept of the frame tree there. We don't
> know whether 3p cookies are blocked here. I suppose we could pipe one or the
> other in one or the other direction.
> > 
> > Assuming we could get them, what metrics would you need in order to be
> comfortable with this change?
> 
> maybe we can make it a runtime enabled feature and use it ourselves for a
while?
> if nothing egregious happens, we can turn it on by default.

I'll do that, and send an intent to spark some conversation.

[jochen (gone - plz use gerrit), 2015-04-15 13:29:43]

lgtm since it matches FF

[Mike West, 2015-04-16 08:08:04]

Would you mind taking another look, now that there are actually tests and I
rewrote everything? :)

[jochen (gone - plz use gerrit), 2015-04-16 14:45:23]

still lgtm

[Mike West, 2015-04-16 14:48:47]

The CQ bit was checked by mkwst@chromium.org

[commit-bot: I haz the power, 2015-04-16 14:49:19]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1075163002/40001

[commit-bot: I haz the power, 2015-04-16 16:22:34]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=193884

[Mike West, 2015-05-05 16:18:26]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.chromium.org/1118373007/ by mkwst@chromium.org.

The reason for reverting is: This apparently produces behavior that diverges
from Firefox. Reverting as I'm OOO, and can't really investigate until next
week.

BUG=482812.