HTML: test MessageChannel and SharedArrayBuffer more

[annevk]

@yutakahirano @dtapuska @domenic @chihweitung @asutherland the final test in what is now window-iframe-messagechannel.https.html in this PR is the most interesting and Chrome fails there, despite @binji claiming in whatwg/html#4209 (comment) that it works in Chrome. (And it doesn't even generate a messageerror event, the SharedArrayBuffer becomes null somehow.)

I'm not really sure what the best course of action for that scenario is and we're hitting a similar thing in whatwg/html#4734 where this enforcement of boundaries becomes even more critical from a security perspective. Basically, it would be really good if we could have enforcement the moment we cross a boundary, regardless of whether the receiving port is active or not. However, this would basically mean specifying the "agent cluster hop" more explicitly and allowing replacing problematic serialized records with errors there in some form.

(An alternative might be not sending anything across until the receiving port is activated (or at least not from the point where a message contains a problematic object), but then implementations still need to have the above kind of enforcement at the boundary to avoid leaking data in the wrong places. This wouldn't be observable so the specification wouldn't have to do that, but it's always suboptimal if there's such a large architectural gap between implementation and specification.)

[annevk]

Thoughts anyone? It would be nice to make progress here.

[foolip]

I could review the tests, but probably @yutakahirano is a better reviewer?

[yutakahirano]

I'm confused by cross-origin-resource-policy: cross-site. IIUC it should be cross-origin, not cross-site. WICG/cross-origin-embedder-policy#1

Is my understanding stale?

[annevk]

No, that was my mistake.

[foolip]

@annevk sent a fix: #19786

[yutakahirano]

(Sorry, I will come back on Oct 23)

[domenic]

It seems like from the spec's perspective the model might be fine? I.e. the test seems to be testing what the spec is saying, and the spec seems to have a model that's reasonable from a user's perspective. I guess that's what you're getting at in your last paragraph.

If we want to change the spec, and thus the test expectations here, I'd like to hear more from implementations on how exactly they implement MessagePort queues, and in particular how SABs fit in to those. My guess is that it's fairly similar to the spec, except that instead of the serialization containing the [[ArrayBufferData]], [[ArrayBufferLength]], and an agent cluster, it's more likely some kind of pointer/agent cluster ID.

As for implementation enforcement, I don't think there's any danger of implementations leaking SABs across processes, since cross-process shared memory isn't much of a thing. And if two sites/origins are in the same process (e.g. due to resource constraints), then there's no security boundary to be enforced on a technical level; we just want an interop story for when things fail. So I don't quite get the concerns there.

[yutakahirano]

+1 to @domenic, but I'm not familiar with SAB serialization implementation in chromium, too.

[annevk]

I'm happy with continuing to see these as implementation bugs. I think we should push harder for better test coverage with new serializable/transferable objects to account for these various edge cases in order to convince implementers to tackle their infrastructure issues.

@surma was doing some great work with generalizing some of those tests for the new structuredClone() API I remember, but I'm not sure where that ended up and how much it covers the multiple agent cluster cases.

[annevk]

If that's the course of action I guess we should land this test, close whatwg/html#4209, and maybe file a bug against Chrome? (Firefox already has one for MessageChannel/BroadcastChannel not working.)

[domenic]

The test code LGTM. I would still like someone to double-check the headers, as I haven't yet figured those out, but maybe @yutakahirano already did that.

[surma]

We have the “structured clone battery of tests”, which currently does not contain any tests with SharedArrayBuffers. IIRC, this battery of tests is used by workers, shared workers and I think some more. It should be easy (and great!) if the tests for MessagePorts would also use it.

If someone adds some tests for SABs, this tests would be run against all of the above, which seems desirable.

[annevk]

@surma ah great, pushed some fixes for that to #19886 (and analysis as to why SharedArrayBuffer testing there probably is not worth it).

@yutakahirano final thoughts?

[yutakahirano]

LGTM.

I have no concerns for security.

I don't have any negative opinions for the test expectation, but that can come from my unfamiliarity for MessagePort + SAB implementation in Chromium, so it is possible that another Chromium developer raises concerns from implementer POV in the future.