[Identity] Don't reinvent postMessage

[jan-ivar]

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?

[alvestrand]

Does this expose any security risk that PostMessage does not?
If not, this is irrelevant.

Again, this does not seem to be an adoption blocker.

[eladalon1983]

1. +1 Harald's message on both accounts (comparison to postMessage and assertion that this is non-blocking).
2. The track itself is a message channel through which 3840 x 2160 pixels can be sent 60 times per second.
3. I do see a reason to allow multiple calls to setCaptureHandleConfig(). Namely, that a captured tab can switch roles without the top-level being navigated. For example, you might change to sharing a completely different slides deck, creating a new "session" from the application's POV, yet not navigate the top-level document.

[jan-ivar]

Does this expose any security risk that PostMessage does not?

I'm not claiming a security risk here. Merely unfortunate redundant design that undermines the desired usage pattern. This is a mechanism for bootstrapping a message channel, which seems undermined if it's easier to use it as a message itself.

I didn't find a general design principle about needlessly reinventing existing concepts, except for event handlers, but this seems like reasonable feedback to me. cc @annevk to see if there is a design principle that applies here.

The track itself is a message channel through which 3840 x 2160 pixels can be sent 60 times per second.

By this rationale, the Capture Handle API itself seems unnecessary. Again, I'm not making a security claim here.

[jan-ivar]

I would also like to understand what the use case is for calling this method more than once. If this serves no purpose then we shouldn't allow it. I did find https://w3ctag.github.io/design-principles/#simplicity relevant here.

[eladalon1983]

I would also like to understand what the use case is for calling this method more than once.

Please read point number 3 in this message.

[jan-ivar]

switch roles without the top-level being navigated. For example, you might change to sharing a completely different slides deck

This seems out of scope, and not necessary once a relationship has been established.

[annevk]

I looked into this a bit:

1. It seems this does not observe the scope of either BroadcastChannel or Window's postMessage(). That seems potentially problematic. It introduces a way for origins to reach each other that previously could not reach each other at all.
2. Introducing a new way of doing messaging is not necessarily something we want. E.g., storage did that and I think everyone agrees that it would be better if we just had done BroadcastChannel from the start.

I'm not sure what the requirements and tradeoffs are here, but it does seem like some more investigation is warranted.

[eladalon1983]

Before we proceed with the technical discussion of whether setCaptureHandleConfig() should be callable once or multiple times, let's recall that @jan-ivar has claimed that this issue is "adoption-blocking." This technical question can be resolved either way, and 99.9% of the document would remain unchanged. The W3C exists exactly to facilitate discussions of this type. I believe we should first acknowledge that this issue is not adoption-blocking. This would avoid the impression that a WebRTC Working Group chair might be using coercive measures to extract concessions during technical discussions.

Wdys, @jan-ivar?

[eladalon1983]

@jan-ivar?

[eladalon1983]

Resurrecting this issue now that W3C-adoption has been unblocked and completed.

It introduces a way for origins to reach each other that previously could not reach each other at all.

The capturer is already receiving every single pixel the capturee is drawing to the screen. These origins are reaching each other already.

Introducing a new way of doing messaging is not necessarily something we want.

I think that if we look closely, we'll see that a lot of APIs can be creatively used for transporting a message. Since in this case we're carrying a message from capturee to capturer, which is a direction in which communication is already possible, I don't see a problem.

[alvestrand]

With capturee -> capturer communication, we have this flood of data running already.
If we're worried about opening new channels of communication, "actions" is worrisome because it goes in the other direction.

[yoavweiss]

A drive-by suggestion: Maybe rate-limiting the calls to setCaptureHandleConfig() can reduce the risk of it being used as a bit-by-bit communication channel, while at the same time, continue to enable the use cases of the captured application changing state and wanting to notify the capturer of that.

[eladalon1983]

A drive-by suggestion: Maybe rate-limiting the calls to setCaptureHandleConfig() can reduce the risk of it being used as a bit-by-bit communication channel, while at the same time, continue to enable the use cases of the captured application changing state and wanting to notify the capturer of that.

If it helps things along (@jan-ivar?), I am OK with adding rate-limiting initially (as a raised exception), but I'd then like to continue the discussion for removing it. Rationale:
Consider a legitimate application that calls setCaptureHandleConfig() very rarely. But not necessarily once. It nows needs to worry about those very rare occasions when it makes two calls in overly rapid succession. For example, if a presentation software calls setCaptureHandleConfig() whenever changing to another deck, then redirections could happen too rapidly. Such rare bugs are too likely to be missed by developers and end up as bugs.

[alvestrand]

If we were doing rate-limiting, I'd rather do it on the notification end - for instance, change the description of setCaptureHandleConfig's event firing to something like:

Queue a task to execute the following steps:

1. At UA's discretion, insert a short delay to avoid firing too many events
2. set CurrentCaptureHandle to the current value of [[internal slot on capturee indicating last setCaptureHandleConfig]]
3. if it is different from [[internal slot on capturer indicating what was last fired]], fire event

(idea courtesy Jan-Ivar's discussion of reflecting muting on mediacapture-transform)
But again, this is the direction in which we already have a high capacity path (the captured image), so not much of a worry.