[Updated] Intent to Deprecate and Remove: Presentation API on Insecure Contexts

[mark a. foltz]

Note: This is an updated intent that clarifies that we are removing the API on insecure contexts and what behavior sites will see.

Original intent thread: https://groups.google.com/a/chromium.org/d/topic/blink-dev/XybuHIG2WnU/discussion

--

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 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 (similar to browsers that don’t ship the API).

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 until the removal of the API.

An HTTPArchive search yielded ~340 sites that use the Presentation API 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 if necessary.  The remaining usages are enumerations of Window and should be minimally impacted.

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 (required to get screen availability) 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

[Rick Byers]

I agree with the security motivation for restricting to https.  We know, for example, that some ISPs inject ad/tracking content into http traffic. In general it doesn't make sense to ask the user to grant permission to an origin over http, so where we can get away with restricting this we should.

However, 0.2% of page views is really a HUGE number of impacted views (classified as "large risk" in our compat principles).  To what extent does that reflect users actually using remote presentation vs. (for example) popular video sites just probing the API to see if remote presentation is possible?  From the code it looks like this is triggered in the PresentationRequest constructor as opposed to within, for example, the "start" method.  Perhaps it's worth adding a metric to track how often a present request is successfully started from an insecure origin?  Naively I'd assume it'll be several orders of magnitude smaller than 0.2%.

There's also a serious risk of contributing to "deprecation warning blindness" by generating a new deprecation warning on 1 in every 500 page visits.  Perhaps we should get the cast SDK update deployed first before adding the warning so that a much smaller number of users/developers are likely to be exposed to the warning?  This is increasingly important as we work to roll out deprecation reports.

How does the cast SDK behave then the PresentationRequest API doesn't exist?  Does it already do feature-detection and degrade to a no-op gracefully when not present, or might it blow up more violently (unhandled exception, etc.)?  If the latter then I think we definitely need to wait for the cast SDK

--
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%2BHEG%3D_PtVgMTmnEmvEuWnUMjQ%3DUTR0Pstwx7zsE6vV42SA%40mail.gmail.com.

[mark a. foltz]

On Thu, Jul 13, 2017 at 8:23 PM, Rick Byers <rby...@chromium.org> wrote:

I agree with the security motivation for restricting to https.  We know, for example, that some ISPs inject ad/tracking content into http traffic. In general it doesn't make sense to ask the user to grant permission to an origin over http, so where we can get away with restricting this we should.

However, 0.2% of page views is really a HUGE number of impacted views (classified as "large risk" in our compat principles).  To what extent does that reflect users actually using remote presentation vs. (for example) popular video sites just probing the API to see if remote presentation is possible?  From the code it looks like this is triggered in the PresentationRequest constructor as opposed to within, for example, the "start" method.  Perhaps it's worth adding a metric to track how often a present request is successfully started from an insecure origin?  Naively I'd assume it'll be several orders of magnitude smaller than 0.2%.

It is.  According to the UMA metrics we have, there are about 1M requests/day to start presentation, vs 200M calls to the PresentationRequest constructor.

 

There's also a serious risk of contributing to "deprecation warning blindness" by generating a new deprecation warning on 1 in every 500 page visits.  Perhaps we should get the cast SDK update deployed first before adding the warning so that a much smaller number of users/developers are likely to be exposed to the warning?  This is increasingly important as we work to roll out deprecation reports.

Are you asking the SDK to print a deprecation in addition to Blink?  We were planning on doing that anyway with a guide for migration to secure contexts, but it will produce double the frequency of deprecation warnings as nearly all the usages are through the SDK.

 

How does the cast SDK behave then the PresentationRequest API doesn't exist?  Does it already do feature-detection and degrade to a no-op gracefully when not present, or might it blow up more violently (unhandled exception, etc.)?  If the latter then I think we definitely need to wait for the cast SDK

 

