4 ms·
Interesting, but who is responsible for the compilation? The plugin developer? The app developer? The realms approach feels a bit cleaner to me... I would think
by osrec 7y ago
Interesting, but who is responsible for the compilation? The plugin developer? The app developer? The realms approach feels a bit cleaner to me... I would think it's also easier to debug than trying to debug compiled code.
- lern_too_spel 7y agoThe host page must control the compilation to ensure the safety of its data. The compiled code is still JavaScript, just without any access to variables that the host does not want the embedded script to see.
- osrec 7y agoWell, it's an option, but I would probably just go with the iframe approach as it seems like less hassle + cleaner!
- lern_too_spel 7y agoIt has less bloat if you use lots of embedded scripts. My point is that this problem has been solved before in an even cleverer way and was used by hundreds of engineers in MySpace's heyday, so I'm surprised the authors had not considered it.
- rudi-c 7y agoWe did! But while the approach was perfectly plausible in theory, we didn’t feel good about it. We didn’t find anybody currently using this approach in production. Projects like Caja seemed unmaintained. So we’d have to reason about the security properties ourselves, but it’s hard because those approaches are more blacklist centric (remove unsafe JS features) than whitelist centric. They also did more than we needed, which increases the attack surface area. There’s some papers on the topic that formalize Javascript in order to write proofs about it, but they’re quite old and some newer Javascript features like async/await definitely could invalidate some of assumptions behind these proofs. While I don’t know the exact history, the Realms work does derive from Caja, it’s just the latest in this line of evolution.