| 00:00 | <Kris Kowal> | Mathieu Hofman’s points are all correct. ShadowRealm is an orthogonal and sometimes complementary approach to Lockdown and Compartments (or the more surgical Evaluators + Module Harmony) |
| 00:01 | <Kris Kowal> | Lockdown makes the surrounding realm suitable for multiple guest programs. The surrounding realm can be a ShadowRealm, but does not have to be. |
| 00:04 | <Kris Kowal> | danielrosenwasser So, point 3 is not the case: it is practical to lockdown() an ordinary realm. |
| 00:06 | <Kris Kowal> | But running lockdown in the primary realm does mean less JavaScript will function normally in that realm. So, a shadow realm could be useful for those cases. |
| 00:06 | <danielrosenwasser> | right, that's really what I meant |
| 00:06 | <danielrosenwasser> | e.g. your own code expects an "unlocked" realm, but it's a sufficient constraint on guest code where you want to reuse the same Realm instead of spinning up a Shadow Realm per guest |
| 00:07 | <Kris Kowal> | Yes, that is a nice arrangement. |
| 00:07 | <Kris Kowal> | Not one we’ve had the opportunity to try yet though! We’ve been locking down primary realms, including worker realms, for all of Agoric’s work. |
| 00:09 | <Kris Kowal> | Shims are not really a problem. Lockdown just has to cooperate with the shim. After shims, the biggest problem is usually property override mistakes, which aren’t really detectable until you’ve frozen some intrinsics. |
| 00:10 | <Kris Kowal> | Notably, code of the flavor {}.constructor = myConstructor or myPrototype.toString = have to be changed to use Object.defineProperty, but then you’re golden. Folks using Hardened JavaScript generally get by these obstacles by patching the package and sending up a PR. |
| 00:12 | <bakkot> | ugh |
| 00:12 | <bakkot> | can we make Object.prototype.constructor/toString be more exotic instead of that |
| 00:12 | <Kris Kowal> | That would be nice. We would like that. |
| 00:12 | <danielrosenwasser> | (I would like to know what that means too :D) |
| 00:12 | <bakkot> | I want to make it more exotic anyway https://github.com/tc39/proposal-symbol-proto/issues/1 |
| 00:13 | <danielrosenwasser> | So would Shadow Realms not also be an alternative sandboxing technique? It sounds like it provides similar guarantees without needing a lockdown, but at the expense of a higher footprint |
| 00:13 | <Kris Kowal> | Yes, that proposal is consistent with our aims and also hits the data-only prototype-pollution-attack firmly on the head. |
| 00:14 | <Kris Kowal> | I would say complementary. Lockdown gives you multi-tenant realms, including multi-tenant shadowrealms. |
| 00:15 | <Kris Kowal> | And multi-tenancy comes with its own bag of trade-offs. |
| 00:15 | <danielrosenwasser> | Right, so while they are somewhat orthogonal, there is overlap in the use-cases and there will necessarily be a nuanced understanding of which is best for your situation |
| 00:15 | <danielrosenwasser> | e.g. instanceof Array will not be coherent between Realms, Compartments share more than you might anticipate by default, etc. |
| 00:15 | <Kris Kowal> | That is, for example, you can’t safely endow a lockdown compartment with high resolution timers. |
| 00:17 | <Kris Kowal> | Yeah, the instanceof Array issue, we call identity discontinuity hazards, or more recently, Mark dubbed them “eval twins” |
| 00:18 | <Kris Kowal> | But you don’t get identity discontinuity of intrinsics with either ShadowRealm or Compartment. |
| 00:34 | <Kris Kowal> | Regarding multi-tenancy, the thing that we often miss is that all real JavaScript applications are multi-tenant if you count your third-party dependencies as tenants, and especially if you consider the Node.js standard library a tenant. |
| 00:36 | <Kris Kowal> | The only arrangements that qualify as single-tenant are hand-rolled web pages with no dependencies that rely exclusively on platform APIs implemented entirely in the non-JavaScript substrate. And the only cases where multi-tenant programs are not problematic are the ones where there’s no value to staging an attack. |
| 00:38 | <Kris Kowal> | But yes, the mitigations have overlapping threat models and lots and lots of nuance :-) |
| 00:40 | <danielrosenwasser> | Right, there is usually an idealistic "assume my dependencies are not malicious or hijacked". I know stuff like LavaMoat helps protect against that piece of the puzzle. |
| 00:41 | <Kris Kowal> | The idealistic assumptions admittedly work out surprisingly well most of the time. |
| 00:42 | <danielrosenwasser> | yeah, it's worked out well enough so far what could go wrong? :D |
| 00:44 | <danielrosenwasser> | Okay, this has certainly given me a much better understanding of the lay of the land. I might come back with more questions, but I really appreciate you taking the time to explain! |
| 00:44 | <Kris Kowal> | It’s a living! |
| 01:06 | <Mathieu Hofman> | In case anyone reading doesn't have the background, lavamoat is fully leveraging compartments for isolation, and wouldn't be able to be implemented with ShadowRealm. |