RE: Technical Review of EME (DRM in HTML5)

Andreas,

What do you hope to accomplish by calling the spec writers dishonest with your "red herring" comment, referring to EME as "evil" and calling it an "attack on Open Source operating systems"? All of that is counterproductive to having a frank technical discussion about this proposal.

To address one of your points directly:

The statement that "EME is a Trojan Horse which would enable privacy violations" can be applied to many other key web technologies, including but not limited to JavaScript and cookies. Any tool can be used maliciously in the wrong hands. 

I will point out that HTML is a tool that has been widely used to invade privacy and steal information from unsuspecting users, through "phishing" attacks in popular email clients. Convincing-looking HTML emails that masquerade as a legitimate message from your bank allow an attacker to obtain your banking credentials.

I have a question for you, since you've now brought up the "silent monitoring" matter at least twice on this subject.

What do you think "silent monitoring" means, and how do you think it is actually implemented? (Perhaps someone from Google can provide some facts about this vague terminology.)

>From my experience with DRM systems, this kind of "monitoring" means that the application implementing the DRM client receives notification events from the DRM API, indicating what the DRM has detected. E.g. "HDMI output connected" and "Computer Hardware Profile Changed" and so on. The application may then take whatever action its writers deem appropriate.

But ultimately, this isn't particularly germane to the discussion, because as I already pointed out, there are plenty of key technologies in the web stack that "enable privacy violations". 

Thanks,

Dave
________________________________________
From: Andreas Kuckartz [A.Kuckartz@ping.de]
Sent: Wednesday, January 30, 2013 4:35 AM
To: Manu Sporny
Cc: public-html@w3.org
Subject: Re: Technical Review of EME (DRM in HTML5)

Manu Sporny:
> More importantly, who is going to be using Clear Key in production?

Clear Key was introduced as a red herring to "prove" that open CDMs are
possible. That is also the reason for the contradictory statements made
by proponents of EME regarding Clear Key.

> It would be even better if a goal was to provide a decent open source
> CDM so that companies like Mozilla don't get screwed over by the
> royalties from content protection companies.

This is not only about Open Source browsers. EME first of all is an
attack on Open Source operating systems (especially Linux distributions).

>> 4. Does increasing the attack surface on a browser via completely
>> closed DRM plug-in modules pose any privacy risks? How do you know
>> that the DRM module isn't tracking everything you're doing online if
>> people can't verify the source.

EME is a Trojan Horse which would enable privacy violations. One of the
supporters of EME (Google) promotes or promoted such technologies.

Below I have appended a quote from March 2012 from Widevine ("a Google
Company") regarding "silent monitoring".

That is one of the reasons why it is a shame that the W3C is involved in
helping to create a Trojan Horse enabling evil things like this.

Cheers,
Andreas
---

"Here's How It Works:
Content is encrypted, stored and distributed to the user who then
watches it in a browser or video player. During playback, encrypted
content has been decrypted and the video is now vulnerable to piracy
simply by downloading a free software tools such as screen scrapers and
stream recorders which can pirate the video stream to a DRM-free file.

In the background, Widevine’s digital copy protection solution monitors
for the acceptable usage of content. If a user attempts to use a screen
scraper or other piracy method, Digital Copy Protection will detect this
and produce a number of customizable responses from silent monitoring to
revocation of viewing rights."
http://www.widevine.com/digital_copy_protection.html
(page no longer exists)

Received on Wednesday, 30 January 2013 14:29:29 UTC