w3c
Publish only docs that are correctly served over HTTPS
“We could change pubrules to require all resources loaded by our TR documents to be loaded off HTTPS (or relative). It's a relatively easy check to add, and it wouldn't be very disruptive. At least this would ensure that content from now on is ready.”
— W3C Team wiki.
The document downloader could enforce this rule.
See w3c/specberus#184
This is a good suggestion; an authenticated TLS connection is a good way to have a baseline guarantee that you're actually publishing the document an author intended you to publish.
I read 2 different things here:
- The title suggests that documents (source) not served with HTTPS should be refused
- The citation from the wiki suggests that documents (content) that contain non-HTTPS resources should be refused
Not saying any should be avoided, but just that these are 2 very different problems to solve. I suggest editing the title of this issue to reflect the citation.
@astorije, when I wrote “docs that are correctly served over HTTPS” in the title, I meant everything in the doc — the main page itself, plus every other linked resource. I think that is the most strict interpretation of that paragraph from the wiki, so the safest one.
Feel free to edit the title of the issue if you come up with a better one, though.
I do think these are 2 different issues indeed, but maybe I am wrong.
How do you plan to handle links that simply do not have an HTTPS version, by the way? Will they be forbidden from specs or do we need to, for each HTTP resource, de-reference an HTTPS version to check if it exists?
As I understand this, everything should be served (and linked) via HTTPS, explicitly. I think it's better to avoid this idea of “versions”: authors should be publishing using HTTPS only and linking to HTTPS resources specifically, and we should not assume that http://foo/bar and https://foo/bar are just the same document, only served through a different protocol (that may not be true).
Anyway, it's part of our “roadmap to HTTPS” — it's not like we're going to enforce this right now… Fodder for discussion :¬)
So yeah, documents with references to http://something will be rejected. I am not too fond of the idea because it means we make the assumption the entire world can be served under HTTPS, which is sadly not true.
Plus, unless we implement yet-another-whitelist/blacklist mechanism (CORS whitelist, external resources whitelist, ...), references to http://www.w3.org/something-public will have to be written with https, which is merely a redirect to the HTTP URI at the moment.
Not “the entire world”, @astorije — just the resources you create or reuse for your spec…
I agree with you: when this is enforced, all of w3.org/TR/ (or at least the new specs) will have to be served through HTTPS too. Otherwise it would seem absurd to enforce HTTPS for the source of those specs.
And yes, none of these aspects is trivial. I'm not saying we'll do that next week. Just adding here ideas that stem from our internal discussions regarding the future of HTTPS at W3C :¬)
Not “the entire world”, @astorije — just the resources you create or reuse for your spec…
Specs use a lot (and I mean a lot) of URLs that are not created for them. That's what I mean by "the entire world".
And yes, none of these aspects is trivial. I'm not saying we'll do that next week. Just adding here ideas that stem from our internal discussions regarding the future of HTTPS at W3C :¬)
Oh good, we have another N years then! I foresee a wontfix label for this one...