Right now the SDK is a no-op if the API is not present.   If we changed it to do the same on insecure contexts, it would be the equivalent of removing the API entirely without a deprecation period.

m.

[Rick Byers]

On Fri, Jul 14, 2017 at 1:22 PM, mark a. foltz <mfo...@chromium.org> wrote:

On Thu, Jul 13, 2017 at 8:23 PM, Rick Byers <rby...@chromium.org> wrote:

I agree with the security motivation for restricting to https.  We know, for example, that some ISPs inject ad/tracking content into http traffic. In general it doesn't make sense to ask the user to grant permission to an origin over http, so where we can get away with restricting this we should.

However, 0.2% of page views is really a HUGE number of impacted views (classified as "large risk" in our compat principles).  To what extent does that reflect users actually using remote presentation vs. (for example) popular video sites just probing the API to see if remote presentation is possible?  From the code it looks like this is triggered in the PresentationRequest constructor as opposed to within, for example, the "start" method.  Perhaps it's worth adding a metric to track how often a present request is successfully started from an insecure origin?  Naively I'd assume it'll be several orders of magnitude smaller than 0.2%.

It is.  According to the UMA metrics we have, there are about 1M requests/day to start presentation, vs 200M calls to the PresentationRequest constructor.

Ok, good.  Do we know what fraction of those 1M are on insecure contexts though?  I could imagine that people are more likely to use casting on the most popular sites and so starting presentation could be biased towards secure sites?  That's the key metric we need I think in order to evaluate the web compat trade-off here (how many presentations are we breaking?).

There's also a serious risk of contributing to "deprecation warning blindness" by generating a new deprecation warning on 1 in every 500 page visits.  Perhaps we should get the cast SDK update deployed first before adding the warning so that a much smaller number of users/developers are likely to be exposed to the warning?  This is increasingly important as we work to roll out deprecation reports.

Are you asking the SDK to print a deprecation in addition to Blink?  We were planning on doing that anyway with a guide for migration to secure contexts, but it will produce double the frequency of deprecation warnings as nearly all the usages are through the SDK.

No, I was saying that we can't have blink generate a deprecation warning for something that occurs anywhere near as often as one in 500 page views.  If instead blink generate a warning only when a presentation was actually started on an insecure context, then (depending on the above) I imagine it would be fine.

 

How does the cast SDK behave then the PresentationRequest API doesn't exist?  Does it already do feature-detection and degrade to a no-op gracefully when not present, or might it blow up more violently (unhandled exception, etc.)?  If the latter then I think we definitely need to wait for the cast SDK

 

Right now the SDK is a no-op if the API is not present.   If we changed it to do the same on insecure contexts, it would be the equivalent of removing the API entirely without a deprecation period.

I see, I think that's good.  FWIW I don't have much input/say in what warnings you want to generate from the cast SDK (in particular, those won't be sent via the Reporting API so don't have quite the same spam problem).

What about doing a two-stage plan here to separate Cast SDK from other usage?  First Cast SDK warns (in whatever fashion you prefer) and then at whatever timeframe you decide is appropriate becomes a no-op on insecure.  Then we enable the deprecation warning in blink (either for 'start' in insecure, or if the usage has fallen by several order of magnitude on the constructor) for a single milestone (assuming usage is indeed very low) and remove in the next?  I'm just trying to tease apart the rules we apply for making breaking changes in blink for the entire web from what you want to do with your library for your customers (which IMHO is entirely up to the Cast team and not really an issue for the blink launch process).  Would this be any better do you think?

[mark a. foltz]

On Fri, Jul 14, 2017 at 11:55 AM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Jul 14, 2017 at 1:22 PM, mark a. foltz <mfo...@chromium.org> wrote:

On Thu, Jul 13, 2017 at 8:23 PM, Rick Byers <rby...@chromium.org> wrote:

I agree with the security motivation for restricting to https.  We know, for example, that some ISPs inject ad/tracking content into http traffic. In general it doesn't make sense to ask the user to grant permission to an origin over http, so where we can get away with restricting this we should.

