title: People are STILL Writing JavaScript "DRM"
author: u/medy17
contenttype: redditpost
publication: r/programming
published: 2026-02-27T15:46:15+00:00
sourceurl: https://www.reddit.com/r/programming/comments/1rga6md/peoplearestillwritingjavascriptdrm/
word_count: 417
Link: https://the-ranty-dev.vercel.app/javascript-drms-are-stupid
Score: 170 | Comments: 39 | Subreddit: r/programming
Top Comments
u/Whispeeeeeer (62 pts):
Overall, great article and I learned a lot. I just disagree with the conclusion.
Isn't it also true that TEE doesn't prevent lower level kinds of copying as well? The CPU has to route the audio information to a piece of hardware and - presumably - a user could produce a piece of hardware which acts like a speaker, but functions like a recorder. So, while this DRM is easier to "hack", it serves basically the same purpose, no? A deterrent - as it is mentioned in the article.
Another example I've seen is HDMI splitters to record video output which is encrypted with TEE.
Ultimately I think this claim is where I have the most beef:
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
I just don't think it does require serious time to bypass media-based DRMs. DRMs that obfuscate complex code (like video games) are much harder to get around because you need to find ways to actually decrypt the source. But anything that produces a "static" product like images, videos, music, etc. are always going to be easily bypassed by simply moving the unencrypted bits into a piece of hardware/software you control and recording the unencrypted bits on that hardware (ie., recording signals across HDMI, audio cables, etc.). Because ultimately, all of these static products must interface with something a human can perceive - which leads to generic encodings that currently don't support encryption (god help us if they start integrating encryption into the full life cycle and Spotify only plays music on Spotify^(TM) headphones).
The author seems mostly like they're advocating against building DRMs in JavaScript, but they also counter their own argument too well. It's not to prevent hackers. It's to prevent the layperson.
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.
I would say it is working the way it's intended. Again, I think the article is correct in most of its assertions, I just disagree with the conclusion.
u/Bartfeels24 (51 pts):
Most client-side obfuscation just slows down determined people while annoying your own developers trying to debug production issues. If you're actually worried about IP theft, that's a server-side problem.
u/Snarwin (15 pts):
The purpose of DRM is not really to stop people from copying content, it's to provide a justification for legal action under DMCA section 1201 (or equivalent laws in other jurisdictions). As long as the courts accept it as an "effective access control," it's doing its job.
u/Bartfeels24 (15 pts):
Watched someone spend three weeks obfuscating their React bundle with a custom webpack plugin only to have it cracked in an afternoon because the API keys were still hardcoded in the network tab.
u/Bartfeels24 (14 pts):
Built a canvas drawing app a few years back and watched someone spend twenty minutes trying to deobfuscate my webpack bundle to steal the brush algorithm, which was honestly just Bresenham's line with some easing functions. The whole exercise made me realize most "DRM" in JS is just security theater since the browser literally hands you everything you need to reverse it.