Discussion :

[Stéphane le calme]

DRM dans HTML5 : le père du web soutient cette spécification sur laquelle le W3C travaille,
mais l'EFF estime que les retombées négatives sont démesurées

Le World Wide Web Consortium (W3C), l’organisme qui supervise le développement de nombreuses technologies liées au web, envisage de nouveau l'élaboration d'une spécification permettant aux médias protégés par DRM de contenir du HTML. Le délai accordé au groupe travaillant sur les extensions de médias cryptées (EME) étant fixé pour fin avril, le W3C se trouve face à deux choix s’il veut continuer sur cette lancée : valider la proposition EME telle qu’elle est et la publier en tant que norme avant la fin du mois d’avril ou prolonger le délai accordé au groupe de travail.

La question de savoir si le W3C devrait approuver la norme EME (Encrypted Media Extensions), qui permet à une page Web d'inclure du contenu crypté en connectant un système DRM (Digital Rights Management) sous-jacent existant dans la plate-forme sous-jacente, a soulevé la polémique.

L’Electronic Frontier Foundation (EFF) ainsi que la Free Software Foundation (FSF), les groupes de défense des droits numériques, se sont montrés contre cette proposition. Accompagnés par d’autres associations, ils ont publié une lettre ouverte pour faire entendre leur opposition et ont encouragé à signer une pétition.

L’EFF s’interroge tout d’abord sur l’utilité d’un tel système. Le groupe avance que « les entreprises qui veulent l’EME disent qu'elles en ont besoin pour prévenir la violation des droits d'auteur. Mais, après une longue expérience avec les DRM, il est apparu maintes et maintes fois qu'il n'est pas difficile de contourner ces systèmes. Et une fois qu'une personne trouve comment faire cela, il est possible de télécharger des versions sans DRM de vidéos sur des sites Web où les gens qui veulent violer le droit d'auteur peuvent se rendre [ … ]. Si les DRM servent de prévention de la piraterie, elles ne font pas un très bon travail ».

Ensuite l’EFF estime que les menaces de sanction autour de ce système sont démesurées. « Une fois qu'une entreprise utilise une DRM dans son produit, elle peut menacer quiconque ouvre ce produit d’une manière qui ne lui plait pas. Les limites exactes du DMCA 1201 sont contestées, les procureurs, les titulaires de droits et certains tribunaux plaidant pour une portée très large. Parce que les sanctions pour la perte d'une demande DMCA sont si effrayantes - dans certaines circonstances commerciales, cela pourrait signifier une amende de 500 000 $ et une peine de prison de 5 ans pour une première infraction ! - peu de gens veulent opérer dans la zone grise menacée par la DMCA 1201 ».

Selon l’EFF, trois groupes importants dans l’écosystème web vont perdre leurs droits à cause de l’EME. Il s’agit :

• des concurrents (cibles de l’EME) : les entreprises, les projets de logiciels libres et les individus qui veulent aider les gens à profiter au mieux des vidéos dans leurs navigateurs auront besoin de la permission des Netflix du monde afin de développer leurs outils ;
• les dénonciateurs en matière de sécurité (victimes collatérales) : les défenseurs de DRM ont estimé que la simple divulgation de défauts dans les produits qui utilisent des DRM viole l'article 1201 de la DMCA. Voici leur raisonnement : « lorsque vous dites aux gens les erreurs que nous avons commises dans la conception de nos produits, vous leur montrez également où se trouvent les points faibles de l'armure de notre DRM » ;
• les personnes handicapées (cibles involontaires) : si l’EFF reconnaît que l’EME embarque de nombreuses adaptations pour aider les personnes handicapées à profiter des vidéos, le groupe estime qu’il y a plusieurs façons dont cela pourrait être amélioré. Normalement, adapter la technologie pour accommoder les handicaps implique d'écrire du code. Cependant, parce que ces adaptations exigeraient de contourner DRM, les personnes voulant travailler sur des outils d'accessibilité devront obtenir des permissions au préalable, sous peine de sanctions criminelles et civiles.

Mais l’EME a également ses défenseurs. Parmi eux figure Tim Berners-Lee, le père du web. « La raison pour laquelle je recommande EME est que, en agissant ainsi, nous conduisons l'industrie qui l'a développée en premier lieu à produire un moyen simple et facile d'utiliser du contenu crypté en ligne, de sorte qu'il y aura interopérabilité entre les navigateurs. Cela va faciliter la tâche des développeurs web, mais va également profiter aux utilisateurs. Les gens aiment regarder des vidéos sur Netflix (par exemple). Les gens passent beaucoup de temps sur le Web, ils aiment être en mesure d'intégrer le contenu Netflix dans leurs propres pages Web. Ils aiment être en mesure d'avoir des discussions où ils expriment ce qu'ils pensent sur le contenu où leurs commentaires et le contenu peuvent tous être liés ».

Pour lui, il vaut mieux que les DRM passent par EME qu’autrement. Il explique par exemple que les systèmes EME peuvent faire du sandboxing du code de DRM pour limiter les dégâts potentiels sur le système des utilisateurs ou sur leur vie privée.

Le père du web a tout de même reconnu l’existence de problème avec les DRM au niveau des utilisateurs, des développeurs et de la loi (notamment pour les chercheurs en sécurité). Malgré cela, il estime qu’il vaut mieux que HTML5 intègre EME.

Source : EFF, lettre ouverte, pétition, billet Tim Berners-Lee

Et vous ?

Êtes-vous pour ou contre l'EME ?

[laerne]

L'argument de Tim Berners-Lee est mou du genou… On sort des arguments pareils avec l'industrie militaire : si on produit pas les armes pour des régimes à l'éthique questionables, d'autres le feront, blablabla… Et au final personne ne fait d'effort et rien n'évolue dans le bon sens.

[_FLX_]

1) M. Berners-lee n'est pas LE mais UN père du web.
2) Il n'a pas plus de légitimité que n'importe qui pour s'exprimer sur la question.
3) S'il en avait une, il vient de la perdre.


DMCANCER

[Grimly]

Je comprends mal cette histoire de DRM et je n'ai pas le temps de chercher le détail, pourrait-on m'aider à comprendre comment un DRM pourrait exister alors qu'un système tel que OAuth permettrait déjà de bloquer une ressource à une session ?

De plus, comment ça serait implémenté car il ne faut pas oublier qu'un navigateur ne sait pas deviner, il affiche ce qu'on lui donne et donner une donnée chiffrée avec sa clé n'empêche pas une personne motivée de reproduire l'opération de déchiffrement que fait le navigateur pour lire le flux audio/vidéo.

[psychadelic]

Mauvaise idée, les DRM induisent obligatoirement un assujettissement ou un tiers technique s'en met plein les poches et qui, mis à part une fourniture technique, n'apporte rien.

1) M. Berners-lee n'est pas LE mais UN père du web.
DMCANCER

Tu peux développer ?
parce que la j'ai l'impression que tu confond Internet (le réseau) et le Web, non ??

Ou alors est-ce que tu veux inclure Steve Jobs dans l'histoire (il a produit la machine NeXT) ou aussi Jean-Marie Hullot (il a créé Interface Builder, permettant T.B.Lee de créer le premier serveur Web). ???

[_FLX_]

Tu peux développer ?
parce que la j'ai l'impression que tu confond Internet (le réseau) et le Web, non ??

Ah, oui.
Quand je lis web je pense "INTERNET", pas "LES TROIS PRINCIPAUX PROTOCOLES INVENTES A LA PREHISTOIRE PAR SIR TIMOTHY JOHN BERNERS-LEE BIEN AVANT SA SENILITÉ".

J'ai probablement tort, mais je doute être le seul, surtout parmi les non-initiés.

[psychadelic]

Ben oui, pour moi ton jugement est mauvais.

Tim n’a jamais revendiqué l’invention d’internet, ni des « 3 principaux protocoles d’internet » ; il à juste eu la bonne idée d’utiliser cette technologie pour faciliter la visualisation de documents, en ajoutant par exemple la balise <a> pour mettre des liens hypertextes dans les documents du CERN (en SGML), de créer de toute pièce le premier serveur Web (sur une machine NeXT) , etc , etc.

Puis il a fondé le W3C sans lequel le web n’aurait jamais eu le minimum de cohérence qu’on lui connait aujourd’hui.

Bref, son apport à notre société numérique est loin d’être négligeable.

Quand à sa sénilité qu’elle soit avérée ou non, c’est franchement méchant

[thelvin]

Je comprends mal cette histoire de DRM et je n'ai pas le temps de chercher le détail, pourrait-on m'aider à comprendre comment un DRM pourrait exister alors qu'un système tel que OAuth permettrait déjà de bloquer une ressource à une session ?

Ça n'a rien à voir. OAuth c'est juste un système d'authentification login/mot de passe qui est fait pour être un peu transmissible entre différents partis.
Il empêche les gens qui ne connaissent pas le mot de passe d'un compte, de se connecter à ce compte. Et autorise les gens qui en connaissent le mot de passe, à s'y connecter.

Les DRMs ne veulent empêcher personne d'accéder à une ressource (ça c'est le boulot d'une autre techno, comme par exemple OAuth.)
On veut que l'utilisateur puisse accéder à la ressource, parce que sinon il y a des chances qu'il ne paie pas pour l'avoir.
Mais on ne veut pas qu'il en fasse ce qui lui chante : comme par exemple l'enregistrer sur son disque dur, et la regarder plus tard quand il veut, peut-être dans son propre lecteur sans passer par le site d'origine, et peut-être même la donner à d'autre gens qui pourront la regarder sans jamais passer par le site d'origine.
On veut qu'il y accède, oui, mais qu'il ne puisse en faire que ce qu'on est d'accord qu'il en fasse. Typiquement la regarder juste après avoir cliqué sur le bouton prévu dans le site web, et pas à un autre moment, pas ailleurs que sur le site web.
C'est un autre rôle, une autre restriction que les technologies d'authentification comme OAuth.

De plus, comment ça serait implémenté car il ne faut pas oublier qu'un navigateur ne sait pas deviner, il affiche ce qu'on lui donne et donner une donnée chiffrée avec sa clé n'empêche pas une personne motivée de reproduire l'opération de déchiffrement que fait le navigateur pour lire le flux audio/vidéo.

C'est effectivement la raison la plus évidente pour laquelle les DRMs ne seront jamais d'une efficacité totale.
Mais en théorie, c'est plus facile à dire qu'à faire : ce qui s'occupe de déchiffrer n'est pas le navigateur lui-même, mais un module de lecture fourni par les fournisseurs de technologies cryptées. Et ces modules sont des boîtes noires qu'on peut toujours essayer de décompiler, mais c'est loin d'être évident. Ils pourraient en principe communiquer directement avec la carte graphique ou avec l'OS à un niveau où il n'est pas évident de s'insérer pour espionner ce qui passe, et où de toute façon l'enregistrer ne fournirait pas une bonne qualité comme on en a en lisant le contenu comme prévu.
En théorie c'est plus difficile à dire qu'à faire, sauf que ce qui est prévu en pratique, c'est que les modules de déchiffrement fournissent les trames au navigateur pour qu'il les compose sur l'affichage en temps réel. Et là je voudrais bien, moi aussi, qu'on m'explique ce qui empêche de prendre le code source de Firefox, et donner au monde une version de Firefox qui enregistre les trames qu'il reçoit après décodage de contenu.

[Michel Rotta]

Si l'on regarde bien à l'usage, les DRM ne permettent pas de protéger un contenu contre la copie, il permet d’emmerder ceux qui payent pour voir légalement ce contenu.

Il reste encore beaucoup de lois à faire disparaitre.

[Stéphane le calme]

DRM dans HTML5 : la spécification EME franchit une nouvelle étape vers sa normalisation,
malgré l'opposition de nombreux défenseurs des droits numériques

Les extensions de médias chiffrées (EME, Encrypted Media Extensions), qui permettent à une page Web d'inclure du contenu crypté en connectant un système DRM (Digital Rights Management, gestion numérique des restrictions) sous-jacent, a franchi une nouvelle étape dans la voie controversée de sa normalisation. En effet, le W3C, l’organisme de normalisation qui supervise la plupart des spécifications liées au Web, a annoncé que EME en est désormais à la phase de « recommandation proposée ».

Après cette étape, le Comité consultatif du W3C va examiner la proposition et, s’il la trouve correcte, la proposition va enfin faire partie des recommandations de la W3C.

Dans son annonce, la W3C rappelle que « cette spécification ne définit pas un système de protection du contenu ou de gestion des droits numériques. Elle définit plutôt une API commune qui peut être utilisée pour découvrir, sélectionner et interagir avec de tels systèmes ainsi qu'avec des systèmes de cryptage de contenu plus simples. La mise en œuvre de la gestion des droits numériques n'est pas requise pour se conformer à cette spécification : seul le système Clear Key doit être implémenté comme ligne de base commune ».

Depuis que l’organisme a commencé à travailler sur EME, de vives polémiques ont été soulevées. L’Electronic Frontier Foundation (EFF) ainsi que la Free Software Foundation (FSF), les groupes de défense des droits numériques, se sont montrés contre cette proposition. Accompagnés par d’autres associations, ils ont publié une lettre ouverte pour faire entendre leur opposition et ont encouragé à signer une pétition.

L’EFF s’interroge tout d’abord sur l’utilité d’un tel système. Le groupe avance que « les entreprises qui veulent l’EME disent qu'elles en ont besoin pour prévenir la violation des droits d'auteur. Mais, après une longue expérience avec les DRM, il est apparu maintes et maintes fois qu'il n'est pas difficile de contourner ces systèmes. Et une fois qu'une personne trouve comment faire cela, il est possible de télécharger des versions sans DRM de vidéos sur des sites Web où les gens qui veulent violer le droit d'auteur peuvent se rendre [ … ]. Si les DRM servent de prévention de la piraterie, elles ne font pas un très bon travail ».

Mais Tim Berners-Lee, le père du Web qui est à la tête du W3C, organisme qu’il a fondé, a soutenu qu’étant donné que les DRM existent déjà et qu’il est peu probable qu’ils disparaissent dans un avenir proche, au moins du côté des vidéos, il est donc préférable que le contenu protégé fasse partie de l’écosystème Web au lieu d’être séparé de celui-ci.

Il a assuré que, pour presque tous les fournisseurs de vidéos, l’alternative à une DRM dans le navigateur est une DRM comme application autonome. Il a également fait valoir que ces applications autonomes représentent un risque plus important pour la vie privée et la sécurité que l'environnement contraint et sécurisé du Web.

Bien entendu, il a reconnu que les DRM rencontrent des difficultés, notamment en ce qui concerne une utilisation équitable, les travaux dérivés, mais aussi les sauvegardes. Il note cependant qu'un grand nombre de consommateurs ne semblent pas trop préoccupés par ces questions, car ils continuent à acheter ou à souscrire à des contenus protégés par DRM.

Jusqu'à présent, ces préoccupations ont été sensiblement ignorées, car ce sont des problèmes inhérents aux DRM et non des problèmes liés à une spécification particulière. Mettre de côté ces préoccupations est implicite dans la décision de développer la spécification EME en premier lieu.

EME ne définit pas de DRM lui-même. La seule exigence obligatoire est de fournir un système Clear Key (qui utilise des clés en clair) pour déchiffrer du contenu protégé.

Le W3C a répondu à certaines autres préoccupations. En particulier, à cause d’une clause du Digital Millennium Copyright Act (DMCA) des États-Unis, les chercheurs en sécurité craignaient que faire des rapports de bogues concernant les systèmes DRM pût se transformer en poursuite judiciaire si les consortiums estimaient que ces bogues créent la possibilité de contourner la protection DRM.

À cette fin, le W3C développe un ensemble de bonnes pratiques de sécurité pour la divulgation de ces bogues. Ces règles sont conformes aux politiques communes de « divulgation coordonnée », dans lesquelles les entreprises disposent d'un délai raisonnable pour réagir et colmater les failles avant leur divulgation. Elles exigent également que l'entreprise en question ne porte pas plainte contre quiconque divulgue des failles ou coopère dans des enquêtes des forces de l’ordre liées à une telle divulgation.

Si EME n’est pas acceptée comme recommandation complète, la spécification peut par exemple être publiée sous forme d’une note de groupe de travail, une option vers laquelle se tourne la W3C sans former de consensus lorsqu’elle choisit d’abandonner le travail effectué sur une proposition particulière.

Même si la spécification EME est abandonnée, tous les principaux navigateurs (Chrome, Internet Explorer, Edge, Firefox et Safari) utilisent déjà des versions préliminaires et des modules DRM compatibles. D’ailleurs, les sites Web comme Netflix et YouTube peuvent déjà diffuser des vidéos cryptées dans le navigateur sans avoir besoin de plug-ins tels que Silverlight ou Flash.

Source : W3C (recommandation proposée), W3C (meilleures pratiques de divulgation de sécurité)

[Michael Guilloux]

DRM dans HTML 5 : la Free Software Foundation appelle ses partisans à dire non
pour maintenir la sécurité et les droits des utilisateurs en ligne

Dans moins de deux semaines, la spécification EME (Encrypted Media Extensions) pourrait recevoir l’approbation finale du World Wilde Web Consortium (W3C). Elle pourra donc faire partie des standards du Web, et ce, en dépit des polémiques autour de cette initiative. Cela pourra avoir pour conséquence de booster la publication de contenu protégé par DRM sur le Web. Si la spécification elle-même ne définit pas de système de protection de contenu ou de gestion de droits numériques, elle définit une API commune qui peut être utilisée pour découvrir, sélectionner et interagir avec de tels systèmes ainsi qu'avec des systèmes de chiffrement de contenu plus simples.

Le 13 avril, nous saurons si la spécification EME sera validée par le W3C, et la Free Software Foundation (FSF) tente donc une dernière fois de freiner son intégration dans les standards du Web. La FSF demande en effet à ses partisans d’appeler Tim Berners-Lee « à ne pas mettre en danger les utilisateurs en intégrant une technologie oppressive dans les standards de base du Web ». Celui qui est à la tête du W3C s’est en fait affiché comme partisan de cette spécification, estimant que les DRM existent déjà et qu’il est peu probable qu’ils disparaissent dans un avenir proche, au moins du côté des vidéos. Il estime donc qu’il est préférable que le contenu protégé fasse partie de l’écosystème Web au lieu d’être séparé de celui-ci. Un standard permettra également d’éviter que chaque navigateur implémente différentes technologies pour la manipulation de contenu protégé par DRM, ce qui créerait des problèmes de compatibilité, en sachant également que l’implémentation de ces technologies pourra ne pas être à la portée des petits navigateurs.

Rappelons-le, les DRM (Digital Rights Management) offrent un ensemble de mesures techniques de protection qui ont pour objectif de contrôler l'utilisation qui est faite des œuvres numériques. Le premier problème avec les fichiers protégés par DRM (vidéos ou ebook par exemple) est donc le fait qu’ils imposent des restrictions aux utilisateurs sur du contenu qu'ils ont acheté et dont ils devraient disposer librement en principe. Les utilisateurs pourront par exemple ne pas être en mesure de les enregistrer sur leur machine, ou encore les lire avec d'autres logiciels, ou en dehors d'une plateforme unique proposée par le fournisseur du contenu. Bref, l'utilisateur ne dispose que d'un usage restreint du contenu qu'il a obtenu légalement, et pendant ce temps, d'autres personnes l'ayant obtenu illégalement pourront l'utiliser sans restriction. En effet, si les DRM visent à protéger les contenus de la piraterie, cet objectif n'est pas vraiment atteint. Les DRM sont très souvent contournés par certaines personnes qui vont ensuite publier les contenus piratés sur des sites pour les rendre disponibles au public.

Comme l’explique encore la FSF, les DRM ont déjà montré qu’ils pourraient exposer les utilisateurs à des risques de sécurité énormes et porter atteinte à leur vie privée. Le défenseur du Libre évoque par exemple le cas du DRM de Sony en 2005. La solution DRM utilisée par Sony pour protéger ses CD installait un rootkit sur le système des utilisateurs. Cet outil utilisant des techniques de dissimulation employées par des hackers permettait de s’assurer en toute discrétion qu’aucune copie n’est réalisable. La FSF rappelle encore que plus récemment, en 2014, il a été découvert que la DRM Digital Editions d’Adobe collectait les informations des utilisateurs et les envoyait à son éditeur en texte clair, sans une protection de chiffrement basique ; ce qui les exposait aux pirates.

La FSF estime donc la spécification EME ne devrait pas être validée par le W3C s’il est impossible d’analyser le code de ses systèmes DRM pour la recherche de problèmes de sécurité ; ce qui sera le cas, si la spécification est validée le 13 avril. Avec cette norme, les DRM seront en effet couverts par des lois anticontournement qui qualifient de crime potentiel, la révélation des défauts dans les produits sans l’autorisation de l’éditeur. Ces lois stipulent que « nul n’est autorisé à contourner une mesure technologique qui contrôle l’accès à une œuvre protégée », en précisant que « contourner une mesure technologique signifie déchiffrer une œuvre chiffrée ou procéder autrement pour éviter, contourner, désactiver ou altérer une mesure technologique, et ce, sans l’autorisation du propriétaire du copyright ».

La FSF estime donc que si cette API est ajoutée aux outils dont disposent les développeurs Web, il faudrait nécessairement inclure des protections pour les personnes qui découvrent des vulnérabilités de sécurité. Ces protections devraient couvrir aussi « les personnes qui adaptent les outils Web pour les personnes handicapées et les personnes qui créent de nouvelles technologies légitimes et novatrices pour améliorer les vidéos sur Internet ».

Source : Defective by Design

Et vous ?

Qu’en pensez-vous ?
Êtes-vous d'accord avec l'intégration de cette spécification dans les standards du Web ? Pourquoi ?

Voir aussi :

Le W3C refuse de protéger les chercheurs en sécurité qui étudient les DRM, la WHATWG s'allie à l'EFF pour lui demander de changer d'avis
USA : la justice a publié une liste d'exceptions à la section 1201 du Copyright Act, pour protéger les chercheurs qui étudient la sécurité des DRM

[23JFK]

Dès que je dois avoir affaire à un fichier protégé par DRM, soit j'essaye de trouver une alternative sans DRM, soit je me gratte le menton pour voir comment déplomber le fichier par moi-même, ceci car j'utilise trop de machines différentes, avec quasiment 100% de chances qu'un DRM m'empêche d'utiliser l'information que je désire consulter sur la machine la plus adaptée à ma situation du moment.

[Michael Guilloux]

DRM dans HTML5 : pourquoi le W3C renoncera à ses principes
s’il valide la proposition sur les extensions pour médias chiffrés

Dans une dernière vague de mouvements visant à empêcher la validation de la spécification EME (Encrypted Media Extensions), Kẏra, bien connue dans la communauté Haskell et ancienne militante de la Free Culture Foundation a sorti un ancien billet dans lequel elle accuse le W3C d’avoir trahi tous les internautes. Rappelons que plus tôt, c’était la Free Software Foundation qui appelait ses partisans à demander à Tim Berners-Lee, le patron de la W3C, de « ne pas mettre en danger les utilisateurs en intégrant une technologie oppressive dans les standards de base du Web ».

« Ne laissez pas les mythes vous tromper : le plan du W3C pour le DRM dans HTML5 est une trahison pour tous les utilisateurs du Web », tel était le titre du billet de blog de Kẏra, datant de 2013. Elle explique en effet que le Web Consortium s’est basé sur trois mythes pour défendre la nécessité d’intégrer le DRM dans HTML5.

Le premier mythe serait la croyance selon laquelle « le DRM ne fonctionne pas, qu’il existe pour protéger les créateurs, mais comme il peut être facilement contourné, il est complètement inefficace et impertinent ». D’après Kẏra, c’est complètement faux, parce que le DRM ne vise pas à protéger les droits d'auteur, mais plutôt à limiter les fonctionnalités des œuvres et commercialiser des fonctionnalités sous forme de services. « La perception publique selon laquelle le DRM existe pour empêcher la copie non autorisée est une erreur grave qui dissimule la fonction réelle du DRM, qui a un succès majeur : éviter les utilisations légales de la technologie afin que les entreprises de médias puissent facturer à plusieurs reprises pour des services qui fournissent des fonctionnalités qui ne devraient jamais être supprimées pour commencer. »

L’un des arguments avancés pour défendre l’intégration du DRM dans HTML5 est que cela constitue « un compromis nécessaire pour finalement mettre fin à la prolifération de plugins de navigateurs propriétaires comme Adobe Flash Player et Microsoft Silverlight ». D’après Kẏra, c’est également une fausse idée. Elle estime en effet que le DRM dans HTML5 n’entrainera pas la fin de ces plugins propriétaires, mais les encourage. La spécification Encrypted Media Extensions pourrait en effet offrir à ces plugins propriétaires « un nouvel espace en tant que module de déchiffrement de contenu (CDM) ». À propos, l’Electronic Frontier Foundation avait dénoncé le fait que « la proposition EME abdique explicitement la responsabilité sur les problèmes de compatibilité et permet aux sites Web de disposer d'un logiciel tiers exclusif ou même d'un matériel spécial et de systèmes d'exploitation particuliers (tous désignés sous le nom générique « modules de déchiffrement du contenu », et aucun d'entre eux n'est spécifié par la proposition EME). »

Notons déjà que certains contenus protégés par DRM peuvent être lus en utilisant les plugins Microsoft Silverlight et Adobe Flash. Autrement dit, Kẏra sous-entend que la spécification EME pourra intégrer de nouvelles implémentations de ces plugins sur le Web. « Les extensions pour médias chiffrés prévoient de prendre ce qui rend ces technologies particulières terribles pour les utilisateurs (gestion des restrictions numériques, support multiplateforme médiocre, etc.) et l'injecter directement dans le tissu du Web », dit-elle. « Ceci équivaut à inviter Microsoft Silverlight, Adobe Flash Player et autres technologies similaires à faire partie de la norme HTML5. »

Le dernier mythe serait le fait que le Web a besoin du DRM dans HTML5 afin que Hollywood et d'autres géants des médias puissent finalement commencer à donner la priorité au Web, plutôt qu’aux voies traditionnelles, pour la distribution de médias. Ici, elle rappelle que ce sont les grands médias qui dépendent du Web et non l'inverse, et les grandes entreprises médiatiques savent qu'elles doivent s'adapter pour survivre.

En somme, pour Kẏra comme pour nombreux observateurs, le DRM n’a pas sa place dans HTML5, surtout que cela va à l’encontre de la mission du W3C. Celle-ci consiste en effet à rendre les avantages du Web « disponibles à tous, quels que soient leur matériel, leur logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur situation géographique ou leur capacité physique ou mentale », comme indiqué sur le site officiel de l’organisme de normalisation. Kẏra conclut donc que la proposition pour les extensions de médias chiffrés n’est pas un compromis pour l'avancement du Web, mais plutôt « une concession complète des principes du W3C. »

Source : Kẏra

Et vous ?

Qu’en pensez-vous ?

[Shepard]

Les navigateurs qui cherchent à rendre le web ouvert tels que Firefox et Google Chrome vont-ils suivre la recommandation du W3C ? Rien ne les y force a posteriori de cette décision d'intégrer le support des DRM au HTML5 ...

Je ne suis pas franchement calé en "webopolitique", si quelqu'un est plus éclairé que moi sur la question, je ne demande qu'à parfaire ma culture

[thelvin]

Les navigateurs qui cherchent à rendre le web ouvert tels que Firefox et Google Chrome vont-ils suivre la recommandation du W3C ?

Google a ses propres services de vente de vidéo, et utilise pour cela cette recommandation (depuis bien avant que ce soit au stade recommandation.) On peut imaginer qu'ils ne seraient revendeurs de rien du tout s'ils ne le faisaient pas car aucun ayant-droit ne leur confierait de vidéo à revendre. Quoi qu'il en soit, ils s'en servent et fournissent eux-même le module de déchiffrement directement dans Chrome.

Firefox a été assez clair que cela lui soulève le cœur. Mais il a décidé que puisque le web utilisait déjà en grande partie cette recommandation, et donc que les navigateurs concurrents peuvent lire les vidéos restrictives sans problème pour les gens qui s'en servent, il ne voulait pas être volontairement incapable de lire les vidéos restrictives que ses utilisateurs lui demandent de lire. Tout ce qu'ils y verraient, c'est que Firefox ne marche pas pour lire des vidéos, et donc qu'il faut utiliser un autre navigateur. Un autre navigateur qui ne propose pas les valeurs que Firefox applique sur tout le reste que sur ce point-là précis.
Concrètement Firefox gère deux modules de déchiffrement, celui de Google et un autre, qui sont chacun téléchargés et activés automatiquement quand l'utilisateur visite une page qui en a besoin. Il est possible de le voir dans la pages des add-ons. Le plus simple pour vérifier est d'aller acheter une vidéo sur Google Play et la regarder.

Cela fait donc belle lurette qu'ils suivent cette recommandation, l'un sans trop dire pourquoi mais en même temps il y a du bénéfice qui en dépend. L'autre ça lui fait du mal mais c'est ça ou passer pour un navigateur qui ne fonctionne pas, les utilisateurs n'étant pas du genre à se demander les valeurs qui poussent à ce que leur vidéo ne marche pas, ils prennent juste un navigateur qui marche.

Rien ni personne n'est, certes, forcé de suivre une recommandation du W3C. Il y en a une cinquantaine pourtant bien abouties que personne ne suit. Parce que ça ne les intéresse pas. Quand par contre, une nouvelle fonctionnalité populaire apparaît dans la technologie web, et que plusieurs navigateurs la gèrent plutôt bien, les autres ont juste intérêt à faire pareil s'ils veulent une raison d'exister. C'est en général bien après ce passage qu'ils se réunissent pour standardiser cette technologie et qu'elle devient un jour une recommandation W3C.

[CoderInTheDark]

C'est très dangereux un contenu protégé est potentiellement inaccessible
Donc pour faire des profits ils sont prèts à exclure des utilisateurs
Déjà que je galère pour promouvoir l'accessibilité.
M'adresser a ces acteurs qui méprisent déjà leur utilisateurs lambdas, vont pas se soucier des 2 ou 3 %% de défficients visuels.

[Michael Guilloux]

DRM dans HTML5 : Tim Berners-Lee approuve la spécification Encrypted Media Extensions
les organisations membres du W3C peuvent encore faire appel

Le 6 juillet 2017, Tim Berners-Lee, le patron du World Wild Web Consortium (W3C) a approuvé la controversée spécification EME (Encrypted Media Extensions). Si elle ne définit pas de système de protection de contenu ou de gestion de droits numériques (DRM), la spécification EME définit une API commune qui peut être utilisée pour découvrir, sélectionner et interagir avec de tels systèmes ainsi qu'avec des systèmes de chiffrement de contenu plus simples. Elle pourra donc avoir pour conséquence de booster la publication de contenu protégé par DRM sur le Web, raison pour laquelle elle fait l’objet de controverse. Rappelons-le, les DRM (Digital Rights Management) offrent un ensemble de mesures techniques de protection qui ont pour objectif de contrôler l'utilisation qui est faite des œuvres numériques.

La décision de Tim Berners-Lee était attendue depuis avril dernier, mais semble-t-il, a été retardée pour un examen approfondi, vu l’importance et la polémique autour de cette spécification. Plusieurs objections ont été soulevées au cours de la dernière révision de la spécification. « Le directeur [du W3C] a examiné très attentivement ces objections et a également discuté avec les experts et le grand public », rapporte Philippe Le Hégaret, Project Management Lead, au nom de Tim Berners-Lee. « Dans certains cas, le directeur a constaté que les objections avaient déjà été traitées, mais a demandé au groupe de travail de préciser la manière dont ces questions étaient traitées [...] Dans d'autres cas, les objections ont été rejetées. Sur la base de cela, et le fait que [la spécification] EME améliore l'expérience de l'utilisateur par rapport aux solutions d'aujourd'hui, le directeur a décidé de publier la spécification EME révisée en tant que Recommandation du W3C. »

Tim Berners-Lee estime en effet que « par rapport aux méthodes précédentes de visualisation de vidéo chiffrée sur le Web, EME a l'avantage que toutes les interactions se produisent au sein du navigateur Web et sont gérées par le navigateur et non les plugins. De cette manière, EME offre une meilleure expérience utilisateur, offrant une plus grande interopérabilité, confidentialité, sécurité et accessibilité à la visualisation de vidéos chiffrées sur le Web. » Bien que cette spécification ne supprime pas le fait que l'utilisateur doit interagir avec un module de déchiffrement de contenu (CDM), le patron du W3C pense qu’il s'agit d'une « amélioration par rapport à la situation pré-EME et une étape vers des améliorations futures également ».

Cette décision peut toutefois être encore renversée, et pour cela, la Free Software Foundation (FSF), avec sa campagne Defective by Design, lance un appel aux organisations membres du comité consultatif du W3C à réagir. « Les organisations membres du W3C doivent prendre leurs responsabilités pour les droits numériques des utilisateurs du Web et faire appel de la décision désastreuse de Tim Berners-Lee », a déclaré Zak Rogoff, responsable des campagnes FSF. « Les priorités de ceux qui définissent les normes doivent être la liberté, la confidentialité, la sécurité, l'interopérabilité et l'accessibilité des utilisateurs, et ne pas aider Hollywood et les entreprises de streaming à rendre leur DRM anti-utilisateur plus efficace », dit-il. Il suffirait que 5 % des 475 membres du comité du W3C rejoignent la campagne anti-EME pour déclencher un vote de l'ensemble du comité afin de prendre une décision définitive soit pour ratifier, soit pour rejeter la spécification EME.

Sources : Décision de Tim Berners-Lee, FSF

Et vous ?

Qu'en pensez-vous ?

[poma88]

Concrètement il va se passer quoi ?

Fini le DDL avec un soft ou plugin, des vidéos sur YT, vimeo, etc... ?

[thelvin]

Concrètement il va se passer quoi ?

Il ne va rien se passer. Comme la plupart du temps quand une recommandation W3C atteint l'approbation, ça s'est déjà passé depuis longtemps. C'est juste Tim qui dit, "ouais, c'est bon" à propos d'un truc qui est déjà utilisé par tous ceux qui seraient intéressés à l'utiliser.

À la rigueur, il reconnaît que ça a l'air de bien coller en l'état et qu'il va pas y avoir de changement nécessaire à la manière dont ça fonctionne. Quand ça changera ce sera une évolution avec compatibilité ascendante. Ce qui peut motiver des sites plus frileux à se lancer maintenant que ça semble annoncé stable. Mais dans ce cas-là il vaut mieux attendre que les oppositions soient encore un peu rebutées, au cas où. Mais bon dans ce cas très précis, les oppositions à la recommandation ne s'opposent pas à des points techniques, mais à l'existence même de proposer une recommandation pour cela. Du coup, leur but n'est pas d'améliorer la recommandation mais de lui retirer son aspect officiellement approuvé.

Ce qui s'est passé, quand cette recommandation a commencé à bien prendre forme il y a quelques temps, c'est que des sites web, comme YouTube et Google Play, sont devenus capables d'afficher des vidéos avec restrictions de droits numériques, et cela sans utiliser de plugin du genre Flash. Uniquement en utilisant un plugin de déchiffrement de vidéo conforme à cette recommandation. C'est à dire infiniment plus léger que Flash, et moins sujet aux bugs, attaques de sécurité et plantages. Pour la simple raison que Flash cherche à faire tout et n'importe quoi alors qu'un déchiffreur de vidéo cherche à déchiffrer des vidéos. Pas besoin de planter la machine pour ça. Du moins en principe.

Quant à ce que ça veut dire concrètement jouer les vidéos avec restriction de droits numériques, ça veut dire la même chose que quand ils le faisaient avec Flash : rien de très réel. En théorie quand on joue des vidéos sans restriction, il est "facile" de brancher quelque part un programme qui enregistre cette vidéo dans un fichier. Ce qui te permet ensuite de donner ce fichier à tes amis ou de le regarder à nouveau plus tard, dans ton propre lecteur vidéo au lieu de sur le site, sans session ouverte et sans payer d'abonnement. D'ailleurs quand on fait une simple balise <video> avec une simple URL source, le navigateur propose d'enregistrer la vidéo avec un clic droit.

En pratique si jamais cette vidéo est diffusée en streaming contrôlé par JavaScript et non pas en spécifiant une URL, le navigateur ne peut pas deviner comment l'enregistrer et donc ne le propose déjà pas. Et cela, avec ou sans restriction de droits. C'est censé être "facile" de concevoir un programme qui va le faire, ouais ben on peut raisonnablement demander à voir. L'idée de la restriction des droits, c'est de rendre l'enregistrement de la vidéo "pas facile" en chiffrant cette vidéo lors des échanges réseaux et en ne la déchiffrant qu'à l'intérieur d'un plugin qui tourne sur la machine et ne propose pas l'enregistrement. Sauf que dans la réalité, il est discutable que ce soit compliqué de faire un programme qui intercepte les vidéos déchiffrées par le plugin. Si les gens ne le font pas, c'est plutôt parce qu'on n'en a pas besoin pour l'instant.

Quant aux DDL dont tu parles, rien ne change. On pouvait les télécharger parce qu'ils n'étaient pas chiffrés avant et ils ne l'étaient pas plus après. Ils ne sont pas chiffrés parce que ça n'intéressait pas les sites en question de faire du chiffrement. S'ils avaient voulu en faire, ils pouvaient le faire avant par d'autres moyens.

[RyzenOC]

Au lieu de télécharger le flux vidéo on fera une capture vidéo de l'écran, voila voila (qu'ils sont con quand meme )