DRM dans HTML5 : pourquoi le W3C renoncera à ses principes S'il valide la proposition sur les extensions pour médias chiffrés 42PARTAGES 20 0 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



« 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 :



Et vous ?



Quen pensez-vous ? 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 Quen pensez-vous ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 46 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Expert éminent sénior https://www.developpez.com Envoyé par RyzenOC Envoyé par (qu'ils sont con quand meme ) 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



Dans un premier temps oui, ça sera sans trop de douleur. Actuellement c'est juste un plugin, produit par un tiers, sandboxé, qui est préinstallé dans les navigateurs. Dailleurs ça me fait bien rire quand Tim Berners-Lee dit que ça permet déchapper au plugins. On a exactement le même problème qu'avec Flash : un plugin propriétaire de Adobe maintenant remplacé par celui de Google. Ça limite les plateformes supportables et ça posera des problèmes le jour le support viendra à défaillir.



Mais le deuxième effet Kisscool, c'est que comme les mécanismes de protection ne sont absolument pas définis : ils peuvent passer s'ils le souhaitent aux DRM matériels, et tu peux être sur qu'ils le feront lorsque EME sera si bien installé que passer aux solutions alternatives sera trop compliqué. Pour info, les cartes graphiques est les moniteurs actuels ont tous des protections qui ne sont pas encore activées dans la plupart des cas. Ils sont capable de traiter eux même un signal HDMI crypté sans décodage du coté de l'ordinateur.



Bref cette norme est une reconnaissance de fait des chevaux de Troie dans les navigateurs web. 4 0 Sauf que, toute la subtilité de cette norme, c'est qu'elle est assez vague pour permettre d'aller bien au delà de ce qui est fait aujourd'hui.Dans un premier temps oui, ça sera sans trop de douleur. Actuellement c'est juste un plugin, produit par un tiers, sandboxé, qui est préinstallé dans les navigateurs. Dailleurs ça me fait bien rire quand Tim Berners-Lee dit que ça permet déchapper au plugins. On a exactement le même problème qu'avec Flash : un plugin propriétairemaintenant remplacé par celui de Google. Ça limite les plateformes supportables et ça posera des problèmes le jour le support viendra à défaillir.Mais le deuxième effet Kisscool, c'est que comme les mécanismes de protection ne sont absolument pas définis : ils peuvent passer s'ils le souhaitent aux DRM matériels, et tu peux être sur qu'ils le feront lorsque EME sera si bien installé que passer aux solutions alternatives sera trop compliqué. Pour info, les cartes graphiques est les moniteurs actuels ont tous des protections qui ne sont pas encore activées dans la plupart des cas. Ils sont capable de traiter eux même un signal HDMI crypté sans décodage du coté de l'ordinateur.Bref cette norme est une reconnaissance de fait des chevaux de Troie dans les navigateurs web. Inactif https://www.developpez.com Envoyé par Uther Envoyé par Sauf que, toute la subtilité de cette norme, c'est qu'elle est assez vague pour permettre d'aller bien au delà de ce qui est fait aujourd'hui.



Dans un premier temps oui, ça sera sans trop de douleur. Actuellement c'est juste un plugin, produit par un tiers, sandboxé, qui est préinstallé dans les navigateurs. Dailleurs ça me fait bien rire quand Tim Berners-Lee dit que ça permet déchapper au plugins. On a exactement le même problème qu'avec Flash : un plugin propriétaire de Adobe, ce qui limite les plateformes supportables et qui posera des problèmes le jour le support viendra à défaillir.



Mais le deuxième effet Kisscool, c'est que comme les mécanismes de protection ne sont absolument pas définis, ils peuvent passer s'ils le souhaitent aux DRM matériels, et tu peux être sur qu'ils le feront lorsque EME sera si bien installé que passer aux solutions alternatives sera trop compliqué. Pour info, les cartes graphiques est les moniteurs actuels ont tous des protections qui ne sont pas encore activées dans la plupart des cas. Ils sont capable de traiter eux même un signal HDMI crypté sans décodage du coté de l'ordinateur.



Bref cette norme est une reconnaissance de fait des chevaux de Troie dans les navigateurs web.

