W3C home > Mailing lists > Public > public-html-media@w3.org > August 2016

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

From: David Singer <singer@apple.com>
Date: Tue, 02 Aug 2016 10:40:09 -0700
Message-id: <CBD88E34-45E3-45CA-9165-9051B64CF30C@apple.com>
To: public-html-media@w3.org
Hi

I am puzzled by a few things.


> On Aug 1, 2016, at 15:42 , Harry Halpin <hhalpin@w3.org> wrote:
> 
> [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, 

I’m not sure what problems you are referring to, so I am not sure what you’d like fixed.  Later in the thread it becomes “risks” which puzzles me more.

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

I don’t think it matters what the software does; any install should be a subject of consent, shouldn’t it?

> For many users, such as those of Firefox, the DCM was installed via a silent update they had no control over.

The CDM or the interface (EME implementation)?  The latter is part of the browser.

> There is prior art in HTML for similarly powerful and privacy-invasive features such as the Geolocation API [4].

Knowing someone’s location is a privacy question. I don’t see that installing a decryption module is the same. Nothing about me is communicated to anyone else as a result. Can you clarify?

> 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

I don’t think we disable interfaces by default.

David Singer
Manager, Software Standards, Apple Inc.
Received on Tuesday, 2 August 2016 17:40:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:12 UTC