However, 0.2% of page views is really a HUGE number of impacted views (classified as "large risk" in our compat principles).  To what extent does that reflect users actually using remote presentation vs. (for example) popular video sites just probing the API to see if remote presentation is possible?  From the code it looks like this is triggered in the PresentationRequest constructor as opposed to within, for example, the "start" method.  Perhaps it's worth adding a metric to track how often a present request is successfully started from an insecure origin?  Naively I'd assume it'll be several orders of magnitude smaller than 0.2%.

It is.  According to the UMA metrics we have, there are about 1M requests/day to start presentation, vs 200M calls to the PresentationRequest constructor.

Ok, good.  Do we know what fraction of those 1M are on insecure contexts though?

We don't have a UseCounter tracking that.  I would imagine the split is similar to the overall API usage (37% Android / 14.5% desktop).

I could imagine that people are more likely to use casting on the most popular sites and so starting presentation could be biased towards secure sites?  That's the key metric we need I think in order to evaluate the web compat trade-off here (how many presentations are we breaking?).

I don't have any data suggesting there is a bias one way or the other.  To get accurate data on secure/insecure usage of .start() would require plumbing a new UseCounter and waiting another release cycle to get data.

There's also a serious risk of contributing to "deprecation warning blindness" by generating a new deprecation warning on 1 in every 500 page visits.  Perhaps we should get the cast SDK update deployed first before adding the warning so that a much smaller number of users/developers are likely to be exposed to the warning?  This is increasingly important as we work to roll out deprecation reports.

Are you asking the SDK to print a deprecation in addition to Blink?  We were planning on doing that anyway with a guide for migration to secure contexts, but it will produce double the frequency of deprecation warnings as nearly all the usages are through the SDK.

No, I was saying that we can't have blink generate a deprecation warning for something that occurs anywhere near as often as one in 500 page views.  If instead blink generate a warning only when a presentation was actually started on an insecure context, then (depending on the above) I imagine it would be fine.

The risk there is that some fraction of developers won't see the warning at all.  I'll let the Cast devrel team know to take that into account when doing outreach.

 

How does the cast SDK behave then the PresentationRequest API doesn't exist?  Does it already do feature-detection and degrade to a no-op gracefully when not present, or might it blow up more violently (unhandled exception, etc.)?  If the latter then I think we definitely need to wait for the cast SDK

 

Right now the SDK is a no-op if the API is not present.   If we changed it to do the same on insecure contexts, it would be the equivalent of removing the API entirely without a deprecation period.

I see, I think that's good.  FWIW I don't have much input/say in what warnings you want to generate from the cast SDK (in particular, those won't be sent via the Reporting API so don't have quite the same spam problem).

So if the concern is warnings generated from Blink, we can certainly restrict the deprecation warning to .start() there and log additional warnings from the SDK.

What about doing a two-stage plan here to separate Cast SDK from other usage?  First Cast SDK warns (in whatever fashion you prefer) and then at whatever timeframe you decide is appropriate becomes a no-op on insecure.  Then we enable the deprecation warning in blink (either for 'start' in insecure, or if the usage has fallen by several order of magnitude on the constructor) for a single milestone (assuming usage is indeed very low) and remove in the next?  I'm just trying to tease apart the rules we apply for making breaking changes in blink for the entire web from what you want to do with your library for your customers (which IMHO is entirely up to the Cast team and not really an issue for the blink launch process).  Would this be any better do you think?

I would rather there be consistency with the Blink process for consistency and so there aren't any surprises.  If we're deprecating it in Blink it should behave as if it's deprecated.

The plan that seems to meet your concerns is to:

1. In Blink, warn on start() now (relatively low volume).

2. In SDK, decide on a warning strategy outside the scope of this I2R.

3. In ~M67, make SDK a no-op in insecure contexts.

4. In M68, remove API from insecure contexts in Blink.

SG?

m.

