TC39 Async Context
2023-01-12
plaintext logs
prev next
source on github
16:00
<littledan>
MarkM started a talk-through of his investigation into whether to embrace AsyncContext at the SES Strategy Meeting yesterday. We didn’t get close to finishing the review, so this is Part 1, and we expect these to get gradually more refined https://youtu.be/vECr5IDJzpg
How has this discussion gone? Any more progress on the subsequent meeting? (Sorry for missing these.)
16:30
<Justin Ridgewell>
Second video is https://www.youtube.com/watch?v=28wfHOWCROo
16:31
<Justin Ridgewell>

We didn't get much feedback during the meeting, but Mark came up with an interesting attack on membranes:

16:33
<littledan>

We didn't get much feedback during the meeting, but Mark came up with an interesting attack on membranes:

huh, could you explain what this attack and fix mean for AsyncContext?
16:34
<Justin Ridgewell>
Briefly, it means all membranes will need to update to use an AsyncContext themselves if they care about preventing this type of communication. If not, it still doesn't allow direct access to to the other's graph, so it's not so terrible.
16:34
<littledan>
oh, which kind of communication?
16:35
<Justin Ridgewell>
You can communicate 1 bit of information per-call that is not directly seen by the membrane
16:35
<Justin Ridgewell>
See my first few paragraphs of the fix
16:35
<Justin Ridgewell>

The crux of this attack is that Alice has received 2 callbacks from Bob (they're actually the same === callback, but run in different fluid var contexts), which she stores. After receiving these callbacks, she can then invoke either. Carol cannot tell from the callback's identity which is invoked. Once invoked, Bob can tell from the fluid var state whether the first callback or second callback is invoked.

16:36
<Justin Ridgewell>
(Carol is the membrane)
23:08
<littledan>
Justin Ridgewell: Can we talk more about whether wrap is Realm-specific?
23:08
<littledan>
I think this would significantly complicate any implementation
23:08
<littledan>
the use cases for membranes and the types of mitigations don't depend on Realms at all, so I'm not convinced we should do it this way
23:11
<littledan>
On second thought, maybe implementation wouldn't be so complex, but this depends a lot on what semantics we adopt when different realms call each other (I honestly don't know what you have in mind)
23:27
<Justin Ridgewell>
Having it be per-realm or per-agent isn't important to me, I chose realm because it's easiest to implement in JS, I figured it be easy in C++, and it seems the least objectionable (per the dedent caching semantics)
23:38
<Justin Ridgewell>
Given that membranes will need to update to use AsyncContext in same-realm anyways, I don't think it matters if we choose to do per-agent (and they'll need to update for both same-realm and cross-realm)