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

Re: Formal objections to Encrypted Media Extensions

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 8 Sep 2016 08:31:22 -0700
Message-ID: <CAEnTvdDMwNDtitgjf471HazpBTBnp+Sf_BW9Pg2XmcD3Q3wSUA@mail.gmail.com>
To: Joseph Lorenzo Hall <joe@cdt.org>
Cc: David Singer <singer@apple.com>, Harry Halpin <hhalpin@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
On Thu, Sep 8, 2016 at 4:53 AM, Joseph Lorenzo Hall <joe@cdt.org> wrote:

> On Wed, Sep 7, 2016 at 11:57 AM, David Singer <singer@apple.com> wrote:
> >
> >
> > OK, there are risks from at least:
> > 1) installing new software (OS X, for example, has security settings to
> enable you to lock down to the signed installs from the App Store)
> > 2) using software that might have been subject to less security analysis
> (e.g. because of a fear of the DMCA)
> > 3) a combination of the above.
> >
> > The OS might warn people who install new software.  EFF might warn
> people who buy devices with built-in DRMs. The EFF might suggest that that
> warning be stronger for installed DRMs.
> >
> > But I still haven’t got to the EME interface...
> Yes, as you said up-thread EME will in most cases be open and
> analyzable in UA implementations. EME is an interface to working with
> CDMs for video, which will necessarily increase risks to web users in
> your category (2) above.

​First, I do not think it is _necessarily_ the case that CDMs have been
subject to less security analysis because of the DMCA. The
CDM implementor may have taken steps to ensure there is sufficient security
analysis, most obviously paying people to do some (including independent
​third parties, not just their own employees). They might also take steps
to assure researchers that they will not be subject to DMCA risk (see

Seconds, it is not _necessarily_ the case that even if the CDM has been
subject to less security analysis than the rest of the browser that the
user risks are higher. Again, the CDM implementor can take additional steps
to mitigate risks with respect to the CDM over and above what they do for
the rest of the browser.

Independent security research is a powerful tool for risk mitigation. Very
likely it is the most powerful tool. But it is not the only tool.

> (It may also set precedent for future CDM/DRM
> interfaces for things that would dramatically reduce the openness and
> user-oriented control of the web platform... e.g., DRM interfaces for
> text, images, page source, etc.)
> I would like to be able to tell researchers they can analyze a CDM and
> attempt to verify that it is doing certain things and not doing other
> things.

​And, indeed, several CDM implementors do tell researchers that, albeit
implicitly through the offer of monetary compensation for vulnerabilities
across all their products. Perhaps they should be more explicit ?

> (The Sony rootkit compact disc DRM that Alex Halderman
> examined as part of his PhD thesis is an obvious poster child for
> important work here.)

> While CDM producers may not be W3C members, content distribution and
> UA developers tend to be members, and it would be great if all of
> those in the room at W3C could agree that it's best for the web
> platform if: 1) as Mark and David have detailed, the existing EME spec
> has taken care with user consent and experience; 2) that CDM producers
> and those that utilize or implement CDM interfaces agree that having
> third-party analysis of these modules is important for accountability
> and simply finding bugs; 3) the parties at least at W3C developing
> these standards can agree to a [litigation non-aggression
> covenant/something else?] that would give researchers some certainty
> in their work.

​I'm in favor of finding ways to give researchers some certainty in their
work, but it was clear from the discussions earlier this year that a
legally binding covenant approach was not going to work. But there seems to
be little interest in pursuing alternatives (from the EFF, for example).


> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org
> ]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
> Tech Prom, CDT's Annual Dinner, is April 20, 2017!
> https://cdt.org/annual-dinner
Received on Thursday, 8 September 2016 15:32:21 UTC

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