[Rick Byers]

On Mon, Jul 17, 2017 at 5:14 PM, mark a. foltz <mfo...@chromium.org> wrote:

On Fri, Jul 14, 2017 at 11:55 AM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Jul 14, 2017 at 1:22 PM, mark a. foltz <mfo...@chromium.org> wrote:

On Thu, Jul 13, 2017 at 8:23 PM, Rick Byers <rby...@chromium.org> wrote:

I agree with the security motivation for restricting to https.  We know, for example, that some ISPs inject ad/tracking content into http traffic. In general it doesn't make sense to ask the user to grant permission to an origin over http, so where we can get away with restricting this we should.

However, 0.2% of page views is really a HUGE number of impacted views (classified as "large risk" in our compat principles).  To what extent does that reflect users actually using remote presentation vs. (for example) popular video sites just probing the API to see if remote presentation is possible?  From the code it looks like this is triggered in the PresentationRequest constructor as opposed to within, for example, the "start" method.  Perhaps it's worth adding a metric to track how often a present request is successfully started from an insecure origin?  Naively I'd assume it'll be several orders of magnitude smaller than 0.2%.

It is.  According to the UMA metrics we have, there are about 1M requests/day to start presentation, vs 200M calls to the PresentationRequest constructor.

Ok, good.  Do we know what fraction of those 1M are on insecure contexts though?

We don't have a UseCounter tracking that.  I would imagine the split is similar to the overall API usage (37% Android / 14.5% desktop).

Ok, fair enough. 

I could imagine that people are more likely to use casting on the most popular sites and so starting presentation could be biased towards secure sites?  That's the key metric we need I think in order to evaluate the web compat trade-off here (how many presentations are we breaking?).

I don't have any data suggesting there is a bias one way or the other.  To get accurate data on secure/insecure usage of .start() would require plumbing a new UseCounter and waiting another release cycle to get data.

There's also a serious risk of contributing to "deprecation warning blindness" by generating a new deprecation warning on 1 in every 500 page visits.  Perhaps we should get the cast SDK update deployed first before adding the warning so that a much smaller number of users/developers are likely to be exposed to the warning?  This is increasingly important as we work to roll out deprecation reports.

Are you asking the SDK to print a deprecation in addition to Blink?  We were planning on doing that anyway with a guide for migration to secure contexts, but it will produce double the frequency of deprecation warnings as nearly all the usages are through the SDK.

No, I was saying that we can't have blink generate a deprecation warning for something that occurs anywhere near as often as one in 500 page views.  If instead blink generate a warning only when a presentation was actually started on an insecure context, then (depending on the above) I imagine it would be fine.

The risk there is that some fraction of developers won't see the warning at all.  I'll let the Cast devrel team know to take that into account when doing outreach.

Right.  We used to err on the side of over-warning instead of under-warning but we found that in backfires in cases where the vast majority of the warnings were false positives (developers may see they warnings but they assume they are meaningless since they see such warnings all the time all over the place).

 

How does the cast SDK behave then the PresentationRequest API doesn't exist?  Does it already do feature-detection and degrade to a no-op gracefully when not present, or might it blow up more violently (unhandled exception, etc.)?  If the latter then I think we definitely need to wait for the cast SDK

 

Right now the SDK is a no-op if the API is not present.   If we changed it to do the same on insecure contexts, it would be the equivalent of removing the API entirely without a deprecation period.

I see, I think that's good.  FWIW I don't have much input/say in what warnings you want to generate from the cast SDK (in particular, those won't be sent via the Reporting API so don't have quite the same spam problem).

So if the concern is warnings generated from Blink, we can certainly restrict the deprecation warning to .start() there and log additional warnings from the SDK.

