JavaScript DRMs are Stupid and Useless

A while back, I was browsing Reddit and came across a thread about hotaudio.net. For those unfamiliar, it’s a website developed by u/fermaw, the very same developer behind the ever-popular gwasi.com.

If neither of those websites rings a bell, then I need to welcome you to r/GoneWildAudio: an NSFW subreddit for ASMR. Stay and read, the ASMR is only part of this odd tale.

You see, not too long ago, Soundgasm, Mega, and a few others were quite popular for hosting these audios, but as ToS tightened and taboo topics got more taboo, other platforms popped up to fill the gap.

HotAudio is one of them, but in a different way. Their claim is offering DRM for ASMRtists—a rare thing in the ASMR space, let alone the NSFW ASMR space.

u/fermaw, the aforementioned developer, was bragging in that thread I mentioned earlier about coding a DRM and how he found it rather “fun” to do so.

I have no doubt it was fun, and believe me, this post is not meant to ridicule anyone or incite any form of hate, but I think calling it “DRM” is a little far-fetched.

Long before the days of Denuvo, the now-infamous game DRM, we knew that any such system living in the user’s accessible memory was vulnerable. So, we shifted to what we call today a Trusted Execution Environment (TEE).

I’d like to quote Microsoft here: “A Trusted Execution Environment is a segregated area of memory and CPU that’s protected from the rest of the CPU by using encryption. Any code outside that environment can’t read or tamper with the data in the TEE. Authorized code can manipulate the data inside the TEE.”

See what I’m getting at? JavaScript code is fundamentally a “userland” thing. The code you ship is accessible to the user to modify and fuck about with however they wish.

This is the problem with u/fermaw’s “DRM.” No matter how many clever keys, nonces, and encrypted file formats he attempts to send to the user, eventually, the very same JavaScript code will need to exit his decryption logic and—whoops—it goes plain Jane into digital and straight to the speakers.

On Elephants in the Room: Trusted Execution Environments

Before we get into the code, we need to understand why this was always going to end in a bloodbath. The entire history of DRM is, at its core, a history of trying to give someone a locked box while simultaneously handing them the fucking key. The film and music industries have been losing this battle since the first CSS-encrypted DVD was cracked in 1999.

The modern, professional answer to this problem is the Trusted Execution Environment, or TEE.

As quoted above, a TEE is a hardware-backed secure area of the main processor (like ARM TrustZone or Intel SGX). Technically speaking, the TEE is just the hardware fortress (exceptions exist like TrustZone) whilst a Content Decryption Module (CDM) like Google’s Widevine, Apple’s FairPlay, and Microsoft’s PlayReady use the TEE to ensure cryptographic keys and decrypted media buffers are never exposed to the host operating system let alone the user’s browser. For the purposes of this article, I may at times refer to them interchangeably but all you need to know is that they work together and in any case, the host OS can’t whiff any of their farts so to speak.

However, getting a Widevine licence requires a licensing agreement with Google. It requires native binary integration. It requires infrastructure, legal paperwork, not to mention, shitloads of money. A small NSFW audio hosting platform is not going to get a Widevine licence. They’d be lucky if Google even returned their emails. Okay maybe not quite but the point is they’re not getting Widevine.

So what does HotAudio do then? Based on everything I could observe, they implement a custom JavaScript-based decryption scheme. The audio is served in an encrypted format chunked via the MediaSource Extensions (MSE) API and then the player fetches, decrypts, and feeds each chunk to the browser’s audio engine in real time. It’s a reasonable-ish approach for a small platform. It stops casual right-clickers. It stops people opening the network tab and downloading the raw response file, only to discover it won’t play. For most users, that friction is sufficient.

Unfortunately for HotAudio, every r/DataHoarder user worth their salt knows these types of websites don’t have proper blackbox DRMs so it’s only a matter of time before someone with a tool they crafted with spit and spite shows up.

It just doesn’t stop someone who understands exactly where the decrypted data has to appear.

