Open drzraf opened 5 months ago
marcoscaceres
commented
5 months ago Note that "rescinding" means something specific in the W3C Process, and it relates to more to IPR... I've made the same mistake before 🙈. I guess you mean is that it should be "discontinued".... sorry for the semantic Process non-sense.
Personally, I think it might be best to split the above into issues and see if each are insurmountable.
dveditz
commented
4 months ago Your rant is misdirected. The majority of this spec is "non-normative"—that is, descriptive text implementations are free to ignore. The main thing it does is define terms so that if other specifications choose to use them they will have a common definition and avoid security issues arising that might be caused by two specs treating the same context differently. The actual effect of this specification is in section 3 where it defines the terms
This spec has ZERO control over ES6 which is defined in a completely independent standards body. If ES6 is using these concepts it is because the people defining ES6 have chosen to do so.
There is nothing in this spec that prevents the use of DANE. "A potentially trustworthy origin is one which a user agent can generally trust as delivering data securely." A browser that implemented DANE to secure transport would be fully compliant with this spec if they considered that as a trustworthy origin.
HTTPS is about secure transport and certainly not become aimed to be a stone-in-the-shoe rigidly keeping web-developers from innovating. A secure transfer isn't a secure context and even less a "trustworthy" one.
A "context" is not a "site". It is the browsing document/app/content the user agent is computing on. This spec does not consider whether a site is well-programmed or worthy of the user's trust (how could that be algorithmically determined?) but only whether it can be reasonably confident that it has accurately, securely, and confidentially received the content sent by the site. The threat model (section 4) is passive and active network attackers, which have repeatedly been shown to exist. It might be awful content, but authors of that content can trust that what is executing on the user agent is what they sent.
You're right that some server deployment models fall short of guaranteeing E2E encryption, but this spec asks a user agent to verify things to the best of its ability given what it knows about connections.
My local, (GPS/crypto/...-accessing) application served on our local network is way more trustworthy (and secure) than this advertising company X grabbing GPS "securely" from "https://googlex.com.sk" with LetsEncrypt & CT)
There is nothing in this spec that would prevent a browser from defining local networks as secure. Internet Explorer used to support a trusted intranet zone (I don't know if MS Edge does) and it might be reasonable to treat that the same way as the spec treats 127.0.0.1. You'll get some pushback because while you know your local network is secure, a browser by itself can't tell the difference between your set of local addresses and the local addresses seen by Bob the College Student on the university network which we know for sure are NOT secure. But if it were a popular enough request there's no reason a browser couldn't implement a "zone" feature that let users define "secure because I say so" addresses. But users (or their admins) would have to define it, and in practice that means hardly anyone would actually use such a feature. BUT— that's an implementor's decision and not forbidden by this spec.
Lets also remind that when Google wanted it, this body issued spec' granting remote websites access USB/serial ports of everyone's computers (just one "Accept" button away)
W3C has no such spec. There is a W3 "community group" proposal that chromium went ahead and implemented, but it has not been officially adopted by a "working group" as a work item, let alone become a W3C specification. Sounds like your complaint is with Google, not this spec.
Finally, the spec doesn't define WHAT would precisely end up being restricted by so-called "secure context". [...] But isn't the specification text the place where one would look for the precise list of banned/allowed APIs?
No, this spec is defining terms for other specs to use consistently. An early draft of this spec did try to define a list like that but it was incomplete, quickly outdated, and very hard to change once "set in stone" if a final version had been published.
Enforcing HTTPS at a programming-language level is not only a technical mistake but a political spec (which is another name for bad spec). As such it should be at best rescinded and, at worst, superseded.
This spec doesn't require that. For example, the CSS folks continue to implement new features and publish updated specs of their language without requiring secure contexts. Sounds like your real beef is with the ETSI TC39 standards folks and you should be making your case to them and not here with W3C folks.
This spec should not exists in this form in the first place and should be rescinded.
Because the specification's exceeds by far the scope of the W3C: It meddle with ES6 specification, fragments the programming environment and jeopardizes a programming-language consistency and predictability. It makes legit ES6 code failing depending on... the gTLD of an URL or the protocol used to transfer a piece of code.
Because the specification's scope is indirectly (purposefully or not) overly binding multiples independents domains: language's API, sockets, DNS-resolution, ... thus giving too much power to the browser standardization body at the prejudice of others.
Because it's actually disruptive: affecting programmers and users expectations: Their ability (and their ultimate sovereignty) to use web-technologies to resolve problems and provide features.
Because specification introduction (exposing its underlying motivations) makes wrong assumptions in multiple points:
Good intentions set aside, this fundamental sentence lacks key precision and is outdated wrt HTTPS practical use nowadays.
HTTPS is about secure transport and certainly not become aimed to be a stone-in-the-shoe rigidly keeping web-developers from innovating. A secure transfer isn't a secure context and even less a "trustworthy" one.
It doesn't consider the fact that JS can be used to make the app more secure (crypto API in mind)
The increasing presence of SSL termination endpoints (MiTM provider) makes HTTPS no more secure by design since it's not e2e anymore. Same for rogue certificate-authorities which do exist and are present & enabled in the list of most users and have the potential of making an HTTPS link weaker. In multiple countries/regions someone could be safer using HTTP+DANE over a VPN or Tor rather than using Cloudflare pseudo-HTTPS + plain-text Cloudflare-DNS or accepting by default these thousands of CA authorities. (The past years have seen a pervasive move to enforce 3rd-parties reliance [CA+CT instead of DANE for name one example] meanwhile safer and simpler non-intermediary solutions were repeatedly ignored by browser vendors)
Of course but HTTPS is just one among many others (like HSTS, CSP, Subresource Integrity ...) which, together, represent a set of possibilities in the hand of websites/applications' developers & providers and their ultimate choice regarding security. This is NOT a reason for browsers to forcefully disable
window.cryptoorstorageand restrict the JS-engine under arbitrary conditions.This spec' conflate secure and trustworthy : My local, (GPS/crypto/...-accessing) application served on our local network is way more trustworthy (and secure) than this advertising company X grabbing GPS "securely" from "https://googlex.com.sk" with LetsEncrypt & CT)
Overall (and maybe more radically), if a (SRI-enabled or not)
<script>fetches and run some obscure RSA-encrypted Wasm blob over HTTP(s) using their browser of choice, it's an affair between a user and a domain: Not something w3c has a say in.Lets also remind that when Google wanted it, this body issued spec' granting remote websites access USB/serial ports of everyone's computers (just one "Accept" button away) but, when Chrome requests it, it could keep the JS engine fundamental basic language API inoperative if not running over (mostly Google/Cloudflare managed) HTTPs: Was that really about security in the first place?
Finally, the spec doesn't define WHAT would precisely end up being restricted by so-called "secure context". Some broad mention about risk like "GPS" or stateful browsing : But isn't the specification text the place where one would look for the precise list of banned/allowed APIs? On the contrary. We saw JS API were being further and further restricted, one GitHub PR after the other, in a slow process which doesn't match the formalism of (draft [?]) specification.
The only actual and practical effect of this spec is to impose HTTPS for weak reasons (pretexts?) in an era where LetsEncrypt/Google/Cloudflare/MiTM, CA and dubious CA lists HTTPS is certainly not a security panacea anymore.
Enforcing HTTPS at a programming-language level is not only a technical mistake but a political spec (which is another name for bad spec). As such it should be at best rescinded and, at worst, superseded.