A Controversial Unboxing of Firefox’s new D.R.M.
What it means for content creation and, of all things, the 90's grunge scene.
‘Tis the season for new tech, and we developers are anxiously awaiting new gadgets and applications to ring us into the fiscal year. The birth of new tech is sight for sore blog post clicks, especially with Ruby’s own Doug Hanson announcing the death of test-driven development a few weeks ago.
What is surprising to see is the announcement of Firefox releasing their browser using a technology called D.R.M., which has sparked a lot of controversy in the blogosphere. Let’s break down what D.R.M. is and why you need to worry about it.
D.R.M. stands for Digital Rights Markup. It’s like H.T.M.L. but for creative content. We’re talking music, video, art, and anything outside of what the browser can natively handle. D.R.M. isn’t new by any means. Major record labels used to use it to keep people from ripping CDs in the late 90s, and the film industry uses it to show those FBI warnings at the beginning Blue Rays movies.
So what is D.R.M. doing in our browser? It’s protecting content creators from having their intellectual property leaked through new open web features. One of the features that artists fear the most is the Shadow DOM, and it’s with good reason. I’ve warned about Shadow DOM before, and it looks like Firefox’s parent company, Mozella, has finally started listening.
Let’s talk code for a sec.
Here’s a purely hypothetical situation that definitely didn’t happen at all last week: an artist sees that someone is writing posts on Medium which use stock art with watermarks on it. Now, they don’t know if that writer actually paid for the stock image, and they could probably ask her before going on a rant on Twitter about it, but that puts the rest of artists on the Internet at risk and keeps the artist from starting a dialogue at the expense of that writer’s reputation. This is the Shadow DOM.
D.R.M. prevents Shadow DOM from happening by only allowing people who pay for stock photos to be able to use them. For example, here is an image tag:
<img src="stockphoto.png" />Now, all we know about this image when viewing it in the browser is what it looks like. D.R.M. allows us to inject security attributes to let artists know that the content is safe from Shadow DOM and other web components.
<img src=”stockphoto.png" drm-message="I literally paid for this stock photo." drm-literally-paid="2 credits" />The `drm-message` attribute lets the artist know in our purely hypothetical situation above know that, yes, the writer paid for the stock image and therefore does not need to contact the proper authorities on Twitter. An optional attribute of `drm-literally-paid` let’s everyone know the value of the art they are looking at.
See, D.R.M. is not as scary as the blogs are making it out to me. We are still allowed to look at art, but we no longer have to worry about it leaking to hackers. As the languages of HTML and JavaScript evolve, it only makes sense that anti-piracy grows as well.
Jenn Schiffer literally used to work at a large media/entertainment company, so — although she does not like the idea of DRM — she knows that the decisions made by these media companies to require it are not lovers of open source and data like we are, but are instead worried about missing out on financial gain from total control of content even after purchase, regardless of how irrational and selfish that fear may be. Therefore, open source developers find themselves reaching a fork in the road that forces them to make controversial compromises so that they can continue our mission to promote the open web but at the same time cater to users who do not know or care about the mission of promoting an open web, instead of fading into obscurity in vain. Dealing with stubborn, ignorant, rich people in power is one of the hardest problems in computer science.
