I was trying to make sense of the event-stream vulnerability. My take:
require) to which you pass a string. Also a dangerous capability since it means the dependencies of a piece of JS code can’t be statically known.
So you have this global, dynamically accessible object containing all sorts of sensitive information, which every little script on the page gets access to, including the library you expect to be doing only pure computation on the data you explicitly pass it. It’s extremely difficult to secure this: JS access to the DOM is analogous to C’s feature of being able to poke at arbitrary portions of memory, which is difficult to secure for similar reasons.
It’s probably too late for JS, but if you were redesigning a language for the web and had more than 10 days to do it, it would be possible to completely eliminate these possibilities in the first place. Instead we’re stuck with the consequences of a system that’s almost impossible to secure.
People have been quick to blame the maintainer who handed maintenance over to someone who proved to be a bad actor, or other people or process issues. No, those aren’t the root problems. We should expect that people will make mistakes and instead question the system and core tech which allows these mistakes to be amplified and propagated at such enormous scale.comments powered by Disqus