S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité

Flash Info : Fêtons la TVA à 2,1 % : abonnez-vous dès 17 € par an !

Le W3C examine une proposition de gestion des DRM dans le HTML5

Comme une lettre à la poste. Un dimanche.

Le HTML5 est présenté le plus souvent comme la technologie du futur capable de gérer tous les cas de figure, en plus d’être un standard. Beaucoup oublient qu’il s’agit encore d’une technologie en formation, qui n’a rien de terminé et qui ne couvre pas tous les cas de figure. Et c’est bien pour cette raison que trois ingénieurs ont présenté au W3C un projet d’extension qui permettrait au HTML5 de lire le contenu protégé par DRM.

firefox youtube

Créer un terrain fertile

Cette proposition d’un genre particulier a été formulée par trois développeurs : David Dorwin (Google), Adrian Bateman (Microsoft) et Mark Watson (Netflix). Le projet lui-même se nomme Encrypted Media Extensions v0.1 et n’existe pour l’instant qu’à l’état de simple brouillon soumis au W3C pour examen et approbation.

L’objectif principal de ces extensions est de permettre à l’élément HTMLMediaElement de pouvoir lire du contenu multimédia protégé. On comprendra évidemment par « protégé » un contenu encadré par des verrous numériques, autrement dit des DRM. Les DRM en eux-mêmes sont une réalité, car les larges diffuseurs de contenus audio et vidéo en streaming en ont besoin pour éviter que des copies soient faites. C’est évidemment le cas de Netflix, mais Microsoft et Google y ont évidemment des intérêts, surtout en regard de certains codecs comme le MPEG-4 et VP8 (WebM).

Les Encrypted Media Extensions ne sont pas une plateforme complète de DRM, mais plutôt un ensemble d’éléments pour constituer une base de déchiffrage de données protégées basée sur des clés. Les systèmes de DRM qui voudraient s’en servir n’auraient qu’à venir s’y rattacher via un système de plug-ins pour en exploiter les capacités.

La proposition ne fait pas l'unanimité

Évidemment, tout le monde ne voit pas une telle proposition d’un bon œil. Ian Hickson par exemple, du groupe WHATWG qui travaille justement sur la standardisation du HTML, estime pour sa part que la proposition « n’est pas éthique ». En outre : « La proposition ne fournit pas une protection solide du contenu, donc elle ne pourrait remplir sa mission même si elle était éthique ». Une condamnation très nette alors que Hickson travaille lui-même chez Google.

Et si la proposition ne fait pas l’unanimité chez Google, elle la fait encore moins chez Mozilla. Le développeur Robert O’Callahan se demande ainsi comment un tel système pourrait être implémenté dans un navigateur open source. Par définition, le logiciel libre s’accorde relativement mal avec les verrous numériques. Mark Watson de chez Netflix donne la solution : se baser sur les capacités du matériel, car un navigateur open source ne peut effectivement pas intégrer un tel mécanisme.

Une réponse qui n’en est pas vraiment une, car tous les ordinateurs ne disposent pas de ces capacités. Mais cela n’est sûrement pas important dans la vision qu’ont les développeurs des Encrypted Media Extensions : il s’agit d’un brouillon en version 0.1 et il y a donc le temps avant que la technologie murisse. Aussi, des puces auraient le temps d’apparaître, au moins dans les appareils mobiles comme les smartphones et tablettes. Cela étant, les puces dédiées de type TPM ont leur propre lot de polémiques.

Cela étant, que les Extensions soient acceptées ou pas par le W3C ne changera rien à une question qui reste en place : comment protéger les contenus multimédias efficacement ? Le retrait progressif de Flash fait sans doute plaisir aux partisans du pur HTML5, mais il laisse derrière lui des interrogations auxquelles des solutions devront nécessairement être trouvées.
Source : W3C
Vincent Hermann

Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.

Publiée le 24/02/2012 à 10:20

Soutenez l'indépendance de Next INpact en devenant Premium

  • Tout le contenu de Next INpact sans pub
  • Et bien plus encore...

Il y a 123 commentaires

