- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Feb 2022 12:14:58 +0000
- To: public-webrtc-logs@w3.org
> This is part of the API example exposed in the initial message of this thread. There are two separate access-controls here: 1. Who may read, directly from a track, the CropTargets that exist in the current browsing context. 2. Who may cropTo(CropTarget) for a given CropTarget. I gather from your latest message that you intend the same access-control to apply to both simultaneously. I'd just like to bring to your attention that, so long CropTargets are transferable, the first does not imply the second. You'd have to explicitly state that your access-control applies to both. And then you'd also need to discuss what happens to a track that's transferred after a crop has been applied, if the new owner of the track would not have otherwise been allowed to crop by itself. Access-control is hard and best left as post-MVP whenever possible[*]. > > Wdyt? Improvement label > > Sounds good to me. Great, seems like we agree about it being post-MVP. I look forward to resuming this discussion when we've reaches consensus on the MVP parts. -- [*] "Whenever possible" added as a clarification in anticipation of this topic being debated, with inverted roles, around Capture Handle. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/6#issuecomment-1027879202 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 February 2022 12:15:00 UTC