Intent to Deprecate and Remove: Presentation API on Insecure Contexts

[mark a. foltz]

Primary eng (and PM) emails

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:

1. Upgrade site to https.

2. Users can use browser or OS features like desktop casting, tab casting and Media Remoting to remote Web content to other devices.

3. 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

 

[Mike West]

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? :)

--
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.

[Domenic Denicola]

From: mk...@google.com [mailto:mk...@google.com] On Behalf Of Mike West

> 1.  What exactly do you intend to deprecate in non-secure contexts? `new PresentationRequest()`? `PresentationRequest.start()`?

Relatedly, is there a spec change that accompanies this? If both implementers are in support, we should change the spec, probably by using [SecureContext] so that the behavior is uniform with the rest of the platform. And then we can write web-platform-tests, to make sure others do the secure context restriction in the same way!

[Anton Vayvod]

A few months ago I believe: https://github.com/w3c/presentation-api/pull/413. WPT test is already there (in Chromium repo, at least).
 

--
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.

[Anton Vayvod]

On Tue, Jun 20, 2017 at 8:43 AM Mike West <mk...@chromium.org> wrote:

You'll be shocked (shocked!) to learn that I support restricting this feature to secure contexts.

We know. :)

 

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()`?

The spec throws SecurityError from PresentationRequest ctor: https://w3c.github.io/presentation-api/#constructing-a-presentationrequest

 

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?

See above.

 

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? :)

I believe that's because of the default request pattern shown in the following example: https://w3c.github.io/presentation-api/#presentation-initiation-by-the-controlling-ua-example. It is used by the Cast SDK too.

 

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.

[Domenic Denicola]

From: Anton Vayvod [mailto:ava...@chromium.org]

> 1.  What exactly do you intend to deprecate in non-secure contexts? `new PresentationRequest()`? `PresentationRequest.start()`?
>
> The spec throws SecurityError from PresentationRequest ctor: https://w3c.github.io/presentation-api/#constructing-a-presentationrequest
 

It looks like there are actually two restrictions going on here:

1. Removing the API entirely in non-secure contexts, via [SecureContext]. That is, a HTTP page that calls `new PresentationRequest()` will get a TypeError from JS, just like when calling `new ASDF()`.

2. Throwing a "SecurityError" DOMException if any of the URLs passed to the constructor are not "a priori authenticated URL"s.

I guess this intent is for both?

[mark a. foltz]

The spec reflects this change as navigator.presentation and PresentationRequest are marked [SecureContext].  The PresentationRequest only accepts a priori secure URLs so the navigator.presentation.receiver object (exposed to the page being presented) will only be exposed in a secure context.

 

[mark a. foltz]

On Tue, Jun 20, 2017 at 5:42 AM, Mike West <mk...@chromium.org> wrote:

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()`?

Specifically 'new PresentationRequest' will log a deprecation error and eventually throw a SecurityError.  I've updated the OWP tracking bug and chromestatus entry to state this specifically.

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?

The constructor will throw a SecurityError if invoked from an insecure context.  You can't do anything useful with the Presentation API without it.  If it's standard practice to hide properties as well, we can go down that path but I haven't explored the interop or compat implications.

[Domenic Denicola]

From: mfo...@google.com [mailto:mfo...@google.com] On Behalf Of mark a. foltz

> The constructor will throw a SecurityError if invoked from an insecure context.  You can't do anything useful with the Presentation API without it.  If it's standard practice to hide properties as well, we can go down that path but I haven't explored the interop or compat implications.

I think this statement is the source of much confusion in this thread. [SecureContext] is present on the interface, and on various other places, in the Presentation API spec. And per the [SecureContext] spec, that hides properties and interfaces. That's different than throwing a "SecurityError" DOMException.

So it's not clear from this thread whether you're implementing the spec or something else. The spec says nothing about throwing a "SecurityError" DOMException in a secure context, but that proposal is repeated a few times.

[mark a. foltz]

You're right.  I based this intent on an earlier version of the spec before [SecureContext] was added.  I'll redraft this and re-send it to align with the spec.

m.