I don't fully understand how modern web security works. But "executing arbitrary javascript written by user A on website B viewed by user C" seems worrying.
I don't fully understand how modern web security works. But "executing arbitrary javascript written by user A on website B viewed by user C" seems worrying.
Yep, Observable runs user JavaScript code, but that code has no access to your login credentials or anything from the 'application': user code runs in a sandboxed iframe on a separate host - host that doesn't have any cookies or user information. The application communicates with that iframe host through serialized postMessage information only. That's the gist of the 'user code' portion - the rest of the application has additional layers of best-practice security like very strict content security policies and so on that defend from other kinds of attacks.
If you inspect them, you'll see that those frames are hosted on observableusercontent.com instead of observablehq.com.
It's a similar security model to how raw files on GitHub are served from githubusercontent.com.
https://beta.observablehq.com/@ontouchstart/test
to confirm that the code is running in an iframe from host https://static.observableusercontent.com