- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 7 Mar 2012 08:58:03 +0200
- To: Christian Kaiser <kaiserc@google.com>
- Cc: Philip Jägenstedt <philipj@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "<public-html@w3.org>" <public-html@w3.org>
On Tue, Mar 6, 2012 at 7:43 PM, Christian Kaiser <kaiserc@google.com> wrote: > In the browser market, I'd argue that barriers to entry would stay the same > as they are today if one assumes that the proposal would result in a CDM > plug-in model. So far, I haven't seen anyone step forward saying that they intend to produce a pluggable CDM if browsers were to provide an integration point. On the other hand, there's no indication from browser vendors that also have DRM back ends in-house (Google, Microsoft, Apple) whether they'd provide support for pluggable CDMs in their browsers (as opposed to only integrating their in-house DRM without a public API). Considering what's been said so far, pluggable CDMs might be a theoretical thing that no one intends to produce. > The hurdles to pass to allow plugging in CDMs seem pretty > similar to the hurdles to pass to allow plugging in Flash or Silverlight. Indeed, which makes me wonder why previous messages in threads on this topic have implied the integration of pluggable CDMs would be simpler than the integration of NPAPI plug-ins. > I disagree with this statement. The proposal at hand enables (but does not > require!) the use of proprietary and/or royalty-encumbered standard CDMs. > It also enables innovation to allow e.g. non-proprietary, non-encumbered > CDMs to potentially emerge. It would seem healthier to the Web to propose a non-proprietary, non-encumbered CDM from the start instead of opening the door to proprietary and encumbered CDMs. A non-encumbered CDM emerging later might help new Web sites later but it won't help browsers if by that time there's enough popular legacy sites that depend on encumbered CDMs. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 7 March 2012 06:58:32 UTC