Treat http://foo.com -> https://foo.com requests as Sec-Fetch-Site: cross-site.

[anforowicz]

This is a follow-up for https://crbug.com/979257. Could you please update the spec to change how it determines whether to use the cross-site value for the Sec-Fetch-Site header? Currently the spec only says:

If r’s origin's registrable domain is not the same as url’s registrable domain, set header’s value to cross-site and break.

I think it also needs to consider schemes.

[mikewest]

Chrome's made this change, and it seems quite reasonable to me. I'll update the spec.

In fact, I wonder if we can/should change this more generally for URL's "same site" definition, as it's something we run into in ~all the "same-site" checks we're introducing these days.

In fact, SameSite cookies might be the only place where we're not doing this kind of check. We made that decision because we wanted people to be able to upgrade their sites to HTTPS piecemeal, starting with their authentication systems, then spreading throughout the site. Perhaps we've reached enough of an inflection point with that migration that we can tighten the restriction generally.

WDYT, @annevk?

[annevk]

I'm supportive. We could have schemeless same site or some such for the variant that only takes hosts. https://fetch.spec.whatwg.org/#cross-origin-resource-policy-check also needs schemeless btw, even though it ends up checking the scheme a bit.

[mikewest]

Closing this out, as it's fixed in 4316583.

Moving the broader discussion to whatwg/url#448.

[annevk]

I filed #41 as a follow-up.