3 ms·

If I understand correctly, this is to protect the content during delivery over Internet. But the user agent is free to do whatever it wants with the content onc

by kennu 15y ago

If I understand correctly, this is to protect the content during delivery over Internet. But the user agent is free to do whatever it wants with the content once it gets the decryption key. I suppose servers could decline to give the keys out to untrusted user agents.

beggi 15y ago
Hmm, i haven't read the draft but doesn't just https cover what you're saying?
- Tuna-Fish 15y ago
  HTTPS streams cannot be cached, and encrypting large media streams on the fly to all your clients would be rather expensive.
  - dthunt 15y ago
    The expensive part of https is session creation.
    - Tuna-Fish 15y ago
      ... only because the typical http session is a few tens kilobytes. When you want to stream gigabytes of data for each client, for millions of clients at a time, you are going to start caring about the overheads you create elsewhere in the pipeline.
      - dthunt 15y ago
        Sorry. I should be more clear. The initiation of an HTTPS session is expensive because it consumes a large chunk of CPU for a real-world-measurable chunk of time, all at once, in most libraries. Everything beyond that point you're dealing with <use algorithm of choice> over <max of 32kb> of data. It does indeed consume CPU. It does indeed consume perhaps 8x MORE memory than a typical http connection - but the memory side here is completely dominated by the fact that we're trying to cache multiple gigabytes of data. You can serve HTTP faster than you can serve HTTPS with less CPU - this is objective fact. But if we're talking about CPU utilization? I can't speak to whether this argument has traction right now, for large connections, relative to the claimed 'non-problem' position of several companies who serve small sessions dominated by that connection time, but as time passes it's going to be even less coherent a position than it is right now.
dhx 15y ago
It may be possible under the proposal but is distant from the intended or anticipated uses. This proposed extension appears to provide a means for distributing keys between DRM chips/implementations (BD+/AACS/etc) and a remote license server. The reason this is a HTML specification extension is that Netflix and Google want to use <video> within HTML -- thus the browser environment must become responsible for interfacing between the DRM implementation and license providers. Knowing the "keys" being transmitted is not useful because they'll be encrypted using public key cryptography. A heavily protected/tamperproof[1] DRM chip will have access to the actual keys required to decrypt the content. This could take the form of a Trusted Platform Module (TPM) as part of the widely criticised "Trusted Computing" initiative (is this one of the reasons why Microsoft is involved with the proposal?). Some of the motivations of pushing towards this heavily restricted and inaccessible method of delivering content could include: 1) Ability to lock content to particular devices (iPhone users can access a TV show 2 weeks before anyone else). 2) Taking control over the purchasing cycle of consumers by forcing constant hardware upgrades. 3) Renting content for short durations of time under very specific conditions and limitations. 4) Pricing content on a per-user basis (some users pay more than others for the same content) [1] Security Engineering, Edition 1, Chapter 14 by Ross Anderson - https://www.cl.cam.ac.uk/~rja14/Papers/SE-14.pdf https://www.cl.cam.ac.uk/~rja14/Papers/SE-14.pdf
- alan_cx 15y ago
  "It may be possible under the proposal but is distant from the intended or anticipated uses." Always a scary sentence.
alanh 15y ago
> untrusted user agents All user agents are untrusted, and for that matter, are often not the UA they claim to be. C’est la vie.

by kennu 15y ago

beggi 15y ago

Hmm, i haven't read the draft but doesn't just https cover what you're saying?

Tuna-Fish 15y ago
HTTPS streams cannot be cached, and encrypting large media streams on the fly to all your clients would be rather expensive.
- dthunt 15y ago
  The expensive part of https is session creation.
  - Tuna-Fish 15y ago
    ... only because the typical http session is a few tens kilobytes. When you want to stream gigabytes of data for each client, for millions of clients at a time, you are going to start caring about the overheads you create elsewhere in the pipeline.
    - dthunt 15y ago
      Sorry. I should be more clear. The initiation of an HTTPS session is expensive because it consumes a large chunk of CPU for a real-world-measurable chunk of time, all at once, in most libraries. Everything beyond that point you're dealing with <use algorithm of choice> over <max of 32kb> of data. It does indeed consume CPU. It does indeed consume perhaps 8x MORE memory than a typical http connection - but the memory side here is completely dominated by the fact that we're trying to cache multiple gigabytes of data. You can serve HTTP faster than you can serve HTTPS with less CPU - this is objective fact. But if we're talking about CPU utilization? I can't speak to whether this argument has traction right now, for large connections, relative to the claimed 'non-problem' position of several companies who serve small sessions dominated by that connection time, but as time passes it's going to be even less coherent a position than it is right now.

dhx 15y ago

It may be possible under the proposal but is distant from the intended or anticipated uses. This proposed extension appears to provide a means for distributing keys between DRM chips/implementations (BD+/AACS/etc) and a remote license server. The reason this is a HTML specification extension is that Netflix and Google want to use <video> within HTML -- thus the browser environment must become responsible for interfacing between the DRM implementation and license providers. Knowing the "keys" being transmitted is not useful because they'll be encrypted using public key cryptography. A heavily protected/tamperproof[1] DRM chip will have access to the actual keys required to decrypt the content. This could take the form of a Trusted Platform Module (TPM) as part of the widely criticised "Trusted Computing" initiative (is this one of the reasons why Microsoft is involved with the proposal?). Some of the motivations of pushing towards this heavily restricted and inaccessible method of delivering content could include: 1) Ability to lock content to particular devices (iPhone users can access a TV show 2 weeks before anyone else). 2) Taking control over the purchasing cycle of consumers by forcing constant hardware upgrades. 3) Renting content for short durations of time under very specific conditions and limitations. 4) Pricing content on a per-user basis (some users pay more than others for the same content) [1] Security Engineering, Edition 1, Chapter 14 by Ross Anderson - https://www.cl.cam.ac.uk/~rja14/Papers/SE-14.pdf https://www.cl.cam.ac.uk/~rja14/Papers/SE-14.pdf

alan_cx 15y ago
"It may be possible under the proposal but is distant from the intended or anticipated uses." Always a scary sentence.

alanh 15y ago

> untrusted user agents All user agents are untrusted, and for that matter, are often not the UA they claim to be. C’est la vie.