Consider restricting SharedArrayBuffer to same-origin usage

[annevk]

Currently SharedArrayBuffer is limited to an agent cluster, but can be cross-origin (though same-site and same-scheme) within that agent cluster. We should consider restricting it further so it cannot be used cross-site, so that SharedArrayBuffer does not become the new document.domain.

cc @whatwg/security

[wanderview]

@dtapuska I thought you told me we did not support cross-document SharedArrayBuffer until recently (m78, etc). Is that true? Of course, @domenic tells me the WPT tests for this pass in M76. I'm just wondering if we can assume low usage due to lack of implementation.

[dtapuska]

Because of two different code paths postMessage (MessageChannel and Window are different). It was supported on Window but not on MessageChannel I believe. Check out this WPT test link

[annevk]

This also affects the Wasm Web API: https://webassembly.github.io/spec/web-api/#serialization.

cc @littledan

[annevk]

I think it would be ideal to fix this as part of #4732 as doing this at a later stage makes rolling this out a much larger compatibility concern. Also, the sooner Chrome can roll this out the better. Is there someone investigating this? (Remember that if SharedArrayBuffer/WebAssembly.Module remains same-site deprecating/removing document.domain does not help with the goal of origin-per-process.)

[domenic]

I think we could do it independently (and earlier). I take it Mozilla is interested; I suspect Chrome is but it'd be best to get some confirmation. @dtapuska, can you take the lead here?

[annevk]

We would implement this to effectively make less things depend on PSL, yes. (If document.domain is used this does not shrink the boundary, but it at least would require that to be used.)

[dtapuska]

What is the timeline? I can add a use counter and see how many SharedArrayBuffers get transfered in SameSite vs SameOrigin cases.

[annevk]

That'd be great. Not sure about a timeline, but the longer we leave this the way it is the more likely it is we cannot change it.

[dtapuska]

Hmm, this is a little more complicated. Chrome doesn't serialize the origin for message ports because origin is only used in CrossDocumentMessaging

[littledan]

@annevk I'm not sure how this affects the Wasm/Web API. Could you clarify? cc @Ms2ger

[annevk]

@littledan WebAssembly.Module has an agent cluster restriction similar to SharedArrayBuffer. Agent clusters are keyed on sites due to document.domain. It'd be good if new features are keyed on origin, despite that.

[annevk]

@dtapuska @mikewest any more thoughts here? Perhaps this could be done as Chrome transitions to COOP+COEP? Firefox could maybe also require this out of the gate given that we currently don't support it at all.

[wanderview]

I don't think we've had time to add a use counter for this. It requires a bit more code than we first thought.

That being said, I think @domenic is leaning towards an explicit opt-in for origin isolation for other reasons, so making SAB same-origin may now be orthogonal to that effort. It may still be worth doing on its own, though.

[annevk]

I think this is only worth doing if we make the document.domain setter return early at the same time, as proposed in #5122. Otherwise it's a half-measure. So duplicating this into that.

(Also, my comments about WebAssembly.Module above were wrong, it's agent cluster restriction is largely unrelated to the restrictions for SharedArrayBuffer.)