[x-pubpol] DRM for the Web? Say It Ain’t So

Joly MacFie joly at punkcast.com
Wed Feb 13 12:56:25 PST 2013


(Via  Howard Liptzin ) [not strictly pubpol but relevant]

http://www.webmonkey.com/2013/02/drm-for-the-web-say-it-aint-so/

DRM for the Web? Say It Ain’t So
By Scott Gilbertson
So far it ain’t so, but some form of DRM in HTML is becoming a more
likely possibility every day.

The W3C’s HTML Working Group recently decided that a proposal to add
DRM to HTML media elements — formally known as the Encrypted Media
Extensions proposal — is indeed within its purview and the group will
be working on it.

That doesn’t mean that the Encrypted Media Extensions proposal will
become a standard as is, but it does up the chances that some sort of
DRM system will make its way into HTML.

The Encrypted Media Extensions proposal — which is backed by the likes
of Google, Microsoft, Netflix and dozens of other media giants —
technically does not add DRM to HTML. Instead it defines a framework
for bringing a DRM system, or “protected media content” as the current
draft puts it, to the web.

If you think the idea of DRM seems antithetical to the inherently open
nature of HTML, you’re not alone. Ian Hickson, former editor of the
W3C’s HTML spec, has called the Encrypted Media Extensions proposal
“unethical.” Hickson is no longer in charge of the W3C’s HTML spec,
but HTML WG member Manu Sporny, has already asked the WG not to
publish the first working draft because the “specification does not
solve the problem the authors are attempting to solve.”

There are numerous problems with the Encrypted Media Extensions
proposal, including the basic fact that, historically, DRM doesn’t
work.

Other problems specific to the current draft of the proposal include
the fact that it might well be impossible for open source web browsers
to implement without relying on closed source components. Then there
are the gaping security flaws that would make it trivially easy to
defeat the currently defined system.

But Sporny raises a far more ominous objection — that the proposal in
its current form does not actually define a DRM system. Instead it
proposes a common API, which would most likely lead to a proliferation
of DRM plugins. Here’s Sporny’s take:

The EME specification does not specify a DRM scheme in the
specification, rather it explains the architecture for a DRM plug-in
mechanism. This will lead to plug-in proliferation on the Web. Plugins
are something that are detrimental to inter-operability because it is
inevitable that the DRM plugin vendors will not be able to support all
platforms at all times. So, some people will be able to view content,
others will not.

That sounds a lot like the bad old days when you needed Flash, Real
Player, Windows Media Player and dozens of other little plugins
installed just to watch a video.

That’s a web no user wants to return to.

At the same time there continue to be companies which believe DRM is
essential to their bottom line and the web offers no solution. That’s
why Flash, Silverlight and other DRM-friendly plugins remain the media
players of choice for many content providers.

So the question of DRM on the web boils down to this: should the W3C
continue to work on a spec that defines some kind of DRM system or
should the interested companies go off and do their own work? For its
part the W3C clearly wants to be part of the process, though it
remains unclear what, if any, value a standards-based DRM system might
have for web users.


--
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-



More information about the x-pubpol mailing list