The “PCM Boundary”: a Wannabe-DRM Graveyard

Let me introduce you to what I call the PCM boundary. PCM (Pulse-Code Modulation) is the raw, uncompressed digital audio format that eventually gets sent to your speakers. It’s the terminal endpoint of every audio pipeline, regardless of how aggressively encrypted the source was.

graph TD
    Server[HotAudio Server] -->|Sends Encrypted audio chunks| JS[JavaScript Player]
    JS -->|Decrypts using proprietary logic| DecryptedData([Decrypted Data])
    DecryptedData -->|Calls appendBuffer| Hook[Hook]
    
    Hook -.->|GOLDEN INTERCEPT| SavedAudio[(Captures Pristine Audio File)]
    
    Hook -->|Forwards genuine appendBuffer| MSE[MediaSource API]
    MSE -->|Feeds to codec decoder| Decoder[Browser Decoder]
    Decoder -->|PCM audio output| Speakers[Speakers]

For our purposes, we don’t even need to chase it all the way to raw PCM which is valid avenue albeit in the realm of WEBRips and not defacto “downloaders.” We just need to find the last point in the pipeline where data is still accessible to JavaScript and that point is the MediaSource Extensions API, specifically the SourceBuffer.appendBuffer() method.

In practice:

1. Your JavaScript code creates a MediaSource object and attaches it to a <video> or <audio> element via a blob URL.
2. You call mediaSource.addSourceBuffer(mimeType) to declare what codec format you’ll be feeding the buffer.
3. You repeatedly call sourceBuffer.appendBuffer(data) to push chunks of (in our case, pre-decrypted) encoded audio data to the browser.
4. The browser’s internal decoder handles the rest: decoding the codec, managing the playback timeline, and routing audio to the hardware.

Notice how by step 3, the time HotAudio’s player calls appendBuffer, the data has already been decrypted by their JavaScript code. It has to be. The browser’s built-in AAC or Opus decoder doesn’t know a damn thing about HotAudio’s proprietary encryption scheme. It only speaks standard codecs. The decryption must happen in JavaScript before the data is handed to the browser.

This means there is a golden moment: the exact instant between “HotAudio’s player finishes decrypting a chunk” and “that chunk is handed to the browser’s media engine.” If you can intercept appendBuffer at that instant, you receive every chunk in its pristine, fully decrypted state, on a silver fucking platter.

Anyways, that is the fundamental vulnerability that no amount of encryption-decryption pipeline sophistication can close. You can make the key as complicated as you like. You can rotate keys per session, per user, per chunk. But eventually, the data has to come out the other end in a form the browser can decode. And that moment is yours to intercept.

Now. Let’s talk about how this little war actually played out. Dramatised and Ribbed™ for your pleasure.

Act One: Smash and Grab (V1.0)

The first version of my extension was built on a simple observation: HotAudio’s player was exposing its active audio instance as a global variable. You could just type window.as into the browser console and there it was; The entire audio source object, sitting in the open like a wallet left on a park bench.

The approach had two parts. The extension would attempt to modify a JavaScript file that was always shipped with every request: nozzle.js.

Essentially, this specific block would be appended to the top of nozzle.js before the stream had even begun which would compromise the environment from the get go.

// 1. I first prepare a place to store the intercepted chunks
window.DECRYPTED_AUDIO_CHUNKS = [];
console.log('[HIJACK] Audio chunk collector is ready.');

// 2. Then hijack the function that receives encrypted audio
const originalAppendBuffer = SourceBuffer.prototype.appendBuffer;
SourceBuffer.prototype.appendBuffer = function(data) {
    // 3. Save the copies
    window.DECRYPTED_AUDIO_CHUNKS.push(data);
    console.log(`[HIJACK] Captured a decrypted chunk. Size: ${data.byteLength} bytes. Total chunks: ${window.DECRYPTED_AUDIO_CHUNKS.length}`);

    // 4. Call the original function so the audio would still play
    return originalAppendBuffer.apply(this, arguments);
};

This is, without exaggeration, a client-side Man-in-the-Middle attack baked directly into the browser’s extension API. The site requests its player script; the extension intercepts that network request at the manifest level and silently substitutes its own poisoned version. HotAudio’s server never even knows.

Once the hook was in place, the automation script grabbed window.as.el, muted it, slammed the playback rate to 16 (can’t go faster since that is the maximum supported by browsers), and sat back as the browser frantically decoded and fed chunks into the collection array. When the ended event fired, the chunks were stitched together with new Blob() and downloaded as an .m4a file.

Checkmate-ish.

The First Counter-Attack

Of course, this was a patch war. According to various Reddit threads and GitHub Issues, fermaw is known for patrolling subreddits and Issues looking for ways in which devs have attempted bypasses in order to patch them.

It was only a matter of time. Indeed by week two of the extension’s public release on GitHub, he had patched the vulnerability.

First, he stopped exposing his player instance as a predictable global variable. He wrapped his initialisation code tightly so that window.as no longer pointed to anything useful. Without the player reference, my automation script had nothing to grab, nothing to control, nowhere to start.

Second, and more cleverly: he implemented a hash verification check on nozzle.js. The exact implementation could have been Subresource Integrity (SRI), a custom self-hashing routine, or a server-side nonce system, but the effect was the same. When the browser (or the application itself) loaded the script, it compared the modified file against a canonical hash and if it did not pass the check, the player would never initialise.

This effectively meant the old method was dead.

Act Two: Traps and Dicks. Synonyms and Subs-titutes.

Fermaw’s In-Memory Defences

I suppose at this point, fermaw assumed he was dealing with someone who wasn’t going to just fuck off. And I wasn’t. It was as fun for me to try and beat as it was for him to develop.

His response was to implement anti-tamper checks at the JavaScript level. Specifically, he started inspecting his own critical functions using .toString().

This is a well-known browser security technique. In JavaScript, calling .toString() on a native browser function returns "function appendBuffer() { [native code] }". Calling it on a JavaScript function returns the actual source code. So if your appendBuffer has been monkey-patched, .toString() will betray you; it’ll return the attacker’s JavaScript source instead of the expected native code string.

Fermaw added checks along the lines of:

if (
  !SourceBuffer.prototype.appendBuffer.toString().includes('[native code]')
) {
  // We've been tampered with. Refuse to play.
  throw new Error('Integrity check failed.');
}

Fermaw also, it seems, started obfuscating and scrambling how his player was initialised, making the AudioSource class harder to find via the polling loop. The constructor hijack became unreliable.

Enter, the Omni-Trap.

My technique had changed at this point. Since he was trying multiple things, well, I had to as well.

First: mockToString — The Lie That Defeats The Check

The single most important addition in V2 was a function to make my hooked methods lie about what they are:

function mockToString(target, name) {
  try {
    target.toString = function () {
      return `function ${name}() { [native code] }`;
    };
  } catch (e) {
    console.warn('[Hotaudio] Failed to mock toString', e);
  }
}

After hooking any function, I immediately called mockToString on it. From that point on, if fermaw’s integrity check asked .toString() whether appendBuffer was native, it would receive the pristine, authentic-looking answer: function appendBuffer() { [native code] }. Basically, it’s like asking your ex if they cheated on you and they did but they say they didn’t and you take their word for it because reasons. Don’t worry, on écoute et on ne juge pas.

Fermaw’s anti-tamper check was now returning a false negative. The enemy’s spy was wearing his uniform.

Second: Ambushing HTMLMediaElement.prototype.play

I gave up entirely on finding the player by name. Instead of looking for window.as or window.AudioSource, I simply staked out the exit. I hooked the most generic, lowest-level method available:

const originalPlay = HTMLMediaElement.prototype.play;
HTMLMediaElement.prototype.play = function () {
  window.__ha_player = this;
  window.postMessage({ type: 'HOTAUDIO_PLAYER_READY' }, '*');
  return originalPlay.apply(this, arguments);
};
mockToString(HTMLMediaElement.prototype.play, 'play');

