Hacker News Reader

Comment by dave1010uk | Hacker News Reader

Can anyone explain how this differs from HTTPS in terms of features and goals?

HTTPS is is fundamentally incompatible with caching proxies, CDNs, etc. This scheme would (amongst other things) allow secure exchange of keys (and other data, such as license) while distributing the bulk of the content via http.

This means that the heavy lifting of distributing video can be done by CDNs, with the high-value keys/licenses going over secure links.

And there's more to this than just the transport encryption: it provides a standard API for decryption modules in the client, so a browser doesn't have to understand the details of every technology.

This means that if a provider such as Netflix wanted to, they could supply you with (say) a USB crypto dongle that you would plug in to your PC, which could then interact with your browser to authenticate you, and potentially even decrypt content (or rotating media keys) on the fly. This is, I believe, pretty much what a lot of cable access cards do.

It is providing a mechanism to make it significantly more difficult for the end-user to directly copy/retain the video as it is being streamed to them. 7.3 in the spec is the best example demonstrating how the license model of this implementation differs from how SSL behaves.

HTTPS is fundamentally uncacheable. This specification seems to allow encrypting the media once, and streaming that to everyone.

I take issue with some of the thoughts I see echoed by this and other comments - that the real goal of encrypting video content is to prevent third parties from watching it off the wire, or that the reason we should have DRM is so that video files may be cached.

The goal here is to break the end-user's ability to access the material at will.

Reply on news.ycombinator.com