Related to the chrome://plugins deprecation https://bugs.chromium.org/p/chromium/issues/detail?id=673199#c7

"After the transition away from about:plugins Widevine will become enabled for everyone unless they delete it somehow or use the no binary component updates policy to prevent it from appearing in the first place" https://bugs.chromium.org/p/chromium/issues/detail?id=615738#c34

"All other plugins (PDF, Widevine, Nacl), as well as custom plugins, should be treated as JavaScript." https://bugs.chromium.org/p/chromium/issues/detail?id=615738#c22

I'm pretty sure if you use a developer build of Chromium you don't have to include Widevine -- at least, I know I need to install this package separately to use Widevine with Arch Linux's chromium-dev package: https://aur.archlinux.org/packages/chromium-widevine-dev/

As per   Issue 615738 , this feature is intended, removing the needs bisect label

- Your monitor flickering as soon as you enter a web page? Working as intended!
- You second monitor turns off as soon as you enter a web page? Working as intended!
- Your browser crashes randomly every 20 minutes? Working as intended!
- You can do nothing about it? Working as intended!

Can somebody please give a test URL? I am running Chrome Canary (58.x) on MacOS and would like to see how that affects my VNC session (I am using a Mac in place "home" through a VNC connection from place "work").

I don't see how increasing the attack surface of one of the most used pieces of software on a computer helps. It should always be possible to disable components that provide optional features. 
This goes double if the part is causing issues. 

Android UI offers Site settings -> Media -> Protected content. It defaults to "Ask first" (the enabled setting) and allows completely disabling it. Why not expose a similar option with at least "disable" and "enable" as options via content settings for the desktop? Ideally it could ask each time similar to the toggles for JavaScript, etc. but that might involve some real work.

Regarding the feature being intended: I don't think anyone here is arguing against the deprecation of the NPAPI plugin system, or its settings page. However, it's deprecation has exposed this issue with Widevine/EME by causing a valid user-facing mitigation for some of its unwanted behavior to vanish.

Given the politically charged nature of DRM, and the finnicky nature of HDCP support on a wide variety of video cards and monitors, I think it's perfectly reasonable to expect non-power-users to occasionally need to disable the feature. +1 for some sort of a setting (perhaps just a simple boolean in chrome://flags ?) to turn it off.

Test URL: http://demo.castlabs.com/

Hey Julian: Do we have any thoughts on giving users a UI surface to disable Widevine like we did for PDF and Flash?

The Internet is unhappy: https://news.ycombinator.com/item?id=13514415

I would personally be okay with a chrome://flags switch. Does the DisabledPlugins policy still work for Widevine? https://www.chromium.org/administrators/policy-list-3#DisabledPlugins

I, like "the internet" am also unhappy. I like having control of my computer and until Chrome can ensure that I'm off to Firefox.

@12: Not suitable for chrome://flags (that is not an "advanced config" page, that's a "temporary beta testing, promote or die" page).

If this is going to be a setting, it needs to be an actual setting in the settings.

My understanding from jschuh@ is we're OK with adding a content setting to disable.

Hi everyone! Please keep comments focused on the issue at hand. While there are good places to discuss the future of DRM or Flash, they're not this bug. Thanks!

Want to have ability to disable browser plugins and to see them all as a list.
We need chrome://plugins workable.

Inability to turn off any of the plugins is definitely a negative factor when deciding which browser to deploy in my company. I do not care if DRM video fails to play on those single-purpose business systems. But I do care that black-hearted will have an upper hand over IT for any piece of browser security. In finance IT it is a must to be able to tailor risks to the business task on the system. Especially now that so many internal and DevOps tools are being developed with and controlled via browser interfaces. I think it can be safely extended to other industries, like healthcare or government.

Without an option to disable the legally charged black box of DRM there is zero chance of our organization either using or promoting the use of Chrome over competing browser solutions.  There are proven security holes within the DRM black box that must by definition exist, largely due to the user being considered an untrusted entity, but the question then becomes who is considered "trusted"?  For organizations, this must be their own IT department; for DRM, this must be a central authority which can authorize or deny access, and exfiltrate any data needed to make this determination.  As such, while DRM components are forcibly enabled on Chrome, this browser is inherently unsafe from an IT perspective and, worse, makes the underlying system unsafe as well.

Thanks everyone for your feedback, it was both thoughtful and well reasoned.

