It’s funny how this situation was predicted with 100% accuracy by myself and others arguing against the EME standard, back when the W3C was pretending to consult with the community on the issue.
The author does address this:
My attitude may be slightly defeatist, but if the EME API didn’t exist, we probably wouldn’t be able to watch Netflix on Asahi Linux at all, at least, not without violating the DMCA.
… but I’d argue that that level of defeatism is a bug in our industry, rather than a feature ;)
There never was an argument “for” EME, but there was an argument that of the alternatives obtainable in the actually-existing world we inhabit, EME was the least repugnant.
The TV and movie industries were never going to just go “huh, you’re right, let’s stop using DRM”. And the browser vendors were never going to just go “well, the principle of being anti-DRM is so important to us that we will gladly anger our users by cutting off their favorite streaming services”.
The DRM was always going to happen. It was only a question of how. And the alternative to EME was Flash or some equivalent of it and a corresponding even worse impact on security, observability, etc.
Besides, anyone who truly is willing to take the stand on principle that they demand of everyone else wouldn’t have a Netflix subscription in the first place and wouldn’t want to watch any content produced by a DRM-using entity.
The TV and movie industries were never going to just go “huh, you’re right, let’s stop using DRM”
That’s a strong assertion given that:
BBC iPlayer implemented an entirely separate iOS service that sent unencrypted MP4 video when it was the only way of reaching users on that platform.
The big 4 record labels started allowing Amazon to sell their music with no DRM because it was the only way of reaching most customers and breaking Apple’s monopoly.
DRM is great for giving a monopoly to a distribution channel, it’s not great for the copyright owners, and there’s a good chance that they’d have realised this (though, in a lot of cases, they have and have decided to be their own channel).
I’m not sure that BBC iPlayer is the most representative example, due to their public service remit; almost all of their content goes over the air on DVB-T2 unencrypted, in 1080p, so the DRM is really just a box ticking exercise to add some friction to violating their licence terms, and hasn’t even been applied to web streams since they ditched Flash (see get_iplayer which has been around for at least a decade without BBC interference.)
(In the same way as when they launched on iOS, though, they do lock higher res/bitrate – still unencrypted – streams down by requiring mTLS authentication using an approved TV’s client cert.)
I agree with your general point, though - IMO, the number of people who currently subscribe to Netflix etc. who would switch to torrenting if Netflix removed DRM, would be negligible.
I wrote something at the time that explored the then-current idea that DRM was going to “just” fade away over time.
The crux of it is that I agreed with this:
The big 4 record labels started allowing Amazon to sell their music with no DRM because it was the only way of reaching most customers and breaking Apple’s monopoly.
But did not agree that it would necessarily transfer to video content, for reasons explained in the post. Put simply: the fact that Amazon’s music had to work “out of the box” on Apple’s hardware meant it couldn’t be DRM’d. Apple devices like the iPod would not have supported an alternative DRM scheme, and Apple likely would not have opened up of its own DRM scheme for Amazon’s use.
This is why the only realistic way for publishers to break Amazon’s Kindle ebook monopoly would also require going DRM-free, since the Kindle hardware would almost certainly not aid and abet a competitor. But instead the publishers went to Apple and tried to set up an alternative ebook universe, and it hasn’t really made a serious dent in Amazon’s hold on the market.
Video content never has had the kind of consolidated single entity with broad catalog access and huge market share that music (Apple, at the time) and ebooks (Amazon) had. So TV/film studios have never felt the need to try to prop up a competitor in the first place, let alone a need to go DRM-free to help the competitor. And if anything, the video landscape is getting more fractured over time – Netflix had a brief moment where it might have consolidated, but studios started pulling their stuff and setting up their own alternative services.
So I didn’t and don’t see how DRM on video content would naturally go away over time, or how any entity has the necessary market pressure to make it go away.
(that ten-year-old post did not anticipate that music would swing back from paying for downloads of particular albums/tracks to paying a subscription fee for all-you-can-eat streaming, which also undid a lot of the opening up of music during the Apple-versus-Amazon era, but that’s why I’m not a futurist)
There’s not a lot of point in rehashing this argument - versions of it were made, on both sides, at length (and sometimes with no small amount of vitriol) at the time.
But I’d sum up my counterargument as: EME has given us nothing. It adds nothing to security or observability, ruinously compromised the values of the Web and the W3C, and drove the coffin nail into the idea of an open Web, at least as far as standards are concerned.
How much more observable is the Widevine binary than, say, any other arbitrary binary blob? In the absence of that observability, how can you claim it’s more secure, without invoking security through obscurity? Etc. etc.
Chrome ran Flash in a sandbox from 2012 onwards, with their new PPAPI plugin framework (later used in other Chromium browsers); Firefox also started sandboxing NPAPI plugins in ~2015 afaict, I remember it being a big deal at the time. Not sure how well the latter worked in practice, though.
Not sure when Firefox sandboxed plugins by default, but there was a wrapper that ran them in a separate process, optionally with sandboxing, from the early 2000s, before Firefox was separated out from the Mozilla suite. This was originally used to run 32-bit plugins on 64-bit Mozilla, but was also used to run Linux plugins in ABI compat layers on other operating systems (*BSD, Solaris).
Do you think it worked out well, in hindsight? I don’t believe it did, but I’m in a different industry.
Through Widevine, Google now has a stranglehold on DRM enabled media; refuses to allow its use in most open source projects; and refuses to support OSs like FreeBSD.
Also, I’m not seeing any signs of a decline in the use of DRM on the Web, in fact, having a defacto standard in Widevine and an actual standard in EME seems to have cemented DRM in place.
I already said what I think in my original comment:
There never was an argument “for” EME, but there was an argument that of the alternatives obtainable in the actually-existing world we inhabit, EME was the least repugnant.
Way too many people on the internet hear “this was the least bad option” and want to turn it into “oh, so you think that’s good, do you?” I never said it was good. I said itg was the least bad option. I still think it is the least bad option, because I remember what the applet/plugin world was like. Having the DRM thing be, effectively, something that the browser interacts with in a vaguely codec-like way is indeed less bad than what the status quo ante HTML5 looked like.
Also, I’m not seeing any signs of a decline in the use of DRM on the Web
I never thought that taking any stance with respect to EME would cause DRM to decline or disappear. I laid out in that post the types of factors that I thought were capable of knocking out DRM, and none of those factors ever arose. Nor would a hard-line anti-EME stance by Mozilla have caused such factors to arise.
I never said it was good. I said it was the least bad option.
Understood; I’m not trying to make it sound like you supported DRM or EME, at least beyond a least-worst position.
The point I was trying to make is that EME made things worse by normalising a mechanism for DRM. Coming back to my original post: we now have a de-facto standard for DRM that is controlled by Google, weaponised against the open source community, and perceived as normal by an entire generation of Web devs who’ve grown up with it.
So I guess I chose the wrong word for “managed to make a proprietary software run on a platform against the wishes of its owners (who will close any issues requesting such support) and despite any hurdles put up”, I’m not good at English.
This makes me think again about having some sort of service/container/sandbox type thing that can do something involving shm or something to make it work on a foreign platform.
Something like: [Browser]<->[fake Widevine shim]<->[x86_64 binary running in qemu-user that links against real Widevine]
Has anyone tried this? Is there a technical reason it wouldn’t work that I’m not thinking of?
This is more or less what PipeLight did. It ran Windows plugins under WINE (which could, in turn, run under QEMU user mode) and exposed them to other platforms. I was never able to get it to play Netflix for more than about 30 seconds though.
Yeah. I think that was for Silverlight, though, which was always a bit of a bear to run in WINE because you had to have just the right versions of Mono and WINE together.
I’m surprised that I can’t find anyone who has tried this for Widevine yet…
I also recently switched to an Asahi Linux Kernel on an m1 mini (though with Debian instead of Arch). Spotify not working was a major bummer until I found spotifyd which is delightful and great.
Of course, getting widevine support is also great, but yeah, just in case anyone else is in the author’s shoes but also doesn’t care for widevine in general, spotifyd (with some controller like spt or something) works without widevine.
Unfortunately, if we ever want the “year of the linux desktop” we have to compromise, continually, on matters of openness - many end users don’t care about the purity of their freedom, they care about being able to do the task they want to do. If they can’t do it, they won’t make the switch.
From a technical standpoint, this was fascinating, and almost straightforward. From a commercial standpoint, though, I’d have to ask if the solution isn’t for Google (as, if I’m understanding correctly, the upstream for Widevine) to do more than simply pay lip-service to the concept of driving Linux development?
Realistically, I’m sure they can afford enough Pis (even at today’s prices) to build some packages for aarch64. And maybe, one day, ppc64 ;)
It’s funny how this situation was predicted with 100% accuracy by myself and others arguing against the EME standard, back when the W3C was pretending to consult with the community on the issue.
The author does address this:
… but I’d argue that that level of defeatism is a bug in our industry, rather than a feature ;)
There never was an argument “for” EME, but there was an argument that of the alternatives obtainable in the actually-existing world we inhabit, EME was the least repugnant.
The TV and movie industries were never going to just go “huh, you’re right, let’s stop using DRM”. And the browser vendors were never going to just go “well, the principle of being anti-DRM is so important to us that we will gladly anger our users by cutting off their favorite streaming services”.
The DRM was always going to happen. It was only a question of how. And the alternative to EME was Flash or some equivalent of it and a corresponding even worse impact on security, observability, etc.
Besides, anyone who truly is willing to take the stand on principle that they demand of everyone else wouldn’t have a Netflix subscription in the first place and wouldn’t want to watch any content produced by a DRM-using entity.
That’s a strong assertion given that:
DRM is great for giving a monopoly to a distribution channel, it’s not great for the copyright owners, and there’s a good chance that they’d have realised this (though, in a lot of cases, they have and have decided to be their own channel).
I’m not sure that BBC iPlayer is the most representative example, due to their public service remit; almost all of their content goes over the air on DVB-T2 unencrypted, in 1080p, so the DRM is really just a box ticking exercise to add some friction to violating their licence terms, and hasn’t even been applied to web streams since they ditched Flash (see get_iplayer which has been around for at least a decade without BBC interference.)
(In the same way as when they launched on iOS, though, they do lock higher res/bitrate – still unencrypted – streams down by requiring mTLS authentication using an approved TV’s client cert.)
I agree with your general point, though - IMO, the number of people who currently subscribe to Netflix etc. who would switch to torrenting if Netflix removed DRM, would be negligible.
Especially given the fact that most of that content (even the netflix-exclusive stuff) is already available via torrent.
Especially the streaming-exclusive stuff, honestly, since it’s easiest to get
I wrote something at the time that explored the then-current idea that DRM was going to “just” fade away over time.
The crux of it is that I agreed with this:
But did not agree that it would necessarily transfer to video content, for reasons explained in the post. Put simply: the fact that Amazon’s music had to work “out of the box” on Apple’s hardware meant it couldn’t be DRM’d. Apple devices like the iPod would not have supported an alternative DRM scheme, and Apple likely would not have opened up of its own DRM scheme for Amazon’s use.
This is why the only realistic way for publishers to break Amazon’s Kindle ebook monopoly would also require going DRM-free, since the Kindle hardware would almost certainly not aid and abet a competitor. But instead the publishers went to Apple and tried to set up an alternative ebook universe, and it hasn’t really made a serious dent in Amazon’s hold on the market.
Video content never has had the kind of consolidated single entity with broad catalog access and huge market share that music (Apple, at the time) and ebooks (Amazon) had. So TV/film studios have never felt the need to try to prop up a competitor in the first place, let alone a need to go DRM-free to help the competitor. And if anything, the video landscape is getting more fractured over time – Netflix had a brief moment where it might have consolidated, but studios started pulling their stuff and setting up their own alternative services.
So I didn’t and don’t see how DRM on video content would naturally go away over time, or how any entity has the necessary market pressure to make it go away.
(that ten-year-old post did not anticipate that music would swing back from paying for downloads of particular albums/tracks to paying a subscription fee for all-you-can-eat streaming, which also undid a lot of the opening up of music during the Apple-versus-Amazon era, but that’s why I’m not a futurist)
There’s not a lot of point in rehashing this argument - versions of it were made, on both sides, at length (and sometimes with no small amount of vitriol) at the time.
But I’d sum up my counterargument as: EME has given us nothing. It adds nothing to security or observability, ruinously compromised the values of the Web and the W3C, and drove the coffin nail into the idea of an open Web, at least as far as standards are concerned.
How much more observable is the Widevine binary than, say, any other arbitrary binary blob? In the absence of that observability, how can you claim it’s more secure, without invoking security through obscurity? Etc. etc.
IIRC, Firefox runs Widevine under a tight sandbox? So that might make a difference - not sure how sandboxed Flash/Silverlight/etc were in their heyday
Chrome ran Flash in a sandbox from 2012 onwards, with their new PPAPI plugin framework (later used in other Chromium browsers); Firefox also started sandboxing NPAPI plugins in ~2015 afaict, I remember it being a big deal at the time. Not sure how well the latter worked in practice, though.
Not sure when Firefox sandboxed plugins by default, but there was a wrapper that ran them in a separate process, optionally with sandboxing, from the early 2000s, before Firefox was separated out from the Mozilla suite. This was originally used to run 32-bit plugins on 64-bit Mozilla, but was also used to run Linux plugins in ABI compat layers on other operating systems (*BSD, Solaris).
I linked it already in a reply to someone else, but I still mostly stand by what I wrote at the time.
Do you think it worked out well, in hindsight? I don’t believe it did, but I’m in a different industry.
Through Widevine, Google now has a stranglehold on DRM enabled media; refuses to allow its use in most open source projects; and refuses to support OSs like FreeBSD.
Also, I’m not seeing any signs of a decline in the use of DRM on the Web, in fact, having a defacto standard in Widevine and an actual standard in EME seems to have cemented DRM in place.
I already said what I think in my original comment:
Way too many people on the internet hear “this was the least bad option” and want to turn it into “oh, so you think that’s good, do you?” I never said it was good. I said itg was the least bad option. I still think it is the least bad option, because I remember what the applet/plugin world was like. Having the DRM thing be, effectively, something that the browser interacts with in a vaguely codec-like way is indeed less bad than what the status quo ante HTML5 looked like.
I never thought that taking any stance with respect to EME would cause DRM to decline or disappear. I laid out in that post the types of factors that I thought were capable of knocking out DRM, and none of those factors ever arose. Nor would a hard-line anti-EME stance by Mozilla have caused such factors to arise.
Understood; I’m not trying to make it sound like you supported DRM or EME, at least beyond a least-worst position.
The point I was trying to make is that EME made things worse by normalising a mechanism for DRM. Coming back to my original post: we now have a de-facto standard for DRM that is controlled by Google, weaponised against the open source community, and perceived as normal by an entire generation of Web devs who’ve grown up with it.
What a wonderful deep dive article! I love reading these!
Very cool that they managed to subvert it. I only had the glibc issue, but for me bittorrent was the easier option.
Wait, no, the fact that they didn’t actually subvert it at all was the entire point of doing this
So I guess I chose the wrong word for “managed to make a proprietary software run on a platform against the wishes of its owners (who will close any issues requesting such support) and despite any hurdles put up”, I’m not good at English.
This makes me think again about having some sort of service/container/sandbox type thing that can do something involving shm or something to make it work on a foreign platform.
Something like: [Browser]<->[fake Widevine shim]<->[x86_64 binary running in qemu-user that links against real Widevine]
Has anyone tried this? Is there a technical reason it wouldn’t work that I’m not thinking of?
Then we can have Widevine on Power, RISC-V, etc.
This was actually my plan-A approach, before I learnt that an aarch64 CDM existed.
I learnt even more recently that this is how Firefox on aarch64 Windows handles it too: https://bugzilla.mozilla.org/show_bug.cgi?id=1527811
Afaict this uses Windows’s built-in cross-arch support features so it’s not trivial to port to Linux, but it certainly proves that it’s possible.
I might still implement something like this on Linux, because being able to isolate the glibc jank to within a chroot or container would be nice.
This is more or less what PipeLight did. It ran Windows plugins under WINE (which could, in turn, run under QEMU user mode) and exposed them to other platforms. I was never able to get it to play Netflix for more than about 30 seconds though.
Yeah. I think that was for Silverlight, though, which was always a bit of a bear to run in WINE because you had to have just the right versions of Mono and WINE together.
I’m surprised that I can’t find anyone who has tried this for Widevine yet…
I also recently switched to an Asahi Linux Kernel on an m1 mini (though with Debian instead of Arch). Spotify not working was a major bummer until I found spotifyd which is delightful and great.
Of course, getting widevine support is also great, but yeah, just in case anyone else is in the author’s shoes but also doesn’t care for widevine in general, spotifyd (with some controller like spt or something) works without widevine.
Which front-end do you use? I’m using spotify-qt + spotifyd on FreeBSD and it’s lovely.
Just spotify-tui, but I’ll give spotify-qt a look!
Unfortunately, if we ever want the “year of the linux desktop” we have to compromise, continually, on matters of openness - many end users don’t care about the purity of their freedom, they care about being able to do the task they want to do. If they can’t do it, they won’t make the switch.
From a technical standpoint, this was fascinating, and almost straightforward. From a commercial standpoint, though, I’d have to ask if the solution isn’t for Google (as, if I’m understanding correctly, the upstream for Widevine) to do more than simply pay lip-service to the concept of driving Linux development?
Realistically, I’m sure they can afford enough Pis (even at today’s prices) to build some packages for aarch64. And maybe, one day, ppc64 ;)
The trouble is that everyone wants to compromise on the issues in front of them, and if you only ever do that, no progress gets made.