Lax same-site cookies should allow <a target="_blank">

[jakearchibald]

Unless I'm misreading the spec, it seems like lax same-site cookies will only be sent for top-level browsing contexts. <a href="…" target="_blank"> creates an auxiliary context.

As far as I know, the initiator doesn't get any additional information from a _blank link, so this restriction seems unnecessary.

+@mikewest

[mikewest]

Auxiliary browsing contexts are top-level browsing contexts (see https://html.spec.whatwg.org/#auxiliary-browsing-context). Given that, my understanding is that the algorithm in https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00#section-4.3 includes them for lax same-site cookies.

[jakearchibald]

Ughhh, you're right, I missed that detail.

That means lax cookies will be sent on a window.open load, which will leak some timing through the window proxy. It's it worth tweaking to avoid that?

I'm looking for ways to allow cookies on top level navigations unless another origin has access to the window proxy (window.open, iframes).

[mikewest]

That means lax cookies will be sent on a window.open load, which will leak some timing through the window proxy. It's it worth tweaking to avoid that?

Use SameSite=strict? I'm not sure I see the value of complicating this even further with Lax, SomewhatLessLax, and Strict.

What timing detail leaks through window.open? I'm not familiar enough with the various holes we've bored into things at this point...

I'm looking for ways to allow cookies on top level navigations unless another origin has access to the window proxy (window.open, iframes).

Lax takes care of the latter, as I'm sure you're aware.

[jakearchibald]

A window proxy gives you a load event for the window.

We've been throwing ideas around in w3c/resource-timing#64 and have come to the conclusion that allowing (and recommending) developers to prevent cross-origin credentialed requests is the answer.

Same-site cookies look like the answer (except for intranet and http auth cases), but losing cookies on navigation seems harsh and breaking.

How widely deployed are same-site cookies? Is it too late to tweak the lax behaviour?

[mikewest]

I guess I don't understand how "allowing developers to prevent cross-origin credentialed requests" can be the answer, while at the same time "losing cookies on navigation seems harsh and breaking".

How widely deployed are same-site cookies? Is it too late to tweak the lax behaviour?

What is it that you'd like to change? If we're going to make changes, now seems like the right time.

(FWIW: It looks like ~0.003% of cookies set in the last month were same-site (with all the usual caveats about audience, opt-ins, etc). We don't have a breakdown between Lax and Strict, unfortunately.)

[jakearchibald]

I guess I don't understand how "allowing developers to prevent cross-origin credentialed requests" can be the answer, while at the same time "losing cookies on navigation seems harsh and breaking".

Ah yeah, I wasn't clear. The (non-strict) problem is not so much about being able to make the request, but being able to learn something from the response. .open gives the initiator a load event.

If I'm right (which isn't often), "lax" same-site only gives the initiator control over the new credentialed top level window in the case of window.open, and my proposal is that it shouldn't. Cookies should only be sent if the initiator has no handle to the new cross-origin window.

[mikewest]

.open gives the initiator a load event.

Alternatively, can we stop doing this? :)

[jakearchibald]

We were discussing stuff like that (and padding load times etc), but the worry is it's a hacky patch, and the information will be leaked somewhere else.

Even if we can drop the load event, the initiator can still scroll the page by changing the fragment of the URL whenever it wants.

The alternative is to send headers that indicate the requesting origin (which could be the Origin header if we can tweak its behaviour) & the way it's being loaded (subresource, frame, top level with window proxy, full top level etc). Then server middleware can either serve an error or ignore cookies.

[mikewest]

We were discussing stuff like that (and padding load times etc), but the worry is it's a hacky patch, and the information will be leaked somewhere else.

With the understanding that this is the wrong bug for this discussion: if we feel like this is data that shouldn't be exposed cross-origin, then it seems like a better idea to find and plug the holes rather than creating an opt-in mechanism that folks who know what they're doing can use to protect themselves from things that shouldn't be possible in the first place.

That is, ideally, we'd make the leak opt-in, not the seal.

All that said, from a practical perspective we can probably change Lax's behavior to exclude navigations caused by window.open() (and clients.openWindow()?). I'm a little concerned about both the layering and general confusion along the lines of "Hey, why am I not signed in?", though.

How do you expect this to interact with noopener? Is it too confusing that the disown-opener directive is available only after the request is sent?

[mikewest]

Also, +@annevk, as it seems like we should probably define something at the Fetch level regarding whether or not a given request exposes a handle if we're going to go this route.

[jakearchibald]

clients.openWindow() doesn't give you a handle to a cross-origin client, so cookies can be sent.

It'd be great if the noopener option on window.open would allow cookies (you don't get load events then do you?).

We've been encouraged to move away from "bandaid" solutions by @sleevi w3c/resource-timing#64 (comment), which is why we're looking at opt-ins that tackle the root of the problem.

[mikewest]

clients.openWindow() doesn't give you a handle to a cross-origin client, so cookies can be sent.

I see.

It'd be great if the noopener option on window.open would allow cookies (you don't get load events then do you?).

You don't get a handle to the window (window.open returns null: https://html.spec.whatwg.org/multipage/browsers.html#dom-open).

We've been encouraged to move away from "bandaid" solutions by @sleevi

I think Ryan would agree that it would be better to stop cutting ourselves in the first place by removing features from the default set of things that we offer to developers if we can't build them safely.

which is why we're looking at opt-ins that tackle the root of the problem.

Hrm. I think I disagree that opt-ins "tackle the root of the problem". They give developers who pay attention the ability to mitigate the effects of problems. That seems fundamentally different than making the platform sane in the first place. For instance, X years after introduction, ~52% of cookies are set over secure transport, but only 6% of cookies use the secure attribute (with all the same measurement caveats as above). I'd suggest that that attribute is rather heavily documented as a best-practice that folks should use unless they have a good reason not to.

If solving timing attacks is actually important, then it seems like we're going to have to do significantly better than secure did to have any meaningful effect with an opt-in. Is that likely?

We can't be aggressive enough about SameSite to make it opt-out without actually breaking the internet. I'm not sure that's the case with the various events and resource timing APIs we expose.

I should probably be typing this on the other bug.

[mikewest]

The side-channel attacks via window.open will, I hope, be sufficiently addressed via the currently-ongoing work to define and ship Cross-Origin-Opener-Policy. @jakearchibald does that mechanism generally address the kinds of concerns you had in mind above?

[mikewest]

I'm closing this out, as I'm pretty sure COOP is what we're going to rely on. If I've misunderstood, reopen? :)