We are exploring options to add a content setting (chrome://settings/content) to disable EME, in the space of Chrome 57.  We'll update this issue as we make progress.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/45f66398546e5f402fb9768e05c1321893dbee6b

commit 45f66398546e5f402fb9768e05c1321893dbee6b
Author: tommycli <tommycli@chromium.org>
Date: Tue Feb 07 18:53:27 2017

MD Settings: Make Protected Content setting available to all platforms.

The Protected Content setting has been re-designed to toggle DRM on all
platforms. This makes the setting available on all platforms.

This also updates the string to the new text.

MD Settings equivalent to this patch:
https://codereview.chromium.org/2679723003/

BUG= 686430 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/45f66398546e5f402fb9768e05c1321893dbee6b/chrome/app/settings_strings.grdp
[modify] https://crrev.com/45f66398546e5f402fb9768e05c1321893dbee6b/chrome/browser/resources/settings/privacy_page/privacy_page.html
[modify] https://crrev.com/45f66398546e5f402fb9768e05c1321893dbee6b/chrome/browser/resources/settings/route.js
[modify] https://crrev.com/45f66398546e5f402fb9768e05c1321893dbee6b/chrome/browser/resources/settings/settings_resources.grd
[modify] https://crrev.com/45f66398546e5f402fb9768e05c1321893dbee6b/chrome/browser/resources/settings/site_settings_page/site_settings_page.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/af445fb0a75d6811c0a8991becd79986e996d647

commit af445fb0a75d6811c0a8991becd79986e996d647
Author: xhwang <xhwang@chromium.org>
Date: Wed Feb 08 02:03:56 2017

media: Add string for enabling protected content

This CL only adds the string to enable protected content. The string is copied from https://chromiumcodereview.appspot.com/2679723003/ with modifications. Landing it first so it could be localized. The CL that uses it will come shortly.

NOTRY=true
NOPRESUBMIT=true
TBR=stevenjb@chromium.org
BUG= 686430 

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

[modify] https://crrev.com/af445fb0a75d6811c0a8991becd79986e996d647/chrome/app/generated_resources.grd

Request to merge the strings in #31 to M57. UI and code changes will come shortly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78241e1d0a6f8b216bef8652cd27465ddb0afa57

commit 78241e1d0a6f8b216bef8652cd27465ddb0afa57
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Wed Feb 08 02:10:04 2017

media: Add string for enabling protected content

This CL only adds the string to enable protected content. The string is copied from https://chromiumcodereview.appspot.com/2679723003/ with modifications. Landing it first so it could be localized. The CL that uses it will come shortly.

NOTRY=true
NOPRESUBMIT=true
TBR=stevenjb@chromium.org
BUG= 686430 

Review-Url: https://codereview.chromium.org/2688433002
Cr-Commit-Position: refs/heads/master@{#448851}
(cherry picked from commit af445fb0a75d6811c0a8991becd79986e996d647)

Review-Url: https://codereview.chromium.org/2681033003 .
Cr-Commit-Position: refs/branch-heads/2987@{#377}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/78241e1d0a6f8b216bef8652cd27465ddb0afa57/chrome/app/generated_resources.grd

A friendly reminder that M57 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Cl @ comment #33 landed without approval but this is fine as per internal email discussion. Next time, please wait for approval. 

When do we expect UI and code changes to be landed on trunk? Please do not merge to M57 until change is well baked/verified in Canary. Thank you.

non MD settings (needed for M57) changes have been confirmed across win/mac/cros on canary build 58.0.3007.0 (I did the testing, as did tommycli & xhwang). 

Thank you ericde@. Could you please merge non MD settings (needed for M57) change to M57 then? Thank you.

over to tommycli@ to finish his merge - xhwang already merged his.

It's merged! Thanks!

Nothing else is pending for M57, correct? If yes, please remove "Merge-Approved-57" label. Thank you.

I think we're good here.

Thank you for the merge. Tracking bug for missing translation (bug 691731).

Verified this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome dev #58.0.3012.0.
As per comment #30, observed "Protected Content" under "chrome://md-settings/content"

Hence Adding TE-verified labels

Attaching the screencast for reference.

Deleted: Issue 686430.mp4 590 KB

	Issue 686430.mp4 590 KB View Download

Verified this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome beta #57.0.2987.54 and didn't see any protected content setting under "chrome://md-settings/content"

Attaching the screen-cast for reference.

tommycli@ could you please look into it and let us know your observations.

Deleted: Issue 686430-M57.mp4 1.2 MB

	Issue 686430-M57.mp4 1.2 MB View Download

This is expected. In M57 the new setting is only available in the old settings page, not in the MD-settings.

Verified this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome beta #57.0.2987.54 and observed the protected content setting under "chrome://settings/content"

Attaching the screen-cast for reference.

Hence adding TE-verified labels.

Deleted: Issue 686430 - M57.mp4 680 KB

	Issue 686430 - M57.mp4 680 KB View Download