Dans mon précédent poste, je voulais juste dire que les DRM c'est au final une vaste blague (Denuvo est mort, plus aucun jeu n'arrive à tenir 3 mois)... les drm serons toujours contournée par les pirates et le client honnête sera toujours le dindon de la farce car il profitera d'un service moins performant et/ou avec plus de contrainte que le pirate.



Y'a qu'a voir Netflix qui impose la derriere gen de cpu intel et Windows 10 + edge pour profiter de la 4K...alors que sur mon raspberry 1 de 2012 sous libre-elec je peut regarder un film en 4K

et j'ai appris récemment que les plateforme de streaming légale ne supporte meme pas le surround 7.1...



C'est en bossant sur la qualité qu'on limite le piratage, pas en bossant sur les drm. 4 0 Dans tous les cas ils n'arriverons jamais à nous interdire de filmer l'écran avec une caméra en fasseDans mon précédent poste, je voulais juste dire que les DRM c'est au final une vaste blague (Denuvo est mort, plus aucun jeu n'arrive à tenir 3 mois)... les drm serons toujours contournée par les pirates et le client honnête sera toujours le dindon de la farce car il profitera d'un service moins performant et/ou avec plus de contrainte que le pirate.Y'a qu'a voir Netflix qui impose la derriere gen de cpu intel et Windows 10 + edge pour profiter de la 4K...alors que sur mon raspberry 1 de 2012 sous libre-elec je peut regarder un film en 4Ket j'ai appris récemment que les plateforme de streaming légale ne supporte meme pas le surround 7.1...C'est en bossant sur la qualité qu'on limite le piratage, pas en bossant sur les drm. Modérateur https://www.developpez.com Envoyé par Shepard Envoyé par Les navigateurs qui cherchent à rendre le web ouvert tels que Firefox et Google Chrome vont-ils suivre la recommandation du W3C ?



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. 3 0 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. Modérateur https://www.developpez.com Envoyé par poma88 Envoyé par Concrètement il va se passer quoi ?



À 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. 3 0 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.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 avec une simple URL source, le navigateur propose d'enregistrer la vidéo avec un clic droit.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. Inactif https://www.developpez.com (qu'ils sont con quand meme ) 3 0 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 Expert éminent sénior https://www.developpez.com Envoyé par RyzenOC Envoyé par . Dans tous les cas ils n'arriverons jamais à nous interdire de filmer l'écran avec une caméra en fasse



Envoyé par RyzenOC Envoyé par Dans mon précédent poste, je voulais juste dire que les DRM c'est au final une vaste blague (Denuvo est mort, plus aucun jeu n'arrive à tenir 3 mois)... les drm serons toujours contournée par les pirates et le client honnête sera toujours le dindon de la farce car il profitera d'un service moins performant et/ou avec plus de contrainte que le pirate. 3 0 Bien sur qu'il y a toujours moyen, c'est juste une question de rapport complexité/cout/qualité. Si tu filmes l'écran, tu as un perte de qualité catastrophique. Tu peux aussi détourner lélectronique et/ou le firmware embarqué dans l'écran mais ça devient un exploit qui n'est pas a la portée de tous.Bien évidement et même en sachant ça depuis longtemps, les distributeurs de contenus n'ont pas arrête pour autant. C'est bien qu'ils y ont un intérêt. Le but des DRM n'est pas dempêcher le piratage en soi, on sait très bien que ça ne marche pas, mais de retirer un peu plus au client le contrôle de ce qu'il achète. Membre chevronné https://www.developpez.com

Où étaient les autres sur un vote important comme celui là ? 3 0 Et pourquoi il n'y a eu que 185 participant sur 400 votants ?Où étaient les autres sur un vote important comme celui là ? Membre extrêmement actif https://www.developpez.com Quen pensez-vous ?



Que l'EFF a bien eu raison de quitter le W3C dans ces conditions.

Introduire volontairement une technologie soumise à brevet dans une norme historiquement "ouverte" et clamer que c'est pour le bien de tous, je ne sais pas vous, mais je ne suis pas convaincu.

A la limite, je préfère l'utilisation de plugins proprio qui eux ne "salissent" pas le côté "ouvert" de la norme et qui sont limite plus intéropérable.



Que pensez-vous du Web après que lEME est devenue un standard ?



