Intent to Remove: Insecure usage of EME

[Emily Schechter‏]

Primary eng (and PM) emails

emilysc...@chromium.org, ddo...@chromium.org

Link to “Intent to Deprecate” thread

Summary

Following our powerful feature policy, we intend to remove support for EME APIs over non-secure contexts at the end of Q1 2017.

Motivation

Support for non-secure contexts has been removed from EME v1 spec and will not be in the upcoming Proposed Recommendation (PR) or subsequent final Recommendation. The API was included in the original intent-to-deprecate and listed on the Chromium wiki page starting in Feb 2015, and has been showing a deprecation message since May 2015. If approved, the deprecation message will be updated to include the concrete timeframe.

Some usages of EME expose DRM implementations that are not open source, involve access to persistent unique identifiers, and/or run unsandboxed or with privileged access. The risks are increased when exposed via insecure HTTP, because they could be attacked by anyone on the channel. In addition, for implementations that require explicit permissions, permission for an insecure HTTP site can be exploited.

Compatibility Risk

This will break a small number of media sites who do not transition to HTTPS by the time of removal. As these sites transition to HTTPS, the risk becomes lower. We have a good communication channel with many of the sites currently using EME in non-secure contexts, which makes the risk much lower.

EME support in Chrome: since M42 (unprefixed)

Firefox: deprecation plans.

Usage information from UseCounter

EME over insecure origins: 0.002% of page loads (link).

EME over secure origins: 0.009% of page loads (link)

OWP launch tracking bug

https://crbug.com/672605 for EME

https://crbug.com/520765 for broader removal of old powerful features on insecure origins.

Entry on the feature dashboard

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

[Jochen Eisinger‏]

lgtm1

[Mike West‏]

Non-OWNER's LGTM. I don't believe any new information has popped up since we decided to deprecate this in non-secure contexts, and the deprecation warning in conjunction with y'all's outreach seems to have been effective in driving the numbers down to levels where I'm confident that the impact to developers is outweighed by the benefits.

Thanks for following through on this!

-mike

[TAMURA, Kent‏]

LGTM2

--

TAMURA Kent
Software Engineer, Google

[PhistucK‏]

On Fri, Dec 9, 2016 at 5:27 AM, Emily Schechter <emilysc...@chromium.org> wrote:

EME over secure origins: 0.009% of page loads (link)

With such a low usage, it looks like you can remove the feature altogether, secure or insecure. ;)​

☆PhistucK

[Chris Harrelson‏]

LGTM3

--
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+unsubscribe@chromium.org.

[kid.mira...@gmail.com‏]

Will secure origin be required for apps hosted on private networks?  - thinking about impact on internal test systems...

[Jochen Eisinger‏]

we internal testing, you can always run chrome with command line options to mark individual URLs as secure

[elst...@gmail.com‏]

Can you let me know the command line option to mark individual URLs as secure?

[Emily Schechter‏]

There are developer instructions here ("If a feature is powerful and not available on HTTP, and you are a developer that needs to keep testing a feature on a server that does not have a valid certificate, you have several options...")

[Xiaohan Wang (王消寒)‏]

(copied from earlier communications)

For development and test, you can:

• Use file:///, in which case you also need --allow-file-access-from-files such that your app can load other local files (e.g. js libraries).
• Use --unsafely-treat-insecure-origin-as-secure flag. Note that you MUST provide a list of origins to be whitelisted. Also, this flag MUST be used together with --user-data-dir to work. Here's an example
      --unsafely-treat-insecure-origin-as-secure=http://a.test,http://b.test --user-data-dir=/test/only/profile/dir
  
• To get more background about this the --unsafely-treat-insecure-origin-as-secure flag, you can read the history of this bug.

Xiaohan

On Fri, Apr 21, 2017 at 11:43 AM, <elst...@gmail.com> wrote: