Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formal objection to Encrypted Media Extensions advancing to Proposed Recommendation #305

Closed
rubenquidam opened this issue Aug 16, 2016 · 18 comments

Comments

Projects
None yet
@rubenquidam
Copy link

commented Aug 16, 2016

{Sending to the public-html-mail list, copying it here for visibility}

My name is Ruben Rodriguez and I'm a free software developer and distributor. As a GNU developer I maintain the GNU IceCat browser1, a freedom and privacy focused fork of Mozilla Firefox. As the director of the Trisquel2 GNU/Linux free software distribution I publish copies of the "GNU IceCat" and "Abrowser" Firefox derivatives. Both those programs have their DRM capabilities disabled.

I formally object to Encrypted Media Extensions (EME)3 being incuded as part of the HTML family of standards. My reason is that implementing and distributing DRM encumbered software exposes free software projects, distributors and users to legal risk, due to the wide limitations the DMCA imposes on studying, modifying and distributing software that implements DRM. Security and privacy problems have also been pointed out by others including Harry Halpin4 and Wendy Seltzer5.

These threats exist regardless of whether the software is under a free license or not, but they are amplified for free software projects:
    

  • If the DRM components of an otherwise freely licensed browser are distributed under a proprietary licensing scheme, then the browser is no longer actually free software, and cannot be distributed by projects that only distribute such. 
  • If to circumvent that -as Mozilla Firefox currently does- the non-free components are downloaded separately by the browser itself, then we have a backdoor that -even if we ignore the important security implications- robs the user of their control of their computation. It also exposes them to legal risk, as they are now in possesion of DRM encumbered software they didn't request and are forbidden to audit.
  • The worse case is when the DRM components are licensed under a free software license -as would be possible with clearkey or other implementations- and thus included in the browser itself. The distribution of said browser under a free license would give users a false impression that it was safe to study, modify and redistribute the code. In reality, doing so would expose them to DMCA threats.

Given those alternatives, the conclusion is that DRM encumbered software cannot be distributed by free software developers without putting both the distributors and the recipients of the software at a high legal risk. DRM goes against the principles of free software, and against the World Wide Web as an open platform.

Respectfully,
Ruben Rodriguez.

@Zakkai

This comment has been minimized.

Copy link

commented Aug 16, 2016

As a free software user, I want to add my support for this objection. It's important that Web standards not create legal risks for implementers.

@paulbrucecotton

This comment has been minimized.

Copy link

commented Aug 16, 2016

This Formal Objection will be recorded at https://dev.w3.org/html5/status/formal-objection-status.html. When that is done this GitHub issues will be closed.

/paulc
HME WG Chair

@Adrianzo

This comment has been minimized.

Copy link

commented Aug 16, 2016

I agree with this objection.

@haary

This comment has been minimized.

Copy link

commented Aug 17, 2016

My Name is Henry Jensen, maintainer of ConnochaetOS, a libre variant of Slackware GNU/Linux. I support this objection. DRM components in web browsers do compromise user security and freedom.

@paulbrucecotton

This comment has been minimized.

Copy link

commented Aug 18, 2016

I want to remind those that feel that W3C should not be working on EME that the W3C has previously explained its position publicly on why this work is happening at W3C. Jeff Jaffe’s 2013 blog post [1] explained the rationale for this work occurring at W3C when EME reached the status of first public Working Draft [1] and Tim Berners-Lee’s subsequent blog post [2] gave the W3C Director’s view on why this work is being done at W3C. I also encourage you to review the more recent EME fact sheet provided by the W3C in March 2016 [3].

In addition when the Director approved the transition of EME to the Candidate Recommendation [4] stage in July 2016, the Director considered several Formal Objections [5-6] lodged against the EME work. The Director’s decision was to continue the EME work and to permit the specification to transition to CR status.

I encourage participants on public-html-media@w3.org to review this historical information and if possible to indicate why their objections are different than previous objections to the EME work that have already been dealt with by the W3C.

Participants should also be assured that recently filed Formal Objections will be recorded and will be reviewed with the W3C Director if/when the HME WG prepares an EME Proposed Recommendation for consideration by the Director and eventually the W3C Advisory Committee.

