Re: Individualization

On Fri, Oct 24, 2014 at 1:58 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> On Wed, Oct 22, 2014 at 5:13 AM, David Dorwin <ddorwin@google.com> wrote:
>


> > I assume you are referring to per-origin individualization, which Joe has
> > previously mentioned.
>
> As far as spec changes are concerned, I am referring to download-based
> individualization in general. However, the constraints Firefox places
> on the CDM are supposed to make origin-independent download-based
> individualization impossible, so my immediate interest is with the
> origin-dependent case.


I'm not familiar with the term "download-based individualization". Can you
define it?


> > The per-origin identifiers that presumably come with per-origin
>
> individualization are good for privacy. However, it's unclear whether
> > deferring such individualization to a centralized server maintains those
> > qualities.
>
> This depends on what data the individualization request contains.
> Firefox provides the CDM with some bits that are unique to the
> computer, the origin using EME, the origin in the URL and a
> randomly-generated salt. What the CDM does is up to the CDM, but even
> if the CDM sent these bits verbatim to a centralized server, the
> centralized server wouldn't learn anything from these bits.
>

Does Firefox hash these before providing them to the CDM?

If the CDM or central server is given or can determine the bits that are
unique to the computer, it can track all origins that computer uses EME on
(or potentially any origin it visits - see
http://lists.w3.org/Archives/Public/www-tag/2014Oct/0106.html). Such an
implementation of per-origin individualization would really just move the
potential privacy issues from one place to another.

We should probably mention this in the privacy considerations section.

>
> AFAICT, a centralized individualization server can always tally
> information that's baked into the CDM. Potentially, if the CDM builds
> for different platforms have different in-baked information, the
> centralized server could count individualizations by platform, but the
> platform is already information that browsers expose left and right in
> the UA string (albeit not in a form that's hard for the user to
> forge).
>

As you note, cryptographic proof/identification of the CDM (i.e. a class of
devices) is a concern since it cannot be faked like UA strings and could
potentially be use for platform segmentation (possibly even when not using
the DRM).
However, unique identification of a user or client is much more concerning.

>
> If the server of the application proxies the individualization
> requests to the central server, the central server may not even get to
> learn the IP address of the client the CDM. (Though, of course, the
> browser has no proof that the application's server won't pass this
> information along.)
>
> If the JS program of the application XHRs the individualization
> request directly to the central server (and the central server
> authorizes this via CORS), the centralized server learns that the IP
> address of the client wanted to individualize for the origin of the
> application. Also, if the central server requests credentials and the
> user has for other reasons browsed the site of the CDM vendor to
> obtain a cookie, the central server can match individualizations with
> that cookie. That may not be cool, but at least the credentials can't
> be requested covertly from people who care to inspect what CORS
> headers are sent, so a CDM vendor doing this would get caught and
> getting blogged about.
>

Wouldn't this be an argument for having the license server proxy to the
central server instead of the app? (And thus, not adding the message type.)
The potential for cookies to be passed is quite concerning.

>
> > (I am assuming the reason for the proxying is that the
> > "individualization server" is not run by the application provider.)
>
> The assumption I have is that the individualization server would be
> run by the CDM vendor.
>

If the central server is just getting some bits that are unique to the
computer, the origin(s), and a randomly-generated salt, it would seem that
the content provider's license server could handle this (unless the goal is
to build a central repository). This would seem to greatly improve the
privacy properties of a per-origin individualization solution.

>
> > Is use of a centralized server necessary? Maybe there is another way to
> > achieve per-origin IDs without contacting a central server for each
> origin.
>
> Logically, that's possible in the abstract. I even said how in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c79 . However, I
> think EME should allow for DRM designs that rely on download-based
> individualization, since requiring a redesign of systems that use
> download-based individualization would be quite a barrier to entry. In
> particular, the family of solutions I described in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c79 assumes that
> the bits available for the process are not only unique enough to be
> suitable for node locking but also have proper entropy to be suitable
> for serving as a seed for key generation. With download-based
> individualization, the unique bits extracted locally only need to be
> good enough for node locking while entropy suitable for key generation
> can be left up to the individualization server.
>

I think I'll need to understand "download-based individualization" before I
can comment on this paragraph.

>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>
>