The logic is fairly simple: I don’t give a shit what you name your player object. I don’t care how deeply you bury it in a closure. I don’t care what class you instantiate it from. At some point, you have to call .play(). And when you do, I’ll be waiting.

I was confident in that approach because you would not call multiple .play()s on the same page to lead a reverse engineer astray. Why? Because mobile devices typically speaking will pause every other player except one. If fermaw were to do that, it’d ruin the experience for mobile users even if desktop users would probably be fine. It also makes casting a bitch and a half. Even if you did manage to pepper them around, it would be fairly easily to listen in on all of them and then programmatically pick out the one with actually consistent data being piped out.

Now then, the moment HotAudio’s player commanded the browser to begin playback, the hook snapped shut. The audio element, this, was grabbed and stored. mockToString ensured the hook was invisible to integrity checks.

Third: Keep it Untouchable (Object.defineProperty)

When hijacking the Audio constructor, I also used Object.defineProperty with a specific, paranoid configuration:

Object.defineProperty(window, 'Audio', {
  value: HijackedAudio,
  writable: false,
  configurable: false,
});

writable: false means no code can reassign window.Audio to a different value. configurable: false means no code can even call Object.defineProperty again to change those settings. If fermaw’s initialisation code tried to restore the original Audio constructor (a perfectly sensible defensive move) the browser would either fail or throw a TypeError. The hook was permanent for the lifetime of the page.

Act Three: Choking on Natives (V3.0)

Iframes and the Shadow DOM

By this point, fermaw understood that his player instance was being ambushed whenever it called .play(). He tried to isolate the player from the main window context entirely.

The two primary techniques at his disposal were iframes and Shadow DOM.

An <iframe> creates a completely separate browsing context with its own window object, its own document, and most importantly;its own prototype chain. A function hooked on HTMLMediaElement.prototype in the parent window is not the same object as HTMLMediaElement.prototype in the iframe’s window. They’re entirely separate objects. If fermaw’s audio element lived inside an iframe, my prototype hook in the parent window would never fire.

Shadow DOM is a web component feature that lets you attach an isolated DOM subtree to any HTML element, hidden from the main document’s standard queries. A querySelector('audio') on the main document cannot see inside a Shadow Root unless you specifically traverse into it. If fermaw’s player was mounted inside a Shadow Root, basic DOM searches would come up empty.

On top of this, fermaw was likely switching to assigning audio sources via srcObject rather than the src attribute. srcObject accepts a MediaStream or MediaSource object directly, bypassing the standard URL assignment path that’s easier to intercept.

V3.0 — Hooks, Crooks, and Nooks

My response was to abandon trying to intercept at the level of individual elements and instead intercept at the level of the browser’s own property descriptors. I went straight for HTMLMediaElement.prototype with Object.getOwnPropertyDescriptor, hooking the native src and srcObject setters before any page code could run:

// Hook the 'src' property setter on ALL media elements, forever
try {
  const srcDesc = Object.getOwnPropertyDescriptor(
    HTMLMediaElement.prototype,
    'src',
  );
  if (srcDesc && srcDesc.set) {
    const origSet = srcDesc.set;
    const hookedSet = function (v) {
      capturePlayer(this);
      return _call.call(origSet, this, v);
    };
    spoof(hookedSet, origSet);
    _defineProperty(HTMLMediaElement.prototype, 'src', {
      ...srcDesc,
      set: hookedSet,
    });
  }
} catch (e) {}

// Same for 'srcObject' catches MediaSource-based streams
try {
  const srcObjDesc = Object.getOwnPropertyDescriptor(
    HTMLMediaElement.prototype,
    'srcObject',
  );
  if (srcObjDesc && srcObjDesc.set) {
    const origSet = srcObjDesc.set;
    const hookedSet = function (v) {
      capturePlayer(this);
      return _call.call(origSet, this, v);
    };
    spoof(hookedSet, origSet);
    _defineProperty(HTMLMediaElement.prototype, 'srcObject', {
      ...srcObjDesc,
      set: hookedSet,
    });
  }
} catch (e) {}

