Vers un DRM dans HTML5
Une proposition de spécification, visant à compléter HTML5, avait été soumise au W3C début 2012 par Microsoft, Google et Netflix. Son objectif ? Donner les moyens de chiffrer les contenus vidéo ou audio HTML5. Dans la foulée, l'Electronic Frontier Foundation (EFF) s'était érigée contre cette proposition en soulignant le risque de voir s'immiscer des DRM (systèmes de gestion de droits d'auteur) dans les contenus HTML5. Elle a pour ce faire soumis une objection au W3C. Le consortium vient de la rejeter.
"Cette proposition étend l'interface DOM HTMLMediaElement pour permettre la lecture de contenu protégé", explique le document soumis par les trois protagonistes (titré Encrypted Media Extensions v0.1 ). Schématiquement, l'idée est de proposer une API pour gérer en JavaScript l'échange de licence/clé de contrôle avec le navigateur, et d'implémenter des algorithmes de gestion de licences client.
Il ne s'agit donc pas à proprement parler d'intégrer à HTML5 une brique de gestion des droits digitaux (DRM). En revanche, l'API en question pourrait très bien permettre à des solutions de DRM tierces d'autoriser ou d'interdire l'accès à des contenus vidéo ou audio publiés en HTML5. A l'heure où Flash, qui intègre un DRM, voit s'imposer HTML5 comme grand concurrent sur le terrain de la diffusion de contenus Web riches, on comprend pourquoi certains acteurs souhaitent se donner des moyens de contrôler la diffusion audio et vidéo dans ce format.
Un agent de gestion problématique pour Firefox
Aux côtés de l'EFF, d'autres voix se sont élevées contre le projet. Sans grande surprise, c'est le cas de la Free Software Foundation. Pourtant salarié de Google, Ian Hickson qui est connu pour être l'auteur des tests Acid2 et Acid3, avait également réagi sur la liste de diffusion du W3C en qualifiant cette initiative de "non-éthique". Face à cette levée de boucliers, le W3C a tranché en rejetant les critiques.
Jeffrey Jaffe, le directeur du W3C, est lui même monté au créneau pour défendre la position du consortium sur le blog de l'organisation. "Nous sommes persuadés que pour avoir des standards étendus qui soient interopérables, il est essentiel d'y inclure des connections vers ce type d'éléments propriétaires, qui pourraient à terme tendre à être remplacés par des standards ouverts", indique-t-il tout en rappelant que la spécification EME ne fournit qu'une définition d'API permettant d'accéder à des modules de déchiffrement de contenu, c'est-à-dire l'un des éléments d'un dispositif de DRM. "Nous ne cherchons pas à standardiser la technologie de DRM en tant que telle", martelle-t-il.
En aval, pour que cette technologie soit applicable, il sera aussi nécessaire que les éditeurs de navigateurs Web implémentent un agent client de gestion. C'est d'ailleurs à lui que serait dévolu la prise en charge des codecs (ce qui permettrait d'ailleurs d'ouvrir potentiellement le processus à n'importe lequel d'entre eux). L'opération sera donc plus difficilement possible avec les navigateurs open source, au premier rang desquels Firefox. La spécification le précise d'ailleurs : "ce n'est pas quelque chose que les navigateurs open source pourront supporter de manière native".