- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 May 2022 10:31:45 +0000
- To: public-webrtc-logs@w3.org
> That is not true in general, given how the web is authored today. Web pages embed adds and do not control what adds will do (they might well do fingerprinting so will generate CropTargets) They should not embed abusive iframes. IIRC, you have yourself, @youennf, brought up a few objects of which browsers can only instantiate a limited number. > There is a communication channel between the two, otherwise there would be no CropTarget. * It is not necessarily two-way. * It might be going through several embedders. * It is not ergonomic to communicate the error back. Certainly less ergonomic than having production be async. > no latency in 99.99% cases There is latency between the time a frame is first tagged and the time it's rendered. If tagging happens ahead of time, cropTo() reduces latency 100% of the time. > Second, produceCropTarget will rarely fail. When it will fail, web applications will get broken. 1. As I understand it, Safari and Firefox plan an implementation that imposes no limit on the number of tokens that can be minted. It is not mandated that produceCropTarget must fail. It would be an issue with Chrome's implementation. 2. I think the exact value of "rarely" is important here. If it's not too rare, it will be handled by applications. If it's exceedingly rare, like SHA-1 collisions, it's not a problem. Which specific value are you aiming at? Why are we worried? > I filed #48 to dig into that. Can we continue this particular discussion there? Gladly. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1131522076 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 May 2022 10:31:47 UTC