What about shimming?

[erights]

Modern web practice often first loads shim code, to enhance/correct underlying browser behavior to conform more closely to some anticipated standard. However, this is impossible for the proto-SES realm. This impossibility is fundamental, since anything implicitly shared by mutually suspicious parties with no prior coordination can clearly not first be shimmed by any one of them.

The SES realms can only do name overriding of the proto-SES realm. They cannot, for example, override Array.prototype since it is also an intrinsic reachable by syntax. This creates a continued need for the SES-shim as well. Thus, we should also seek help, like the to-be-proposed "def" bulk freeze primitive, for making the SES-shim approach more affordable as well.

The Realms API may enable another way to make a SES-shim much cheaper.

[benjamingr]

I think a polyfill (with the caveats) would enable a playground which would be really helpful for discussing the proposal. I'm not sure about the actual proposal itself - because while we can control and keep the spec in line with other spec changes, I doubt browser vendors will do a good enough job of keeping the implementation of new JS features in sync with it - especially since usually the first version of new features is not spec compliant anyway in browsers.

[erights]

@benjamingr I do not understand the comment. Until the browser vendors do a good enough job, what prevents our shim from doing so instead?

[benjamingr]

What I'm saying is that I believe the polyfill should focus on people trying out the proposal and not on full security.

Browsers add features that are in the early stages of the proposal process all the time for trying things out (it's even part of the process). I think maintaining such a polyfill up-to-date will be very hard if I understand the proposal correctly because it would effectively require someone to go through commits in web browsers and make sure nothing breaks constantly.

[erights]

See #23