What I want to talk about in this blog post is which video-on-demand providers decided to not use these mechanisms for their content.

The basic gist of what I wrote there was that copyright holders of popular media wanted a means to protect their content when distributed to consumers digitally, video on demand providers wanted technical solutions to provide such means of protection and make a feasible business model out of it and tech companies wanted to solve these issues in various ways.

Long story short, they all had their dreams come true via the development of three concurrent technologies for protecting digital media: Apple's FairPlay, Microsoft's PlayReady and, last but not least, Google's Widevine.

These three pieces of technology is nowadays used to protect, behind the scenes, all video media that's copyright protected but which also reaches your screen.

They are the foundational building blocks that enforce copyright in a mostly transparent way.

Now, let's talk about enforcement, as not all video on demand providers use these technologies in equal capacity.

Technically, to enable the usage of these technologies in an agnostic way, the W3C introduced a new web standard called the Encrypted Media Extensions (which introduced the requirement for web browsers to include some form of proprietary decryption components, even browsers that had been traditionally open source).

By the standardization of this technology, all web platforms had a common and stable API to call from their client-side Javascript to interact with the underlying FairPlay/PlayReady/Widevine protection facilities in order to initiate and maintain a secure channel to transfer copyrighted video content through the internet.

Since this particular standardization back in September 2017, it was pretty clear that video on demand services had a stable future ahead of them.

Netflix, which had already been proven to have a successful business model by that point and was already an extremely popular platform even back then, was reaching revenues that were quite impressive.

Many other video on demand platforms were already quite well established, by this point, which was already a good indicator that this EME tech being standardized was pretty much inevitable.

However, there were those people that had issue with this: the free software crowd.

Free software, as a social movement, was always about promoting open source and the ability to contribute and share your changes with the world at large, as much as possible.

The free software crowd never liked the idea of forcing proprietary components into web browsers in order to keep them compliant, as that would go against the very principle of what they argue the open web should be.

But, as I said in my previous blog post, the open source dilemma was a huge one and, realistically, there is no way to write a web browser that's fully open source but which also is supposed to allow for hiding of digital data that's copyright protected and very valuable.

To do so entails that anyone that has some experience with the programming language that this web browser is implemented in can very well take the source code as it is, change it to bypass the security measures that are implemented in the vanilla browser, re-write the pipelines that the protected data are supposed to go through and change them so that you reconstruct a video file from the stream instead, dump said file on your desktop and then, “voila!”, just like that, you have an unofficial fork of that browser that can steal the video contents from Netflix and dump them in mp4 files on your desktop and then share that file with the world at large.

Nobody wants that.

And so, even though this decision displeased the free software crowd by a lot (so much so that, the same day the EME tech was officially standardized, the Electronic Frontier Foundation published an open letter of resignation from the W3C), the W3C made the difficult decision to standardize this technology anyways in order to prevent third party media plugins (e.g. Adobe Flash or Microsoft Silverlight) from re-emerging into the scene as necessities to use Netflix or other video-on-demand providers.

