Paul Chiusano

Functional programming, UX, tech, econ

TwitterGitHubLinkedInRSS


Consulting services

I offer Scala and FP consulting services. If you're interested in working together, please contact me.


About my book

My book, Functional Programming in Scala, uses Scala as a vehicle for teaching FP. Read what people are saying about it.


Popular links

Unison: a next-gen programming platform
unison.cloud: the worldwide elastic computer (coming soon)
Type systems and UX: an example
CSS is unnecessary

What is really the root cause of the event-stream vulnerability?

[   fp   programming   tech   ]            

I was trying to make sense of the event-stream vulnerability. My take:

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