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.

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.

12 réponses sur « Du chiffrement de média dans HTML5 ? Pourquoi pas… »
Je suis absolument en désaccord avec votre position. Le Web Libre et ouvert s’est construit **en dépit** des acteurs industriels, et jamais « grâce » à eux. Si on avait suivi ce type de discours, le Web ne serait d’ailleurs jamais apparu et aujourd’hui on serait tous sur Gopher, obligés de payer des licences au Minnesota (il y a beaucoup d’autres exemples : après tout, on a même fini par avoir la peau de MSIE6).
Flash est *déjà* en train de disparaître, tout le monde le sait à commencer par Adobe, et rien ne l’empêchera. La bataille à venir (elle est déjà entamée) ne se jouera donc pas sur le terrain du Flash, mais des codecs et brevets : le w3m ayant eu la lâcheté de ne pas indiquer de format préféré pour la balise (précisément en suivant un raisonnement comme le vôtre, et en voulant éviter de mécontenter les industriels), nous avons perdu à peu près cinq ans avant l’avènement de vidéo universellement accessible sur le Web.
Les DRM ne servent strictement à rien d’autre qu’à compliquer la vie des simples citoyens ; la vraie question n’est donc pas celle de l’utilité ou de l’efficacité, mais celle du symptôme qu’ils représentent : une volonté de contrôle et de privatisation du Web.
Aujourd’hui, alors que s’imposent des formats ouverts (encore une fois, non _grâce_ aux industriels mais _malgré_ eux), voici donc la nouvelle parade : ajouter des DRM pour satisfaire aux jérémiades d’Hollywood — exactement de la même façon que le législateur américain ou européen se laisse dicter ses lois par leurs lobbys. Il est GRAND temps que l’on cesse de prendre au sérieux ces caprices d’enfant gâté. À plus forte raison dans le milieu Libriste.
Je suis totalement contre.
Un standard ouvert doit-il permettre l’imposition de restrictions à l’encontre de ceux qui l’utilisent ? Il ne s’agit nullement de « sécuriser » ni de « protéger », mais au contraire de dégrader l’accès aux contenus. Ceci ne devrait jamais être intégré dans une norme.
Pourquoi d’ailleurs accepter une telle restriction pour les vidéos et pas pour les autres contenus ? Pourquoi pas pour les images et pour le texte ? Un composant permettrait de chiffrer le texte empêchant tout copier-coller… (c’est pour sauver les journalistes on vout dit)
Ce qui est préférable, c’est de ne pas les aider à développer ce contre quoi on lutte (les DRM, la diffusion entravée, etc). Et justement, ils paniquent parce qu’ils voient qu’il n’ont pas d’autre choix que d’abandonner Flash, que HTML5 bride l’accès ou non.
Là encore, je ne suis pas d’accord, ceux qui veulent imposer des restrictions pour conserver leur rente sont justement démunis face à la libre diffusion des contenus, et cette norme leur permettrait de (leur donner l’illusion de) pouvoir continuer à promouvoir un modèle basé sur la rareté.
Je ne suis pas convaincu qu’aujourd’hui qu’il soit réaliste de passer à un modèle de distribution complètement libre. Il y aura encore trop de réticences. Il reste trop idéaliste de penser qu’on peut convaincre tout le monde de donner un accès libre à son contenu.
Il y aura toujours des gens qui ne voudront pas publier leur contenu de façon libre, des gens qui menacent de procès au premier copier-coller. Et ce n’est pas uniquement les vieux de chez hollywood (pour eux même flash est pas suffisant) Que ce soit un site de distribution de vidéo vendant des abonnements premium, une chaine de tv proposant le replay pendant une durée limitée, un site de vente de musique permettant le streaming,… tous refuseront l’abandon du flash s’ils n’ont pas un minimum de garantie.
Je ne suis pas d’accord avec l’affirmation qu’une norme permettant le chiffrement est dégradée. Au contraire, elle permet de faire plus de choses, de convenir à plus de monde.
Attention, je ne dis pas que c’est une bonne chose en soit que de ne pas avoir un accès direct à un fichier. Juste que je comprend que certains ne veulent pas le permettre. L’extension est un moindre mal.
Pour revenir au fait que ce sont les gens avec du fric qui dirigent le web, c’est entièrement vrai aux niveaux de la gestion des backbones. Il y a des accords commerciaux entre les grands sites internet (tel que megaupload) et les gros AS pour avoir des accès privilégiés, la gestion du trafic internet se base également sur des accords commerciaux entre les gros partenaires. Le web fonctionne parce qu’il y a des gros sous derrière. C’est triste mais c’est comme ça. Est-ce vrai à la couche applicative ? Moins mais toujours inévitable. On a bien vu ça avec le débat de codecs vidéos. Si Google (qui fait partie des riches) n’était pas intervenu avec une solution libre, rien ne garantit qu’un vainqueur comme le WebM se soit démarqué (et encore, le h264 est loin d’être mort, on peut difficilement s’en passer).
Euh je vois pas en quoi les entreprises faisant de la VOD ont besoin de DRM ou de flash pour protéger l’accès à ses videos.
Contrôlez qui accède a une page html sur un serveur y a 15000 manière de le faire et de manière plutôt simple.
Ton argumentaire Mart est assez douteux, à mon goût. Ca ressemble tellement à « le brevet logiciel est nécessaire à l’innovation ».
Que certains veuillent contrôler leur contenu, c’est une chose, que l’on implique tous les autres à marche forcée, c’en est une autre.
Je comprend que mon opinion ne plaise pas à tout le monde. Je suis convaincu que c’est différent des brevets logiciels (qui nuisent très clairement à l’innovation) dans le sens où si une personne fait le choix d’utiliser cette technologie, ça ne devrait pas impacter les autres distributeurs de média. Je vois vraiment ça comme un moyen de contenter plus de monde, faire plus avec un standard et une amélioration par rapport à flash.
« Je vois vraiment ça comme un moyen de contenter plus de monde »
Et puis pourquoi ne pas proposer une censure sur le Web, pour contenter les dictateurs ? Ben quoi, c’est un moyen de contenter plus de monde…
Le Web est ouvert par définition, on ne pas pas y mettre des restrictions, juste pour faire plaisir à 2-3 industriels.
Mart, comme je le disais précédemment, lorsque tu parle de « contenter plus de monde », ce « plus de monde » c’est les majors et diffuseurs globaux contre le reste du monde entier, soit une frange extrêmement réduite du monde, pour ne pas dire insignifiante, mais en revanche beaucoup plus riche que le reste du monde. Ce dispositif, le pelo de base s’en contrefout royalement, avec ou sans DRM c’est la même pour lui.
Et cette tentative est une première tentative de corruption du W3C dont le rôle n’est certainement pas de définir un premier verrou officiel du web. Si elle devait passer, cette jurisprudence permettra alors le verrouillage complet et définitif de toutes les technos web. Et nous les libristes, on devra, comme d’habitude, contourner les lois et les protections pour avoir un accès à l’information.
Si ils veulent des DRMs, ils se font leur plugin dans leur coin, et comme les autres plugins, l’utilisateur final choisira s’il l’installe ou pas. Mais qu’ils ne demandent pas au monde de décréter comme standard incontournable leurs menottes numériques.
pour rappel, par ailleurs, le code de l’API qui gère le cryptage, ne sera pas offert au monde, sinon celà n’aura servi à rien. Il serait plutôt question de l’intégrer dans un chipset. La dernière ligne du schema dit clairement : « CDM may use or defer to platform capabilities ».. Bref un UEFI du web.
Tu es sûr pour l’API intégrée dans le chipset ? Je ne le comprend pas comme ça. La remarque que j’ai citée dans l’article pousse à penser plutôt au contraire. De plus il y a la remarque d’un ingénieur de Google qui dit :
Il faut voir s’il parlait au nom de sa compagnie ou exprimait son opinion mais ça me semble indiquer qu’il n’y aura pas de secret caché du client. Un secret intégré coté hardware serait évidement très mauvais et me semble de toute façon impossible à mettre en place.
Ce que je dis peut paraitre un peu contradictoire mais je pense qu’il y a toute une part du marché commercial à qui l’HTML5 est actuellement fermé, pas uniquement les vielles majors. Les priver d’une protection basique ne serait pas bon pour eux (et je suis pour le développement d’une activité économique sur le web). Si je peux écouter une musique en streaming sur le site du distributeur mais doit payer pour pouvoir la télécharger (et obtenir ainsi un fichier sans DRM), je n’ai pas de problèmes avec ça. Après il faut évidement faire très attention à ce que l’on va faire avec ça pour ne pas tomber dans des dérives trop fermées mais de toute façon la tendance ne va pas dans ce sens là, les gens prennent conscience.
Pour le chipset, oui : http://www.pcworld.fr/2012/02/24/internet/html5-doit-supporter-drm/525191/
http://www.macgeneration.com/news/voir/235452/une-protection-anti-copie-pour-les-videos-html5
Pour l’aspect logique de la chose, aucun système de DRM ne peut être open source, car cela implique l’utilisation libre et détournée des algorithmes; Si un navigateur libre peut implémenter le DRM alors n’importe quel programme ou extension de « copie » peut le faire.
Alors libre à eux de vouloir imposer des DRM pour leurs contenus, mais il est hors de question d’impliquer un standard ouvert ayant pour but l’inter-opérabilité libre (matérielle et logicielle)
Il serait absurde de mettre des DRM dans HTML5 … Je veux dire que c’est complètement ridicule !
HTML/CSS sont des norme pour l’affichage d’une page … HTML est une gramaire de mise en forme, il est donc bien absurde de faire de la sécurité dans la mise en page !
La couche qui s’occupe de faire du controle d’accès sur Internet est HTTP qui peut dans sa version actuelle (1.1 seulement) tout a fait contrôler que tu as payé ton abonnement (et même supporterai un échange de clé crypté)
Donc je serait choqué que HTML5 intègre les DRM.
Je serait swulement, affligé que certain utilise HTTP pour ça (car forcément non compatible OpenSource). Maism j’ai bonne espoire que les géants de la vidéo, vont faire comme les grands de la musique et comprendre que les DRM c’est contre productif.