Project: chromium Issues People Development process History Sign in
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 7 users
Status: Fixed
Owner:
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Launch-OWP
Launch-Accessibility: ----
Launch-Legal: ----
Launch-M-Approved: ----
Launch-M-Target: ----
Launch-Privacy: ----
Launch-Security: ----
Launch-Status: ----
Launch-Test: ----
Launch-UI: ----
Product-Review: ----
Team-Security-UX



Sign in to add a comment
Remove support for EME over non-secure contexts
Project Member Reported by emilyschechter@chromium.org, Dec 8 2016 Back to list
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
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1322517
Safari: supported
 
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.
Thanks!
Components: Internals>Permissions>Model
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 dimu@chromium.org, 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)
Project Member Comment 7 by sheriffbot@chromium.org, Dec 21 2016
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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 8 by bugdroid1@chromium.org, Dec 21 2016
Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0339b514a839cc46abb4a316d2a5e7e7cd2e6dbb

commit 0339b514a839cc46abb4a316d2a5e7e7cd2e6dbb
Author: John Rummell <jrummell@chromium.org>
Date: Wed Dec 21 23:47:55 2016

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

Intent to Remove:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tXmKPlXsnCQ

BUG= 672605 

Review-Url: https://codereview.chromium.org/2558813007
Cr-Commit-Position: refs/heads/master@{#439244}
(cherry picked from commit 810fa54c3422d6f7e3666506ee8cd3b84b9b2c82)

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

[modify] https://crrev.com/0339b514a839cc46abb4a316d2a5e7e7cd2e6dbb/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] https://crrev.com/0339b514a839cc46abb4a316d2a5e7e7cd2e6dbb/third_party/WebKit/Source/core/frame/Deprecation.cpp

Comment 9 by xhw...@chromium.org, Jan 10 2017
Cc: jrumm...@chromium.org ericde@google.com xhw...@chromium.org
Components: Internals>Media>Encrypted
Labels: -Pri-3 Pri-1
As mentioned above in the CL description, the "Intent to Remove" is at:
https://groups.google.com/a/chromium.org/forum/#!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?

We have all the LGTMs on that thread. ddorwin -- do we need anything else?
Cc: faniel@chromium.org
Not that I can think of, other than tracking progress.
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?
We don't need those other bits for an OWP launch.
Comment 14 Deleted
Labels: -Type-Feature Type-Launch-OWP
Assign to myself for implementation.
Project Member Comment 16 by bugdroid1@chromium.org, Feb 5 2017
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e01734f26cbce202d66b1f2b5a45bce895bd72d0

commit e01734f26cbce202d66b1f2b5a45bce895bd72d0
Author: jrummell <jrummell@chromium.org>
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 

Review-Url: https://codereview.chromium.org/2667393007
Cr-Commit-Position: refs/heads/master@{#448179}

[modify] https://crrev.com/e01734f26cbce202d66b1f2b5a45bce895bd72d0/third_party/WebKit/LayoutTests/NeverFixTests

Project Member Comment 17 by bugdroid1@chromium.org, Feb 9 2017
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4de117544debac896ba8205f8835ba9ed484a4d3

commit 4de117544debac896ba8205f8835ba9ed484a4d3
Author: xhwang <xhwang@chromium.org>
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.

[1]
third_party/WebKit/LayoutTests/media/encrypted-media/encrypted-media-unique-origin.html
[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.

Review-Url: https://codereview.chromium.org/2678433003
Cr-Commit-Position: refs/heads/master@{#449344}

[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/android_webview/javatests/src/org/chromium/android_webview/test/KeySystemTest.java
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/android_webview/test/BUILD.gn
[add] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/android_webview/test/shell/assets/key-system-test.html
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin-expected.txt
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/LayoutTests/http/tests/security/powerfulFeatureRestrictions/old-powerful-features-on-insecure-origin.html
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/LayoutTests/media/encrypted-media/encrypted-media-unique-origin.html
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/Source/modules/encryptedmedia/HTMLMediaElementEncryptedMedia.idl
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/Source/modules/encryptedmedia/MediaKeys.idl
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/Source/modules/encryptedmedia/NavigatorRequestMediaKeySystemAccess.cpp
[modify] https://crrev.com/4de117544debac896ba8205f8835ba9ed484a4d3/third_party/WebKit/Source/modules/encryptedmedia/NavigatorRequestMediaKeySystemAccess.idl

Status: Fixed
Hi @xhwang, can I confirm that this landed for M58?
Yes, this was landed for M58.
Project Member Comment 21 by bugdroid1@chromium.org, May 6
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb4dd15c290ffa283c157f42f4d5abae97c3193d

commit fb4dd15c290ffa283c157f42f4d5abae97c3193d
Author: xhwang <xhwang@chromium.org>
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 

Review-Url: https://codereview.chromium.org/2859293003
Cr-Commit-Position: refs/heads/master@{#469866}

[modify] https://crrev.com/fb4dd15c290ffa283c157f42f4d5abae97c3193d/chrome/browser/media/protected_media_identifier_permission_context.cc

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