The "downloads anything" lie
There's a whole genre of download tool that promises to grab anything you point it at. Paste a URL, get a file. It's a comfortable promise, and it collapses the moment you paste a Netflix link.
The collapse is usually quiet. The tool accepts the URL. A progress bar appears. Segments start downloading. A few seconds in, or a few minutes in, or right at the end during the mux, something fails, and the error is almost always useless. "Download failed." "Decryption error." "Unknown codec." You wonder if you picked the wrong quality, if the network dropped, if the tool is broken today. You retry. It fails again.
The answer -- "this stream is protected and was never going to download" -- was knowable before the first byte got fetched. A tool that waits until the end to tell you isn't being thorough. It just hasn't bothered to check.
What DRM actually is
When people say "DRM" on the modern web, they almost always
mean one of two systems: Google's Widevine (used
by Netflix, Prime Video, Disney+, most of the web) or Apple's
FairPlay (used by Apple TV+ and a handful of
others). They work the same way in outline. The video is
encrypted with a content key. The content key lives on a
license server. To decrypt a segment, your player has to talk
to a CDM -- a content decryption module -- which
performs a cryptographic handshake with the license server,
receives a wrapped key, and unwraps it inside a trusted
environment the user can't touch.
The CDM is the whole point. It separates "encrypted content" from "content encrypted with a key you're allowed to have." A normal HTTP client can't impersonate a CDM. The license server won't hand over a usable key without the handshake, and the handshake can't be faked by a download manager written in Swift. That's the design of the system, and the design works.
AES-128 is not DRM
Here's the distinction that trips everyone up. A lot of HLS streams -- including many that have nothing to do with Netflix or Disney+ -- use AES-128 encryption on their segments. The manifest declares a key URL. The player fetches the key over HTTPS. Segments get decrypted and played. On the surface this looks like DRM, and it isn't.
AES-128 segment encryption is transport integrity, not rights management. The key is served to anyone who can fetch the manifest. There's no license server, no CDM, no handshake. It's a speed bump against passive sniffing, not a wall. DRM is the wall.
Veloxar handles AES-128 HLS fine. That's covered in the
adaptive streaming
post; the key request is another HTTP call. I'm not going
to pretend the same approach works for Widevine.
"Fetch a key over HTTPS" and "negotiate with a license server
through a trusted CDM" are two different problems, and
optimism doesn't close the gap between them.
Detection happens before the first segment
The useful thing about DRM is that it announces itself. HLS
manifests declare protected streams through
EXT-X-SESSION-KEY or EXT-X-KEY lines
with a method that gives the system away. DASH manifests
embed ContentProtection elements that name the
scheme directly, usually with a com.widevine.alpha
or com.apple.fps URI. MPEG-CENC markers in init
segments are another reliable signal.
A FairPlay stream in HLS looks, in the manifest, like this:
#EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://license.example/key",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"
METHOD=SAMPLE-AES with a skd://
scheme is unambiguous. A Widevine stream in DASH is equally
unambiguous. Veloxar reads the manifest, scans for these
markers, and classifies the stream before any segment fetch
starts. The cost is a single HTTP request and a few hundred
microseconds of string matching.
What "fail fast" means in practice
When detection fires, the download doesn't start. It fails immediately with a message that names the protection system and makes the limit explicit: "This stream is protected with Widevine. Veloxar can't download protected content." No retries. No placeholder file. No partial state.
Bluntness matters here because ambiguity is what burns time. A task that fails with "decryption error" and sits in the queue looking retry-able will get retried. The user will also wonder if it's their fault, or their network, or the host, and spend twenty minutes debugging a situation with no debug path. The honest message closes that loop in under a second. Paste the link, get an answer, move on.
The commit that added this landed as
feat: DRM detection -- fail fast with clear message on
Widevine/FairPlay streams. It's a small change by line
count and a large change by UX.
Why the refusal is technical, not moral
Veloxar isn't refusing because I think users shouldn't have the content. It's refusing because the content cannot be downloaded without attacking the key system, and attacking the key system is a different project on a different legal footing. That's a technical limit stated plainly.
The side effect is that being correct at the edges is how a
tool earns trust on the middle cases. A download manager that
lies to you about Netflix is the same download manager that
will shrug about the quality it picked or the file it
produced. I'd rather be precise about Widevine
and FairPlay than vague about the easy stuff.
The other thing worth mentioning: starting a download, fetching hundreds of megabytes, and failing on decryption burns bandwidth on both ends. Fail-fast is cheaper for everyone involved.
On a Netflix link
You paste a Netflix link. The task appears in the queue. A beat later, not a progress bar or a five-minute spinner, the task turns red with a sentence that says what went wrong and why retrying won't help. Delete it. Move on.
Paste an AES-128 HLS link from a normal CDN and it downloads. Paste a DASH manifest with no protection markers and it downloads. The only thing that fails is the thing that was never going to work, and it fails in the time it takes to read one manifest.