Free Culture Foundation explore arguments for and against DRM in HTML5
April 25, 2013 3:39 AM Subscribe
The three most pervasive arguments for DRM in HTML debunked by Freeculture.org " A handful of myths have become common defenses of the W3C’s plan for “Encrypted Media Extensions” (EME), a Digital Restrictions Management (DRM) scheme for HTML5, the next version of the markup language upon which the Web is built."
The entire article is quite short, and worth a read but see the extended description for a TL:DR summary -
Statement 1:
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
Response 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.
Statement 2:
DRM in HTML5 is a necessary compromise to finally bring an end to the proliferation of proprietary, platform-specific browser plugins such as Adobe Flash Player and Micrisoft Silverlight
Response 2:
DRM in HTML5 doesn’t obviate proprietary, platform-specific browser plug-ins; it encourages them.
Statement 3:
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
Response 3:
The Web doesn’t need big media; big media needs the Web.
Statement 1:
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
Response 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.
Statement 2:
DRM in HTML5 is a necessary compromise to finally bring an end to the proliferation of proprietary, platform-specific browser plugins such as Adobe Flash Player and Micrisoft Silverlight
Response 2:
DRM in HTML5 doesn’t obviate proprietary, platform-specific browser plug-ins; it encourages them.
Statement 3:
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
Response 3:
The Web doesn’t need big media; big media needs the Web.
Well that was certainly a balanced analysis. Does DRM also cause autism by any chance?
posted by pipeski at 3:52 AM on April 25, 2013 [12 favorites]
posted by pipeski at 3:52 AM on April 25, 2013 [12 favorites]
three blind mice:
The wording of the TL:DR was taken verbatim from the article. But, yes I think your point of 'it just doesn't work' is a valid one.
pipski:
If you know of a more balanced article please post it as a comment. I've tried finding more egalitarian articles online, but it's been difficult.
I didn't want to editorialise the post contents just wanted to place - what I consider to be - an interesting article here, and see what Mefites have to say about it.
posted by Faintdreams at 4:23 AM on April 25, 2013 [1 favorite]
The wording of the TL:DR was taken verbatim from the article. But, yes I think your point of 'it just doesn't work' is a valid one.
pipski:
If you know of a more balanced article please post it as a comment. I've tried finding more egalitarian articles online, but it's been difficult.
I didn't want to editorialise the post contents just wanted to place - what I consider to be - an interesting article here, and see what Mefites have to say about it.
posted by Faintdreams at 4:23 AM on April 25, 2013 [1 favorite]
Trying to stop DRM by excluding it from standards is Cnut behaviour, and attempting to enforce a political goal by technological means.
The real solution for DRM is for content creators to conclude it is a bad idea.
posted by unSane at 4:36 AM on April 25, 2013 [3 favorites]
The real solution for DRM is for content creators to conclude it is a bad idea.
posted by unSane at 4:36 AM on April 25, 2013 [3 favorites]
Trying to stop DRM by excluding it from standards is Cnut behaviour...
It's not, when DRM is actively damaging to those same standards. Building DRM into an open standard does not work; it literally means that any platform that can't support your proprietary, black-box "extension" can be labelled "not standards compliant." It will be a huge setback to systems that are not walled gardens.
posted by sonic meat machine at 5:10 AM on April 25, 2013 [9 favorites]
It's not, when DRM is actively damaging to those same standards. Building DRM into an open standard does not work; it literally means that any platform that can't support your proprietary, black-box "extension" can be labelled "not standards compliant." It will be a huge setback to systems that are not walled gardens.
posted by sonic meat machine at 5:10 AM on April 25, 2013 [9 favorites]
This is a fairly good analysis I think. At least it doesn't start with the premise that DRM is a tool of the cabal.
posted by pipeski at 5:17 AM on April 25, 2013 [2 favorites]
posted by pipeski at 5:17 AM on April 25, 2013 [2 favorites]
DRM’s purpose is to give content providers control over software and hardware providers, and it is satisfying that purpose well.
This (a quote in the article from Google's Ian Hickson, original here) is exactly right, and it's why DRM is such a bad thing for free software and any kind of open computing. The real benefit of DRM for content providers isn't that it prevents "piracy", it's that the anti-circumvention provisions in US copyright law, which the US requires other countries to adopt as a condition for entering into bilaterial and plurilateral trade agreements, override fair use and all other exceptions to copyright. There are exceptions to the anti-circumvention laws, but they are designed to be as narrow and hard to exercise as possible (especially for individual users; corporations and institutions have more leeway).
Essentially what DRM does is to do away with all of the legal doctrine that balances the interests of rights-holders against the interests of users, and to prevent the courts (and the legislatures of parties to trade treaties with the US) creating any new kinds of user rights through exceptions to copyright. It is very effective at doing this.
Anyway, here's an earlier thread with plenty of discussion of DRM in html5.
posted by A Thousand Baited Hooks at 5:23 AM on April 25, 2013 [4 favorites]
This (a quote in the article from Google's Ian Hickson, original here) is exactly right, and it's why DRM is such a bad thing for free software and any kind of open computing. The real benefit of DRM for content providers isn't that it prevents "piracy", it's that the anti-circumvention provisions in US copyright law, which the US requires other countries to adopt as a condition for entering into bilaterial and plurilateral trade agreements, override fair use and all other exceptions to copyright. There are exceptions to the anti-circumvention laws, but they are designed to be as narrow and hard to exercise as possible (especially for individual users; corporations and institutions have more leeway).
Essentially what DRM does is to do away with all of the legal doctrine that balances the interests of rights-holders against the interests of users, and to prevent the courts (and the legislatures of parties to trade treaties with the US) creating any new kinds of user rights through exceptions to copyright. It is very effective at doing this.
Anyway, here's an earlier thread with plenty of discussion of DRM in html5.
posted by A Thousand Baited Hooks at 5:23 AM on April 25, 2013 [4 favorites]
Related? Amazon video stopped working on a wide range of devices recently. Another reason I won't be renewing my Prime membership…
posted by jepler at 5:25 AM on April 25, 2013
posted by jepler at 5:25 AM on April 25, 2013
it literally means that any platform that can't support your proprietary, black-box "extension" can be labelled "not standards compliant.
Worse than that, even if the technical ability exists it means that you open the door to requiring code oversight by DRM providers. After all, what's the point of using the extension if you can use any code desired on the other side? You end up having to have some kind of secure code path that excludes FOSS principles entirely.
posted by jaduncan at 5:30 AM on April 25, 2013
Worse than that, even if the technical ability exists it means that you open the door to requiring code oversight by DRM providers. After all, what's the point of using the extension if you can use any code desired on the other side? You end up having to have some kind of secure code path that excludes FOSS principles entirely.
posted by jaduncan at 5:30 AM on April 25, 2013
Without DRM in HTML5, Netflix will keep Silverlight alive, and, to a lesser extent, Google will keep Flash alive. These are arguably technologies that we'd be better served by having them not kept past their use-by date any longer than they already have.
posted by Blazecock Pileon at 5:32 AM on April 25, 2013 [2 favorites]
posted by Blazecock Pileon at 5:32 AM on April 25, 2013 [2 favorites]
Well that was certainly a balanced analysis. Does DRM also cause autism by any chance?
Should all articles be "fair and balanced" or is it possible to take a stand on an issue as being fundamentally right or wrong?
posted by nowhere man at 5:38 AM on April 25, 2013 [7 favorites]
Should all articles be "fair and balanced" or is it possible to take a stand on an issue as being fundamentally right or wrong?
posted by nowhere man at 5:38 AM on April 25, 2013 [7 favorites]
Huh. Their second point actually seems very reasonable. There's little point in standardizing DRM into HTML5 video if it's still going to allow content owners to rely on 3rd-party binary plugins for decryption. (When I first read it, I thought "There's no way that's in the proposal," but there it is...)
Personally, I think that DRM is okay in certain instances. We wouldn't have Netflix or Spotify without DRM. However, the cards are already pretty heavily stacked in favor of the content owners, so I'm also not going to really encourage DRM's reach to extend any further (although standardizing the existing status quo seems pretty innocuous, and like a win for consumers overall).
I refuse to buy any content that is encrypted with unbreakable DRM. However, I'll accept it as a tradeoff for content that I effectively rent.
I do web video stuff for a living, and the politics and infighting surrounding HTML5 video make the standard absolutely hellish to deal with. Video patents are shitty and expensive, but standards proliferation is so, so, so much worse from a practical perspective. I see where Google, Mozilla, and the EFF are coming from, but I really just want a standard that bloody works everywhere.
The semantics of HTML5 video are lost when you need to lean heavily on browser capability testing, and transcode your videos into a thousand different formats (did I mention that CDN-backed storage is expensive?). We still end up using a ton of Flash, because the benefits of HTML5 video don't yet outweigh the costs for non-iOS users. (iOS itself can also be a huge pain, as it doesn't provide a complete implementation of the HTML5 video API).
posted by schmod at 5:41 AM on April 25, 2013 [4 favorites]
Personally, I think that DRM is okay in certain instances. We wouldn't have Netflix or Spotify without DRM. However, the cards are already pretty heavily stacked in favor of the content owners, so I'm also not going to really encourage DRM's reach to extend any further (although standardizing the existing status quo seems pretty innocuous, and like a win for consumers overall).
I refuse to buy any content that is encrypted with unbreakable DRM. However, I'll accept it as a tradeoff for content that I effectively rent.
I do web video stuff for a living, and the politics and infighting surrounding HTML5 video make the standard absolutely hellish to deal with. Video patents are shitty and expensive, but standards proliferation is so, so, so much worse from a practical perspective. I see where Google, Mozilla, and the EFF are coming from, but I really just want a standard that bloody works everywhere.
The semantics of HTML5 video are lost when you need to lean heavily on browser capability testing, and transcode your videos into a thousand different formats (did I mention that CDN-backed storage is expensive?). We still end up using a ton of Flash, because the benefits of HTML5 video don't yet outweigh the costs for non-iOS users. (iOS itself can also be a huge pain, as it doesn't provide a complete implementation of the HTML5 video API).
posted by schmod at 5:41 AM on April 25, 2013 [4 favorites]
The wording of the TL:DR was taken verbatim from the article.
No kidding. My point was that the "Free Culture Foundation" got their own reasoning wrong. That's what too much free beer does to you.
posted by three blind mice at 5:46 AM on April 25, 2013 [1 favorite]
No kidding. My point was that the "Free Culture Foundation" got their own reasoning wrong. That's what too much free beer does to you.
posted by three blind mice at 5:46 AM on April 25, 2013 [1 favorite]
This is a fairly good analysis I think.
The problem with that article is that it assumes that the point of including DRM in the HTML5 specification is to prevent "opportunistic piracy". But as Hickson points out, this isn't really what DRM is about. DRM is about using a combination of patent protection and the prohibition on selling services and devices that circumvent DRM to prevent third parties producing hardware or software that allows users to interact with media in any way that the publisher doesn't like.
Remember the Betamax VCR decision? DRM guarantees that something like that will never happen again.
posted by A Thousand Baited Hooks at 5:49 AM on April 25, 2013 [2 favorites]
The problem with that article is that it assumes that the point of including DRM in the HTML5 specification is to prevent "opportunistic piracy". But as Hickson points out, this isn't really what DRM is about. DRM is about using a combination of patent protection and the prohibition on selling services and devices that circumvent DRM to prevent third parties producing hardware or software that allows users to interact with media in any way that the publisher doesn't like.
Remember the Betamax VCR decision? DRM guarantees that something like that will never happen again.
posted by A Thousand Baited Hooks at 5:49 AM on April 25, 2013 [2 favorites]
Without DRM in HTML5, Netflix will keep Silverlight alive, and, to a lesser extent, Google will keep Flash alive. These are arguably technologies that we'd be better served by having them not kept past their use-by date any longer than they already have.
Paradoxically, having it unstandardized may actually be beneficial. If any of the content providers have access to a platform that the others don't, there is an competitive incentive to extend the reach of your platform. If everyone can say: "We use HTML5. What do you mean, your Linux (or Windows XP or Mac OS X [<CURRENT]) PC can't watch it? You should upgrade to Windows 8 or Mac OS X Post-Jobs Edition for the best experience."
posted by sonic meat machine at 5:50 AM on April 25, 2013
Paradoxically, having it unstandardized may actually be beneficial. If any of the content providers have access to a platform that the others don't, there is an competitive incentive to extend the reach of your platform. If everyone can say: "We use HTML5. What do you mean, your Linux (or Windows XP or Mac OS X [<CURRENT]) PC can't watch it? You should upgrade to Windows 8 or Mac OS X Post-Jobs Edition for the best experience."
posted by sonic meat machine at 5:50 AM on April 25, 2013
Without DRM in HTML5, Netflix will keep Silverlight alive, and, to a lesser extent, Google will keep Flash alive. These are arguably technologies that we'd be better served by having them not kept past their use-by date any longer than they already have.
This seems like arming the Taliban to fight the Soviets.
posted by DU at 5:55 AM on April 25, 2013 [6 favorites]
This seems like arming the Taliban to fight the Soviets.
posted by DU at 5:55 AM on April 25, 2013 [6 favorites]
three blind mice: "Isn't that really the argument for leaving it out of HTML5? It just doesn't work."
Not only that, but enough bugs an incompatibilities will creep into a project all on their own. Adding them on purpose borders on pure malice.
posted by Karmakaze at 5:56 AM on April 25, 2013 [2 favorites]
Not only that, but enough bugs an incompatibilities will creep into a project all on their own. Adding them on purpose borders on pure malice.
posted by Karmakaze at 5:56 AM on April 25, 2013 [2 favorites]
sonic meat machine: "Paradoxically, having it unstandardized may actually be beneficial. If any of the content providers have access to a platform that the others don't, there is an competitive incentive to extend the reach of your platform. If everyone can say: "We use HTML5. What do you mean, your Linux (or Windows XP or Mac OS X"
I don't think you understand the meaning of the word "standardized."
posted by schmod at 5:57 AM on April 25, 2013 [1 favorite]
I don't think you understand the meaning of the word "standardized."
posted by schmod at 5:57 AM on April 25, 2013 [1 favorite]
I didn't finish my post, apparently... if everyone can say [that], then there is no competitive inducement to change the status quo.
posted by sonic meat machine at 5:57 AM on April 25, 2013 [2 favorites]
posted by sonic meat machine at 5:57 AM on April 25, 2013 [2 favorites]
I think using DRM as a means of standardizing web content is a devil's bargain. It will come back to haunt users when they realize they have no choices in how they access their media and what they can do with it.
posted by nowhere man at 6:08 AM on April 25, 2013 [2 favorites]
posted by nowhere man at 6:08 AM on April 25, 2013 [2 favorites]
From ars technica: Netflix coming to HTML5 just as soon as the DRM ducks are in a row.
posted by KatlaDragon at 6:08 AM on April 25, 2013
posted by KatlaDragon at 6:08 AM on April 25, 2013
Paradoxically, having it unstandardized may actually be beneficial. If any of the content providers have access to a platform that the others don't, there is an competitive incentive to extend the reach of your platform.
Last time I checked, the proposal for HTML5 wouldn't mean that all content providers would use the same, standard approach to DRM. It would mean that each content provider would be able to require their own special DRM black box (available now for Windows Metro Ultimate and OSX Palm Civet! other systems not supported) for anything on the web. Of course, they can do that now, but they can't claim to be standards-compliant when they do it.
This EFF piece (linked by the original article) does a pretty good job of explaining this, and why it would not be a good thing.
posted by A Thousand Baited Hooks at 6:14 AM on April 25, 2013
Last time I checked, the proposal for HTML5 wouldn't mean that all content providers would use the same, standard approach to DRM. It would mean that each content provider would be able to require their own special DRM black box (available now for Windows Metro Ultimate and OSX Palm Civet! other systems not supported) for anything on the web. Of course, they can do that now, but they can't claim to be standards-compliant when they do it.
This EFF piece (linked by the original article) does a pretty good job of explaining this, and why it would not be a good thing.
posted by A Thousand Baited Hooks at 6:14 AM on April 25, 2013
... and from Wired: BBC supports attempt to sneak DRM into HTML5.
posted by KatlaDragon at 6:14 AM on April 25, 2013
posted by KatlaDragon at 6:14 AM on April 25, 2013
This seems like arming the Taliban to fight the Soviets.
Not sure what this really has to do with what I said, but I do love the diversity of weird analogies that come up in tech threads.
Of course, they can do that now, but they can't claim to be standards-compliant when they do it.
DRM is here, like it or not, so perhaps it may as well be in a standard container to help put the onus back on content distributors to broaden access options. You can't claim you're following standards, if a standards-compliant browser can't open your stuff. Silverlight and Flash put the control in the content owners' hands; HTML5 would shift some — not all, but some — of that control back to the community and to users.
posted by Blazecock Pileon at 6:21 AM on April 25, 2013
Not sure what this really has to do with what I said, but I do love the diversity of weird analogies that come up in tech threads.
Of course, they can do that now, but they can't claim to be standards-compliant when they do it.
DRM is here, like it or not, so perhaps it may as well be in a standard container to help put the onus back on content distributors to broaden access options. You can't claim you're following standards, if a standards-compliant browser can't open your stuff. Silverlight and Flash put the control in the content owners' hands; HTML5 would shift some — not all, but some — of that control back to the community and to users.
posted by Blazecock Pileon at 6:21 AM on April 25, 2013
I was listening to a piece about SnapChat on NPR yesterday, and it occurred to me that "DRM" can describe scenarios more interesting to me than "Hollywood doesn't want you to steal their stuff".
posted by Slothrup at 6:35 AM on April 25, 2013 [3 favorites]
posted by Slothrup at 6:35 AM on April 25, 2013 [3 favorites]
You can't claim you're following standards, if a standards-compliant browser can't open your stuff.
The Encrypted Media Extensions standard doesn't cover the actual DRM; it covers an API that will make it easier for "content decryption modules" (i.e. DRM black boxes) to interact with standards-compliant web browsers. Since the DRM modules themselves are not covered by the standard, there will be no requirement that they be available for browsers on all systems.
Silverlight and Flash put the control in the content owners' hands; HTML5 would shift some — not all, but some — of that control back to the community and to users.
No, it will do the opposite. It will make it much easier for the Silverlights and Flashes of tomorrow to be developed, only there will be more of them and they will be integrated far more deeply into the basic structure of the web.
posted by A Thousand Baited Hooks at 6:45 AM on April 25, 2013 [1 favorite]
The Encrypted Media Extensions standard doesn't cover the actual DRM; it covers an API that will make it easier for "content decryption modules" (i.e. DRM black boxes) to interact with standards-compliant web browsers. Since the DRM modules themselves are not covered by the standard, there will be no requirement that they be available for browsers on all systems.
Silverlight and Flash put the control in the content owners' hands; HTML5 would shift some — not all, but some — of that control back to the community and to users.
No, it will do the opposite. It will make it much easier for the Silverlights and Flashes of tomorrow to be developed, only there will be more of them and they will be integrated far more deeply into the basic structure of the web.
posted by A Thousand Baited Hooks at 6:45 AM on April 25, 2013 [1 favorite]
"If DRM isnt available evil corporations will stop wanting DRM, see the error of their ways and just produce content for free without expectation of payment" seems a vastly unlikely proposition. This is a bunch of Sticking It To The Man bullcrap or a late breaking argument for flash.
posted by Artw at 7:02 AM on April 25, 2013
posted by Artw at 7:02 AM on April 25, 2013
Money speaks for money;
The devil for his own...
If the web's purpose is to democratize information, then it needs to maintain an anti-DRM stance. DRM is strictly concerned with maintaining advantage, which is the antithesis of increasing availability of information. Private interests will, and should, push for things that benefit them, but they have to make their OWN arguments and find their own solutions. HTML capitulating to them at the most basic level is the wrong move.
posted by Benny Andajetz at 7:03 AM on April 25, 2013 [5 favorites]
The devil for his own...
If the web's purpose is to democratize information, then it needs to maintain an anti-DRM stance. DRM is strictly concerned with maintaining advantage, which is the antithesis of increasing availability of information. Private interests will, and should, push for things that benefit them, but they have to make their OWN arguments and find their own solutions. HTML capitulating to them at the most basic level is the wrong move.
posted by Benny Andajetz at 7:03 AM on April 25, 2013 [5 favorites]
I don't see the big deal. Web and broswer developers will do what they always do in these cases -- ignore the standards and do what they want, then blame the user for not using version X with widget Y.
So, if there's DRM in HTML 5, they'll ignore it and hack around it. If there isn't, content providers will build plug-ins that have it and say "use me, or no content. Suck it, DRM haters."
Seriously. The Internet treats standards as damage and hacks around them. And as long as the user base gets the shiny, they don't care.
posted by eriko at 7:48 AM on April 25, 2013 [1 favorite]
So, if there's DRM in HTML 5, they'll ignore it and hack around it. If there isn't, content providers will build plug-ins that have it and say "use me, or no content. Suck it, DRM haters."
Seriously. The Internet treats standards as damage and hacks around them. And as long as the user base gets the shiny, they don't care.
posted by eriko at 7:48 AM on April 25, 2013 [1 favorite]
eriko: "So, if there's DRM in HTML 5, they'll ignore it and hack around it. If there isn't, content providers will build plug-ins that have it and say "use me, or no content. Suck it, DRM haters."
Seriously. The Internet treats standards as damage and hacks around them. And as long as the user base gets the shiny, they don't care."
A lot of this has to do with the petty politics and glacial pace that the W3C takes while ratifying standards. They make congress look like a polite and efficient bunch of folks.
posted by schmod at 8:19 AM on April 25, 2013
Seriously. The Internet treats standards as damage and hacks around them. And as long as the user base gets the shiny, they don't care."
A lot of this has to do with the petty politics and glacial pace that the W3C takes while ratifying standards. They make congress look like a polite and efficient bunch of folks.
posted by schmod at 8:19 AM on April 25, 2013
Not sure what this really has to do with what I said, but I do love the diversity of weird analogies that come up in tech threads.
It means you are solving a problem today by introducing the same problem (but probably in this case worse) a few years down the road. It's an obvious Operation Foot-Bullet. And it's stupid because we should be solving new problems not old problems II: electric bugaloo.
posted by Mitheral at 8:31 AM on April 25, 2013
It means you are solving a problem today by introducing the same problem (but probably in this case worse) a few years down the road. It's an obvious Operation Foot-Bullet. And it's stupid because we should be solving new problems not old problems II: electric bugaloo.
posted by Mitheral at 8:31 AM on April 25, 2013
schmod - The semantics of HTML5 video are lost when you need to lean heavily on browser capability testing, and transcode your videos into a thousand different formats (did I mention that CDN-backed storage is expensive?). We still end up using a ton of Flash, because the benefits of HTML5 video don't yet outweigh the costs for non-iOS users. (iOS itself can also be a huge pain, as it doesn't provide a complete implementation of the HTML5 video API).
Trying to meet FCC compliance for broadcast tv to caption all web videos is a ridiculous format hell nightmare too. I've seen a lot of people just throw their hands up in exasperation and burn open captions right into the video, which is just plain ugly but increasingly preferable as a Gordian Knot solution. There are almost no developers working on open source solutions for this and it's expensive enterprise software (that relies on other expensive enterprise software, that relies on even more...) all the way to preserve the closed captioning from transport stream to captured file to clips to way too many formats on the CDN. Most developers of capture software and non-linear editors decided "ehhhh fuck it, you can manually add your preexisting captions back in at the end in a half dozen subtitle formats and bottleneck your entire workflow, if it's that important." Like Adobe Premiere's lovely approach: "well, you can run captions out to a preview monitor or tape, but embedding them in a file (when the file type already clearly supports that)? Ha! Why would you want to do that?"
So yeah, the video format hell of HTML5 is, imo, actively hindering a big portion of content from receiving the much-touted accessibility features HTML5 is known for, because nobody is even bothering to create tools that can do the job correctly for the ridiculous collection of video formats we're stuck with. And it's a ridiculous challenge to learn to code solutions yourself considering that most of the rest of the software involved is locked down.
posted by jason_steakums at 8:46 AM on April 25, 2013 [3 favorites]
Trying to meet FCC compliance for broadcast tv to caption all web videos is a ridiculous format hell nightmare too. I've seen a lot of people just throw their hands up in exasperation and burn open captions right into the video, which is just plain ugly but increasingly preferable as a Gordian Knot solution. There are almost no developers working on open source solutions for this and it's expensive enterprise software (that relies on other expensive enterprise software, that relies on even more...) all the way to preserve the closed captioning from transport stream to captured file to clips to way too many formats on the CDN. Most developers of capture software and non-linear editors decided "ehhhh fuck it, you can manually add your preexisting captions back in at the end in a half dozen subtitle formats and bottleneck your entire workflow, if it's that important." Like Adobe Premiere's lovely approach: "well, you can run captions out to a preview monitor or tape, but embedding them in a file (when the file type already clearly supports that)? Ha! Why would you want to do that?"
So yeah, the video format hell of HTML5 is, imo, actively hindering a big portion of content from receiving the much-touted accessibility features HTML5 is known for, because nobody is even bothering to create tools that can do the job correctly for the ridiculous collection of video formats we're stuck with. And it's a ridiculous challenge to learn to code solutions yourself considering that most of the rest of the software involved is locked down.
posted by jason_steakums at 8:46 AM on April 25, 2013 [3 favorites]
Oh, and after all that there's no standard way to display the damn captions without involving proprietary embedded players. You're welcome, deaf users! Sincerely, the W3C.
posted by jason_steakums at 8:49 AM on April 25, 2013 [1 favorite]
posted by jason_steakums at 8:49 AM on April 25, 2013 [1 favorite]
If the goal of the Content Decryption Module is to do its job in the most obfuscated manner possible, couldn't they just have used CSS?
posted by RobotVoodooPower at 9:13 AM on April 25, 2013
posted by RobotVoodooPower at 9:13 AM on April 25, 2013
This seems like arming the Taliban to fight the Soviets.
Isn't it more like building skipjack into your encryption chips?
posted by Obscure Reference at 9:33 AM on April 25, 2013
Isn't it more like building skipjack into your encryption chips?
posted by Obscure Reference at 9:33 AM on April 25, 2013
Does DRM also cause autism by any chance?
whoa look at all this bad faith
posted by This, of course, alludes to you at 10:54 AM on April 25, 2013
jason_steakums: "So yeah, the video format hell of HTML5 is, imo, actively hindering a big portion of content from receiving the much-touted accessibility features HTML5 is known for, because nobody is even bothering to create tools that can do the job correctly for the ridiculous collection of video formats we're stuck with. And it's a ridiculous challenge to learn to code solutions yourself considering that most of the rest of the software involved is locked down."
Oh God. You've been down this rabbit hole too. I'm so, so sorry.
There are a few groups pushing to make this less horrible (YouTube made a big push for it a year or two ago, but it seems to have gone nowhere), but right now things suck badly.
As bad as captioning prerecorded video is, the workflow for captioning live content is so, so, so much worse. For starters, there's no HTML5 standard for live video. MPEG-DASH is coming, but it's not ready just yet, and will presumably be subject to the same sort of insane standard fragmentation that has plagued HTML 5. We won't see good browser adoption for a long, long time (and Apple may never support it, as they have their own competing standard, and you know how Apple is about that).
As far as captioning goes, Adobe recently began supporting live captioning through their server product if you can get the captions encoded into your video stream. Good luck on actually doing this, though, as the only devices that support it are $10,000+ hardware encoders running proprietary software. iOS also requires captions to be encoded in an incredibly specific manner that almost nobody else supports. If you want to roll your own captioning solution (ie. streaming them over websockets), you can't; iOS only allows HTML5 videos to be played in a fullscreen window, and doesn't allow you to overlay anything on top of the video. The iOS implementation of the HTML5 video API is hilariously incomplete, despite the OS's reputation as HTML5 Video's poster-child.
When we did the webcast of the 2012 Inauguration, we ended up encoding and serving about 12 different streams, and just burned open captions into one of the feeds -- it was *so* much easier than any of our other options, and had the benefit of actually working. Those 12 streams were for a single bitrate, and we never managed to properly support Android, given that most Android browsers won't handle live streaming (and a few will crash if you try to sniff for streaming capabilities).
I can handle transitioning from an old technology to a new technology (the RealMedia to Flash transition was a bit painful for our users, but was fairly straightforward and offered huge benefits). Transitioning from Flash to the HTML5 cluster*$ actually makes me want to forgive all of Flash's horrible shortcomings, especially given that HTML5 video standard is so woefully incomplete (and not even completely implemented in most browsers, at that). Things like the MediaSource API will take tiny steps toward fixing the standard's shortcomings, but the implementation of the technology is still half-baked in all current browsers.
posted by schmod at 10:54 AM on April 25, 2013 [4 favorites]
Oh God. You've been down this rabbit hole too. I'm so, so sorry.
There are a few groups pushing to make this less horrible (YouTube made a big push for it a year or two ago, but it seems to have gone nowhere), but right now things suck badly.
As bad as captioning prerecorded video is, the workflow for captioning live content is so, so, so much worse. For starters, there's no HTML5 standard for live video. MPEG-DASH is coming, but it's not ready just yet, and will presumably be subject to the same sort of insane standard fragmentation that has plagued HTML 5. We won't see good browser adoption for a long, long time (and Apple may never support it, as they have their own competing standard, and you know how Apple is about that).
As far as captioning goes, Adobe recently began supporting live captioning through their server product if you can get the captions encoded into your video stream. Good luck on actually doing this, though, as the only devices that support it are $10,000+ hardware encoders running proprietary software. iOS also requires captions to be encoded in an incredibly specific manner that almost nobody else supports. If you want to roll your own captioning solution (ie. streaming them over websockets), you can't; iOS only allows HTML5 videos to be played in a fullscreen window, and doesn't allow you to overlay anything on top of the video. The iOS implementation of the HTML5 video API is hilariously incomplete, despite the OS's reputation as HTML5 Video's poster-child.
When we did the webcast of the 2012 Inauguration, we ended up encoding and serving about 12 different streams, and just burned open captions into one of the feeds -- it was *so* much easier than any of our other options, and had the benefit of actually working. Those 12 streams were for a single bitrate, and we never managed to properly support Android, given that most Android browsers won't handle live streaming (and a few will crash if you try to sniff for streaming capabilities).
I can handle transitioning from an old technology to a new technology (the RealMedia to Flash transition was a bit painful for our users, but was fairly straightforward and offered huge benefits). Transitioning from Flash to the HTML5 cluster*$ actually makes me want to forgive all of Flash's horrible shortcomings, especially given that HTML5 video standard is so woefully incomplete (and not even completely implemented in most browsers, at that). Things like the MediaSource API will take tiny steps toward fixing the standard's shortcomings, but the implementation of the technology is still half-baked in all current browsers.
posted by schmod at 10:54 AM on April 25, 2013 [4 favorites]
> DRM is not about protecting copyright.
Why do people say stupid things like that that are patently false?
I have a small software business. We sell music software. If we didn't copy-protect it, we'd sell none at all. People have inevitably broken each copy-protection scheme we have, and we can see it because we see the sales take a dive literally the next day after the cracked version hits the boards - but the copy-protection does do what we want, which is to prevent casual copying.
Sure, DRM is used for other purposes too, but there are all sorts of people like me who do it entirely to protect their copyright.
This argument that "people just contribute of their own free will" is patently ridiculous, by the way. People will give free money to a small number of high-profile organizations where they have personalized the people involved - everyone else is just a "face in the crowd" to them and they just don't care. For the vast majority of small developers who rely on "contributionware", less than 1% of the users contribute anything at all...
posted by lupus_yonderboy at 11:17 AM on April 25, 2013 [1 favorite]
Why do people say stupid things like that that are patently false?
I have a small software business. We sell music software. If we didn't copy-protect it, we'd sell none at all. People have inevitably broken each copy-protection scheme we have, and we can see it because we see the sales take a dive literally the next day after the cracked version hits the boards - but the copy-protection does do what we want, which is to prevent casual copying.
Sure, DRM is used for other purposes too, but there are all sorts of people like me who do it entirely to protect their copyright.
This argument that "people just contribute of their own free will" is patently ridiculous, by the way. People will give free money to a small number of high-profile organizations where they have personalized the people involved - everyone else is just a "face in the crowd" to them and they just don't care. For the vast majority of small developers who rely on "contributionware", less than 1% of the users contribute anything at all...
posted by lupus_yonderboy at 11:17 AM on April 25, 2013 [1 favorite]
> but since it is easily cracked and can be worked around, it is largely ineffective and irrelevant.
You can always tell people who haven't ever tried to sell software or other digital media... ;-)
Consider another analogy.
"Locks are easily picked (or bumped) and doors are easily forced, so locking your front door is largely ineffective and irrelevant."
I got broken into twice in one apartment - the second time they used a car jack to get through the door! But that didn't stop me from locking the door when I went out.
Nothing will prevent piracy. But you can certainly discourage casual piracy - and, in my business anyway, that's the difference between making money and not.
posted by lupus_yonderboy at 11:22 AM on April 25, 2013 [2 favorites]
You can always tell people who haven't ever tried to sell software or other digital media... ;-)
Consider another analogy.
"Locks are easily picked (or bumped) and doors are easily forced, so locking your front door is largely ineffective and irrelevant."
I got broken into twice in one apartment - the second time they used a car jack to get through the door! But that didn't stop me from locking the door when I went out.
Nothing will prevent piracy. But you can certainly discourage casual piracy - and, in my business anyway, that's the difference between making money and not.
posted by lupus_yonderboy at 11:22 AM on April 25, 2013 [2 favorites]
schmod - As bad as captioning prerecorded video is, the workflow for captioning live content is so, so, so much worse.
I'm wrestling with both right now on a small-mid market station's budget, it's lovely. CPC seems to be the only game in town for workflow solutions using our Matrox MXO2's for capturing, and even that's extremely lacking. I love how Matrox is all "we totally preserve closed captions in the VANC! Good luck keeping 'em or getting them out, but hey, we'll let you run them straight through to tape! Maybe you should talk to CPC..." I can't even get the otherwise excellent CCExtractor to pick up captions through that thing.
I am absolutely eager to get closed captioning on all web video possible, FCC or no. Accessibility is always worth it. But the last thing anybody needed was the FCC wading into the web video standards mess out of the blue with a list of orders, totally oblivious to the reality of the situation. A smart and feasible move would be government funding for an open source standard project for captioning and presenting it to the W3C and browser & OS developers on a platter, but the FCC is not made of smart moves, especially when it comes to the internet.
posted by jason_steakums at 11:49 AM on April 25, 2013
I'm wrestling with both right now on a small-mid market station's budget, it's lovely. CPC seems to be the only game in town for workflow solutions using our Matrox MXO2's for capturing, and even that's extremely lacking. I love how Matrox is all "we totally preserve closed captions in the VANC! Good luck keeping 'em or getting them out, but hey, we'll let you run them straight through to tape! Maybe you should talk to CPC..." I can't even get the otherwise excellent CCExtractor to pick up captions through that thing.
I am absolutely eager to get closed captioning on all web video possible, FCC or no. Accessibility is always worth it. But the last thing anybody needed was the FCC wading into the web video standards mess out of the blue with a list of orders, totally oblivious to the reality of the situation. A smart and feasible move would be government funding for an open source standard project for captioning and presenting it to the W3C and browser & OS developers on a platter, but the FCC is not made of smart moves, especially when it comes to the internet.
posted by jason_steakums at 11:49 AM on April 25, 2013
Without DRM in HTML5, Netflix will keep Silverlight alive, and, to a lesser extent, Google will keep Flash alive. These are arguably technologies that we'd be better served by having them not kept past their use-by date any longer than they already have.
Putting DRM into HTML5 doesn't help, though. Think about it; all that happens is that you replace a handful of incompatible, proprietary, insecure, closed-source, infrequently-updated, binary blobs (Flash and Silverlight plugins) with a handful of incompatible, proprietary, insecure, closed-source, infrequently-updated, binary blobs (DRM implementations). Net progress: zero. It's nice to imagine that the DRM plugins will all be well-written, carefully-engineered, reliable, secure pieces of software, but unless you have some argument why this time will be different you're just fooling yourself.
posted by hattifattener at 12:48 PM on April 25, 2013
Putting DRM into HTML5 doesn't help, though. Think about it; all that happens is that you replace a handful of incompatible, proprietary, insecure, closed-source, infrequently-updated, binary blobs (Flash and Silverlight plugins) with a handful of incompatible, proprietary, insecure, closed-source, infrequently-updated, binary blobs (DRM implementations). Net progress: zero. It's nice to imagine that the DRM plugins will all be well-written, carefully-engineered, reliable, secure pieces of software, but unless you have some argument why this time will be different you're just fooling yourself.
posted by hattifattener at 12:48 PM on April 25, 2013
Then should Multimedia be implemented outside of plugins at all?
posted by Artw at 12:52 PM on April 25, 2013
posted by Artw at 12:52 PM on April 25, 2013
You're confusing multimedia with DRM, Artw. They're nearly orthogonal things (and I expect you know this).
posted by hattifattener at 1:26 PM on April 25, 2013
posted by hattifattener at 1:26 PM on April 25, 2013
If the argument for eliminating plugins is that browsers should be able to handle all the content that plugins used to handle then that includes DRMed content. Otherwise it's only a partial solution and plugins need to stay, and if plugins are staying then why not put all the multimedia in there?
posted by Artw at 1:32 PM on April 25, 2013
posted by Artw at 1:32 PM on April 25, 2013
International coalition of Internet freedom organizations urges W3C to reject Encrypted Media Extensions, a proposal to build Digital Restrictions Management into the Web
Defective by Design
posted by homunculus at 2:15 PM on April 26, 2013
Defective by Design
posted by homunculus at 2:15 PM on April 26, 2013
'The Single Most Valuable Document In The History Of The World Wide Web'
posted by homunculus at 3:31 PM on May 1, 2013
posted by homunculus at 3:31 PM on May 1, 2013
Ars Technica:
DRM in HTML5 is a victory for the open Web, not a defeatposted by XMLicious at 6:38 PM on May 12, 2013
W3C's decision to publish a DRM framework will keep the Web relevant and useful.
« Older "Oh my God, it's orcas attacking sperm whales." | Photos of large and non fatal mine collapse Newer »
This thread has been archived and is closed to new comments
Isn't that really the argument for leaving it out of HTML5? It just doesn't work.
posted by three blind mice at 3:48 AM on April 25, 2013