W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: AES-CTR inside vs. outside the media container (was: Re: Encrypted Media proposal: Summary of the discussion so far)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 7 Mar 2012 18:02:46 +0200
Message-ID: <CAJQvAucF20tTqU8bBK50kOEGOPbXu+XZGRPSDYyU4kULXB-jVA@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Mark Watson <watsonm@netflix.com>, Tab Atkins <jackalmage@gmail.com>, Christian Kaiser <kaiserc@google.com>, HTML WG <public-html@w3.org>
On Wed, Mar 7, 2012 at 5:53 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> On 3/7/12 7:54 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>>(Presumably in non-streaming cases, it might be useful to be able to
>>read embedded metadata even if the media is unrenderable, but in the
>>streaming Web case, that doesn't seem like an important benefit.)
> Remember that streaming does NOT simply mean "start at byte 0 and go to
> byte n".  The byte-range feature of HTTP allows the client to fetch any
> specific set of byte ranges from the stream in whatever order it wishes.

Encrypting HTTP payload with AES-CTR supports this, since you know how
far in terms of AES blocks you are from the start of the HTTP entity
body, so you can compute the right counter value.

> Thus a smart media player could leverage selective encryption on the MP4
> blocks to read the (unencrypted) metadata and display it to the user if
> they couldn't read the rest of the package.

Does that matter for HTML video? We don't have APIs exposing media
file metadata anyway and one would expect use cases to be such that
the user doesn't get to examine the media file before (s)he has paid
to receive the key, so the user wouldn't browse to a media file
without a key anyway.

Henri Sivonen
Received on Wednesday, 7 March 2012 16:03:22 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:49 UTC