Il y a quelque temps, je pestais contre le W3C et le fameux DRM d’HTML5, et j’ai eu le plaisir d’avoir un bon retour de Robin Berjon qui participe activement au W3C. Vous allez voir que son son de cloche est très différemment de ce qu’on a pu lire sur les sites spécialisés et que j’ai relayé ici même.
D’après Robin, il est totalement faux que le W3C tient des discussions secrètes sur le DRM dans HTML5 puisque tout est public ici même ainsi que les discussions générales ici.
Dans les deux cas, ce sont des listes entièrement publiques, tant en lecture qu’en écriture. Tout le monde peut venir participer. Il arrive que certaines personnes soient bannies, mais il faut vraiment chercher (et c’est seulement après avertissement). Et même sans être inscrit, même après avoir été banni, on peut toujours lire ce qui est écrit.
C’est d’ailleurs drôle vu que le post de Boing Boing criant au secret faisait référence à un message publiquement disponible…
Voici maintenant les commentaires de Robin sur le DRM HTML5 :
EME n’est pas un système de DRM, mais une interface vers des systèmes de DRM. L’idée est simple: ça doit normalement permettre à quelqu’un d’écrire une application Web interagissant avec un système de DRM tout en bénéficiant d’une abstraction qui évite de réécrire le code pour chaque système de DRM.
La plainte d’origine, relayée de travers par Boing Boing (et autres), est que les requirements sur les *DRM* ne sont pas connus. Les requirements sur EME sont connus (soit dans http://www.w3.org/TR/encrypted-media/, soit en discussion sur la liste).
Formellement, le W3C et les participants n’ont pas besoin de connaître les requirements sur les DRM vu que ce sont des systèmes en amont du travail effectué sur EME. C’est un peu comme demander les requirements de Unicode pour bosser sur HTML juste parce que ça utilise du texte Unicode.Ceci dit, il serait très utile de disposer des requirements formulés en amont par les studios sur le DRM en général parce que ça permettrait potentiellement de formuler des solutions alternatives. Ou au pire ça clarifierait la situation pour tous.
C’est dans ce cadre que le W3C et bon nombre de participants font du mieux pour essayer d’obtenir la publication de ces requirements et du fonctionnement des systèmes DRM qui sont en amont d’EME.Le point le plus spécifique de cette confrontation est ce bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944.
Il a été indiqué clairement (et publiquement) que sans résolution favorable de ce problème, le W3C se réserve le droit de bloquer l’avancée d’EME vers un standard. Cf http://www.w3.org/2013/11/14-html-wg-minutes.html#item06 (c’est jargonneux, mais les lignes « if there’s no response on an important bug » et la dernière intervention sur ce sujet indiquent ça, « MikeSmith » et « darobin », aka moi, étant représentants du W3C dans cette discussion).
Le raout que nous voyons donc aujourd’hui, et relayé par ton blog, est donc plutôt à l’inverse de la situation réelle (même s’il est vrai que pour le moment le problème n’est pas résolu).Il y a les producteurs de contenu qui veulent des DRM, il y a les distributeurs comme Netflix qui n’aiment pas les DRM, mais veulent des contenus et veulent être sur le Web, il y a les navigateurs qui ne sont pas fans des DRM, mais veulent pouvoir afficher le contenu de Netflix, et il y a les utilisateurs qui n’aiment pas les DRM du tout. Trouver une solution qui conviendra à tous est particulièrement difficile. Mais c’est pour ça qu’il y a une discussion (et qu’elle est publique).
Quand j’évoque le risque de mise en place de DRM sur des choses comme les textes ou les polices, voici ce que Robin me répond :
C’est sûr qu’il serait terrible d’en arriver là. Ceci dit la question des DRM sur les polices est considérée comme close (il y a un indicateur de licence en métadata qui est considéré comme suffisant, c’est une mesure légale et non technique) et le groupe DigiPub a rejeté l’idée de travailler sur les DRM des ebooks.
Enfin, quand j’accuse le W3C d’être à la solde des studios hollywoodiens et des distributeurs comme Netflix ou Microsoft et de suivre leurs demandes les yeux fermés, voici ce que m’explique Robin :
C’est totalement faux. Il est évident que le W3C ne travaillerait pas sur ce sujet si les implémenteurs n’en voulaient pas, mais il n’y a en aucun cas d’imprimatur clé en main. EME n’est pour le moment qu’un item de travail, la spécification n’a pas été entérinée (et n’est pas pour le moment en situation de l’être).
L’idée même d’accepter cet item de travail est de le rendre public (pour que tout le monde puisse contribuer, et peut-être trouver une alternative) et royalty-free (pour qu’on ne se retrouve pas dans une situation où les navigateurs open source ne pourraient pas afficher ce type de contenu).
Évidemment, personne dans la communauté Web n’est content de voir arriver les DRM. Mais l’alternative est précisément que tout se passe en secret et de façon propriétaire. L’idée est, à minima, d’essayer d’obtenir un moindre mal; l’espoir est, à maxima, de trouver une alternative par le biais de discussions ouvertes.
Rien, rien, rien n’est secret… Par contre, le manque de vérification de la presse en ligne fait gentiment le boulot des amoureux du DRM en sapant le boulot de ceux qui essaient de trouver (peut-être à tort, mais sincèrement) une voie pragmatique.S’il était possible d’ignorer la question des DRM il est évident que le W3C se passerait volontiers de travailler dessus.
Voilà un retour intéressant qui recadre un peu le débat enflammé autour des DRM. Après c’est à chacun de se faire son avis… En ce qui me concerne, j’ai un peu l’impression qu’on se retrouve ici dans une situation similaire de feu-les-labs Hadopi. Des gens pleins de bonne volonté qui travaillent dans le sens de l’ennemi pour essayer au maximum de limiter les dégâts. Espérons juste qu’ils auront plus de succès…
Si vous vous intéressez au sujet, je vous invite à visiter le site de Robin et à le contacter via Twitter si besoin. Merci à lui pour ce feedback passionnant.