Web browsers that were historically open source but still wishing to remain fully web standards complying (such as Mozilla's Firefox) ended up with having to devise clever workarounds to provide the needed functionality to their userbase. Mozilla, for example, figured out a way to do this by simply piggybacking on Google Chrome's existent proprietary Widevine CDM solution and simply utilizing this as a plug-in to their, otherwise open source, web browser. And, to still keep their free software promoting user base happy and not have them cry foul and yelling that Mozilla is “polluting” a free software browser with proprietary nastiness, they added a checkbox in their browser's settings that allows the end user to decide whether to enable the Widevine plug-in or disable it completely. Disabling it would mean, obviously, that video on demand providers would have no way to create a secure communication channel with the Content Decryption Module on the end user's device (since there is no CDM to talk about at all) and, thus, there would be no way to secure the video content, which means that sites like Netflix would simply refuse to let you stream from them, even if you were a paying customer.

Obviously, this meant that most people that still use Firefox kept that checkbox enabled, so that Widevine would remain as an installed plug-in and be constantly enabled. After all, who doesn't want to watch Disney+ TV shows on their computer?

Well, maybe this won't surprise very many people, but I am a hard-boiled free software advocate myself and I've always been very adamant about the web needing to be as open and devoid of proprietary technologies, as possible.

Given my very puritan stance on this matter, it should come as no surprise, dear reader, that I was among the very few Firefox users that kept said checkbox unchecked, and so I had no Widevine CDM to speak of installed on my Linux system.

This meant, effectively, that video on demand providers like Netflix, Disney+, Amazon Prime Video and so on would detect the lack of a proper CDM in my browser and, obviously, they would refuse to stream any content to me, because there was a very real risk that I would then copy said video and allow others to pirate it from me.

Needless to say, I was a bit unhappy with the current state of affairs. Still, I wasn't willing to compromise, and I genuinely believed, deep down, that video-on-demand as a business model was doomed to fail and that it was the root of all evil, as it was causing the advent of more proprietary solutions that were parasitizing a pure and virgin web.

In my quest to find video on demand on the web to consume but which did not require me to enable the proprietary CDM in my browser, I ended up with three video on demand platforms that I had to choose from: Crunchyroll, HIDIVE and Wakanim.

Before you say anything, no, I wasn't specifically choosing anime services to watch; it just so happened that these were the only services that did not require me to have Widevine enabled.

All the others (Netflix, Amazon Prime Video, HBO Max etc) automatically detected my lack of a CDM and would give me errors when trying to play any stream on their platforms whatsoever.

Those three were the only services that I could use (although, with Wakanim, even this might not have been the case, as I couldn't even reach the point where I could play media on it).

Wakanim

Wakanim is the outlier because I simply couldn't use it at all. For whatever reason, whenever I tried to use their website, the website presented itself in Russian to me.

I've encountered situations like these when a website tries to auto-detect my location based on my IP and then decides to auto-translate their entire page to whatever language it thinks I speak as a means of convenience.

The only issue is, I'm not Russian, nor do I know or speak Russian whatsoever. I've been born, raised, and am currently living in Romania. So the website auto-translating itself to Russian was quite a hindrance to me.

Normally, a rationally designed web platform would still offer the end-user the possibility of correcting these types of errors by giving them a language selection menu to select a different language from the current one. But no, of course it wouldn't be that easy. Apparently the programmers that worked for Wakanim decided that their platform was too perfect to need such a fallback and that such bugs could never happen on their polished little website (spoiler alert: it happened, to me at least).

So, with Wakanim, at least, I really can't say whether it would or not allow for playing protected media without a CDM installed. From what I read online, supposedly, you can actually download the video series that you purchase from their platform, in an unencrypted format, so you can then play that media on any player of your choice, offline.

If that were true, I would have been mighty impressed and a big fan of. It would mean that there's really no point in employing a CDM and encrypting the data stream if you're just gonna gift-wrap the protected content to your customers anyway.

I guess we'll never know now, since they've been discontinued since November 2023.

HIDIVE

Oh, good ol' HIDIVE. It's very funny to think that the entire reason why I initially chose to become one of their customers is because I could use their platform without needing to install proprietary components in my browser to watch their videos.

My relationship with them was a short lived one, as any of those that follow my anime blog already know (specifically, the blog which can be found here).

If you don't know, long story short, I made a subscription to them back in early 2022, watched a couple of their shows that were pretty fun (like Tokyo Mew Mew New, The Executioner and Her Way of Life, Endo and Kobayashi Live! The Latest on Tsundere Villainess Lieselotte and many, many more) but eventually, at some point during April or May 2023 I think, they suddenly and abrutly stopped servicing Romanian customers on their platform. You can read more about that over here.

Eventually I decided to mask my location using a VPN to appear as if I was from a different country so that I could still stream from them but, when the time eventually came to renew my yearly subscription towards them, I decided to cancel and never look back.

In the end, I liked the fact that they don't force a proprietary CDM down your throat in order to stream videos from them. And if you're also anti-proprietary DRM and want to support video-on-demand platforms that don't require them too, then you might like them.

Personally I cannot, in good conscience and with my self respect intact, continue to financially support a service that discriminates against me simply for being from Romania, so I choose not to continue giving them money (I know that it's not a personal matter and that they just made a financial decision to stop supporting Romania, I get that, but I still find it insulting nonetheless).

Crunchyroll

Finally we came to the last one in our list. Please be aware, though, that what I'm about to write is a, mostly, historical piece about how things were back at the time.

For a long time (I don't even know since when but it's been the case at least since I joined them), Crunchyroll has somehow allowed you to stream their content without actually necessitating to activate the Widevine CDM in your web browser.

I don't know if they've ever officially supported that, since as far as I can tell, their website always warned that you should enable it to have it work, but unofficially, if you kept it disabled, either intentionally or unintentionally, the page you'd load would warn you that you need to turn it on but, eventually, the video would still load without any issues.

Yes, that's right. You used to be able to watch Crunchyroll videos entirely unprotected, no CDM required, at your leisure.

That. was. AWESOME.

Key words being “used to”.

At some point in the past (I think late 2023?) they've patched their Javascript implementation and now their website correctly detects whether you have the CDM disabled or not. If you do have it disabled it doesn't allow you to stream anymore.

So this obscure workaround doesn't actually work anymore, as of the posting of this blog post.

I am tremendously sad by this outcome, I'm not gonna lie.

Crunchyroll, the last bastion of hope that I had for a free web has betrayed me, and now I am forced to enable my Widevine CDM again, just to watch Crunchyroll videos again.

Conclusion

I know what many people are going to tell me: it's selfish of me to want for streaming services to disable the only means that they have for protecting their content just because of my personal puritan ideology of hating proprietary software.

I get it, I really do.

That's why, in the end, I decided to still keep my Crunchyroll subscription.

Because, even though I'm unhappy with how things turned out to be, I realize that what I want is pretty much impossible to implement: I want full complete control over my own hardware and everything that runs on it (i.e. the free software philosophy, in a nutshell) but I also want to be able to stream copyright protected videos through that hardware as well (which requires at least some proprietary closed-source components to implement the necessary protections).

This is a contradiction that has no solution. In fact, this isn't even a technical dilemma, the way I always thought of it, but merely a philosophical one.

The only way to reconcile on this is to make some compromise: either I give up on streaming media on my PC entirely and embrace a fully open and free software ecosystem, or I decide to allow media streaming on my PC, in which case, I have to install at least some proprietary software to allow for its protection and copyright enforcement.

Ultimately, I made the decision that any weak willed individual would make and I eventually caved in and enabled the Widevine CDM. It was a choice, a painful choice, but a choice I needed to make.

Some might argue that it was the wrong choice and, to be honest, I wouldn't necessarily even disagree with them. Compromising on one's own ideals because of convenience is never an easy pill to swallow, but I did.

Still, it is because of this decision that I still get to watch Crunchyroll streams to this day, and maintain my anime blog as well.

So I guess at least some things worked out, for better or for worse.

Still, I can't help but wish for a better world: a world that maybe copyright holders decide to be more trusting of their consumer base and would allow them to watch their media without having to devolve to such barbaric and convoluted processes just to prevent piracy.

Because, as many people have shown in the past, DRM is nothing more than additional hoops that are added to discourage piracy. It does not guarantee that piracy will never happen.

And time and time again it's been shown that pirates, for better or for worse, will get their hands on said protected media one way or another, through various means, and the end result is always the same: DRM just acts as a minor impediment in the grand process of breaking the protection schemes.

The people that always end up suffering the most when DRM is added to products are the lawful consumers.

Blog post by Alexandru Pentilescu.

You may contact me at alexandru.pentilescu@disroot.org

Optionally, you may also encrypt your emails to me using the following PGP key: 0xFF49E5748BD42A6A6A7DECFDD38B28DF9F7497A2

Download that key from any keyserver you wish

Time to talk about DRM again.

Naturally, most people don't care much about this topic, and I'm sorry if another blog post talking about DRM might seem very boring and too technical for you, but I really need to get this off my chest.

With that said, I'll try to keep this as simple and easy to understand for non-technical people as I can.

So, let's get started!

A bit of background on DRM

So, what is DRM anyways? DRM stands for Digital Rights Management and is an umbrella term used to refer to any technological means of enforcing copyright over digital information of any kind. Examples of digital information that are usually DRM protected are music, books, video games and, of course, video files.

Since copy-pasting a file in a computer is as simple as doing a Control + C, Control + V on it and, just like that, you have an exact copy of it without having had to pay any amount of money for a second copy of it, DRM was invented to stop the user from being able to do just that, for the sake of enforcing copyright restrictions.

There are many schemes that have been invented (and reinvented) over the years to do just that, one of the most popular known ones being Apple's FairPlay technology, that is implemented on macOS and iOS. This tech was used historically for protecting music that was distributed over the iTunes store (and still is), but was also extended for protecting ebooks too, as well as video and other media.

Microsoft also tried their hand at this and came up with the PlayReady technology, a similar proprietary tech that is used primarily for encrypting copyrighted video that gets streamed to devices running the Windows family of operating systems (especially on Microsoft's own brand of web browsers, particularly Microsoft Edge).

These pieces of technology are needed in the modern day world simply because, if they did not exist, it would be trivial for anyone to steal digital information passing through their computer. Simple tools like Wireshark (which are free, by the way), would allow anyone with a Netflix subscription to capture the network packets coming from Netflix servers and reconstruct the video file that would represent any TV show or movie that you wanted to get a hold of.

Once this reconstruction process would be complete, you, as a simple Netflix customer, would have in your possession a digital copy of the episode or movie in question and would then be able to share it illegally with anyone of your choice.

It is for this reason that Netflix and other video-on-demand platforms have been employing the aforementioned technologies to protect their digital content and bar computer users from misusing their privileges to enable software piracy.

Why is this a problem?

Now, on paper, DRM sounds quite fine and dandy and, for all intents and purposes, it can be seen even as a necessity in a modern digital age.

After all, how could you, as a movie studio or a musician, ever feel comfortable to distribute your own work digitally to your customers if there was no protection in place to prevent them from illegally copying your work and then distributing it freely to others against your will?

After all, piracy means loss of money to you, doesn't it?

Well, here's where we get into murky territory.

While it's easy to think in black and white terms like that when you're the owner of your own work, it gets complicated when you have to really think about how to prevent people from copying over information when that information has to go through untrusted computers.

Because, at the end of the day, anything that can be shown on a computer, whether it's a book, music or video, has to come down to being a long series of bits. Because, deep down, that's the only thing that computers can work with: digital data.

And, also, that data, in order to be useful to a customer that pays you money, has to go through his own hardware: his CPU, his GPU and, eventually, reach his display or his speakers. A song can only be useful to someone if it plays on his speakers, a video can only be useful if it gets played on his monitor etc.

So, regardless of how you spin it, this protected data, somehow, has to travel through the medium of the internet and eventually reach hardware that is a customer's, a customer that may or may not have malicious intentions of illegally copying it for his own needs.

The inherent problem that I'm trying to highlight here is that, in the end, the data has to reach untrusted territory, and be processed by untrusted hardware.

How can this be resolved when any piece of hardware can be tampered with, physically? How can one guarantee the safety of a piece of data if it has to pass through a CPU that can be made to run an untrustworthy operating system on it?

Well, there is no easy answer to that question. Theoretically, the answer is it's impossible but, then, that would be quite problematic.

That answer would cause a lot of issues, least of which is the fact that video on demand, as a business model, would be effectively impossible to implement if that were the colloquial answer to this dilemma.

Oh, you want to make a business out of streaming copyrighted content to computers all over the world that have an internet connection? Well, TOO BAD. It's technically impossible to protect said data from being illegally copied by malicious technically savvy actors and so, well, you can't make a business out of that. Sorry.

Imagine if that was the case! Netflix, as a business, wouldn't exist. And TV shows and movies would remain only in the world of TV and Blu-ray/DVD releases. That would be a very sad thing indeed.

But wait a second! I just mentioned Blu-ray and DVD, didn't I? Home media, as a concept, has been a very lucrative industry for many years and, even that, in theory, relies on giving customers access to copyrighted digital data and letting them view that at their leisure.

Blu-ray, by definition, allows a customer that had purchased the Blu-ray disc of a particular movie or TV show, to watch said movie or TV show on their own TV, which is technically untrusted (since any piece of hardware can be tampered with).

So, if Blu-ray could do it, why can't video-on-demand platforms?

The breakthrough (sort of)

Multiple things had to happen at the same time to make Blu-ray, as a piece of technology, become possible.

For one, digital transmission of video streams had to be locked down entirely.

Ever used an HDMI cable? Or a DisplayPort? That's digital video transmission and everything going through those cables has to be encrypted.

The exact name for this encryption technique is known as HDCP, which stands for High-bandwidth Digital Content Protection and it was invented back in 2000 by none other than the Intel Corporation (initially for DVI and later expanded to include other kinds of physical links as well).

Nowadays HDCP is used behind the scenes by pretty much every piece of hardware in existence.

Any type of graphics card will, at the very end of the processing pipeline, encrypt the video stream before it sends it out on the physical cable so that, no matter what that cable is connected to, it will only receive encrypted data (and when I say graphics card, I also mean integrated graphics as well).

But how can a TV or computer monitor read a video stream that's encrypted?

Well, before the encryption even begins, there's a special kind of key exchange that happens, and that kind of exchange is only possible if the TV or monitor in question has its own kind of key burned into its own hardware that is, inherently, trusted. The exact type of exchange is complicated and is designed in such a way as to not leak trusted key material to untrusted parties. I won't go into detail of how this is done but, if you're up to the task, you can read up on the details here.

In addition to this, the trusted keys that have to be burned into monitors or TVs had to be buried into microchips that are difficult to extract data from.

Physically this is not impossible but it requires specialized equipment and knowledge to reverse engineer these keys.

This is to say, to circumvent the problem of How can you protect copyrighted information that has to go through untrustworthy hardware, the solution engineers came up with was Simple! Just design all hardware in existence that has to handle such information to be trustworthy.

This is to say, make an authentication scheme that cannot be spoofed very easily to ensure that sensitive information doesn't get sent out to tampered hardware, bury sensitive cryptographic materials that such schemes rely on in microchips that are very difficult to tamper with and, finally, whenever data has to exit such trusted hardware and has to travel through physical links whose integrity cannot be guaranteed, encrypt that information before it has to travel through said links so that only trusted hardware can decrypt it back to a readable form.

So, how did Microsoft and Apple implement a solution for video-on-demand providers? They designed their FairPlay and PlayReady protection schemes to make use of these hardware technologies by enhancing their respective operating systems with the capability of creating secure write-only pipes that have special anti-tamper protections built into the very kernels. Such pipes would have sensitive copyright protected information travel through them, which, in practice, just means that this information gets encrypted as it gets passed around from one memory area to another (much like how a VPN encrypts your network traffic as it travels from one point to the next) and only the hardware parts that need raw access to that information has the means of decrypting it. Everything else would just see encrypted gibberish.

To make this possible, TPMs had to become widespread (as they are designed to be trusted by default and also handle sensitive information), drivers for graphics cards had to be enhanced by video card manufacturers to support these protection schemes, and much more.

Ultimately, the end result of all of this was a very complex system with many many moving parts, where many giant tech companies had to agree to multiple standards and had to come together in their engineering efforts (among of which were Microsoft, Apple, Intel, nVidia, AMD, Google; pretty much all the big names that you can think of) and, in the end, it resulted in a highly advanced protection scheme whose sole purpose was to enforce copyright over digital data.

And, after all these efforts, we had a technological means of guaranteeing to video-on-demand providers that their data could be safely handed over to secure machines running secure operating systems, that would run secure hardware handled by secure signed proprietary drivers.

But wait! What about Linux?

Oh right, of course things couldn't be that easy! Open source just had to make things complicated again!

You see, dear reader, in this world of security through proprietary secret technologies and encryption schemes implemented through locked-down TPMs or proprietary drivers that nobody can inspect the source code for, there exist those people that want to run only free software, open source software; there exist operating systems whose very kernel can be modified by whoever has the technical knowledge to do so and can be changed to do whatever they so desire. And doing that requires no reverse engineering or hardware tampering whatsoever.

In such a world, you may wonder, how can such data be protected, if the operating system can be modified by anyone in any way?

It would be one thing if the web browser ran directly on the video card and web developers could interface against a secret API from Javascript to access the proprietary underlying drivers to encrypt media, but that's not how anything works.

The web browser runs from the context of an operating system. The operating system runs on a CPU. In order for data coming from a Netflix server to be protected against illegal copying, it has to be passed over from the web browser process to the video drivers (since we're talking specifically about video content now) through system calls, and then the video drivers have to take it and encrypt it and then pass it on to the monitor link.

It is at this point where the data has to be passed over from the web browser process to the video card drivers where it is vulnerable to being copied.

If the kernel is truly open source and a hacker can manipulate its source code to make a modified malicious version that can steal any data that gets passed over during this time and extract the unencrypted bits, then it's all over.

What's even worse is the fact that there are versions of graphics drivers that are also open source, made by third parties unrelated to nVidia or AMD or Intel, who cannot be controlled by them and who publish the source code for their work as well. These drivers can very well be rewritten by anyone skilled enough to copy the data when it is still unencrypted and dump it into a file.

These issues are very pressing and, honestly, this is where we get into the grey area that nobody likes to talk about.

In a world where nobody cares, the solution that most engineering companies would come up with would be “just ignore Linux users” and that would be it. “Since we cannot ensure a secure pipeline for copyrighted data from the web browser to the physical wire that goes to the monitor, we cannot trust the operating system at all. As such, let's not support it” and that would be the end of the discussion.

What this would mean would be that Linux users would be left in the dust, and Netflix, Amazon Prime Video, HBO max and all these other platforms would simply refuse to service them, as none of them would be willing to hand over their copyrighted video data to such untrustworthy platforms.

Thankfully, this is not the case.

Widevine to the rescue

And here we come to the end of our story. The hero that saved Linux and made video-on-demand streaming possible to it was none other than a company that wanted to provide a means of securing data from the context of a web browser.

Widevine Technologies have been making a name for themselves in the area of protecting digital content from 1999 onwards, being among the most famous companies that enforce content protection on various platforms.

In 2010, the company was acquired by Google, who was very well aware of the necessity of acquiring their tech.

The problem with the aforementioned PlayReady and FairPlay technologies is that they were proprietary and relied on special support from the underlying operating system to work.

PlayReady would only work on Windows and FairPlay would only be accessible from the context of Apple's own ecosystem of operating systems.

This posed a problem to Google, since they wanted to make a cross-platform web browser that would the same across all operating systems (namely Google Chrome).

To make Chrome work correctly, it would, in theory, be possible to maintain different code bases for each separate operating system, but that would be an unnecessary amount of extra effort to invest into a means of protecting digital data.

Instead, Google sought to obtain a universal solution, a one-size-that-fits-all glove that would be agnostic to the operating system that it ran on and, would additionally work well on Google's own operating systems, namely the Linux-based Android and ChromeOS environments which lacked the aforementioned protection schemes.

As such, Google realized that it only made sense to acquire Widevine Technologies as a response to this necessity, and integrate their solutions into Google Chrome and Android ecosystems, which lacked them.

“But how can an open source web browser like Chromium ever be able to encrypt data in such a way that's impossible to be bypassed by hackers who can just change the source code? And how can they protect such data from a potentially hostile tampered operating system?” you may ask.

Well, the answer is a fair bit complicated, but, to put it simply, Google had to do a lot of patchwork to get there. But, it's Google. At the end of the day, they had more than enough money and engineers to throw at the problem.

The way they did it for the Chromium project was to simply not make their solution available there, at all.

If you use a pure version of the Chromium web browser to watch Netflix, you'll quickly find out that it simply doesn't work. That's because Google could not reliably implement such a solution into an open source project, lest it invite the open source dilemma that we already talked about.

Instead, they implemented it only for Google Chrome as a proprietary plugin-in dynamic library who does all the heavy work duty of both encrypting and decrypting the media streams in a closed proprietary environment that's very difficult to reverse engineer.

This is known as the Widevine CDM, and is only a small part of the whole Widevine infrastructure that's behind the content protection that's needed.

As this CDM is just a dynamic library file on the local file system, in theory, it is possible for a malicious party to simply disassemble it and extract its inner functioning, analyze it, and figure out how it does things (and this has happened before; I've even read up on a now archived Github page how one user attempted to do just that).

At one point in the past, the way this CDM did things was by using RSA encryption to decrypt video content that was being sent over the wire to it.

Basically, the CDM had its own public-private RSA keypair burned into the library, with the private key very cleverly hidden in some .data section in the library file. Whenever a protected content stream was to be initiated, the Chrome browser would load the proprietary plug-in, the plug-in would send an exact copy of its public key in clear text to the Widevine server that was on the other end of the internet connection, the server would check against its database of trusted RSA keys to see if it was trusted and, if it still was trusted at that point in time, would start encrypting the protected data stream using that public key and send the encrypted data to the browser over the internet. The CDM would then use its associated private key to decrypt the stream back to its original form and then display everything from the context of the web browser as a video feed.

Simple, easy and very elegant.

That was how it was done at one point. Since then, especially after this information got released from the guy that reverse engineered it, I imagine Google engineers updated the method to something else now.

The point is, there exist many different ways to do it, and, as hackers reverse engineer the Widevine library to keep finding out how it works, Google has the resources to find new ways of protecting the content, in a constant cat-and-mouse game of trying to evolve a solution to protect digital video feeds.

“But wouldn't a tampered host operating system defeat this? One could just inspect the RAM memory of the Widevine CDM and access the raw decrypted data directly, if they were skilled enough”.

Yes, yes they could. For this reason Widevine has such a thing as protection levels. Because, unlike Windows or macOS, the Linux operating system that runs in the background cannot have its integrity guaranteed in any way, if Google Chrome detects that it's running on such an environment, it considers this to be in an L3 (i.e. protection level 3) context. This is the least secure context and it is, for this reason, considered the highest risk one.

Within an L3 context, all operations are done in an unprotected memory area by the Widevine CDM, and this is considered low security. For this reason, most video-on-demand platforms only hand over low quality streams to such an environment, content that, even if it were illegally copied and then distributed via piracy, would only lead to marginal financial damages. I forgot exactly what type of restrictions this has, but for Netflix, if I recall correctly, I think they send out only a maximum of 540p quality streams to such environments (either that or 480p or 720p, I can't remember which). Such low quality streams are considered low-risk enough that even if they were sent over to insecure channels, the amount of damage they would do would be limited.

The next level up would be L2 protection, in which video decoding and encoding is done in an unprotected environment but cryptographic operations are done securely. This is where Google Chrome running from the context of ChromeOS would be (sometimes, ChromeOS might even support L1 protection even). Technically ChromeOS is also Linux, but it's treated in a special way, because the operating system is heavily modified by Google to be locked down intensely against tampering, and its own source code is not published online (there is the open source ChromiumOS project that ChromeOS is based off of, but it's only an approximation of the real thing, as ChromeOS modifies it using proprietary means very heavily, much in the same way that the Chromium project is only an open source approximation of Google Chrome).

Inside the L2 context, most video-on-demand platforms would allow for content streaming up to 1080p, as it's very unlikely for memory inspection tools to be available in such environments for hackers to tamper around with.

Finally, there is the L1 context, that's only available on modern hardware that use TPMs and hardware-protected video decoding to ensure the availability of a secure pipeline to send copyright protected information through. This is a 1:1 equivalent to the aforementioned PlayReady and FairPlay solutions, where data protection is guaranteed on every step of the way through the pipeline, from the browser until the data gets displayed on the monitor/TV.

This level of protection can only be guaranteed only on the latest versions of Intel and AMD CPUs (that have TPMs incorporated in them), you have up to date device drivers that ensure that the hardware can handle protected data and the host operating system is guaranteed to not have been tampered with in any way (usually by integrity checks and ensuring that the boot loader of the device is locked, if possible).

From the context of Widevine, this is usually only possible on the latest Chromebooks and on Android devices (smartphones, tablets or smart TVs) that have never had their bootloaders unlocked (and always on iOS and iPadOS devices as well).

In such environments, the security guaranteed is so high that there are no more limits with regards to the quality of the content being shown. This is considered the maximum level of security that Widevine can afford, equivalent to the PlayReady and FairPlay schemes.

And so, thanks to Widevine, Linux as a whole now supports protected video playback (albeit L3 level but still).

Blog post by Alexandru Pentilescu.

You may contact me at alexandru.pentilescu@disroot.org

Optionally, you may also encrypt your emails to me using the following PGP key: 0xFF49E5748BD42A6A6A7DECFDD38B28DF9F7497A2

Download that key from any keyserver you wish

A blog post talking about the history of the privacy-focused Tox protocol.

Background

After the 2013 Snowden US government leaks, it's no secret that many people, including those from the general public, have become quite uncomfortable about the topic of government surveillance.

Up until then, there was always an air of acceptance among everyone that the government was spying on them and that, most likely, all digital communications were being harvested by it somehow, but nobody gave the thought too much thinking.

Well, Snowden changed this and, in the wake of publications of classified materials that showed just how much the US government was eavesdropping on everyone, including domestically on US citizens, it became clear that the idea of being spied upon suddenly lost all its humor in the public's eyes.

Programs such as PRISM became part of the public consciousness and technologies that many had taken for granted, such as Skype, became the target of much distrust all of a sudden.

People were suddenly concerned about their online privacy, and felt betrayed by the revelations.

And so, as a consequence, in June 2013, the first commit was published on github by a user named irungentoo, a commit for a repository named toxcore.

And so was the Tox protocol born.

Design goals

The protocol, in its infancy, strived to achieve some very straight forward goals:

1. It was supposed to be entirely a peer-to-peer protocol, meaning that unlike many other instant messaging protocols devised up until that point (such as Whatsapp, Signal, Telegram etc.), the tox protocol will not rely on any central service at all, outside of the barebones bootstrap nodes which would be used to get the ball rolling

2. It would be an end-to-end encrypted messaging system, meaning that the only players involved in the conversation would be the ones that would have the means of decrypting it

3. Once a contact's friend request is accepted, the two clients would immediately connect directly to each other, without relying on any relays or intermediaries whatsoever (except if any of the contacts decides to use Tor to mask their IPs for additional privacy)

The Snowden leaks revealed that the main reason digital communication was prone to being eavesdropped on was that the most famous and common instant messaging communication programs relied on servers to relay the messages between the participants. This means that the NSA only needed to go to the server operators to convince them to handle these messages to them, either voluntarily or via use of legal coercion.

So the Tox protocol solved this dilemma by simply getting rid of servers altogether. You can't easily spy on everyone if people are directly connecting to each other to talk, without central intermediaries.

A good analogy is the advent of telephone companies. It's easy for the government to spy on phone conversations because, ultimately, there are only a handful of phone companies in any country, so they just need to compromise all of them and then they can access the phone conversations of millions of people. This is possible because all these millions of people rely on just a handful of companies for all their communication.

The less companies there are to compromise, the easier it is for the government to breach the service.

Drawbacks

The idea, was a good one. There were some caveats though.

Who came first? The chicken or the egg?

The main issue that hampered Tox's growth was the fact that Tox, by design, was very privacy focused.

Yes, in theory, you could use your real name as your tox profile account's name, you could post your email and phone number in your tox details as well for all your contacts to see.

But, in practice, most people used an anonymous username that was very difficult for others to guess. Moreover, the protocol didn't even mandate for the registration of an email address or a phone number. Basically, the protocol allowed for full anonymity at all times.

This was by design like this.

The issue with this was that there was no easy way to find your friends even if they also used tox.

There was no directory where you could search people by name, email address, phone number or even tox username at all.

Instead, if you wanted to talk with someone over tox, you first had to share your Tox ID with them, which is this long 76 character long hexadecimal string, that they would then use to find you over the internet and send you a friend invite.

Once you accepted the invite, your tox client would connect directly with theirs over the internet, negotiate a secret encryption key with them and then use this to encrypt all your communications with each other.

The key would only exist on your device and theirs, never leaked to any third party at all.

Needless to say, this was a cumbersome process, and it made finding new people a complete and utter hassle. Not only this, but it opened the door for a chicken and an egg dilemma, because if you needed to securely talk with someone, you first had to give them your tox ID (or they had to give you theirs) over a secure private channel before you even started talking over tox.

But in order to do that, you needed to have a private trusted communication channel between the two of you already to send the tox ID through, so what even was the point of tox if you already had that?

Offline messages? What's that?

Another, glaring shortcoming that the tox protocol suffered from, due to its server-less architecture, was the lack of offline messaging functionality.

Skype, Teams, Signal and all these other instant messaging platforms have servers that are, inherently, trusted by all the clients by design.

Servers might not seem like that much of a huge deal, but it allows for useful features like offline messaging to happen without having to overly engineer a very complicated solution.

Basically, if Bob wants to send Alice a message over Skype, for example, but Alice is offline at the time, Bob can send the message, the message gets recorded and timestamped by Skype servers which are, by design, always online, and then Bob can do other things in the meantime, even go offline as well, knowing that the message has been sent.

Now, even if Bob may have gone offline in the meantime, Alice may come online, connect to a Skype server and, as soon as the server sees her coming online, it remembers that Bob had tried to send her a message when she was offline, and sends the message to her now.

Bob doesn't need to be online for any of this. The Skype server did the job for him behind the scenes. This is what's known as offline messaging.

Tox doesn't have servers, though, so none of this is possible.

I'm sure, technically, this can be done in a peer-to-peer application too, if you put enough thought into designing a clever solution.

As long as there are other peers for you to connect to, you can engineer a solution in which they store the message themselves, instead of relying on a server, and relay it somehow to Alice when she gets online, but then you have to design a propagation protocol so that the message is kept alive while peers come online and go offline randomly, make sure that a malicious peer doesn't just flood the network with bogus offline messages meant to DoS all other peers and other such nonsense.

The point is, designing a solution that doesn't rely on servers is not easy and tox just decided to take the easiest approach out: just avoid supporting offline messages entirely.

What this means is that in Tox, if you wish to send any of your contacts a message, both you and the contact in question have to be online!

Sure, tox can hide this fact by queuing the message locally on your computer, waiting for your contact to come online to send it to him but, if you decide to shut down your computer during this time while they're still offline, they won't be getting your message while your computer is shut down, even if they will come online in the meantime.

Basically, all your offline messages to your contact will ever be sent to them only during the brief period when both you and them are online at the same time.

This makes people who live on opposite sides of the planet, and who have huge time zone differences between them, very difficult to communicate with each other over tox, as one is usually offline sleeping while the other is online, and vice versa.

Worse, if you have an urgent message you really need someone over tox to read, your only recourse is to keep your computer online and not sleeping at all times, until they get online, for the message to be delivered.

This is not only a huge waste of power but, many times, it's impractical. Basically, in order to mitigate the lack of servers, communicating parties have to turn their clients into servers themselves.

And, not only this, but because Tox is a trustless protocol by design and peers are designed not to trust each other, even if they are directly communicating with one another, a message that is being received by Alice at a later time than it was when being sent by Bob (i.e. an offline message), gets timestamped by Alice's tox client as the time of it being received by Alice, not the time it had been sent by Bob to Alice.

Or, in simpler words, if Bob sent Alice a message, but Alice was offline on Tox for an entire week afterwards so she couldn't receive it, when Alice does finally come online on Tox and receives Bob's message, the message is recorded in Alice's client as having been sent at the time Alice came online, not a week prior when it had actually been sent by Bob.

This is because, Bob could have hacked his own Tox client to lie to Alice about when he had sent the message, in which case his client could claim that the message had been sent a month prior, or even a year prior. Without a trusted third party server to corroborate the sending event, Alice's client has no way of knowing if what Bob's client says is true, nor can Bob's client even prove that he had sent the offline message at the time he claims he has and not earlier or later.

As such, in Tox, the offline messages you receive from a contact are timestamped on your end as the time you actually receive them, not at the time your contact claims to have sent them to you.

This is the issue with software that's inherently distrustful by design. You always end up lacking features that software with trusted servers have.

Have more than one computer? Sucks to be you!

Oh, this one's a doozy.

You know how, on Skype or Microsoft Teams, you just have to login to your account and then you can send messages from literally any internet-connected computer at your disposal?

Like, let's say you send a message to your boss on at work, close your computer to go on lunch break, and then, while you're gone and eating, you decide to see if your boss answered by just logging into Teams via your phone and check.

You can do this because your Teams account is stored somewhere in a database and, regardless of where you connect to Teams servers from, whether it's your work Desktop machine, your Android phone or your grandma's laptop, the servers are always the same and the database that they use to store information about you is also always the same. Only the Teams clients are different.

Well, Tox only has clients. It has no servers, no databases, no anything.

Basically, if you want to share your Tox conversations across machines, you're pretty much out of luck.

OK, in theory, there's nothing in the Tox protocol that prevents a Tox client from somehow implementing a solution to synchronize conversations across multiple computers using peer-to-peer technology. Maybe someone, someday, will actually implement this and I'll take my words back.

But, in practice, I've personally never seen this done.

Only once did I move my qTox profile from a Linux laptop to my Windows desktop by copying the profile folder on a thumb drive and, thankfully, everything went smoothly and without any bugs whatsoever. That way, I've effectively moved my encrypted Tox conversations across machines.

However, it's worth noting that, at least back at the time, this wasn't officially supported by qTox, meaning that it could have very well not worked. Or, even if it did work, a future update could make it not work anymore.

Basically, if you want to use Tox on multiple computers, the official fully supported way of doing it, is to just generate a new Tox profile on each and every one of them. And that means you'll have to re-add all your contacts across all of them, every one of your contacts will have to accept a separate friend request for each computer you use tox on, your friends will have you listed multiple times in their contacts list, once for each of your computers and, even with all of this, none of your chats will be synchronized across your devices, meaning that different computers will have entirely separate conversation histories.

This.IS.A.NIGHTMARE.

If you ever wonder why the Tox protocol was never successful, it's not because it was buggy or it lacked advanced features; it's because, by design, it couldn't implement some of the most basic features that most people expect by default from any instant messaging app.

Its greatest strength, the fact that it had no servers or central database, was also its downfall: no servers means no simple way of inter-device data syncing, offline messaging or central user directories to add friends from.

This is why Tox failed

Lack of support for niche Linux distros for certain Tox clients

This is more of a niche thing, as most software doesn't support Linux anyways, but the user base that most Tox clients pandered to, was the privacy oriented, corporation hating, free software loving Linux community.

Sure, there were Tox clients that were geared only towards Windows too, but those were very rare.

So you'd think, given their primary user base, that many client developers would go out of their way to ensure good support for most distros. Well, you'd be wrong in thinking that.

Or at least, I was wrong about this with a tox client named qTox.

qTox was one of the more popular clients out there, and it was my client of choice because it had the widest operating system support of all clients.

So, naturally, that was my first choice for a client.

I also have to point out that I'm a Fedora linux user. I use Fedora Workstation as my daily driver on my personal laptop, and I love this OS, with all its flaws and shortcomings.

One day, I upgraded to Fedora 36, as that was the latest release at the time and then, as usual, I went ahead and enabled RPM fusion repositories on my system.

Then, from RPM fusion, I installed qTox on my system.

Well, wouldn't you know it, I was getting an error upon trying to start the program.

The error? A library called libvpx.so.6 was missing on my system. Of course, I didn't get this error message while trying to start qTox normally from my launcher, I had to try to start qTox from the terminal, just so that I would get a printout on why it was failing to start in the first place on the console.

Well, wouldn't you know it, apparently Fedora 36 upgraded its system libraries and instead of coming preinstalled with libvpx.so.6, as qTox seemed to be expecting, it came with libvpx.so.7 instead, which was entirely different.

I mean, I know RPM Fusion was a third party repository and that people shouldn't expect much quality control from stuff in it but, isn't the entire point of a package manager that it was supposed to solve dependency issues like this?

And yes, I tried creating a symbolic link named libvpx.so.6 to libvpx.so.7, expecting it to work out of the box, but it wouldn't. The program would still crash immediately upon start-up with an even uglier error message.

The point is, while Fedora is indeed a bit niche, it's still one of the most popular Linux distros on the planet. You'd think the development team for qTox would try to pre-emptively fix issues like these before people would make the upgrade.

And, for the record, I didn't do the upgrade the exact day Fedora 36 came out. I usually wait a couple of weeks before I upgrade, so they had more than enough time to sort this out. The fact is, they didn't care.

Granted, qTox is just one Tox client. Their development team doesn't develop c-toxcore or any of the many other Tox clients on the planet, so they are just one party at fault here.

And, despite this issue, qTox also offered an AppImage that worked out of the box so I could continue to use qTox even after this.

But still, it's disheartening when you realize that this is the type of bugs you encounter quite often when trying to use Tox.

The titan has fallen

With all of these shortcomings, and without obvious technical solutions in sight, the Tox protocol has seen an excruciatingly slow but painful death.

It bled users year after year, as more and more privacy focused individuals sought to use other software suites that promised privacy but which also offered the benefits of centralized services, like Signal.

Don't get me wrong, I despise Signal as much as the next person, and the fact that I still have to have a phone number in order to use the service is extremely infuriating. But, at the end of the day, Signal is easier to use than Tox. And that fact is simply indisputable.

Couple that with the fact that Signal also is open source, much like most tox clients are, and you really have no reason to prefer Tox over Signal.

As time went on, developers, for one reason or another, started abandoning their tox projects, one after the other.

People simply didn't seem to care about peer-to-peer protocols anymore and, as the Snowden leaks were slowly fading out of the general population's consciousness, so too did the volunteers working on the myriad of tox clients all around the world.

And, after many years, the most popular tox client out there, qTox, had its official repository on github frozen, with the developers leaving behind a message that they're planning on abandoning the project.

Keep in mind, there are still many tox clients out there, and the main project, c-toxcore, the one that actually implements most of the functionality offered by Tox, is still maintained to this day.

But c-toxcore is just a platform-agnostic library that implements the Tox protocol itself. A library is worthless if you don't have front-end clients to expose its functionality.

That's what all the tox clients are supposed to do. Now, qTox is abandoned, so that's out of the question.

If you go to the Tox protocol's wikipedia page, you'll see a table with the most popular tox clients out there, as well as a column in that table mentioning whether they're still supported or not.

And, at least as of right now, most clients reported on that page are said to have been abandoned.

The most popular Tox client still being maintained right now is one named Toxic, a C client implementation relying on the Ncurses library. Issue with this one is that it's reliant on Unix functionality, meaning that it doesn't work out of the box on Windows.

Sure, technically savvy people can go out of their ways to make it work on Windows, either by compiling the source code using Cygwin or maybe using the Linux subsystem for Windows that's available under Windows 11 but, at the end of the day, most normal people won't go through this stuff when there's Skype, Microsoft Teams, Slack and many other alternatives available at their fingertips.

qTox was the last Tox client that still supported Windows out of the box and now that it's also abandoned, a large portion of desktop users will don't have the option anymore to use Tox, sadly.

Sure, this is a huge loss for Windows users, but it's an even larger loss for Tox, as now, a lot of people won't even consider using the protocol anymore, since they won't be able to use it to communicate with friends and family that do use Windows.

The protocol itself is maintained by the previously mentioned c-toxcore github project, which only maintains the library that does all the heavy work behind the scenes and which is used by Tox clients.

The library's latest stable version, 0.2.17, as of the posting of this blog post, was published more than a year ago at this point (13 months, to be exact).

The developers never said that it was being abandoned too, but, personally, if a piece of software doesn't get any updates for more than a year, I really start to wonder if it's still being maintained.

Technically there's also another Tox client that supports Windows called yat, but as of the writing of this blog post, I tried installing it myself and all installation links lead me to a website called www.lovecry.pt that seems to be down.

I also tried to reach that website a week ago and I didn't have any success back then either.

So yeah, I'm not getting my hopes up anymore.

At this point, I'm convinced the Tox protocol is either destined to die sooner or later, as nobody cares about mass surveillance anymore to go through the hoops that is using Tox, or, best case scenario, it becomes a protocol mainly used by third party clients that work only on Unix operating systems and used by a very niche community of privacy focused nerds.

For the past decade that I've been using it, I've never heard anyone mention Tox in day to day conversations, as an alternative to Skype or Discord, and now I'm more than sure I never will.

And with the advent and promotion of the federated communication protocol Matrix, there's even less of an incentive for people to seek out Tox nowadays.

In the end, one really has to wonder: how long does it take for a project to die?

This blog is federated. If you wish to follow this tech blog, please use the following Fediverse handle: @tech@blog.transistor.one

Blog post by Alexandru Pentilescu.

You may contact me at alexandru.pentilescu@disroot.org

Optionally, you may also encrypt your emails to me using the following PGP key: 0xFF49E5748BD42A6A6A7DECFDD38B28DF9F7497A2

Download that key from any keyserver you wish