HTMLMediaElement.prototype is the browser’s own internal prototype for all <audio> and <video> elements and by redefining the property descriptor for src and srcObject on this prototype, I ensured that regardless of where the audio element lives (whether it’s in the main document, inside an iframe’s shadow, or buried inside a web component) the moment any source is assigned to it, the hook fires. The element cannot receive audio without announcing itself.

Even if fermaw’s code lives in an iframe with its own HTMLMediaElement, the prototype hookery via document_start injection means my hooks are installed before the iframe can even initialise.

But the triumphance of V3 is in the addSourceBuffer hook which solves a subtle problem. In earlier versions, hooking SourceBuffer.prototype.appendBuffer at the prototype level had a vulnerability in that if fermaw’s player cached a direct reference to appendBuffer before the hook was installed (i.e., const myAppend = sourceBuffer.appendBuffer; myAppend.call(sb, data)), the hook would never fire. The player would bypass the prototype entirely and call the original native function through its cached reference.

try {
  const MS = window.MediaSource || window.ManagedMediaSource;
  if (MS && MS.prototype) {
    const origAddSB = MS.prototype.addSourceBuffer;

    const hookedAddSB = function addSourceBuffer(mimeType) {
      const sb = _apply.call(origAddSB, this, arguments);

      // Hook the SourceBuffer INSTANCE immediately,
      // before anyone else can cache a reference to appendBuffer
      try {
        const origAppend = sb.appendBuffer;
        const hookedAppend = function appendBuffer(data) {
          try {
            _chunks.push(data);
          } catch (e) {}
          return _apply.call(origAppend, this, arguments);
        };

        spoof(hookedAppend, origAppend);

        _defineProperty(sb, 'appendBuffer', {
          value: hookedAppend,
          writable: true,
          configurable: true,
        });
      } catch (e) {}

      return sb;
    };

    spoof(hookedAddSB, origAddSB);
    MS.prototype.addSourceBuffer = hookedAddSB;
  }
} catch (e) {}

The V3 approach obliterates this race condition by hooking addSourceBuffer at the MediaSource.prototype level, I intercept the creation of every SourceBuffer. The moment a buffer is created and returned, I immediately install a hooked appendBuffer directly on that specific instance; before any page code can even see the instance, let alone cache a reference to its methods. The hooked appendBuffer is installed as an own property of the instance, which takes precedence over the prototype chain. There is no window for fermaw to cache the original. The hook is always first.

To catch any elements that somehow slipped through all of the above, I added capturing-phase event listeners as a belt-and-braces fallback:

// document_start means these listeners are in place before any element exists
document.addEventListener(
  'play',
  (e) => {
    if (e.target?.tagName === 'AUDIO' || e.target?.tagName === 'VIDEO')
      capturePlayer(e.target);
  },
  true,
); // <-- 'true' = capture phase, fires on the way DOWN the DOM tree

document.addEventListener(
  'loadedmetadata',
  (e) => {
    if (e.target?.tagName === 'AUDIO' || e.target?.tagName === 'VIDEO')
      capturePlayer(e.target);
  },
  true,
);

The true flag for useCapture is important. Browser events propagate in two phases: first, they travel down the DOM tree from the root to the target (capture phase), then they bubble up from the target back to the root (bubble phase). By listening in the capture phase, my listener fires before any event listener attached by HotAudio’s player code. Even if fermaw tried to cancel or suppress the event, he’d be too late because the capturing listener always fires first.

The combination of all four layers in addSourceBuffer at the MediaSource prototype level, src and srcObject property descriptor hooks, play() prototype hook, and capture-phase event listeners means there is, practically speaking, no architectural escape route left. The entire browser surface area through which a media element can receive and play audio has been covered. How fucking braggadocious of me to say that. I will be humbled in due time. That much is universal law.

