whatwg
Secure cookies should be permitted on secure requests, not just where there is a `https` scheme
What is the issue with the Fetch Standard?
Secure contexts are defined to allow things where the web platform wants to ensure there isn't a network attacker. There is no corresponding definition for URLs, so we just match on the scheme for Secure cookies. In the interest of letting localhost be localhost, we should probably permit Secure attributed cookies when host="localhost". We could even extend this to include DNS resolution to loopback addresses or IP addreses that are routed to not leave the device.
cc @DCtheTall @mikewest
This seems like a logical thing to do, but I may be overlooking some horrible property of the Web platform that complicates things.
I guess it does complicate the separation between http://localhost and https://localhost, but in so far as that matters, we should fix that by shipping https://github.com/sbingler/Origin-Bound-Cookies
I believe this matches Chromium's existing behavior, though I'd want to test it to make sure I'm remembering the code correctly.
We cannot. At least, not in a way that works in a context-independent way.
We could add a webdriver mechanism to define some other origin as "localhost" (similar to what we did for loopback IP addresses in https://github.com/web-platform-tests/wpt/issues/26166), but that would be a reasonable amount of work to get right (in Chromium at least).
This also matches Firefox's existing behavior, but not Safari's
So the proposal here is to use https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy on request's current URL instead of doing a scheme check? That's probably reasonable, but does seem best tackled as follow-up. (This does make me recall we never quite fully settled how Secure Contexts and HTML integrate, but that isn't really a blocker.)
The initial PR was doing a secure context check on request's client, which is quite a bit different.
Yeah, the initial PR was definitely wrong. I think this is a good follow up as well.