DRM is Killing Software – Fixing It as a Developer
24 January, 2024
After packaging my Gameflip command-line applications into Windows executables (as explored in a previous blog post), end users found it significantly easier to get up and running, with setup now being a single download. This means that they no longer needed my help to set up a clunky Node.js environment and run JavaScript directly on their computer. Great, right? Well, yes. However, it also meant that anyone with the executable and a mouse to double-click could run the app — including those who weren't my customers.
I discovered that my application had been spreading like wildfire between Gameflip sellers with compensation returning back to me for my hard work. If only there was a way to ensure that my customers could use the software like normal, but those with pirated copies couldn't...
Digital Rights Management
DRM or Digital Rights Management is the practice of locking down software or media to limit access. It's primary goal is to stop (or more realistically, hinder and slow) piracy. In terms of software applications, this generally means some form of licencing system.
The solution was to set-up a licencing server. The goal of a licencing server is to determine whether an individual or specific copy of software should be allowed to run. In my case, I don't care where a customer runs the software from — be it their desktop, laptop or even a friends computer — as long as they are a customer.
Licence Keys
Licence keys are simply codes that a user can enter in to validate their purchase of a certain software application. Traditionally, these keys were algorithmically validated offline, i.e. allowing use of the program without internet, but this method has gone out of fashion. Todays, keys are often validated against a licencing server as this process is harder to reverse engineer en masse.
Account-bound Licences
While account-bound licences may seem like a sensible way to ensure that only authorised users can use software, there's a catch. It's well known that friends and family often share a login for Netflix. What would stop someone from doing the same with an account for your software? The answer is that the account has to be important or valuable. For example; its rare that you'd see someone hand over their Google account to a friend due to how much personal information is stored there. All your emails, documents, photos and more are sensitive and important.
Luckily, we can leverage the "importance" or "value" of services like Google or Microsoft accounts to make our licence accounts valuable too. Instead of providing a separate login for our licencing account, we can instead use OAuth to login via the aforementioned methods. This means that in order to share the licence, a customer would also need to share the login details to their Google account... less appealing. While it is possible for someone to create a separate Google account for the sole purpose of sharing a licence, the barrier to entry for this kind of sharing is significantly higher and as we have established, DRM isn't foolproof, it's simply a way of making piracy more inconvenient than just paying for the software in the first place.
Responsible DRM
While it's all well and fine to ensure that you aren't being stolen from using DRM, with great power comes great responsibility. The truth is, a large amount of software featuring DRM sucks. These piracy prevention measures often come at the cost decreased usability. Even the act of entering a licence key in first boot is more cumbersome than just starting the software. The games industry is notorious for creating systems that lock customers out of their accounts, data and or hurting performance. Just take a quick search of Denuvo to see what I'm talking about.
As developers, we must keep in mind that it is our job to implement DRM in a seamless way for customers. There are 3 factors to consider:
- Does the DRM implementation adversely affect the function of the application for customers?
- Will that application still work when the licensing servers are offline or sunset?
- Does the DRM actually discourage or inhibit attempts at piracy?
Reducing DRM Friction
In nearly all cases, DRM makes the user experience of software worse not only for pirates, but also legitimate users — i.e. your customers. Your customers are paying you for a worse experience when you add DRM. It's no wonder there is so much pushback against developers that implement DRM in attempt to bolster their bottom line.
When we add DRM, we should really think about how it will affect the user experience. For example, with my Gameflip bot, I simply ask a user to provide a link to their Gameflip profile when purchasing their licence, and from then on, the user experience is identically to that of the software before the licencing system was implemented. This is because in order to use the Gameflip software, the user needs to configure their Gameflip API credentials. Now, at each startup, the software can silently check that the logged in user has purchased a licence with my licencing server. If the check comes back positive, then the user will have no idea it even happened.
In all, this simple check takes less than a second and only requires additional action from the user once — at the time of purchase. The DRM friction for paying customers in this case is incredibly minimal, reducing the chance that the user experience will be harmed.
Operation into the Future
It's all well and good to provide reliable licencing servers in the short term, however its a complete fantasy to believe that we as developers will maintain a project forever. One of the major arguments against DRM is what happens when the licencing servers go down? The system could break down for any number of reasons; the company no longer wants to pay the cost of maintenance, they can't pay it, perhaps the server moves to a different address or the API spec changes. When building licencing into our software, we can't just code for the happy path. We need to allow for any passive licencing failure to pass through as a success. What do I mean by this?
- 404? 500? Licencing check ✅
- SSL error? Licencing check ✅
- Failed to resolve domain? Licencing check ✅
- Couldn't parse the response? Licencing check ✅
If there is any issue validating the licence, it should instantly be treated as a valid licence. While this policy does allow for workarounds by those smart enough to intercept the response from the licencing server, the reality is, most users will simply just buy the software because it is easier.
Is DRM a Deterrent Anyway?
The last thing to think about is the most fundamental of all. After considering the paying customer experience and adapting your solution to suit, does it prevent piracy in a meaningful way at all? Like seriously, if its trivial to work around, what the point in implementing DRM at all? The process takes time, testing, and inevitably some annoyed users when you mess up in production. Just taking a few minutes to brainstorm some potential workarounds or pitfalls could save you hours of work.
What DRM should be
DRM isn't the cure-all for piracy, it's merely an speed bump. It's an inconvenience that should make paying for your work the easier choice, while not passing on this burden to your customers. For the sake of all of us, developers and customers alike, I ask that when you next implement DRM into your product, take the time to think about what responsible DRM looks like.
