Intent to Ship: Feature Policy: diplay-capture

[Elad Alon]

Contact emails

elad...@chromium.org

Explainer

https://docs.google.com/document/d/1qb26hiLwPO8XnvHvBjgsGDGXNI5ABvGA32461uERRSA/edit?usp=sharing

Specification

https://w3c.github.io/permissions/#dom-permissionname-display-capture

API spec

Yes

Summary

Implement the display-capture feature policy from the Screen Capture spec. https://w3c.github.io/permissions/#dom-permissionname-display-capture This policy allows restricting access to the getDisplayMedia() API in embedded resources.

Blink component

Blink

TAG review

https://github.com/w3ctag/design-reviews/issues/309

https://github.com/w3ctag/design-reviews/issues/440

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Firefox and Safari already implement this. (MDN claims otherwise, but it is out of date. The demo in https://plastic-brief-carnation.glitch.me/ demonstrates as much.)

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals

Ergonomics

The spec for getDisplayMedia lists display-capture as the mandated gating. Performance unaffected.

Activation

Some websites could conceivably lose access to display capture if they call getDisplayMedia from a context which is not currently allowlisted by display-capture. This is unavoidable, as the spec (rightfully) mandates that such calls to getDisplayMedia be rejected. We have considered introducing display-capture carefully by only emitting a deprecation warning when getDisplayMedia is called from an non-permitted context for two milestones. There are some inherent problems: 1. Sites will remain unprotected for longer. (display-capture serves a vital purpose, after all.) 2. This would mislead sites that use feature discovery to decide whether it's safe to embed an iframe. Such sites would incorrectly believe they can strip away getDisplayMedia access from iframed documents. Mitigating the risks of shipping this immediately is that Firefox and Safari already implement display-capture. This makes it unlikely that sites of appreciable size and polish fail to apply display-capture.

Security

This is a pure security gain. It plugs an existing security hole.

Debuggability

This is one feature policy, and piggybacks on the general debuggability of feature policies.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

GetCurrentBrowsingContextMedia

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1150788

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1231698

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5144822362931200

This intent message was generated by Chrome Platform Status.

[Philip Jägenstedt]

Hi Elad,

I think I could parse the answer out of the spec(s), but can you clarify if this amounts to a change of default behavior in any context, whether top-level browsing contexts or in iframes? Or is the only change that it will now be possible to disallow getDisplayMedia() with Permissions Policy (not Feature Policy, right?) but the default behavior is unchanged?

Although it's not (yet) part of our process, can I also ask that you file a new BCD issue pointing back to this intent/bug/etc. requesting that compat data for this is updated when the change is getting close to stable?

Best regards,

Philip

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPGfXfE5z6hJcWO112zX3We-oNTb%2BZjiJk%2B6RNb9%2Bv05w%40mail.gmail.com.

[Elad Alon]

* This does indeed change default behavior. Cross-origin iframes will not, by default, be allowed to call getDisplayMedia, unless explicitly allowlisted by the embedder. That is because the default value of the policy is 'self'.

* Gladly, I will file a new BCD issue. My understanding is that I should do this once I get the CLs landed or at least LGTMed. If you meant right now, though, let me know, I can do that, too.

[Chris Harrelson]

Hi, a comment below.

On Thu, Jul 22, 2021 at 9:38 AM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:

* This does indeed change default behavior. Cross-origin iframes will not, by default, be allowed to call getDisplayMedia, unless explicitly allowlisted by the embedder. That is because the default value of the policy is 'self'.

* Gladly, I will file a new BCD issue. My understanding is that I should do this once I get the CLs landed or at least LGTMed. If you meant right now, though, let me know, I can do that, too.

Do you have any data, such as a use counter or other research, indicating that very few page loads will be affected by this change?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d744a237-738a-4883-a21a-36be4b87a9d6n%40chromium.org.

[Elad Alon]

I intentionally intended to introduce those (see the Alternatives Considered section of the design doc), and even got UKM approved and the CLs lined up (UKM-CL, UMA-CL). But after thinking about it for a bit longer, I realized that I had no way of distinguishing legitimate breaks - those display-capture was intended to stop - from illegitimate breaks - those where the website just needs to be rewritten. It also occurred to me that with a security issue, it's good to move fast and plug the hole soon, not wait a few milestones until the new UMA+UKM is in the field and data starts coming in. I therefore think it's best to ship without waiting for the UKM+UMA. I do, however, intend to land those CLs for after-the-fact tracking. Wdyt?

[Elad Alon]

s/intentionally/initially

[Chris Harrelson]

On Thu, Jul 22, 2021 at 12:45 PM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:

s/intentionally/initially

On Thursday, July 22, 2021 at 9:44:10 PM UTC+2 Elad Alon wrote:

I intentionally intended to introduce those (see the Alternatives Considered section of the design doc), and even got UKM approved and the CLs lined up (UKM-CL, UMA-CL). But after thinking about it for a bit longer, I realized that I had no way of distinguishing legitimate breaks - those display-capture was intended to stop - from illegitimate breaks - those where the website just needs to be rewritten. It also occurred to me that with a security issue, it's good to move fast and plug the hole soon, not wait a few milestones until the new UMA+UKM is in the field and data starts coming in. I therefore think it's best to ship without waiting for the UKM+UMA. I do, however, intend to land those CLs for after-the-fact tracking. Wdyt?

Well, if the sum of the "legitimate" and "illegitimate" use cases is very small, say less than 0.01% of page loads, then that is enough to safely approve this intent (with no need to figure out which parts were "legitimate"). If it is substantially higher, we'd need to evaluate. So it'd help a lot if you could collect some data on the approximate percent of affected page loads. Even Canary and Dev channel data would help.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa43f56d-9218-49ae-9d71-c09be39fef09n%40chromium.org.

[Elad Alon]

Sorry, I've neglected to mention that there's another problem here. I can't collect data about how many sites call getDisplayMedia() from a context that is not allowlisted by display-capture, without introducing display-capture. A possible work-around is to introduce display-capture but make it no-op. But if we do that, then sites that capability-detect for display-capture would potentially be tripped up by this. A site could think it safe to embed an iframe when it's not. That's another reason for why we abandoned the plan to gather data before applying the policy. Wdyt?

[Elad Alon]

The scope of potential breakage is very limited, as evidence by this use counter.

[Chris Harrelson]

Great! For those who didn't click, the use counter shows 0.006%.

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/187df2bc-8616-4459-baee-014b7a0a0b1bn%40chromium.org.

[Philip Jägenstedt]

LGTM2

Thanks Elad, that does put an upper limit on the breakage which is quite modest.

Assuming we'll match Firefox and Safari default behavior for cross-origin iframes, that means any breakage Chrome would see would either be content already broken in other browsers, or in Chrome-only code paths. Browser-specific code for WebRTC and related APIs seems fairly common from what I've seen, but still it seems like a modest risk.

In a situation like this where Firefox and Safari agree, I think we should also consider the risk of delay itself, namely the risk that sites start to depend on our behavior while we're waiting for evidence that we can change it. So let's try it and trust our bug triage to catch regressions.

[Alex Russell]

LGTM3; thanks for the pointer to the usecounter.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell]

I see that the use counter has a couple of sample urls included. Now you already have 3xLGTM but they might still come in handy when checking the effects of the change (hopefully none).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b3f759d6-e531-4b7d-b488-b94bb3463150n%40chromium.org.

[Philip Jägenstedt]

On Thu, Jul 22, 2021 at 6:38 PM Elad Alon <elad...@google.com> wrote:

* Gladly, I will file a new BCD issue. My understanding is that I should do this once I get the CLs landed or at least LGTMed. If you meant right now, though, let me know, I can do that, too.

I forgot to answer this. The actual change to BCD will be later, so it's OK to just create the issue and say which Chromium milestone you predict this will be in. A reviewer can verify that it wasn't reverted or delayed when there's a PR for it. (A PR won't magically appear, if you'd like to later create one that's cool, but just the issue is more than enough.)

[Joe Medley]

The status entry says this shipped on desktop in 90. So is this intent for Android and WebView?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--

[Elad Alon]

This has been OT-gated since m90, and only applied to getCurrentBrowsingContextMedia / preferCurrentTab. Now (m94+) it is shipped by default for all Desktop platforms, and applies to getDisplayMedia as well.