Formal objection to Encrypted Media Extensions progressing to Proposed Recommendation without greater user protection

[Note this is a formal objection as an individual in a private capacity,
not on behalf of my organization]

I'd like to fill a formal objection against Encrypted Media Extensions
progressing to Proposed Recommendation status without adequate
protection for users.

I believe that this work is so problematic given the well-known and
well-documented problems with DRM,  it should not happen as a standard
at all at W3C. That being said, for reasons which I do not agree with
and hope he reconsiders, the Director has approved both the scope of the
charter and the move of the Working Draft to Candidate Recommendation.

If it does happen, then it seems given the well-documented problems,
some harm mitigation should be pursued. The security research community
has broad support for the EFF covenant being a normative requirement
[1]. However, it appears consensus is not forthcoming on either EME
itself or the EFF covenant, with the Technology and Policy IG also
failing to gain any consensus for even further discussion (as it failed
to even get chartered).

To myself, the danger of EME is that over the last year suddenly over
millions of people had a content decryption module installed without
their explicit consent on their computer. For many users, such as those
of Firefox, the DCM was installed via a silent update they had no
control over. Such a content decryption module can serve as both a
technical security risk, as it puts a highly privileged process in the
user's computer outside their direct control by design, and as a legal
risk subjects any inspection of the DRM-enabled system on their computer
due to the anti-circumvention provision of the DMCA or local equivalent.
Thus, regardless of whether or not one agrees with EME, it seems the
*least* the W3C should do is warn the user about the installation and
activation of a CDM on their machine - and that the CDM should not be
installed and EME should not be activated without explicit user consent.
Thus, in all configurations, EME should be *de-activated by default.*

There is prior art in HTML for similarly powerful and privacy-invasive
features such as the Geolocation API [4]. Thus, there should be no
procedural problem in requiring user consent and disabling EME by
default in all browsers.  While it can be argued many users will want to
watch protected videos and will turn them on, just as many users will
want to use Google Maps with Geolocation APIs, there does not seem to be
a reasonable case for having such
powerful and possibly dangerous features enabled by default.

Current language in the spec is so weak as it may not be enforced and so
EME does not have to be disabled by default: " User Agents have some
flexibility to determine whether consent is required for a specific
configuration and whether such consent may also apply to other
configurations. For example, consent to one configuration may also imply
consent for less powerful, more restricted configurations. Equally, a
denial of consent for one configuration may imply denial of consent for
more powerful, less restricted configurations."

The only place where the spec [5] makes normative statements around
consent, but due to how DRM (i.e. Key Systems) are designed, it is
unclear how the user agent should interpret these statements

"If a user agent chooses to support a Key System implementation that
cannot be sufficiently sandboxed or otherwise secured, the user
agent//should//ensure that users are fully informed and/or give explicit
consent before loading or invoking it."

"User Agents should ensure that users are fully informed and/or give
explicit consent before a Key System that presents security concerns
that are greater than other user agent features (e.g. DOM content) may
be accessed by an origin..."

" User agents must ensure that users are fully informed and/or give
explicit consent before Distinctive Identifier(s) are exposed, such as
in messages from the Key System implementation."

Although these statements show some progress towards trying to mitigate
the dangers of DRM, given that DRM systems work in conjunction with
anti-circumvention legislation that prevents a developer from knowing
whether or not they can sufficiently sandboxed (or 'otherwise secured')
and whether a Distinctive Identifier is used by the DRM system, so the
use of EME will *always* present security concerns that are greater than
the rest of the user agent features involving the Open Web Platform.

Is the Working Group amendable to having EME and associated DRM systems
(i.e. "Key Systems") *normatively* disabled by default in order to
protect users?

   cheers,
       harry

[1]
https://www.eff.org/deeplinks/2016/03/security-researchers-tell-w3c-protect-researchers-who-investigate-browsers
[2]
https://en.wikipedia.org/wiki/Digital_rights_management#Opposition_to_DRM
[3] https://en.wikipedia.org/wiki/Digital_rights_management#Shortcomings
[4] https://www.w3.org/TR/geolocation-API/#implementation_considerations
[5] https://w3c.github.io/encrypted-media/