You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider an application that self-captures, crops to a region of interest, and then posts the track on to a cross-origin iframe. One typical scenario for this would be when a general application embeds a third-party service that provides video-conferencing capabilities.
Because it's possible to change crop-targets, and even undo cropping altogether, the cross-origin iframe was basically given permission to capture the entire tab, which might be more than the original owner of the track intended. The receiver would even be able to embed third-party content and then re-crop to only capture that content!
It would be good if a mechanism existed to "lock-in" a track to its current crop-target, disallowing further calls to cropTo().
I think this is the MVP. Theoretically, we could specify an unlock() mechanism, to be available only in the origin of the original locker. But I think we don't need to do that yet; the original could polyfill this by keeping an uncropped clone. We can revisit if the need arises.
The text was updated successfully, but these errors were encountered:
Consider an application that self-captures, crops to a region of interest, and then posts the track on to a cross-origin iframe. One typical scenario for this would be when a general application embeds a third-party service that provides video-conferencing capabilities.
Because it's possible to change crop-targets, and even undo cropping altogether, the cross-origin iframe was basically given permission to capture the entire tab, which might be more than the original owner of the track intended. The receiver would even be able to embed third-party content and then re-crop to only capture that content!
It would be good if a mechanism existed to "lock-in" a track to its current crop-target, disallowing further calls to cropTo().
I propose:
I think this is the MVP. Theoretically, we could specify an unlock() mechanism, to be available only in the origin of the original locker. But I think we don't need to do that yet; the original could polyfill this by keeping an uncropped clone. We can revisit if the need arises.
The text was updated successfully, but these errors were encountered: