Subject: Re: [httpwg/http-extensions] Lax same-site cookies should allow <a target="_blank"> (#226)

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 03:36:42 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240066597

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 04:00:11 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240070949

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 04:10:23 -0700

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

We've been throwing ideas around in https://github.com/w3c/resource-timing/issues/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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240072758

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 04:17:23 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240073987

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 04:34:53 -0700

> `.open` gives the initiator a load event.

Alternatively, can we stop doing this? :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240076937

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 05:03:40 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240082066

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 05:05:53 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240082538

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 05:48:12 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/226#issuecomment-240091227