4 ms·

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

• ecaron 15y ago
  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.
• Tuna-Fish 15y ago
  HTTPS is fundamentally uncacheable. This specification seems to allow encrypting the media once, and streaming that to everyone.
  • dthunt 15y ago
    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.
• ldite 15y ago
  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.
  • ldite 15y ago
    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.