Automation: Rinsing It in Seconds

With the capture hooks in place, the automation script handles the actual download process. The approach has been refined significantly across the three versions, but the core idea has remained fairly constant: trick the browser into buffering the entire audio track as fast as the hardware and network allow, rather than in real time.

The script grabs the captured audio element, mutes it, sets playbackRate to 16 (the browser maximum), seeks to the beginning, and calls .play(). The browser, in its infinite eagerness to keep the buffer full ahead of the playback position, frantically fetches, decrypts, and feeds chunks into the SourceBuffer. Every single one of those chunks passes through the hooked appendBuffer and gets collected.

Of course, fermaw does have protections against this. For one, he aggressively throttles bursty traffic meaning downloads can go from a few hundred KB/s to 50-ish KB/s. Of course, it will in every case be several times faster than listening and recording anyways.

Fermaw cannot realistically slow down the stream more than that since it would stutter real traffic that has a download-y pattern. There is a possibility that he could enforce IP bans on patterns that display it but it would have to risk blanket bans against possible CGNAT traffic. There are ways to get around it but it prolongs the inevitable.

audioElement.currentTime = 0;
audioElement.playbackRate = 16;
audioElement.muted = true;
audioElement.play().catch((e) => {
  cleanup();
  updateStatus('ERROR: PLAY FAILED', -1);
});

V3 also added adaptive speed control. Rather than blindly holding at 16x, the script monitors the audio element’s buffered time ranges to assess buffer health. If the buffer ahead of the playback position is shrinking (meaning the network can’t keep up with the decode speed), the playback rate is reduced to give the fetcher time to catch up. If the buffer is healthy and growing, the rate is nudged back up. This prevents the browser from stalling entirely on slow connections, which would previously break the ended event trigger and leave you waiting forever.

const monitorBufferHealth = () => {
  if (audioElement.paused || audioElement.ended || downloadTriggered) return;
  if (audioElement.buffered.length > 0) {
    const current = audioElement.currentTime;
    let bufferedEnd = 0;
    for (let i = 0; i < audioElement.buffered.length; i++) {
      if (
        audioElement.buffered.start(i) <= current &&
        audioElement.buffered.end(i) > current
      ) {
        bufferedEnd = audioElement.buffered.end(i);
        break;
      }
    }
    const bufferAhead = bufferedEnd - current;
    if (bufferAhead > 15) {
      setSpeed(currentSpeed + 0.5); // Comfortable, push faster
    } else if (bufferAhead < 3 && currentSpeed > 2) {
      setSpeed(currentSpeed - 1.0); // Starvation, back off
    }
  }
};

When the track ends—detected either via the ended event or via the stall watcher noticing the currentTime approaching durationit will collect chunks that are stitched together:

