Intent to Prototype: display-capture feature policy

[Elad Alon]

Contact emails

elad...@chromium.org

Explainer

Link

Design doc/Spec

Spec

Summary

Implement the display-capture feature policy, defined in the Screen Capture spec.

Motivation

This feature-policy enhances privacy/security by giving an embedding frame control over an embedded frame's access to the getDisplayMedia API. Without it, some attack vectors would be open to the embedding frame, as it would be able to visually inspect most things which the embedding frame draws to the screen.

Risks

Interoperability and Compatibility

0. This is a standardized feature policy, so for better interoperability/compatibility, it should be implemented.

1. We are not applying the display-capture feature policy to getDisplayMedia yet, for fear it will break too many things on the Web. Once we've introduced some UMA histograms to track how many things might be broken, we'll know how to proceed.

2. We are applying the display-capture feature policy to getCurrentBrowsingContextMedia. However, since that's still only behind a feature flag, no risk exists to interoperability.

Firefox: Shipped

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Yes - getDisplayMedia and getCurrentBrowsingContextMedia.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

Probably not.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No; they likely already use it in order for their applications to be compatible with Firefox.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Probably not, but some outreach might be necessary before we apply it to getDisplayMedia.

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

Link

Requesting approval to ship?

No

[Mike West]

Hey Elad!

1. Are we still adding features to `Feature-Policy`, given the Permissions Policy shift? +Ian Clelland.

2. I note that no TAG review is linked below. Is this covered by some existing review, or will you be filing a separate review request before shipping?

-mike

[Ian Clelland]

On Thu, Nov 19, 2020 at 3:17 PM Mike West <mk...@chromium.org> wrote:

Hey Elad!

1. Are we still adding features to `Feature-Policy`, given the Permissions Policy shift? +Ian Clelland.

I think we can just s/Feature Policy/Permissions Policy/g here, and the intent is otherwise okay. It's just a rename, so at the spec level, they refer to the same thing.

 

2. I note that no TAG review is linked below. Is this covered by some existing review, or will you be filing a separate review request before shipping?

 I would expect that this is covered by one of the (few) exceptions:

> We did decide that the following cases don't need a TAG review:

>  1. Shipping a new API or augmentation of an API, or changing an API to match a spec, that is (a) already specified and accepted by the relevant standardization body, and (b) has already shipped in at least one other browser.

The feature is already specified, and has been shipped in Firefox, AFAIK.

[Guido Urdaneta]

The tag review for this is https://github.com/w3ctag/design-reviews/issues/440

--
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/CAK_TSXKTmRGPosRcwmY%2BR%2B6_4SUD1R5mxyWnG-9A9%3DxPvDtzFw%40mail.gmail.com.