[Identity] Don't reinvent postMessage · Issue #11 · w3c/mediacapture-handle (original) (raw)

The way navigator.mediaDevices.setCaptureHandleConfig and track.oncapturehandlechange are defined, they create an unintentional broadcast messaging channel from capturee to all capturers (and all their track clones, wherever they may have been transferred). And due to #9 it works long after capture ends.

Capturee can send data like this:

async send(dataStr) { for (const handle of dataStr.split(/(.{1024})/).filter(x => x)) { navigator.mediaDevices.setCaptureHandleConfig({handle}); await new Promise(r => setTimeout(r, 10)); } });

Capturers receive data like this:

track.oncapturehandlechange = ({handle}) => div.innerText += handle;

While the handle field is capped at 2k bytes, permittedOrigins is unbounded (with some munging).

This is awkward and there are ways to design APIs that do the same thing without such side effects, so we should do that. Otherwise someone somewhere will start relying on it, and then we have to support another alternative to postMessage forever.

Possible solution

I see no reason to allow a (top-level) document to call navigator.mediaDevices.setCaptureHandleConfig more than once with non-default values. Maybe throw instead?