1341114 - Limit WebAssembly.Module serialization/deserialization to an agent cluster

Status: RESOLVED DUPLICATE of bug 1609990

(Core :: DOM: postMessage, defect, P3)

Description

[Luke Wagner [:luke]]

This bug is for restricting postMessage() of a WebAssembly.Module to only work between dedicate workers in the same origin.  The reasoning given by the blink folks is that, when it comes to cross-origin sharing/caching of code, other proposals like SW+foreign-fetch (or just relying on the HTTP cache) are safer because they don't involve setting window.onmessage.

Comment 1

[Andrew Overholt [:overholt]]

Luke, are you planning to work on this?

Comment 2

[Luke Wagner [:luke]]

baku said it was an easy change so I hoping that he perhaps could?

Comment 3

[Andrea Marchesini [:baku]]

Luke, do we want to support window-to-DedicatedWorker and DedicateWorker-to-window communication?

Comment 4

[Luke Wagner [:luke]]

Oops, yes.

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 6

[Anne (:annevk)]

This should be relatively straightforward to add now that we're adding agent cluster support for SharedArrayBuffer. That's still not quite same-origin, it's same-site, but that also matches the current specification for WebAssembly.Module. Same-origin is proposed at https://github.com/whatwg/html/issues/4920 and can be done on top.

Comment 7

[Tom Tung [:tt, :ttung]]

Luke, could you remind my the importance of this bug? Is this blocking reSAB? If not, I would like to deal with it after the bug 1563335

Comment 8

[Luke Wagner [:luke]]

My impression is that it's not a high priority or blocker; SAB (and the scope of where a SAB can be postMessage()'d) seems like the more important thing to get right. That being said, it seems like, since WebAssembly.Module objects have the same postMessage() rules as SAB, this could be a simple change to implement, so maybe worth doing earlier?

Comment 9

[Tom Tung [:tt, :ttung]]

(In reply to Luke Wagner [:luke] from comment #8)

My impression is that it's not a high priority or blocker; SAB (and the scope of where a SAB can be postMessage()'d) seems like the more important thing to get right. That being said, it seems like, since WebAssembly.Module objects have the same postMessage() rules as SAB, this could be a simple change to implement, so maybe worth doing earlier?

Sure (I asked this mostly because I want to prioritize my work)

Comment 10

[Anne (:annevk)]

Couple things:

1. This isn't important for "resab".
2. Given "resab", WebAssembly.Module will likely have different rules from SAB as SAB requires a COOP+COEP process and this isn't needed for WebAssembly.Module.
3. Per https://webassembly.github.io/spec/web-api/#serialization WebAssembly.Module has to be restricted to an agent cluster (this is similar to SAB), but comment 0 and the summary of this bug ask for something else.

Luke, can you clarify with WebAssembly folks what the actual design should be? In particular point 3 above seems pertinent.

Comment 11

[Luke Wagner [:luke]]

Yes, iirc, comment 3 predates the subsequent discussion of further limiting to Agent Cluster; other than the COEP+COOP restriction, WebAssembly.Module should have the exact same allowed postMessage() scope as SAB.

Comment 12

[Tom Tung [:tt, :ttung]]

I don't have time to work on this before the end of this year. Will work on this again next year if no one happens to have time to fix this.