const blob = new Blob(chunks, { type: 'audio/mp4' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = `${filename}.m4a`;
a.style.display = 'none';
document.body.appendChild(a);
a.click();

There is a minor artefact in the final file. The stitched .m4a sometimes contains silent padding at the start or end from incomplete chunks at buffer boundaries. A quick ffmpeg pass fixes it cleanly:

ffmpeg \
  -err_detect ignore_err \
  -fflags +genpts+discardcorrupt+igndts \
  -analyzeduration 500M \
  -probesize 500M \
  -i input.m4a \
  -af "aresample=async=1:first_pts=0,aformat=sample_fmts=fltp:\
sample_rates=44100:channel_layouts=stereo,silenceremove=start_periods=0:\
start_threshold=-90dB,loudnorm" \
  -c:a libmp3lame \
  -q:a 2 \
  fixed.mp3

The Technical Footnote: Why the spoof() Function is Different in V3

Across all three versions, there’s a mockToString or spoof helper. But the V3 implementation is subtly more robust than the V2 one, and it’s worth examining why.

V2’s version was straightforward:

function mockToString(target, name) {
  target.toString = function () {
    return `function ${name}() { [native code] }`;
  };
}

This works, but it has a vulnerability: it hardcodes the native code string manually. If fermaw’s integrity check was especially paranoid and compared the spoofed string against the actual native code string retrieved from a trusted reference (say, by calling Function.prototype.toString.call(originalFunction) on a cached copy of the original), the manually crafted string might not match precisely, particularly across different browser versions or platforms where the exact whitespace or formatting of [native code] strings varies slightly.

I tried to solve it somewhat elegantly:

function spoof(fake, original) {
  const str = _call.call(_toString, original);
  _defineProperty(fake, 'toString', {
    value: function () {
      return str;
    },
    writable: true,
    configurable: true,
  });
  return fake;
}

Instead of hardcoding the expected string, it captures the actual native code string from the original function before hooking it, then returns that exact string. This way, no matter what browser, no matter what platform, the spoofed toString returns precisely the same string that the original function would have returned. It is, in effect, a perfect forgery.

Also note the use of _call.call(_toString, original) rather than simply original.toString(). This is because original.toString might itself be hooked by the time spoof is called. By holding cached references to Function.prototype.call and Function.prototype.toString at the very beginning of the script (before any page code runs), and invoking them via those cached references, the spoof function is immune to any tampering that might have happened in the interim. It’s eating its own tail in the most delightful way.

Ethics, Grandstanding, Pretentiousness, and Playing Wise

DRM, as an industry institution, has an almost comically bad track record when it comes to actually protecting content. Denuvo which is perhaps the most sophisticated game DRM ever deployed commercially has been cracked for virtually every major game it’s protected, usually within weeks of release. Every DVD ever made is trivially rippable. Every Blu-ray. Every streaming service has been ripped by someone, somewhere.

The reason is always the same: the content and the key that decrypts it are both present on the client’s machine. The user’s hardware decrypts the content to display it. The user’s hardware is, definitionally, something the user controls. Any sufficiently motivated person with the right tools can intercept the decrypted output.

For a small NSFW audio platform run by a solo developer, “true” blackbox DRMs running with TEEs are not a realistic option. Which brings me to the point I actually want to make:

The HotAudio DRM isn’t stupid because fermaw is stupid. It’s the best that JavaScript-based DRM can be. He implemented client-side decryption, chunked delivery, and active anti-tamper checks and for the vast majority of users, it absolutely works as friction. Someone who just wants to download an audio file and doesn’t know what a browser extension is will be stopped completely.

The problem is that calling it “DRM” sets expectations it simply cannot meet. Real DRM, you know; the kind that requires a motivated attacker to invest serious time and expertise to defeat; lives in hardware TEEs and requires commercial licensing. JavaScript DRM is not that. It’s sophisticated friction. And sophisticated friction, while valuable, is a completely different thing.

The question is whether any DRM serves ASMRtists well. Their audience is, by and large, not composed of sophisticated reverse engineers. The people who appreciate their work enough to want offline copies are, in many cases, their most dedicated fans. The kind who would also pay for a Patreon tier if one were offered. The people who would pirate the content regardless are not meaningfully slowed down by JavaScript DRM; they simply won’t bother and will move on to freely available content or… hunt down extensions that do the trick, I suppose.

I’m genuinely not convinced the DRM serves the creators it’s designed to protect. But I acknowledge that this is a harder conversation than just the technical one, and reasonable people can disagree.

Happy Endings

I got all the dopamine I needed from “reverse engineering” this “DRM.” I don’t imagine there’s any point continuing its development considering the fact that I have made my point abundantly clear even beyond this very article.

I hate DRM, I love FOSS, I love the very idea that the internet should be open and accessible.

Unfortunately, the Internet is no longer just a toy for the nerds amongst us. For many, it’s a source of income and a way to put food on the table. So I do understand that DRM is in turn a way for people to feel protected against “pirates” threatening their livelihoods. I don’t think it works the way it’s intended to work but I suppose I cannot fault fermaw for wanting to create a solution for the ASMRtists who felt they needed it.

Just… don’t do it with JavaScript ffs.

Until next time :)