Du chiffrement de média dans HTML5 ? Pourquoi pas…

Avec son coté trollesque légendaire, Numérama titrait HTML5 : Google et Microsoft veulent ajouter des DRM, je ne pouvais que morde à l’hameçon.

L’idée derrière cette proposition se base sur une comparaison avec flash. La consultation de média via ce dernier peut être bridée et contrôlée beaucoup plus facilement qu’en utilisant l’HTML5. Normal, avec la balise <video> et <audio>, le chemin du fichier est indiqué en dur dans la balise HTML, le browser le récupère pour consulter la vidéo ou son. Seulement, comment mettre des restrictions sur la consultation ? Elles seraient trop facilement contournées.

Google, Microsoft et Netfix se sont rassemblés pour soumettre un brouillon pour l’évolution du HTML5. Si acceptée, cette extension permet de normaliser un moyen de gérer le déchiffrement d’un contenu avec une clef reçue en javascript. Est-ce du DRM ? Techniquement oui (contrôler par des mesures techniques de protection, l’utilisation qui est faite des œuvres numériques dixit wiki) même si ce n’est pas ceux auquel on est « habitué » sur les iTunes & co. On est plutôt dans une approche pour créer une API permettant le déchiffrement d’un fichier.

J'avoue, j'ai pas tout compris...

Typiquement, l’on imagine un (non-regretté) Megavideo-like en full HTML5 où les gens visionneraient leur vidéos (légales ou non, là n’est pas la question) après avoir payé leurs abonnements.

Maintenant, on peut se demander si cette proposition est une bonne idée ou non. Si pas admirable, je pense quand même que cette idée devrait aboutir. Avant de me faire lyncher, je m’explique vite :

Aujourd’hui, pour imposer des restrictions, de nombreuses sociétés utilisent flash (certains parlent d’un silverlight mais c’est une légende urbaine, tout comme un réseau social par Google). Or, on a plus besoin de le répeter, flash c’est le mal, le plus loin on se trouve de lui, le mieux c’est. Le HTML5 étant l’avenir, de plus en plus de gens s’y mettent, c’est le cas de Grooveshark par exemple. Mais sans le contrôle proposé par flash, tous ne peuvent pas faire le pas.

Comme je le disais il y a quelques mois, ils sont loin d’être con chez Adobe (il faut le reconnaitre). Ils ont compris que leur monopole vidéos de chatons et space invadors touchait à sa fin et qu’il fallait évoluer. Ils ont ainsi commencé à lâcher les secteurs moins intéressants à leurs yeux (smartphones et Linux) pour se consacrer sur ce qui avait de l’avenir pour eux. Ils se lancent dans l’HTML5 et développent le coté « premium » et HD de flash. C’est justement à cette niche premium que l’on veut s’attaquer avec cette extension, donner un moyen aux gros de garder une protection à l’accès de la vidéo.

Les plus libristes d’entre vous me reprocheront que cette façon de penser est dépassée, que restreindre l’accès à un média c’est se foutre de la gueule du client et que ça poussera d’autant plus les gens à se procurer un bon torrent (cf ce tweet). Je suis d’accord avec ça mais il faut aussi être réaliste. On est pas dans le mode de distribution idéale et on est pas prêt d’y arriver. Il y a des géants qui veulent se faire du fric, et même si l’aspect financier n’est pas l’objectif, il est aujourd’hui quasi impossible de tenir une plateforme de distribution massive de vidéos sans restriction et être viable financièrement.

Réfléchissons à l’envers : est il préférable d’avoir un HTML5 avec une restriction d’accès de contenu implémentée et une adoption massive ou juste quelques personnes ayant leur site en HTML5 mais les géants continuant a être accroché à flash ? Personnellement je préfère la première situation. Tout comme je préfère que quelqu’un utilise Skype sur Ubuntu, voir même Firefox sur Windows que de rejeter massivement les choses qui ne sont pas à 100% libre. Commençons petit à petit. Pour Iceweasel sous Debian, ça viendra en son temps, arrêtons de clasher à tour de bras. N’oubliez pas la grosse nouvelle de la semaine qu’est l’abandon du développement de flash pour Linux (en dehors de Chrome). Il est temps de préparer l’avenir.

Est-ce pervertir le HTML5 ? Non ! Ce qui reste important à garder en tête est que le but est de créer une norme ouverte. De plus il faut savoir que cette norme n’apporte pas une protection parfaite. C’est un des points soulevés dans la proposition.

Can I ensure the content key is protected without working with a content protection provider?

No. Protecting the content key would require that the browser’s media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support.

La clef de déchiffrement peut être obtenue car doit être communiquée avec le browser à un moment. A moins qu’il n’y ai un secret à partagé l’intérieur du browser mais inconnu de l’utilisateur (ce qui est complètement incompatible avec le libre et se rapproche plus des « vrais » DRM), le fichier sera toujours récupérable et la protection contournable. L’idée est d’avoir une solution plus sécurisée que ce que l’on a actuellement (pas très difficile) et de compliquer un peu l’accès aux ressources. De toute façon, il est impossible de contrôler complètement ce qui se passe chez le client, on ne peut l’empêcher de capturer le flux de donnée déchiffrée, que ce soit en flash, HTML5 ou ÜberDRMOfZeDead.

J’espère donc que ce draft va être accepté, et que les gens adopteront des standards libres pour les sites web de demain. Une fois que ça sera fait, on peut les convaincre qu’il n’est pas à leur avantage de lutter contre le client. L’avenir est aux technologies du web ouvertes mais ne peut se faire sans l’accord de ceux qui ont de l’argent.

Music DRM par XKCD, CC BY-NC