Avatar de aureus INpactien
aureus Le vendredi 24 février 2012 à 13:56:38
Inscrit le lundi 7 mars 11 - 1566 commentaires


Bah de base c'est une solution centralisée, donc qui ouvre la porte à ce genre de problème. Vu les acteurs en question il y a de fortes chances que si ça se fait, à l'avenir, la majorité des vidéos soir DRMisé. Par construction Internet est décentralisé, justement pour éviter ces problèmes.



Vu les acteurs en question je ne me fais pas trop d'illusions


On ne condamne pas une technologie à cause de son exploitation. Faire l'amalgame: les DRM sont mauvais car tout le monde va en mettre est aussi stupide que de dire que le P2P est mauvais car des personnes télécharge.

De plus internet est décentralisé, mais les usages qui en sont faits sont quasiment tous centralisé. Même le P2P nécessite la connexion à un serveur .

Et le but des DRM n'est pas et ne sera jamais d'interdire totalement la copie comme le but de toute technologie de protection, le but est de le rendre suffisamment dur pour décourager les néophytes.

Edité par aureus le vendredi 24 février 2012 à 13:57
Avatar de jb INpactien
jb Le vendredi 24 février 2012 à 14:06:31
Inscrit le samedi 13 mai 06 - 3716 commentaires

Oui, effectivement, mais dans l'idée, je pense que l'encryption/décryption se fera dans le media stack et pas à un autre niveau du browser.


C'est pas ce que j'en ai compris.

La media stack est celle du browser, puisque c'est elle qui gère les clés et le réseau.
La partie CDM est pas celle du browser, mais la media stack si, vu le schéma.
Avatar de Drepanocytose INpactien
Drepanocytose Le vendredi 24 février 2012 à 14:12:55
Inscrit le jeudi 26 mai 11 - 9646 commentaires


C'est pas ce que j'en ai compris.

La media stack est celle du browser, puisque c'est elle qui gère les clés et le réseau.
La partie CDM est pas celle du browser, mais la media stack si, vu le schéma.

C'est ce que j'en comprends également.
Avatar de pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 14:16:45
Inscrit le jeudi 15 janvier 09 - 9585 commentaires


C'est pas ce que j'en ai compris.

La media stack est celle du browser, puisque c'est elle qui gère les clés et le réseau.
La partie CDM est pas celle du browser, mais la media stack si, vu le schéma.


