Martin: the goal is to allow access to shared array buffers -

Dan: the risks are to do with cross-proccess attacks with high-resolution timers...

Martin: timing attack related stuff ...

Dan: what is the user need?

Martin: being able to deploy your wasm code... you've got a popup with some code, some of the code is wasm, you want to use shared array buffers... but you can't use it because ... The user benefit here would be that the app would use less of the battery, cpu, etc... because it's able to use the more efficient version of the code... There's a lot of work here .. and a lot of use of mechisms that maybe shouldn't exist...

Dan: example?

Martin: like not partitioning popups...

Martin: key example - cross origin isolation breaks the communication ... you have an iframe, that opens a popup window, then that window is able to communicate back.

Yves: payment is one use case.

Martin: ... use cases that involve cryptography ...

Yves: this could always be misused for [advertising]... Reading the explainer - it's possible to do this but they want to remove it for security reasons...

Martin: but wouldn't be able to access coi restricted APIs...

Yves: allowing this capability... you open up another process to avoid timing attacks...

Martin: i don't like these things without going through the negatives...

Yves: all efforts around restricting sharedarraybuffer... it's done by patching and patching and patching ...

Martin: they want to restore the ability to do cross-origin communication... if you isolate something then you want to be able to communicate it still... but question on whether that should be allowed - the reasonable one is : if you COEP something it can't embed something... it would be seem reasonable to loosen the restrictions on COEP if you isolate...

Dan: we could get them along to a call...

Martin: first thing to do might be ask something... In the explainer (though it's a lot) there is no discussion of the trade-off. They want to change the way cross-origin isolation works so...

Questions:

We're still struggling a little bit with the explainer here, but there are a few things you might add to help us a little.

1. What is the user need that this addresses? There is some mention of performance benefits in your writeup here (~40%! [citation-needed]), but that isn't really substantiated. Can you give us some examples of real-world scenarios in which this would be used and provide material end-user benefit. In particular, why do these applications need to jointly use popups and this sort of arrangement? In "use cases" you list "App with cross-origin popup" and state "The user would like some of their compute heavy web apps to be faster" - but there is no discussion of why these applications must exist cross-origin.

2. What are the trade-offs taken for this? Or, what are the risks that we'd be taking on by allowing this loosening of cross-origin isolation? The explainer focuses exclusively on arguing for the proposal, but if we're going to make a reasoned decision, we need to understand the cost of the change. Are there any safeguards that might be needed to mitigate these risks?

3. Are there cases where applications might want to use SharedArrayBuffer, but are unable to employ a fallback method, such that enabling easier access to the capability would dramatically simplify the deployment/development of those applications?

we agree on the above comment and Martin posts it