Re: [mediacapture-handle] Should the handle be an object? (#68)

> One thing to consider is that the current 1024 bytes size might be harder to define with objects.

I intended that limitation to defang potential attacks where a captured site overwhelms a capturing site with extremely large messages. That's probably¹ not terribly concerning, though, as the captured site would have to pay as much for the attack as would the victim, and the cost would be paid without the attacker even knowing if there is a victim, or who it is. I think it's safe to drop this limitation².

> An alternative to consider is to enable MessagePort level communication.

There is value in the capturer being able to read something about the capturee, without letting the capturee know that there is a capturer.
* It prevents attacks like the one discussed in the previous paragraph.
* It simplifies things for some Web developers. For capurees that only have on static thing to report, it's easier to set the CaptureHandleConfig once, than to register a handler that responds to queries over a MessagePort.

> As a side note, and this also applies to structured exposure of CropTargets, if a web application starts to create CropTargets proactively, UAs should make the creation of such objects cheap and only start expensive operations when these objects are actually used to crop. This is another argument in favour of creating CropTarget synchronously.

Agreed. (But there are other arguments both ways.)

For now, I am not concerned, because I expect a very limited number of CropTargets. But, yes, that is indeed a valid argument. If we later observe that sites often expose several CropTargets, this argument could increase in weight.

--
[1] Or wdyt?
[2] I intend to ask Chrome's security experts.


-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1256707918 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 23 September 2022 21:47:08 UTC