Oui, en fait je me suis mal exprimer (j'avais la tête ailleurs). La decryption se fait dans le CDM mais c'est le media stack qui l'initie et qui en reçoit le résultat. Donc, dans le cas d'un browser certifié HTML5, chapitre des DRM, aucun autre module du browser ne peut accéder directement au contenu décrypté, hormis pour l'afficher. Donc, ça n'empèche que si un petit malin créer un fork d'un browser en source libre, il pourra capter les flux, mais que tous les browser à très large diffusion implémenteront une "media stack" boite noir avec une primitive d'accès uniquement pour le module d'affichage (que ce soit flash ou le lecteur embarqué conforme à la balise video HTML). Comme dis, l'idée est de s'assurer que dans la très grande majorité des cas, le contenu reste dans un cycle protégé et que le délai avant qu'il ne le soit plus (et donc qu'il y ait des solutions de contournement à large diffusion) soit le plus long.

De même, rien n'empèche d'imaginer que pour obtenir la certification HTML 5, chapitre DRM, les browsers web doivent assurer ce cycle de protection tant pour leur core system que pour les extensions (ex.: rejet d'une extension type DownloadHelper qui contourne le mécanisme). Et ceci est simple à mettre en place grâce à la signature des plugins (comme le fait déjà Chrome et avec des serveurs officiels de signatures des plugins).
Avatar de Dunaedine INpactien
Dunaedine Le vendredi 24 février 2012 à 14:19:26
Inscrit le samedi 7 janvier 06 - 15989 commentaires


On ne condamne pas une technologie à cause de son exploitation. Faire l'amalgame: les DRM sont mauvais car tout le monde va en mettre est aussi stupide que de dire que le P2P est mauvais car des personnes télécharge.

De plus internet est décentralisé, mais les usages qui en sont faits sont quasiment tous centralisé. Même le P2P nécessite la connexion à un serveur .

Et le but des DRM n'est pas et ne sera jamais d'interdire totalement la copie comme le but de toute technologie de protection, le but est de le rendre suffisamment dur pour décourager les néophytes.


C'est faux le P2P ne nécessite pas forcément la connexion à un serveur et ceci depuis très longtemps (protocole Kadmelia par exemple). Ensuite les DRM ne servent à rien, causent pas mal de soucis. Et cela qui les rend mauvais. C'est juste l'une des plus grosses arnaques de ce début de siècle.
Avatar de ano_634845199311307630 INpactien
ano_634845199311307630 Le vendredi 24 février 2012 à 14:22:36
Inscrit le jeudi 19 mai 11 - 294 commentaires
De même, rien n'empèche d'imaginer que pour obtenir la certification HTML 5, chapitre DRM, les browsers web (..)

Il y a une certification HTML5 pour les browsers?
Avatar de jb INpactien
jb Le vendredi 24 février 2012 à 14:27:38
Inscrit le samedi 13 mai 06 - 3716 commentaires

Oui, en fait je me suis mal exprimer (j'avais la tête ailleurs). La decryption se fait dans le CDM mais c'est le media stack qui l'initie et qui en reçoit le résultat. Donc, dans le cas d'un browser certifié HTML5, chapitre des DRM, aucun autre module du browser ne peut accéder directement au contenu décrypté, hormis pour l'afficher.


On est bien d'accord que le browser a les frames déchiffrés donc, juste avant l'affichage (normal pour afficher dans un canvas ou autre). Si le browser est open source, il est trivial de patcher la dll pour récupérer ces frames déchiffrés...
C'est le souci identique dans VLC.
Avatar de pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 14:29:46
Inscrit le jeudi 15 janvier 09 - 9585 commentaires


On est bien d'accord que le browser a les frames déchiffrés donc, juste avant l'affichage (normal pour afficher dans un canvas ou autre). Si le browser est open source, il est trivial de patcher la dll pour récupérer ces frames déchiffrés...
C'est le souci identique dans VLC.


Yep, mais tout le souci étant ici, combien de temps avant le patch (probablement court) et combien de temps avant la large diffusion (probablement long dans la mesure où la plupart des utilisateurs qui ne sont pas des power-user utilise et mettent à jour le browser depuis les repo officiels) IMHO.
Avatar de pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 14:33:49
Inscrit le jeudi 15 janvier 09 - 9585 commentaires

Il y a une certification HTML5 pour les browsers?


Pas au sens strict du terme (y'a pas un monsieur avec un joli stample), disons plutôt une normalisation/standardisation. Comme le W3C normalise et valide tout ce qui touche à HTML5 (les spécifications minimum que doivent implémenter un browser), un browser qui n'implémenterait pas le strict minimum risque de voir sa part commerciale chuter très rapidement (ex.: IE6 à partir du moment où le W3C à repris la main assurant le décollage de Fx qui a pu proposer de nouveau usage grâce à la conformité plus stricte envers les HTML4.x).

Et comme le marché aujourd'hui se concentre autour de celui qui sera le plus conforme, la suite est facile à deviner. Il suffit de mettre au niveau des minimum requirements, le cycle de contrôle des DRMs.
Avatar de Dunaedine INpactien
Dunaedine Le vendredi 24 février 2012 à 14:36:08
Inscrit le samedi 7 janvier 06 - 15989 commentaires


Yep, mais tout le souci étant ici, combien de temps avant le patch (probablement court) et combien de temps avant la large diffusion (probablement long dans la mesure où la plupart des utilisateurs qui ne sont pas des power-user utilise et mettent à jour le browser depuis les repo officiels) IMHO.


Il suffit d'un utilisateur qui cracke, enregistre puis rediffuse sur d'autres réseaux pour que la protection puisse être considérer comme morte. C'est bien ce qui rend cette course stupide. Que cela complique la tâche aux néophytes ne change rien si une seule personne arrive à passer la protection et diffuse ensuite le contenu.
;