/paulc
HME WG Chair

[1] http://www.w3.org/blog/2013/05/perspectives-on-encrypted-medi/
[2] https://www.w3.org/blog/2013/10/on-encrypted-video-and-the-open-web/
[3] http://www.w3.org/2016/03/EME-factsheet.html
[4] http://www.w3.org/TR/2016/CR-encrypted-media-20160705/
[5] https://lists.w3.org/Archives/Public/public-html-admin/2013May/0138.html
[6] https://lists.w3.org/Archives/Public/public-html-media/2016Jun/0041.html

Note: I sent the above material to the HME WG in:
https://lists.w3.org/Archives/Public/public-html-media/2016Aug/0078.html

@plehegar

This comment has been minimized.

Copy link
Member

commented Aug 18, 2016

There is also:
[[
We do recognize that issues around Web security exist as well as the importance of the work of security researchers and that these necessitate further investigation but we maintain that the premises for starting the work on the EME specification are still applicable.
[...]
The only required key system in the specification is one that actually does not perform any digital rights management (DRM) function and is using fully defined and standardized mechanisms (the JSON Web Key format, RFC7517, and algorithms, RFC7518). While it may not satisfy some of the requirements from distributors and media owners in resisting attacks, it is the only fully interoperable key system when using EME.
[...]
]]
https://www.w3.org/blog/2016/04/html-media-extensions-to-continue-work/

@sampablokuper

This comment has been minimized.

Copy link

commented Aug 21, 2016

A short essay...

Introduction

The World Wide Web Consortium (aka "W3C" or "W3") has a deserved reputation for creating open technological standards that provide a common good for humanity. I am confident that the staff and managers at the W3C act with the best of intentions, and I find that there exists in the W3C much good reasoning.

Sadly, the W3C has shown itself, over the last decade or thereabouts, and particularly in the last three years, to have a blind spot in relation to DRM. In relation to DRM, it reasons unsoundly, and has come to act against the common good.

Examples

@paulbrucecotton wrote:

I want to remind those that feel that W3C should not be working on EME that the W3C has previously explained its position publicly on why this work is happening at W3C. [W3C CEO] Jeff Jaffe’s 2013 blog post explained the rationale for this work occurring at W3C [...].

Jaffe's post contains the following sentence:

Without content protection [mechanisms being provided for in a W3C standard], owners of premium video content [...] will simply deprive the Open Web of key content.

As I understand it, the intended meaning of that remark is:

With content protection mechanisms provided for in a W3C standard, owners of premium video content will use those content protection mechanisms to provide the Open Web with key content.

There is much that is wrong with this.

Analysis

The falsehood that if the W3C does it, then it is open

The underlying assumption of the sentence I paraphrased is, "If a technological standard emerges from the W3C, then its fruits are inevitably part of the Open Web." This reduces to, "If I do it, then it must be right." In other words, the W3C appears to have adopted the "appeal to authority" fallacy, using itself as the authority.

This hints at a regrettable grandiosity at the top of the W3C; an attitude comparable to white knighting. Sadly, Tim Berners-Lee somewhat echoes this complex:

if content protection of some kind has to be used for videos, it is better for it to be discussed in the open at W3C, better for everyone to use an interoperable open standard as much as possible, and better for it to be framed in a browser which can be open source, and available on a general purpose computer rather than a special purpose box.

No, Tim, it isn't better. Those of us using browsers that are open source, and relying on interoperable open standards, want no part of DRM.

I don't want anyone to use DRM; but if they do, let them do it in a special purpose box, where it won't pollute and make hazardous the devices of anyone who desires to avoid it. (Thank you, @rubenquidam , for pointing out the pollution risk.) And let the DRM be as cumbersome, incompatible and dangerous as possible, so that its perpetrators can be successfully sued and so that any potential user remotely paying attention will shun it.

The falsehood that content provided via DRM is Open Web content

What is the Open Web? Wikipedia, has a good summary, but let us go to the primary source it cites: Tantek Çelik.

Çelik points out that for the Web to be the Open Web:

The web, and the internet as a whole, depends on the independence of content and addressing (i.e. domain names) and devices. You must be able to serve and access any kind of content across any domain name on any web device. Obviously not all devices will be capable enough to support all formats, but that should have nothing to do with the nature of the content itself.

This open access depends on the open ability to browse and use any web page or application (i.e. URL) on your:

  • web browsing device
  • internet service

And this must be without censorship per domain, URL, content-type, or nature of the content.

Very clearly, content provided by DRM, which by its nature would only be authorised for viewing on specific devices or by specific people, fails to meet this standard.

Private posts on Facebook and suchlike, of course, also fail to meet this standard (which is one of many reasons to avoid Facebook...); but DRM is much worse. A private Facebook post that has been shared with a given user is, at least in principle, accessible to that user regardless of the device that user is using to access the post, as long as the device has a reasonably capable Web browser (implementing the Web's open standards), and the user has logged in to Facebook. And having accessed the post, if the user wants to excerpt part of it to use elsewhere for free speech reasons like tuition, criticism or comment, they would not be technologically barred from doing so. With DRM, the user might not even have that limited level of access. They might have to log in via a specific device that they had previously registered with their media provider, together with their personal details; and they might be technologically barred from excerpting any part of it without excruciatingly cumbersome workarounds.

The falsehood that there exists "key content"

There is no absolute canon of key content, and never has been.

If a particular publisher or distributor wants to deprive Web users of its publications despite the many ways in which multimedia content can already be distributed over the Web, then that is regrettable. But it is manifestly the fault of that publisher or distributor, not of the Web. People can and will make do without those publications, and society could very well make do without such publishers and distributors.

As such, any decision by a publisher or distributor to withhold a publication from the Web (short of providing it with DRM) is that organisation's responsibility to rectify. It is not the responsibility of the World Wide Web Consortium.

An example: DRM and music in iTunes. Record labels were wrong to insist upon a mechanism (in this case, FairPlay) for publishers to distribute music with DRM via iTunes. Consumers worked around this by buying DRM-free music elsewhere, as Apple acknowledged. If that was the same music, great, then the artists didn't lose out, and the fans got DRM-free media: good for everybody. But if people couldn't find their favourite artists' music available DRM-free, then they simply sought out other music: I speak from experience. As such, many artists who distributed their music without DRM gained new followings, as did DRM-free stores like MagnaTune; and conversely, artists/labels/etc who distributed their music with DRM lost fans and customers. And in this way, the canon of popular music was proved not to be absolute, nor exclusive to major labels: there was no "key content" that listeners could not either do without or obtain DRM-free elsewhere. Eventually, the record labels and music publishers that had insisted upon Apple using DRM in iTunes relented, and there was much rejoicing.

An ad nauseam basis?

Why has Jaffe adopted the fallacious reasoning above?

Perhaps he has done so due to lobbying pressure. It is certainly possible that Jaffe and other W3C staff have succumbed to the repetition, ad nauseam, of similarly fallacious arguments by lobbyists aligned with DRM proponents in the media publishing industry. Under that sort of pressure sustained for year after year, even well-meaning, level-headed people might eventually snap and engage in doublethink.

The battle over DRM on the Web has been going on for at least 15 years. It is plausible that W3C staff have been being lobbied by the motion picture industry, etc, for much or all of that time. If so, then that is a lot of pressure for those individuals to bear. It might explain why they have cracked.

But this is just speculation. I cannot discern the workings of Jaffe's mind; I can merely note the paucity of his arguments in this case.

Summary

For the W3C to support, in any way, the implementation of DRM, is for the W3C to grossly betray the ideals of the Open Web.

The W3C CEO's justification for betraying those ideals is that there exists a category of "key content" without which the Web is suffering, such that the W3C must remedy this; but this justification is fallacious.

@zutje

This comment has been minimized.

Copy link

commented Sep 4, 2016

I want to support this objection.

EME is technically flawed and is open to interoperability issues, since the possibility is left open that CDMs be implemented platform specific.
Next to that it is technically flawed and open to security issues since there is no CDM specification and no specification of the DRM methods used. This makes an open and verifiably safe implementation impossible.

EME can therefore never be an open standard, which is in contrast with all W3C stands for: open standards for an open web.

@paulbrucecotton

This comment has been minimized.

Copy link

commented Sep 6, 2016

This issue will be closed with no action as per HME WG decision and added to the list of current Formal Objections against EME.

/paulc
HME WG Chair

@jdsmith3000

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2016

Closing per #305 (comment).

@jdsmith3000 jdsmith3000 closed this Sep 6, 2016

@zutje

This comment has been minimized.

Copy link

commented Sep 6, 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Paul,

although late in the process, I would ask you and the WG to sincerely
reconsider the protests against EME, because the standard is simply
incomplete for implementation of the full DRM stack, which should be
specified in the standard to counter the critiques issued in a
meaningful way. How can an incomplete, security wise flawed, and
legally problematic draft become a standard? That is nonsense.

Anyway, if criticism is justified, which I think it is in this case,
then cancellation of a proposed standard is no shame.

As a personal note: Maybe the workgroup has decided something, as a
protester I'm not convinced by simply being shifted aside... Maybe
(probably not even then) if the WG were more diverse including
representatives of the opposing parties too (in even measure). At this
point the shifting aside action is a farce, I even dare state: this
whole WG is a farce if it deals with severe criticism like this!

And yes that is criticism for the role W3C plays here too! As well as
an appeal for W3C to overrule the judgement of the WG over the
critical voices on EME.

Best regards,

Tjeerd Pinkert

On 09/06/2016 08:34 PM, Paul Cotton wrote:

This issue will be closed with no action as per HME WG decision
<https://lists.w3.org/Archives/Public/public-html-media/2016Sep/0003.h
tml>

and added to the list of current Formal Objections against EME
https://dev.w3.org/html5/status/formal-objection-status.html.

/paulc HME WG Chair

— You are receiving this because you commented. Reply to this email
directly, view it on GitHub
<#305 (comment)
045>,

or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADmeESTKaFxmvf5xYti
aj-JeMNesrMgjks5qnbIegaJpZM4Jlgpu>.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlfPPJkACgkQ9xQaBfeouap3OQCeMr6S8ItN4krxhL0eEsybPJ+W
kK0AmwRTkv0+o9coxUtc48LkLlGY//aa
=e8j+
-----END PGP SIGNATURE-----

@pikurasa

This comment has been minimized.

Copy link

commented Sep 7, 2016

_Here is my formal objection to EME in HTML5 to W3C (public-html-media@w3.org) from 8/19 with some edits for clarification in its point:_

My name is Devin Ulibarri and I am a music teacher. I am the chair of
the guitar department for the prep school and continuing education at
the New England Conservatory as well as an avid and published researcher
into how we can "educate better" (To sum things up in short. For more info, please see
my website, http://devinulibarri.com for links to my research).

As an active performing musician and educator, I have a vested interest
in electronic media, its distribution, and its preservation. I just want
to let others know that I oppose DRM of any kind--especially in web
standards such as "EME" (Electronic Media Extensions), which I
understand is a base for connecting the browser to a DRM module that
would be elsewhere in the system. (Thus, for practical purposes, it is
the way to put DRM in the browser). I wrote an in-depth rationale as to
why DRM is of concern to
musicians and music educators in the following article, published
earlier this year:

https://www.defectivebydesign.org/blog/why_should_musicians_care_about_digital_restrictions_management

Of particular concern is how DRM blocks the community's (e.g. teachers,
students, parents, studying performers) ability to use media under the
safe harbor of Fair Use.

[[[ On this note, I cannot support any technological "remedies" that
attempt to distinguish Fair Use from other use because it could not be
done anonymously--it would be an invasion of privacy. ]]]

And of even greater concern to me is the criminalization of DRM
circumvention, which is why I fully support the EFF's recent lawsuit
detailed here:

https://www.eff.org/press/releases/eff-lawsuit-takes-dmca-section-1201-research-and-technology-restrictions-violate

I found this argument from the cited article particularly compelling:

This ban applies even where people want to make noninfringing fair
uses of the materials they are accessing.

I implore you to reverse actions taken to implement DRM into web
standards. For the sake of music and for the sake of education, please
remove DRM from the W3C web standards.

Thank you for taking the time to read my thoughts on EME and DRM in
HTML5 as an Internet stakeholder, researcher, professional musician, and
educator.

@marado

This comment has been minimized.

Copy link

commented Oct 18, 2016

EME can therefore never be an open standard, which is in contrast with all W3C stands for: open standards for an open web.

Just to be clear, since this issue was raised to me in a conversation with someone from the W3C, we understand (I'm here speaking for @zutje , as I believe this is also his interpretation, may he speak up if it isn't) that there are many different definitions for "open standard", and while this might not be the case under W3C's definition, it is under other definitions, life FSFE's, which is widely adopted in slightly variants, like, for instance, in Portuguese Law.

@zutje

This comment has been minimized.

Copy link

commented Oct 19, 2016

To react on this:

On 10/18/2016 04:37 PM, Marcos Marado wrote:

EME can therefore never be an open standard, which is in contrast
with all W3C stands for: open standards for an open web.

Just to be clear, since this issue was raised to me in a conversation
with someone from the W3C, we understand (I'm here speaking for @zutje
https://github.com/zutje , as I believe this is also his
interpretation, may he speak up if it isn't) that there are many
different definitions for "open standard"
https://en.wikipedia.org/wiki/Open_standard, and while this might not
be the case under W3C's definition
https://open-stand.org/about-us/principles/, it is under other
definitions, life FSFE's https://fsfe.org/activities/os/def.en.html,
which is widely adopted in slightly variants, like, for instance, in
Portuguese Law https://m6.ama.pt/docs/Lei362011-NormasAbertas.pdf.

In short, I believe the "open" in the W3C statement was always meant to
be broader than the strict sense, at least, that is how I always assumed
it to be, since it is the interest of W3C that the web can be viewed by all.

From the wikipedia page we read:
On the standard organisation side, the World Wide Web Consortium (W3C)
ensures that its specifications can be implemented on a royalty-free basis.

On this basis, EME as such is "open". However, its sole purpose is to
embed code that is intrinsically meant to be closed, both in
specification and implementation. Therefore the purpose of the EME
standard goes against the principles of an open web, where all content
can be viewed by anyone implementing "the standard". This is the spirit
of the W3C law, to have all participate, not only some. In my
interpretation participating is not only on the browser "vendor" side,
but also on the browser "user" side. W3C wants to enable, through
dissemination of open standards, all web users to have access to the
content offered. In my opinion the spirit of the law should in this case
prevail over the letter.

In the case of EME content will be hidden, when the closed source
counterpart is not available, or for some reason not working anymore
(e.g. because of OS updates). It is there that my objection lies. Only
the owner of third party code will be able to enable access to certain
content.

This is now also the case with certain plugins available for browsers,
but it has never been so tightly integrated in the browser code itself,
nor is this tight integration needed for the sake of the purpose of the
plugin writers, while the integration on the other hand decreases the
openness of the web to users. The distinction between browser
implementing the open web standard and third party software implementing
other standards will be blurred, such a blurred boundary should in my
opinion not be advocated by W3C through it's standards. Nor should
browser producers want this situation, where foreign code can interact
with the browser and it's environment. This is a potential security thread.

My biggest concern regarding the open web is that EME allows a browser
in browser loophole, where certain websites will only work if the
browser in browser is installed, which would certainly go against open
web standards. While this is already possible, the user has to choose to
install third party code. EME would obfuscate this process.

Next to that there are more objections against DRM in general (IANAL).
Let's be clear that the sole purpose for EME is to allow vendors to
implement DRM more closely integrated in the browser environment.

Objections that lie on the legal side could in my opinion be:

  • Are browser vendors implementing EME vulnerable for lawsuits when
    closed code gets hacked and the hacked plugin is allowed to bind to the
    EME code?
  • Do DRM plugins violate the copyright acts in place? Can users do a
    lawsuit to providers of DRMed content because their rights are violated
    by protection measures that are protected against reverse engineering by
    law?
  • Is W3C liable for enabling such law violations through creation of EME?

Then there are objections that lie on the humanity side:

  • Is a vendor of DRM content allowed to take technical measures that
    will restrict future research into history?

I will illustrate this with an example. Let's assume a big independent
new corporation decides to close off all it's articles and news videos
with DRM. Let's assume it goes bust at some point. Then no-one (let's
assume there are no technical circumvention possibilities of the DRM
used) will have any access to the broadcasted content in the future. DRM
is thus refraining e.g. truth finding or cultural research for future
generations.

With all these objections then, how then to proceed? EME can only become
a standard if the closed counterpart can be opened up. In my opinion
there are proper technical solutions available, e.g. in cryptography, to
allow for an open solution where buyers of the "key" have access and non
key-owners not. This is indeed less restrictive, in the sense that the
decoded content can be saved on local disks and such. It will on the
other hand be also less infringing on the buyers rights. Many are
willing to pay for the content, DVD's and Blue Rays are still being sold...

Best regards,

Tjeerd Pinkert

@emanuil-tolev

This comment has been minimized.

Copy link

commented Nov 11, 2016

@paulbrucecotton It feels like you are ignoring a varied and diverse set of voices (certainly not limited to those with more extreme feelings towards EME). E.g. you ruled to close a number of formal objections without further action in https://lists.w3.org/Archives/Public/public-html-media/2016Sep/0003.html for 3 reasons. One of which was "cannot be satisfied without making "substantive changes" [1] to the EME specification or halting work on the specification entirely". I think the objectors want the WG to do exactly that at this stage, so using it as a reason to ignore the objections appears obtuse and facetious. You have said that further action will be taken:

Each of these Formal Objections will be added to the summary page of formal objections [1] and will be presented to the Director when he reviews a request to progress EME to Proposed Recommendation status.

I understand that may be the limit of what you can do as WG chair. I do still feel that this process will be seen as biased towards a positive outcome for the EME spec and insufficient engagement with the criticism of it.

The W3C is a body to standardise practice within the open web community. Forcing a standard down browser vendors' and web developers' throats and ignoring objections just on a procedural basis (raised at wrong stage, too late or other Kafka-esque excuses to not hear valid opinions) is not going to end well for the web or the W3C. I concede that you're just following W3C process rather than shutting out feedback. I'm not sure this will be well understood to be impartial, but we'll see.

EDIT: "you" above to mean "the Working Group working on this issue".

Furthermore, if you truly believe this is worthwhile work and these objections come from a point of not understanding what the WG is doing, please elaborate - so as to bring objectors to see it from the WG's point of view and reach consensus. Pasting in a bunch of links to historical context is not satisfactory, since readers' concerns may not be alleviated by previous proceedings anyway!

@paulbrucecotton

This comment has been minimized.

Copy link

commented Nov 11, 2016

you ruled to close a number of formal objections without further action

That is NOT true. As my email stated:

Each of these Formal Objections will be added to the summary page of formal objections [1] and will be presented to the Director when he reviews a request to progress EME to Proposed Recommendation status.

And that is EXACTLY what is going to happen now that the HME WG has sent the EME Proposed Recommendation to the W3C Director.

/paulc
HME WG Chair

@emanuil-tolev

This comment has been minimized.

Copy link

commented Nov 11, 2016

you ruled to close a number of formal objections without further action

That is NOT true. As my email stated:

I apologise, you have detailed this is the further action to be taken. I was fairly sure in my impression, I must have conflated different conversation threads I've been following about this. I've edited my post.

I stand by my perspective as a total outsider to this process (in the sense that I've never participated in a W3C WG and not in this one) that there can be better engagement from W3C regarding this controversial spec.

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Nov 11, 2016

@emanuil-tolev There was, some years ago now, an extensive discussion on this issue, peaking at > 400 messages in June 2013 alone. In the end, the main objections could not be resolved through discussion and so they remain as Formal Objections, to be addressed by the Director.

Nothing that has been said recently is new or has not been extensively debated during the several years of this work. It should not be a surprise that raising the same issues again has no new effect or that people do not volunteer their time to repeat the prior debates.

None of the objections have been ignored, we just don't agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.