Comme l'a rapporté Mr Maddock, ça n'as aboutie qu'a une privatisation du web par les grands fournisseur de navigateurs.

Mais bon, ce n'est pas comme si ils s'en cacher et serait donc dû être le rôle du W3C de les stopper nette.

"Business is business"



La norme EME empêche-t-elle la création dun navigateur indépendant fonctionnel, selon vous ?



Non, mais du coup on ne peut plus dire que le navigateur est 100% compatible HTML5 par exemple. 3 0 Que l'EFF a bien eu raison de quitter le W3C dans ces conditions.Introduire volontairement une technologie soumise à brevet dans une norme historiquement "ouverte" et clamer que c'est pour le bien de tous, je ne sais pas vous, mais je ne suis pas convaincu.A la limite, je préfère l'utilisation de plugins proprio qui eux ne "salissent" pas le côté "ouvert" de la norme et qui sont limite plus intéropérable.Comme l'a rapporté Mr Maddock, ça n'as aboutie qu'a une privatisation du web par les grands fournisseur de navigateurs.Mais bon, ce n'est pas comme si ils s'en cacher et serait donc dû être le rôle du W3C de les stopper nette."Business is business"Non, mais du coup on ne peut plus dire que le navigateur est 100% compatible HTML5 par exemple. Expert confirmé https://www.developpez.com



Puis il y a ceux qui leur proposent «*une protection*»



Quand il y a une ruée vers lor, ceux qui vendent des pelles et des pioches sont toujours gagnants. 3 0 Il y a ceux qui espèrent trouver fortune en refourguant nimporte quelle vidéo sur la toile, mais qui sont fâchés tout rouge si elles sont copiées sans les payer en retour.Puis il y a ceux qui leur proposent «*une protection*»Quand il y a une ruée vers lor, ceux qui vendent des pelles et des pioches sont toujours gagnants. Modérateur https://www.developpez.com



C'est pas tout d'être un navigateur, encore faut-il qu'il y ait des gens qui s'en servent, en assez grand nombre pour que ça ait un effet pour le monde.



Cette remarque étant faite, à l'inverse, si on imagine un nouveau navigateur émergent, qui fonctionne vraiment bien sur le web d'aujourd'hui, mais qui a "quelque chose" qui plaît énormément aux gens et qui du coup récupère un grand pourcentage d'utilisation comme Chrome l'a fait en son temps, eh ben Google et Microsoft risquent de passer pour des anti-progrès aux yeux de tous et d'un seul coup les solutions de piratage de contournement de ces "connards qui nous empêchent d'utiliser le navigateur qu'on veut" vont gagner en popularité, bref, il serait logique qu'ils fassent pas les kékés devant un vrai navigateur qui existe vraiment, et qu'il y ait une licence pour lui. Si Microsoft veut jouer les gros bras avec sa licence payante, ça ne sera jamais bon pour lui. Et de toute façon qui utilise le DRM de Microsoft aujourd'hui ? Jusqu'à quel point Netflix peut se permettre de dire qu'ils ont pas à gérer un navigateur que tout le monde utilise, s'ils veulent que les gens paient un abonnement au lieu de pirater ? Google ferait bien d'y regarder à deux fois avant de mettre dedans ses partenaires commerciaux.



Cette histoire comme quoi on peut plus faire de navigateur indé, elle est sûrement vraie, mais ça a rien à voir avec les DRM. C'est juste que c'est compliqué sans les moyens de Microsoft, Google ou Mozilla, de faire un navigateur qui rivalise avec les leurs.



Concernant l'histoire selon laquelle ces DRMs auraient empêché un navigateur indé d'exister quand il a demandé une licence des DRM Google, elle est viciée. Oui, d'accord, c'est vrai qu'elle raconte l'histoire du fait que les DRMs nous empêchent d'innover dans les technologies lorsqu'elles sont protégées par DRM. Comme cela a toujours été le cas avec les DRMs, avant ou après que le W3C en standardise sur le web. Mais il est bien normal, car c'est c'est le but même de l'existence des DRMs, que cette licence ait été refusée. Le navigateur en question servait à partager/recaster les vidéos qu'il reçoit vers n'importe quel appareil sur le web qui puisse recevoir ce recast, et notamment le même navigateur sur l'ordinateur de quelqu'un d'autre. Bref, récupérer la vidéo et l'envoyer à ses potes. Exactement ce que les DRMs disent qu'ils existent pour l'empêcher. Ils allaient faire quoi d'autre que refuser ? C'est pas un navigateur normal, ça, c'est pas une fonction qu'un navigateur est censé avoir, et même si on pourrait souhaiter que les navigateurs indés soient libres d'innover comme ils veulent, il reste que les DRMs, ça existe précisément pour empêcher des fonctions comme celle-là. S'il croit vraiment à son idée, il doit bien évidemment accepter qu'elle ne marchera qu'avec les vidéos sans DRM. 3 0 Je pense que la notion "d'exister" pour un navigateur était à prendre comme Mozilla le présentait à l'époque. Ils ont pas envie de se soumettre à ce truc, mais s'ils ne le font pas les utilisateurs qui essaient de regarder des vidéos avec Firefox ne vont pas y arriver, donc ils vont changer de navigateur pour en prendre un qui lit les vidéos. Et si Mozilla se retrouve avec 0% d'utilisateurs, ben ils n'ont plus rien à proposer pour le web à travers leur navigateur, et en cela "ils n'existent pas".C'est pas tout d'être un navigateur, encore faut-il qu'il y ait des gens qui s'en servent, en assez grand nombre pour que ça ait un effet pour le monde.Cette remarque étant faite, à l'inverse, si on imagine un nouveau navigateur émergent, qui fonctionne vraiment bien sur le web d'aujourd'hui, mais qui a "quelque chose" qui plaît énormément aux gens et qui du coup récupère un grand pourcentage d'utilisation comme Chrome l'a fait en son temps, eh ben Google et Microsoft risquent de passer pour des anti-progrès aux yeux de tous et d'un seul coup les solutions de piratage de contournement de ces "connards qui nous empêchent d'utiliser le navigateur qu'on veut" vont gagner en popularité, bref, il serait logique qu'ils fassent pas les kékés devant un vrai navigateur qui existe vraiment, et qu'il y ait une licence pour lui. Si Microsoft veut jouer les gros bras avec sa licence payante, ça ne sera jamais bon pour lui. Et de toute façon qui utilise le DRM de Microsoft aujourd'hui ? Jusqu'à quel point Netflix peut se permettre de dire qu'ils ont pas à gérer un navigateur que tout le monde utilise, s'ils veulent que les gens paient un abonnement au lieu de pirater ? Google ferait bien d'y regarder à deux fois avant de mettre dedans ses partenaires commerciaux.Cette histoire comme quoi on peut plus faire de navigateur indé, elle est sûrement vraie, mais ça a rien à voir avec les DRM. C'est juste que c'est compliqué sans les moyens de Microsoft, Google ou Mozilla, de faire un navigateur qui rivalise avec les leurs.Concernant l'histoire selon laquelle ces DRMs auraient empêché un navigateur indé d'exister quand il a demandé une licence des DRM Google, elle est viciée. Oui, d'accord, c'est vrai qu'elle raconte l'histoire du fait que les DRMs nous empêchent d'innover dans les technologies lorsqu'elles sont protégées par DRM. Comme cela a toujours été le cas avec les DRMs, avant ou après que le W3C en standardise sur le web. Mais il est bien normal, car c'est c'est le but même de l'existence des DRMs, que cette licence ait été refusée. Le navigateur en question servait à partager/recaster les vidéos qu'il reçoit vers n'importe quel appareil sur le web qui puisse recevoir ce recast, et notamment le même navigateur sur l'ordinateur de quelqu'un d'autre. Bref, récupérer la vidéo et l'envoyer à ses potes. Exactement ce que les DRMs disent qu'ils existent pour l'empêcher. Ils allaient faire quoi d'autre que refuser ? C'est pas un navigateur normal, ça, c'est pas une fonction qu'un navigateur est censé avoir, et même si on pourrait souhaiter que les navigateurs indés soient libres d'innover comme ils veulent, il reste que les DRMs, ça existe précisément pour empêcher des fonctions comme celle-là. S'il croit vraiment à son idée, il doit bien évidemment accepter qu'elle ne marchera qu'avec les vidéos sans DRM. Poster une réponse Signaler un problème

