Re: [mediacapture-region] Cropping non-self-capture tracks (#63)

Mozilla judges the impact of API changes not just on API users, but on end-users as well. The more sites become involved in what was traditionally a 100% user-controlled power tool (`getDisplayMedia`), the more we have to consider the tradeoff of loss of user-control as a side-effect of site involvement. Current discussion assumes all site involvement is helpful. What if it isn't? We'd like to make sure user agents can offer options to keep the user in control should sites make decisions that aren't helpful.

My concern is about unintentionally enabling self-censoring:

* With this new API, a service _**could**_ decide to offer cropping to any site that asks. Today it can't.
  * This doesn't seem farfetched given that we see `"*"` passed as origin to `postMessage` and `allow=` all the time. Expecting sites to show restraint in the interest of end-users doesn't work for all sites.
* This could be exploited by captured sites to defeat capture (self-censor), which may neither be the capturing site's intent or in the end-user's interest.

Allowing sites to self-censor may have merit or not, and merits explicit discussion, which we haven't had. Hopefully this isn't controversial. I'd like to separate comprehension of this argument from whether we agree what weight to put on it.

This has been an ongoing concern, but I'll explain why I think this particular feature crosses the Rubicon.

* I concede that a service today could decide to let captured sites know they're being captured. It seems reasonable to assume such a service would understand the consequences of that: it lets captured sites self-censor by modifying their DOM. But those captured sites wouldn't know when capture ends, and would be unable to uncensor again, a usability issue for this strategy, and thus e.g. they'd likely not take the extreme step of trying to subvert a user refreshing the page to workaround this censoring.

* I concede that a service today might attempt to let captured sites know when capture ends, though I'm not sure how well it would work in practice if the user closes a tab or a process is killed. In any case, the service's intent in this case also seems clear.

* In contrast, censoring with a cropTarget seems a lot simpler (if censoring is one's goal) since it only affects the capture, not the DOM. It seems concerning to me that services cannot offer cropping to sites without simultaneously risking this power being used to self-censor. This seems new with this proposal, given that this is the first tool that solves it satisfactorily IMHO (based on the shortcomings I described above).

Mozilla isn't necessarily opposed to self-censoring, provided users can override it. But step one is acknowledging this risk. Step two for us is, to find ways to mitigate this concern, which for us to support this feature, would require some language around this, e.g.

    User agents MAY offer users the option to defeat cropping through this feature outside of self capture.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 28 June 2022 23:53:35 UTC