What about doing a two-stage plan here to separate Cast SDK from other usage?  First Cast SDK warns (in whatever fashion you prefer) and then at whatever timeframe you decide is appropriate becomes a no-op on insecure.  Then we enable the deprecation warning in blink (either for 'start' in insecure, or if the usage has fallen by several order of magnitude on the constructor) for a single milestone (assuming usage is indeed very low) and remove in the next?  I'm just trying to tease apart the rules we apply for making breaking changes in blink for the entire web from what you want to do with your library for your customers (which IMHO is entirely up to the Cast team and not really an issue for the blink launch process).  Would this be any better do you think?

I would rather there be consistency with the Blink process for consistency and so there aren't any surprises.  If we're deprecating it in Blink it should behave as if it's deprecated.

The plan that seems to meet your concerns is to:

1. In Blink, warn on start() now (relatively low volume).

2. In SDK, decide on a warning strategy outside the scope of this I2R.

3. In ~M67, make SDK a no-op in insecure contexts.

4. In M68, remove API from insecure contexts in Blink.

SG?

The one step that's missing here to meet the normal blink process is actually verifying the data that shows that the impact on websites of removal is small.  I think we have lots of good reason to believe it will be, but just to be sure how about we add:

3.5: Check the UseCounter data and circle back on this intent thread to confirm that the volume of remaining usage of start() in an insecure context is indeed quite low (less than 0.0001% of PageVisits or so?). 

[mark a. foltz]

Definitely, we should track this before removing.  Filed crbug.com/745010 to track this work.

m.

 

[Rick Byers]

Ok, the plan sounds good to me, thanks.

LGTM1 to deprecate now (with a blink warning just on 'start' in insecure contexts), and remove in the M68 timeframe assuming the insecure 'start' UseCounter has dropped <0.0001% of PageVisits.

[Dimitri Glazkov]

LGTM2

--
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/CAFUtAY9C5%3DS_hiw3jbPSgcA3LmMqoCCMSidCYEZt5b7%2BgMjTpA%40mail.gmail.com.

[Jochen Eisinger]

lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx5dUavpzeuGjz9d7-OnJKYppvP9vK48sN-Si7Ew7x1yTA%40mail.gmail.com.

[mfo...@chromium.org]

Update on this (from the right address :-)

I have landed https://chromium-review.googlesource.com/c/1306336 to remove the Presentation API on insecure contexts for M72.

At this time, the number of presentations started on insecure contexts is 0.0001% of page views on desktop and 0.0004% on Android.  We also got the OK to remove support from the Cast SDK on insecure contexts.

Let me know if you have any questions,

m.

[mfo...@google.com]

Update on this:

I have landed https://chromium-review.googlesource.com/c/1306336 to remove the Presentation API on insecure contexts for M72.

At this time, the number of presentations started on insecure contexts is 0.0001% of page views on desktop and 0.0004% on Android.  We also got the OK from the Home team to remove support in the Cast SDK on http:.

m.

On Friday, July 21, 2017 at 2:01:44 AM UTC-7, Jochen Eisinger wrote:

[myron.sz...@gmail.com]

As a non-developer with this, I think the user needs to be given a choice where the Cask SDK can be utilised on the local area network if the option is selected to allow this (this option selection does not yet exist) and insecure connections are not allowed to any WAN destinations.

I've been left scratching my head for a few days why the Plex Media player suddenly ceased detecting the Chromecase on when the server was accessed directly on the LAN subnet.  After reading somewhere else about accessing using Plex's portal I used https where I am presented with Chrome's page that the certificate presented by plex server is not secure. Luckily Chome allows this and remembers the option so I'm not bugged by the same warning every time I access the Plex Server directly and not through plex's web app portal.

Possibly build into chrome an exception list so user supplied destinations do not have this restriction applied?

[mark a. foltz]

[blink-dev to bcc:]

Hi,

Plex has a way to run the media server with a certificate that should be trusted by Chrome. 

https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/

If this isn't working for you I suggest following up with Plex support, or can help file an issue if they believe it's an issue with Chrome.

--
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/94d2a7ef-a628-4068-886f-3db2e9d607e4%40chromium.org.