Skip to content
securelms

Video protection

security architecture

seven independent layers stand between your course video and unauthorized redistribution. defeating one layer yields nothing: each assumes the others can fail.

01

encrypted media at rest

every lesson is stored and delivered as AES-128 encrypted HLS. files on servers and CDN edges are ciphertext; a leaked segment file alone plays nothing.

02

token-gated key delivery

decryption keys are never public. the key endpoint requires a signed, short-lived token minted only for an authenticated, entitled viewer.

03

asset-bound tokens

each playback token is cryptographically bound to one specific video. a token issued for lesson A can never fetch the key for lesson B.

04

signed segment urls

individual video segments are unfetchable without valid, per-session authorization. copying a url out of the player gives an attacker nothing durable.

05

short-lived credentials

playback authorization expires quickly and is refreshed continuously for legitimate viewers. shared links die fast by design.

06

session authentication

everything sits behind account-level auth: signed JWTs, refresh rotation, and server-side session controls in front of every media route.

07

identity watermarking & client hardening

each stream renders the viewer's own identity into the frame, repositioning continuously. screen-capture APIs are intercepted, and automation signals are denied playback.

Honest limits

what this does, and what nothing can do

what encryption stops

downloading a playable file, sharing working stream links, scraping segments, replaying expired sessions, and cross-account key reuse.

what encryption cannot stop

pointing a camera at a screen. no vendor can prevent that, which is why every frame carries the viewer's identity. a leaked recording traces back to the exact account that made it.

deterrence, not theater

client-side defenses (capture interception, automation detection) raise the cost of extraction. we treat them as one layer of seven, never as the security boundary itself.

reporting a vulnerability

found a weakness in any of these layers? we want to know before anyone else does. email datatechsonline@gmail.com with reproduction steps and we'll respond within two business days. good-faith research is welcome; we don't pursue researchers acting responsibly.

questions about protecting your own course content? talk to us.