Le W3C vient de publier le premier brouillon d’un standard qui permettra à terme aux sociétés de diffuser des contenus multimédias protégés par DRM. Il s’agit en fait d’une suite logique à une proposition faite voilà un an.
Rappel des faits. En février 2012, trois ingénieurs déposaient au W3C une proposition de nouveau standard. David Dorwin (Google), Adrian Bateman (Microsoft) et Mark Watson (Netflix) travaillaient sur un projet baptisé Encrypted Media Extensions dont l’objectif était de permettre au HTML5 de servir de relai à des contenus protégés par des verrous numériques, les fameux DRM.
Un an plus tard, le W3C vient de publier un brouillon de cette technologie, qui n’a d’ailleurs pas changé de nom. C’est de fait l’occasion de faire le point sur le caractère particulier d’un standard qui semble, de prime abord, heurter de plein fouet le caractère ouvert et libre des technologies du web, surtout en regard d’un W3C qui lutte pour uniformiser les technologies.
C’est en fait bien de cela dont il s’agit : uniformiser. Les Encrypted Media Extensions, ou EME, ne sont pas à proprement parler une technologie de type DRM. Il s’agit précisément d’une « tuyauterie » qui permettrait aux sociétés intéressées d’y déverser ensuite leur contenu. Ce n’est donc pas un lot d’API pour chiffrer/crypter/protéger le contenu, mais une infrastructure commune pour formaliser une pratique qui, dans tous les cas, va se répandre.
L’idée derrière les EME est en quelque sorte de compléter les balises audio et vidéo du HTML5. Il ne fait aucun doute que le standard est important pour l’avenir du web, mais tous les besoins ne sont pas pour autant comblés. À travers la nouvelle technologie, un contenu de type « Premium », tel que la vidéo à la demande, pourrait utiliser ces balises. Avantage : plus besoin d’un composant tiers capable de gérer les droits numériques sur un contenu, tel que Flash, Silverlight ou autre.
Les EME ne sont par ailleurs qu’une proposition. Dans la discussion qui suit l’annonce par Philippe Le Hégaret du W3C, il est bien précisé que la publication d’un brouillon n’a d’autre valeur que consultative. En d’autres termes, le W3C travaille dessus, mais il n’existe aucune garantie que la technologie sera finalement adoptée. Il existe d’ailleurs un certain débat autour de la question car certains jugent que ce type de travail n’entre pas dans les attributions du W3C.
Commentaires (69)
#1
" /> en espérant que ça dérape pas parce que les DRM pff
#2
#3
#4
#5
#6
Si ils font un truc standard et compatible avec beaucoup de plateformes, je vois pas ce qu’on peu leur reprocher.
#7
Je ne suis pas sûr que passer par le w3c soit une bonne solution, car ça risque de prendre du temps pour trouver une autre solution quand celle ci sera contournée.
Le mieux est d’avoir une structure indépendant est très réactive sur le sujet si ils veulent vraiment en faire un standard.
#8
C’est de plus totalement inutile car à un moment donné il faut bien afficher l’image en clair pour l’utilisateur (à moins qu’on m’explique qu’on va se faire greffer des puces de déchiffrement sur le nerf optique !..)
Et du moment qu’on affiche l’image en clair, rien n’empêche de re-encoder le film.
Du coup, comme pour les BluRay, pour des questions d’interopérabilité les gens préfèreront le film “ré-encodé” (terme politiquement correct !) à son original bardé de DRM et qu’ils ne sont pas sûr de pouvoir lire aujourd’hui et demain (quid si le serveur de clé disparaît : faillite ou autre…)
#9
#10
#11
#12
#13
Perso, je pense que les DRM sont le mal.
Et je suis pas expert mais quand je vois le schéma, ça ressemble à une usine à gaz.
#14
#15
#16
#17
EMErde, un DRM de plus. " />
#18
Bientôt, on pourra taper “firefox -dumpstream” !!! " />
#19
#20
#21
#22
Et l’exception à la copie privée ? " />
#23
#24
#25
#26
#27
diffuser des contenus multimédias protégés par DRM
diffuser des contenus multimédias restreints par DRM
#28
#29
#30
#31
#32
#33
#34
#35
#36
#37
#38
#39
#40
#41
#42
#43
#44
#45
#46
#47
#48
#49
du DRM approuvé w3c ? C’est vraiment le début de la fin…
#50
#51
#52
#53
#54
#55
#56
#57
#58
#59
#60
#61
#62
#63
#64
#65
#66
Et ben … " />
Avant, le web ça ressemblait à ça :
IP1 —— get http —->IP2
IP1 <—– http ok —— IP2
Mais ça, c’était avant …
#67
#68
VideoDownloadHelper sera-t-il encore utilisable ? Ou alors j’ai loupé une étape.