New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Closed: Feb 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Launch-OWP
Launch-Accessibility: ----
Launch-Exp-Leadership: ----
Launch-Leadership: ----
Launch-Legal: ----
Launch-M-Approved: ----
Launch-M-Target: ----
Launch-Privacy: ----
Launch-Security: ----
Launch-Test: ----
Launch-UI: ----

Sign in to add a comment

Issue 672605: Remove support for EME over non-secure contexts

Reported by, Dec 8 2016 Project Member

Issue description

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

See intent to remove email for more details and metrics.

Support in other browsers:
Internet Explorer: supported
Safari: supported

Comment 2 by, Dec 13 2016

Hi Emily,
Do you happen to know which release of Chrome will incorporate the removal of access to EME APIs over non-secure origins?  I have a few implementations using HTML5 + Widevine and need to get our delivery requirements in line.

Comment 3 by, Dec 13 2016

Components: Internals>Permissions>Model

Comment 5 by, Dec 17 2016

Labels: Merge-Request-56
The updated message is landed in M57. We would like to provide the date in M56, so I am requesting a merge of the message change (not the removal) to M56.

Comment 6 by, Dec 17 2016

Labels: -Merge-Request-56 Merge-Approved-56 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M56 (branch: 2924)

Comment 7 by, Dec 21 2016

Project Member
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit - Your friendly Sheriffbot

Comment 8 by, Dec 21 2016

Project Member
Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:

commit 0339b514a839cc46abb4a316d2a5e7e7cd2e6dbb
Author: John Rummell <>
Date: Wed Dec 21 23:47:55 2016

Merge "Add milestone to deprecation message for EME on insecure contexts"

Intent to Remove:!topic/blink-dev/tXmKPlXsnCQ

BUG= 672605 

Cr-Commit-Position: refs/heads/master@{#439244}
(cherry picked from commit 810fa54c3422d6f7e3666506ee8cd3b84b9b2c82)

Review-Url: .
Cr-Commit-Position: refs/branch-heads/2924@{#591}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}


Comment 9 by, Jan 10 2017

Components: Internals>Media>Encrypted
Labels: -Pri-3 Pri-1
As mentioned above in the CL description, the "Intent to Remove" is at:!topic/blink-dev/tXmKPlXsnCQ

This is scheduled for M58.

emilyschechter: Do we still need the launch reviews/approvals? If so, how can I get this process started?

Comment 10 by, Jan 10 2017

We have all the LGTMs on that thread. ddorwin -- do we need anything else?

Comment 11 by, Jan 10 2017

Not that I can think of, other than tracking progress.

Comment 12 by, Jan 10 2017

But there are a lot of Launch-* bits to be flipped. Maybe this issue shouldn't be using Type Launch-OWP in the first place?

Comment 13 by, Jan 10 2017

We don't need those other bits for an OWP launch.

Comment 14 Deleted

Comment 15 by, Feb 3 2017

Labels: -Type-Feature Type-Launch-OWP
Assign to myself for implementation.

Comment 16 by, Feb 5 2017

Project Member
The following revision refers to this bug:

commit e01734f26cbce202d66b1f2b5a45bce895bd72d0
Author: jrummell <>
Date: Sun Feb 05 07:02:50 2017

Disable all WPT EME tests while switching to EME over https only

As EME will only be supported on secure contexts, the WPT EME tests are being
updated to run on https. To avoid problems with automatically importing the
renamed tests, disable all WPT EME tests (currently only 7 actually run).

BUG= 672605 

Cr-Commit-Position: refs/heads/master@{#448179}


Comment 17 by, Feb 9 2017

Project Member
The following revision refers to this bug:

commit 4de117544debac896ba8205f8835ba9ed484a4d3
Author: xhwang <>
Date: Thu Feb 09 17:47:17 2017

media: Require SecureContext for EME APIs

In this CL requestMediaKeySystemAccess() requires SecureContext. On
non-SecureContext, this API will not be visible.

Some notes for future reference:

1. file:// is always treated as SecureContext.
2. file:// is not a unique origin. The origin string is "file://"
3. LoadFromData is treated as non-SecureContext. See the updated [1]
   in this CL.
4. LoadFromData is also treated as unique origin. This is what [1]
   used to test without this CL.
5. allowFileAccessFromFileURLs has nothing to do with SecureContext.
   Rather it controls whether you can load other files from file://.
   - So if you run a simple html page on file://, and that file
     doesn't depend on any other file, you don't need
     allowFileAccessFromFileURLs. This is why for [2] we don't
     really need allowFileAccessFromFileURLs.
   - If the html page depends on other js files, without
     allowFileAccessFromFileURLs, those js files will not be loaded.
     This will cause a lot of test failures. That's why in content
     shell, we have allowFileAccessFromFileURLs enabled by default.

[2] android_webview/test/shell/assets/key-system-test.html

BUG= 672605 
TEST=Manually tested and made sure EME APIs are not available on
insecure origins.

Cr-Commit-Position: refs/heads/master@{#449344}


Comment 18 by, Feb 14 2017

Status: Fixed (was: Assigned)

Comment 19 by, Feb 20 2017

Hi @xhwang, can I confirm that this landed for M58?

Comment 20 by, Feb 20 2017

Yes, this was landed for M58.

Comment 21 by, May 6 2017

Project Member
The following revision refers to this bug:

commit fb4dd15c290ffa283c157f42f4d5abae97c3193d
Author: xhwang <>
Date: Sat May 06 19:07:15 2017

media: Restrict ProtectedMediaIdentifier permission to secure origins

Currently EME is restricted to secure origins (see BUG). However, it's
possible that the renderer process is compromised and bypasses this
restriction. This CL restricts the ProtectedMediaIdentifier permission
to secure origin as well to add another layer of protection.

Origins whitelisted by the --unsafely-treat-insecure-origin-as-secure
flag will always be treated as "secure", and as such will not be
affected by this change.

BUG= 672605 

Cr-Commit-Position: refs/heads/master@{#469866}


Comment 22 by, Jun 1 2017

There's still a line in LayoutTests/NeverFixTests that suggests that external/wpt/encrypted-media tests should be re-enabled once this is done, and some other lines can be uncommented - can those tests be re-enabled now?

Comment 23 by, Jun 1 2017

 Issue 664193  is tracking the (re)enabling of external/wpt/encrypted-media. The upstream changes to force them to run as https isn't in the W3C repository yet (rename all the files to .https.html).

Sign in to add a comment