CropTarget, RestrictionTarget, or something else?

[eladalon1983]

As of the time of writing, Element Capture reuses CropTarget.

[Exposed = Window]
partial interface BrowserCaptureMediaStreamTrack {
  Promise<undefined> restrictTo(CropTarget? cropTarget);
};

Pros:

• Simplicity: Avoids introducing additional types unnecessarily.
• Ergonomics: Keeps cropTo() and restrictTo() similar and allow documents to postMessage() a single token that could serve either.

Cons:

• Naming: The name "CropTarget" is misleading in the context of restrictTo().
• Security: Some concerns; see below.

Consider a document from EMBEDDED that previously posted a CropTarget to a cross-origin document EMBEDDER. The team at EMBEDDED might have reasoned that no special permissions were being granted by posting this token, and this was correct at the time when only cropTo() could use CropTarget. But by reusing CropTarget for restrictTo(), the posting of the CropTarget object now implicitly includes permission to remove occlusions from a capture, which might not have been intended by EMBEDDED.

[eladalon1983]

I've vacillated between the opinion of using a new bespoke token, and that of reusing the existing token, quite a few times. Presently I prefer using a new token. As this particular issue was not explicitly discussed, I'll go ahead and change the spec, and raise the topic for discussion during the upcoming SCCG meeting in TPAC 2023. Opinions welcome both here and there.

(FWIW, Chrome's implementation of both tokens will likely be shared under the hood.)

CC @baylesj @mfoltzgoogle @alvestrand

[markafoltz]

The current spec adds a new token type, RestrictionTarget. I believe this can be closed out.