Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next steps for HTTPS state #1062

Closed
domenic opened this issue Jul 27, 2020 · 6 comments
Closed

Next steps for HTTPS state #1062

domenic opened this issue Jul 27, 2020 · 6 comments
Assignees

Comments

@domenic
Copy link
Member

domenic commented Jul 27, 2020

HTTPS state causes issues with the secure context definition, as discussed in whatwg/html#4930 (comment). I've checked with folks on the Chrome side, and we no longer need the "deprecated" HTTPS state, so we can fix that issue. I'm willing to work on helping remove it.

However, I need some guidance. Can we remove the "HTTPS state" concept entirely? I'm not sure. The usage sites I've found are:

  • Secure context definition only cares about "deprecated". So it won't use this.
  • CORP check cares about "none". Could this use the response's URL's trustworthiness instead?
  • Hyperlink auditing cares about "none". Could this use the Document's creation URL's trustworthiness instead? Or maybe it should be using an actual secure context check?

All other references to HTTPS state in HTML and Fetch appear to be plumbing from responses to new environment settings objects.

If we can't remove it, then: should we just keep the infrastructure as-is, and remove the "deprecated" state? Or maybe we should go further and rename things to make a bit more sense, e.g. change it to a "securely delivered" boolean? Are there other simplifications we could make?

@annevk
Copy link
Member

annevk commented Aug 4, 2020

If I look at how https://fetch.spec.whatwg.org/#concept-http-network-fetch sets it, what really matters is the scheme. If the scheme is not "https", it's equal to "none". Otherwise it could be "deprecated" or "modern". It doesn't seem to account at all for http://localhost/ and friends. Maybe it should, but that would be a separate normative change with tests we cannot really write using web-platform-tests...

@domenic
Copy link
Member Author

domenic commented Aug 4, 2020

OK. So where does that leave us? Should we remove HTTPS state entirely, or no?

@annevk
Copy link
Member

annevk commented Aug 4, 2020

Yeah, I think it can be removed in favor of scheme checks. That's all that remains once you remove "deprecated". As "deprecated" means the scheme is "https", the browser did get a response and accepted the TLS connection, but the browser also judges the TLS connection to be of poor quality.

@domenic
Copy link
Member Author

domenic commented Aug 4, 2020

Great, OK. So concretely, the CORP check and hyperlink auditing should use a straight-up scheme check. And in the future we can consider changing them to URL's trustworthiness, or secure context checks, as appropriate.

@annevk
Copy link
Member

annevk commented Aug 4, 2020

Yup!

domenic added a commit to whatwg/html that referenced this issue Aug 4, 2020
domenic added a commit that referenced this issue Aug 4, 2020
domenic added a commit to domenic/ServiceWorker that referenced this issue Aug 4, 2020
Part of whatwg/fetch#1062. Also sets the new-ish fields on environments.
annevk pushed a commit that referenced this issue Aug 5, 2020
It did not get significant adoption.

Part of #1062. Closes #270.
domenic added a commit to whatwg/html that referenced this issue Aug 5, 2020
jakearchibald pushed a commit to w3c/ServiceWorker that referenced this issue Aug 6, 2020
Part of whatwg/fetch#1062. Also sets the new-ish fields on environments.
@domenic
Copy link
Member Author

domenic commented Aug 6, 2020

I guess everything got merged, yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants