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 pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 15:15:17
Inscrit le jeudi 15 janvier 09 - 9585 commentaires

Sauf que les minimum requirements pour les codecs des balises audio et video, y'en a pas. Le seul format minimum imposé est le png pour les images.


Et? je ne te parle pas de minimum requirement sur la balise video mais sur le fait d'implémenter un module DRM "le CDM + sa relation avec la media-stack" (qui reste à confirmer si l'idée des 3 ingénieurs est repris par le W3C). Ce système ne saurait-être viable que s'il passe dans les minimums requirements.

Ensuite, que la balise video soit implanté à la sauce X ou Y par chaque éditeur, osef dans la mesure où s'il n'y a qu'une voie d'accès à la media stack, ben il faudra bien utiliser cette primitive et pas une autre définie elle (hypothétiquement) dans les minimum requirements.

Note: ceci est un exercice de pensé et pas une affirmation catégorique.
Avatar de ano_634845199311307630 INpactien
ano_634845199311307630 Le vendredi 24 février 2012 à 15:17:05
Inscrit le jeudi 19 mai 11 - 294 commentaires


Lis mes commentaires.
Le souci, c'est pas le déchiffrage ni le décodage, mais le moment où tu affiches.

Le decodage peut etre fait dans un layer non accessible en lecture par le browser. Il parait que Vista est drm compatible, mais je sais pas comment ça marche en pratique.
Avatar de Drepanocytose INpactien
Drepanocytose Le vendredi 24 février 2012 à 15:18:33
Inscrit le jeudi 26 mai 11 - 9646 commentaires

Le decodage peut etre fait dans un layer non accessible en lecture par le browser. Il parait que Vista est drm compatible, mais je sais pas comment ça marche en pratique.

Comment il fait, le browser, pour afficher des frames décodées qu'il ne peut pas lire ?
Avatar de ano_634845199311307630 INpactien
ano_634845199311307630 Le vendredi 24 février 2012 à 15:22:55
Inscrit le jeudi 19 mai 11 - 294 commentaires
Et? je ne te parle pas de minimum requirement sur la balise video mais sur le fait d'implémenter un module DRM "le CDM + sa relation avec la media-stack" (qui reste à confirmer si l'idée des 3 ingénieurs est repris par le W3C).

Ouais, j'ai un peu divergé par rapport au sujet initial. C'est juste que je suis toujours agacé par le manque de vrai standard sur le web, mais c'est une autre histoire.
Avatar de pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 15:23:27
Inscrit le jeudi 15 janvier 09 - 9585 commentaires
Lol, oki (+ copain)
Avatar de ano_634845199311307630 INpactien
ano_634845199311307630 Le vendredi 24 février 2012 à 15:25:04
Inscrit le jeudi 19 mai 11 - 294 commentaires

Comment il fait, le browser, pour afficher des frames décodées qu'il ne peut pas lire ?

c'est la carte graphique qui affiche et fait la composition, le browser specifie juste les coordonnées de la fenetre d'affichage de la video.
Avatar de Drepanocytose INpactien
Drepanocytose Le vendredi 24 février 2012 à 15:26:07
Inscrit le jeudi 26 mai 11 - 9646 commentaires

c'est la carte graphique qui affiche et fait la composition, le browser specifie juste les coordonnées de la fenetre d'affichage de la video.

Aucun browser libre n'acceptera de ne pas avoir le contrôle de ce qu'il affiche.
A moins que je m'égare complètement.

jb, t'accepterais, toi, de ne pas contrôler ton affichage ? (vraie question)

Edité par Drepanocytose le vendredi 24 février 2012 à 15:28
Avatar de pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 15:34:36
Inscrit le jeudi 15 janvier 09 - 9585 commentaires

Aucun browser libre n'acceptera de ne pas avoir le contrôle de ce qu'il affiche.
A moins que je m'égare complètement.

jb, t'accepterais, toi, de ne pas contrôler ton affichage ? (vraie question)


Ben tout l'enjeu est là, notamment de savoir sous quel régime d'implémentation sera astreint ce module. Une spécification obligatoire, optionnelle autre? Et dans la mesure où les ayants droits pourraient dire: "on ne diffuse notre contenu DRMisé que si la chaine sécurisé entre réception, décodage, affichage est respecté". Et si cette spécification obligatoire inclue une contrainte du type "il n'est pas autorisé de capturer le flux entre la media-stack et le frame-buffer", c'est possible.

Mais encore une fois, c'est un scénario et non une réalité.

Edité par pti_pingu le vendredi 24 février 2012 à 15:38
Avatar de Drepanocytose INpactien
Drepanocytose Le vendredi 24 février 2012 à 15:40:50
Inscrit le jeudi 26 mai 11 - 9646 commentaires


Ben tout l'enjeu est là, notamment de savoir sous quel régime d'implémentation sera astreint ce module. Une spécification obligatoire, optionnelle autre? Et dans la mesure où les ayants droits pourraient dire: "on ne diffuse notre contenu DRMisé que si la chaine sécurisé entre réception, décodage, affichage est respecté". Et si cette spécification obligatoire inclue une contrainte du type "il n'est pas autorisé de capturer le flux entre la media-stack et le frame-buffer", c'est possible.

Mais encore une fois, c'est un scénario et non une réalité.

J'avais Flash en tête, justement, que les browsers ne contrôlent pas. Par contre il me semble qu'ils contrôlent l'affichage de ce que Flash leur envoie.
Et Flash est un plugin, pas un standard...

Effectivement, tout se joue sur la notion de "standard" et de ce qu'on met derrière.
Avatar de pti_pingu INpactien
pti_pingu Le vendredi 24 février 2012 à 15:43:08
Inscrit le jeudi 15 janvier 09 - 9585 commentaires
De toute façon, ce sera comme pour la musique, il restera la possibilité de faire de la capture vidéo (et là, je dis oui à JB )
;