design-principles

I believe most new capabilities are limited to secure contexts, in part as a way of discouraging bad habits, even when there’s no particular risk. The ideal is that everything should run in a secure context, but it’s a hard sell removing existing functionality from insecure contexts. If it were being added now, I’m pretty sure storage APIs would be secure-only. Search around and you’ll find various information and explanations about it. https://blog.mozilla.org/security/2018/01/15/secure-contexts... is one, though https://w3ctag.github.io/design-principles/#secure-context has apparently been significantly watered down from what it was originally—see the initial proposal in https://github.com/w3ctag/design-principles/pull/75, and what was then merged in https://github.com/w3ctag/design-principles/pull/89.

I am skeptical of WebAssembly and component-model myself, but that AssemblyScript page seems alarmist and as can be seen in several issues linked from that page, dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith: https://github.com/w3ctag/design-principles/issues/322 It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web", which seems patently absurd, but also, just plain boring. I was definitely expecting more along the lines of incompatible object models integrating into component‐model, rather than mass-tagging people over string encodings.

I don't agree with your representation that sanitisation of isolated surrogates constitutes "corruption". As a high-level point, when passing a string from your component to an external one, the external component receives a sanitised copy of your string - the original string is not modified in-place. So you still have access to your original string if you're relying on the presence of isolated surrogates for some reason. For fairness, I will link below to your concrete example of "corruption", noting that you claim it will render Wasm "the biggest security disaster man ever created for everything that uses or opted to preserve the semantics of 16-bit Unicode". https://github.com/w3ctag/design-principles/issues/322#issue... I'd argue that the fundamental bug here is in splitting a string in between two code points which make up an emoji,

Yes, there already is an exception for localhost. HTTP on localhost is considered a "secure context". Edit: To be more precise, and to quote [1] "Secure Contexts says UAs MAY treat localhost as a secure context only if they can guarantee it will only ever resolve to a loopback address (and are in any case not required to). https://w3c.github.io/webappsec-secure-contexts/#localhost" [1] https://github.com/w3ctag/design-principles/pull/75#issuecom...

Wow -- you're right, the overreach in "secure contexts" is astonishing. It looks like [1] is the main thread discussing this policy. The notion of "internal/isolated network services" is mentioned in one comment but never address, other than pointing out the difficulty of getting a cert for such a service. I think it's probably worth jumping into that discussion before the policy is set in stone. [1] https://github.com/w3ctag/design-principles/pull/75