5 ms·
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture. Second, without EME, the s
by om2 9y ago
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture.
Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.)
This has some important advantages:
* Web content authors can build video players using the same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video. No need to learn a whole different plugin environment for this case.
* Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface.
* The browser's built-in playback is generally much more power-efficient, meaning more video viewing time on battery for your Netflix/Amazon/Hulu/etc video content.
* Even if the DRM scheme is some form of plugin, it needs far fewer capabilities than a plugin that has full video playback, live streaming, a scripting environment, etc. So it's less of a security risk
* Flash and Silverlight especially were common sources of critical security vulnerabilities and they'll be out of the picture.
* With approaches like MPEG Common Encryption[1], a single encrypted media resource can be used with multiple DRM schemes. This helps content hosts save on storage, and it makes it materially easier for new browsers to enter the market, since they don't have to ask content providers to host a whole separate copy of the video.
The continuing existence of DRM is admittedly not ideal. But supporting it in the browser instead of solely in the separate world of plugins has major user and developer benefits, as described above.
[1] https://en.wikipedia.org/wiki/MPEG_Common_Encryption https://en.wikipedia.org/wiki/MPEG_Common_Encryption
- chii 9y ago> same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with their wallet, and use the non-DRM version (and avoid the DRM version). If making DRM video easy to play for end users is the goal, then yes, web-DRM is doing it. But it will make DRM more prevailent, as end users will have no reason to try avoid DRM, thus, making web less open.
- agentdrtran 9y ago> i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. so you want to make stuff like netflix as much of a PITA as possible? why? why be this vindictive?
- izacus 9y agoNo, we want to make Netflix pushing DRM as PITA as possible. Video streaming without DRM works just fine. (And please don't come back with "Netflix has no choice BS", they're happily doing all the nasty DRM crap for their own production as well.)
- hopeaboutthis 9y agoi agree with netflix, straight up. they invest quite a lot in infrastructure and production to provide these videos, and making it simpler for average folks to get their protected videos in a profitable manner is a win for everyone except idealistic pirates. i don't get why i'd care about the needs of the people who want to ruin a fertile ecosystem for some abstract principle.
- CuriousSkeptic 9y agoWith DRM+streaming as default the world will be relying on rights holders and streaming services to preserve an archive of cultural works. A situation that invariably will result in loss of a lot of those works once they stop caring or go out of business. Consider f.ex. the situation with the missing Dr. Who episodes. BBC is still hopping it can recover copies from the public. Had they'd been aired with DRM at the time they would be lost without hope, now at least there is hope.
- josteink 9y ago> you want to make stuff like netflix as much of a PITA as possible? Not op but yes, using DRM in a browser should be hard. Netflix should just make a native app, like everyone else who needs drm do. This clearly scopes what is open and webby and what is closed and DRMy. Nobody has issues installing Spotify to stream music. What makes Netflix special?
- Buge 9y ago>Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface. Nope. For any effective DRM (aka what all browsers use) the video codec decoding happens inside the DRM module. Otherwise anyone could just patch the open source browser and grab the decrypted compressed content coming out of the module. In reality, they can only grab the decrypted decompressed content.
- om2 9y agoIn the browser I'm most familiar with the internals of: most of the playback logic is done by shared software, and the decode of the video track is done in hardware in the common case, for both encrypted and unencrypted videos. There are some forks in the path but a lot of commonality.
- sametmax 9y agoPlus having a single blob responsible for, and only for, the DRM part means that hackers will have an easier time crack that, instead of a whole player. So we should get workarounds quite quickly.
- makomk 9y agoIf you read the EME spec, unless they've changed you're not guaranteed to be able to overlay anything over the EME-provided video rectangle using HTML. The only cross-platform approach is to treat it as an opaque, untouchable area that does not interact with the HTML side of things in any way, like the bad old early days of plugins. Also, at least on Android the playback chain goes through TrustZone code that's effectively running at a higher privilege level than the kernel.