I do think that fighting the inclusion of DRM in future HTML standards is worthwhile, but this isn't going to get me to pick up a sword.
I do think that fighting the inclusion of DRM in future HTML standards is worthwhile, but this isn't going to get me to pick up a sword.
I am curious if asm.js is quick enough to produce code that could decode encrypted full-screen HD video on browsers whose vendors won't support the media extensions.
Pardon me for ignorance on this subject, but is there something about DRM that requires a plugin or component built into the browser itself? Could our answer to Netflix be, "Write the codec yourself using asm.js"?
I don't know whether Hollywood would consider JS DRM secure enough; it probably depends how good a negotiator you are.
It seems to me that quashing tampering or observing of the trusted component is the lynchpin. In JavaScript, there is no way to access unexposed internals of an IIFE, that seems to me to get us half way there.
I wonder if there could be some way to add a "use trusted" pragma to an IIFE such that the browser would not allow debugging or watching the network traffic of that code? There'd have to be some new way to compare a checksum of the trusted code as well. I suppose that that could suffice in a video watermarking scenario, but Netflix could never watermark each and every video transmitted. I think they partner with some ISP's to cache content near to the users as well, so they're not even responsible for broadcasting the last mile of the video.
I know I am sortof commandeering the word "trusted" for something much weaker than what I think industry wants it to be here, I realize that. Maybe using such a term in a weak solution would satisfy the pointy haired bosses of the world. >:)
Seems to me if some rogue binary goes in and tampers with my Firefox or Chrome binary in order to circumvent browser security, then the browsers would know it and fail with an error. Obviously, any browser that builds from source can be directly modified by a developer.