libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] Fwd: [FC-discuss] Don’t let the myths fool you


From: Kẏra
Subject: Re: [libreplanet-discuss] Fwd: [FC-discuss] Don’t let the myths fool you: the W3C’s plan for DRM in HTML5 is a betrayal to all web users.
Date: Wed, 24 Apr 2013 19:35:36 -0400

Now, an International coalition of 27 Internet freedom organizations
including the Electronic Frontier Foundation, Free Software Foundation,
Free Culture Foundation, Fight for the Future, and Creative Commons,
urges W3C to reject Encrypted Media Extensions, a proposal to build
Digital Restrictions Management into the Web! They call on individuals
to join them in signing the petition against DRM in HTML5:
http://www.defectivebydesign.org/no-drm-in-html5

Full announcement: 
https://www.fsf.org/news/coalition-against-drm-in-html
Sign on letter: 
http://www.defectivebydesign.org/sign-on-against-drm-in-html

Social links: 
http://www.reddit.com/r/freeculture/duplicates/1d1msw/international_coalition_of_27_internet_freedom/
https://status.fsf.org/notice/20927
https://twitter.com/fsf/status/327152201627742209

On Tue, 2013-04-23 at 19:54 -0400, Kẏra wrote:
> Read this online here:
> http://freeculture.org/blog/2013/04/23/dont-let-the-myths-fool-you-the-w3cs-plan-for-drm-in-html5-is-a-betrayal-to-all-web-users/
> 
> And signal boost! 
> https://identi.ca/notice/100717227
> https://twitter.com/freeculture/status/326842425337323520
> http://www.reddit.com/r/technology/duplicates/1cz0mq/dont_let_the_myths_fool_you_drm_in_html5_is_a/
> 
> 
> -------- Forwarded Message --------
> > From: Free Culture Foundation <webleader+rss-bot@freeculture.org>
> > Reply-to: Discussion of Free Culture in general and this organization
> > in particular <discuss@freeculture.org>
> > To: discuss@freeculture.org
> > Subject: [FC-discuss] Don’t let the myths fool you: the W3C’s plan for
> > DRM in HTML5 is a betrayal to all web users.
> > Date: Tue, 23 Apr 2013 23:15:04 -0000
> > 
> > A handful of myths have become common defenses of the W3C's plan for
> > "Encrypted Media Extensions" (EME), a [Digital Restrictions
> > Management][1] (DRM) scheme for HTML5, the next version of the markup
> > language upon which the Web is built.
> > 
> > These arguments obscure the threat this poses to a free and open web and
> > why we must [send a strong and clear message to the W3C and its member
> > organizations][2], that **DRM in HTML5 is a betrayal to all Web users
> > and undermines the W3C's self-stated [mission][3] to make the benefits
> > of the Web "available to all people, whatever their hardware, software,
> > network infrastructure, native language, culture, geographical location,
> > or physical or mental ability." The W3C exists to bring the vision of
> > ****an undivided 'One Web' to its full potential, and DRM is
> > antithetical to that goal. **
> > 
> > [![][4]][2]
> > 
> > Among the most popular claims are:
> > 
> >   1. that DRM doesn't work; that it exists to protect creators, but
> > since it is easily cracked and can be worked around, it is largely
> > ineffective and irrelevant
> > 
> >   2. that DRM in HTML5 is a necessary compromise to finally bring an end
> > to the proliferation of proprietary browser plugins such as Adobe Flash
> > Player and Micrisoft Silverlight
> > 
> >   3. that the web needs DRM in HTML5 in order for Hollywood and other
> > media giants to finally start giving the Web priority over delivering
> > media over traditional means
> > 
> > All of these myths depend on dangerous misconceptions of how the planned
> > Encrypted Media Extensions work, why Hollywood's threat of boycott is
> > completely empty, who DRM is actually built for, and what the purpose of
> > free and open Web standards is. Implementing the EME proposal would
> > simultaneously legitimize DRM through the HTML5 standard and needlessly
> > concede the very purpose of Web standards. This is not a compromise for
> > the advancement of the Web, it's a complete concession of the principles
> > of the W3C.
> > 
> > The next time any of those myths come up, you can use the following to
> > respond:
> > 
> > **1. DRM is not about protecting copyright. That is a straw man. DRM is
> > about limiting the functionality of devices and selling features back in
> > the form of services.**
> > 
> > Public perception of DRM is that it exists to prevent unauthorized
> > copying, but that it's inherently ineffective because it's impossible to
> > simultaneously show someone something and keep it hidden from them. This
> > is a grave mistake that hides the actual function of DRM, which is
> > overwhelmingly successful: to prevent completely legal uses of
> > technology so that media companies can charge over and over for services
> > which provide functionality that should never have been removed to begin
> > with.
> > 
> > Copyright already provides leverage against media distributors, but DRM
> > provides leverage against technological innovations which have given
> > users the capability to do much more with media than ever before. Free
> > of technologically imposed limits, anyone can view their media whenever
> > they want, wherever they want, on whichever devices they want, and
> > however they want. By imposing digital restrictions, media giants can
> > prevent users from skipping advertisements or viewing media on multiple
> > devices, and then charging for the relief from those antifeatures. This
> > gives media companies total control over how people use their technology
> > and creates a huge market out of artificially produced scarcity. This
> > exploitative practice targets the vast majority of users who acquire
> > their media legally, and it's already stunted the growth of the Web
> > enough.
> > 
> > Ian Hickson, the author and maintainer of the HTML5 specification, is
> > not only overseeing the HTML5 standard at the W3C but also an engineer
> > at Google (ironically, one of the biggest corporate proponents of the
> > EME proposal). He blasts the idea that DRM's purpose is to enforce
> > copyrights and [explains the distinction thoroughly][5]:
> > 
> > > Arguing that DRM doesn't work is, it turns out, missing the point. DRM
> > is working really well in the video and book space. Sure, the DRM
> > systems have all been broken, but that doesn't matter to the DRM
> > proponents. Licensed DVD players still enforce the restrictions. Mass
> > market providers can't create unlicensed DVD players, so they remain a
> > black or gray market curiosity. DRM failed in the music space not
> > because DRM is doomed, but because the content providers sold their
> > digital content without DRM, and thus enabled all kinds of players they
> > didn't expect (such as "MP3″ players). Had CDs been encrypted, iPods
> > would not have been able to read their content, because the content
> > providers would have been able to use their DRM contracts as leverage to
> > prevent it. DRM's purpose is to give content providers control over
> > software and hardware providers, and it is satisfying that purpose well.
> > 
> > **2. DRM in HTML5 doesn't obviate proprietary browser plug-ins, it
> > encourages them.**
> > 
> > The web would certainly be better off without Microsoft Silverlight and
> > Adobe Flash Player, but the idea that putting DRM into HTML itself to
> > make them obsolete is absurd. New implementations of anti-user
> > technology are not preferable to old implementations of anti-user
> > technology. While it may eliminate the corporate demands for Silverlight
> > and Flash, at least in their current incarnation, the Encrypted Media
> > Extensions plan takes what makes those particular technologies terrible
> > for users (digital restrictions management, poor cross-platform support,
> > etc) and injects it directly into the fabric of the Web.
> > 
> > Providing a space for a DRM scheme in HTML5 invites the kind of
> > incompatibilities that HTML was created to undo. EMEs would require that
> > proprietary browsers and operating systems implement more restrictive
> > antifeatures to prevent bypassing the DRM, and as the corollary to this,
> > EMEs would be able to detect whether the user's software did not have
> > such antifeatures (as is the case with free/libre and open source
> > software, specifically GNU+Linux operating systems) and refuse to
> > deliver the media.
> > 
> > As [the Electronic Frontier Foundation (EFF) writes][6]:
> > 
> > > The EME proposal suffers from many of these problems because it
> > explicitly abdicates responsibility on compatibility issues and lets Web
> > sites require specific proprietary third-party software or even special
> > hardware and particular operating systems (all referred to under the
> > generic name "content decryption modules", or CDMs, and none of them
> > specified by EME). EME's authors keep saying that what CDMs are, and do,
> > and where they come from is totally outside of the scope of EME, and
> > that EME itself can't be thought of as DRM because not all CDMs are DRM
> > systems. Yet if the client can't prove it's running the particular
> > proprietary thing the site demands, and hence doesn't have an approved
> > CDM, it can't render the site's content. Perversely, this is exactly the
> > reverse of the reason that the World Wide Web Consortium exists in the
> > first place. W3C is there to create comprehensible, publicly-
> > implementable standards that will guarantee interoperability, not to
> > facilitate an explosion of new mutually-incompatible software and of
> > sites and services that can only be accessed by particular devices or
> > applications. But EME is a proposal to bring exactly that dysfunctional
> > dynamic into HTML5, even risking a return to the "bad old days, before
> > the Web" of deliberately limited interoperability.
> > 
> > >
> > 
> > > …
> > 
> > >
> > 
> > > All too often, technology companies have raced against each other to
> > build restrictive tangleware that suits Hollywood's whims, selling out
> > their users in the process. But open Web standards are an antidote to
> > that dynamic, and it would be a terrible mistake for the Web community
> > to leave the door open for Hollywood's gangrenous anti-technology
> > culture to infect W3C standards. It would undermine the very purposes
> > for which HTML5 exists: to build an open-ecosystem alternatives to all
> > the functionality that is missing in previous Web standards, without the
> > problems of device limitations, platform incompatibility, and non-
> > transparency that were created by platforms like Flash. HTML5 was
> > supposed to be better than Flash, and excluding DRM is exactly what
> > would make it better.
> > 
> > **3. The Web doesn't need big media; big media needs the Web.**
> > 
> > The idea that Hollywood, the MPAA, RIAA, or any other media giant has
> > buying-power over the Web is a farce. The Web is here, it is the nexus
> > of media convergence, and it's eating up other industries. Big media
> > companies know that they must adapt or go out of business, but they are
> > audaciously attempting to convince us that the Web should provide them
> > with another, more expansive system of control over online media
> > distribution on top of the already far-reaching legal restrictions they
> > [abuse][7]. These threats are not new.  During the [Broadcast Flag
> > ][8]negotiations to implement DRM for high-definition digital
> > television,
> > 
> > > MPAA's Fritz Attaway said that "high-value content will migrate away"
> > from television if the Broadcast Flag wasn't imposed; he told Congress
> > that fears of infringement without a Broadcast Flag mandate "will lead
> > content creators to cease making their high-value programming available
> > for distribution over digital broadcast television [and] the DTV
> > transition would be seriously threatened."
> > 
> > Glynn Moody elaborates on these hollow threats [attacking free software
> > and the free and open web][9]:
> > 
> > > Let's look at the record on threats to boycott non-DRM broadcasting
> > from these companies. In 2003, the US Broadcast Protection Discussion
> > Group (a committee in the Hollywood-based Copy Protection Technical
> > Working Group) went to work on a plan for adding DRM called the
> > Broadcast Flag to America's high-def broadcasts. I attended every one of
> > these meetings, working on behalf of the Electronic Frontier Foundation
> > and the free/open TV projects it represented, including MythTV (an open
> > video-recorder) and GNU Radio (an open radio/TV receiver).
> > 
> > >
> > 
> > > Over and over again, the rightsholders in the room during the
> > Broadcast Flag negotiations attempted to create a sense of urgency by
> > threatening to boycott American high-def telly if they didn't get DRM.
> > They repeated these threats in their submissions to the Federal
> > Communications Commission (Ofcom's US counterpart) and in their meetings
> > with American lawmakers.
> > 
> > >
> > 
> > > And here's how it turned out:
> > 
> > >
> > 
> > > So what happened? Did they make good on their threats? Did they go to
> > their shareholders and explain that the reason they weren't broadcasting
> > anything this year is because the government wouldn't let them control
> > TVs?
> > 
> > >
> > 
> > > No. They broadcast. They continue to broadcast today, with no DRM.
> > 
> > The EFF makes this abundantly clear in [their statement][6]:
> > 
> > > The perception is that Hollywood will never allow movies onto the Web
> > if it can't encumber them with DRM restrictions. But the threat that
> > Hollywood could take its toys and go home is illusory. Every film that
> > Hollywood releases is already available for those who really want to
> > pirate a copy. Huge volumes of music are sold by iTunes, Amazon,
> > Magnatune and dozens of other sites without the need for DRM. Streaming
> > services like Netflix and Spotify have succeeded because they are more
> > convenient than piratical alternatives, not because DRM does anything to
> > enhance their economics. The only logically coherent reason for
> > Hollywood to demand DRM is that the movie studios want veto controls
> > over how mainstream technologies are designed. Movie studios have used
> > DRM to enforce arbitrary restrictions on products, including preventing
> > fast-forwarding and imposing regional playback controls, and created
> > complicated and expensive "compliance" regimes for compliant technology
> > companies that give small consortia of media and big tech companies a
> > veto right on innovation.
> > 
> > **Protect internet freedom: tell the W3C that DRM has no place in their
> > standards.**
> > 
> > Help [Defective by Design][10], the [Free Software Foundation][11]'s
> > campaign against DRM gather 50,000 signatures against DRM in HTML5.
> > 
> > Sign the petition here:
> > 
> > [http://www.defectivebydesign.org/no-drm-in-html5][2]
> > 
> > You can also contact the W3C here:
> > 
> > [http://www.w3.org/Consortium/contact][12]
> > 
> >    [1]: http://www.defectivebydesign.org/what_is_drm
> > 
> >    [2]: http://www.defectivebydesign.org/no-drm-in-html5
> > 
> >    [3]: http://www.w3.org/Consortium/mission.html
> > 
> >    [4]: http://freeculture.org/files/2013/04/hollyweb.jpeg
> > 
> >    [5]: https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2
> > 
> >    [6]: https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-drm-
> > out-w3c-standards
> > 
> >    [7]: https://www.eff.org/press/releases/fifteen-years-dmca-abuse
> > 
> >    [8]: https://www.eff.org/deeplinks/2009/06/dtv-era-no-broadcast
> > 
> >    [9]: http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc-
> > attacks-the-open-web-gnulinux-in-danger/index.htm
> > 
> >    [10]: http://www.defectivebydesign.org/
> > 
> >    [11]: https://www.fsf.org/
> > 
> >    [12]: http://www.w3.org/Consortium/contact
> > 
> > URL: 
> > http://freeculture.org/blog/2013/04/23/dont-let-the-myths-fool-you-the-w3cs-plan-for-drm-in-html5-is-a-betrayal-to-all-web-users/
> > _______________________________________________
> > Discuss mailing list
> > Discuss@freeculture.org
> > http://lists.freeculture.org/mailman/listinfo/discuss
> > FAQ: http://wiki.freeculture.org/Fc-discuss
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]