mfo...@chromium.org, sko...@chromium.org
Summary
In aligning with Blink’s intention to remove powerful features on insecure origins, we plan to deprecate and remove support for the Presentation API on insecure contexts. More details, motivation, and metrics can be found in this document.
We plan to add a deprecation message in Chrome 61 and remove it from insecure contexts in Chrome 67.
Motivation
The Presentation API uses a permission (screen selection) dialog and can be used to present arbitrary Web content on screens that may lack a URL bar. Both of these were factors in deciding to restrict it to secure contexts.
Interoperability and Compatibility Risk
Edge: No signals
Firefox: Positive
Safari: No signals
Mozilla requested this change and they are the other shipping implementation of the API so we do not anticipate interoperability risk.
Existing uses of the Presentation API in Chrome are almost all through the Cast SDK. The Cast SDK will be modified to be a no-op on insecure contexts, which should address the compatibility risk: sites that continue to use the Cast SDK on insecure contexts will behave as if the Presentation API is not available.
Direct use of the Presentation API is supported as of M59 on desktop. Sites that use the Presentation API directly in insecure contexts will see a deprecation message, and eventually an exception when the API is removed.
An HTTPArchive search yielded ~340 sites that are referencing PresentationRequest directly (i.e., not through the Cast SDK). About 10% are from sites using a player library that embeds a copy of the Cast SDK. We’ll work with the player library authors to update their script. The remaining usages are enumerations and should not be affected by deprecation and removal.
Alternative implementation suggestion for web developers
Web developers who wish to continue supporting presentation from their site have the following options available:
Upgrade site to https.
Users can use browser or OS features like desktop casting, tab casting and Media Remoting to remote Web content to other devices.
Developers can use the Remote Playback API to trigger remote playback of <video> and <audio>, which is the most common use case for presentation.
We plan to engage with the Cast developer relations team to help sites using the Cast SDK choose from these alternatives. Based on feedback, we may update the removal milestone.
We will also ship Remote Playback API on Chrome desktop before removal, to provide an additional alternative to Web developers.
Usage information from UseCounter
Usage of the PresentationRequest constructor on insecure contexts is 0.177% of page views on Android (representing 37.0% of usage) and 0.245% of page views on Desktop (representing 14.5% of usage).
These metrics are based on Blink.UseCounter.Features as it is deemed more accurate. More detailed metrics can be found in this document.
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=733381
Entry on the feature dashboard
https://www.chromestatus.com/feature/5766218384408576
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgg%2BHGpgh2W9Tqcgw9K1utXPAvaZXuAFrMNYGdBZpKrsf5QcQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BLUPR0501MB8526B19F0105ED62A920709DFC50%40BLUPR0501MB852.namprd05.prod.outlook.com.
You'll be shocked (shocked!) to learn that I support restricting this feature to secure contexts.
That said, can you help clarify a few points of the plan?1. What exactly do you intend to deprecate in non-secure contexts? `new PresentationRequest()`? `PresentationRequest.start()`?
2. It's not clear to me what you mean when you say that "sites that use the Presentation API directly in insecure contexts will see ... an exception". Do you intend to make that constructor throw? Or to hide the interface entirely?
More generally, can you help me understand why the usage of `PresentationRequest.start()` is so much lower than the `PresentationRequest` constructor? Are folks just constructing these objects for fun? :)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfJkoKdoWCvdOQ4ZUJ_-Gh6gxNjq46W%3D1SXhzh%3DVm2ePg%40mail.gmail.com.
You'll be shocked (shocked!) to learn that I support restricting this feature to secure contexts.That said, can you help clarify a few points of the plan?1. What exactly do you intend to deprecate in non-secure contexts? `new PresentationRequest()`? `PresentationRequest.start()`?
2. It's not clear to me what you mean when you say that "sites that use the Presentation API directly in insecure contexts will see ... an exception". Do you intend to make that constructor throw? Or to hide the interface entirely?