• # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Les sources sont dispo

    Posté par  . Évalué à 4.

    Par contre je viens de trouver les sources de DReaM (le nom de ce DRM) qui sont sous licence "libre" (CDDL).
    Et un truc intéressant : il y a déjà un patch pour VLC, sous GPL, ici : https://dream.dev.java.net/source/browse/dream/DReaM/DReaMCA(...)
    A étudier donc pour savoir ce qu'il s'y cache.

    • [^] # Re: Les sources sont dispo

      Posté par  . Évalué à 10.

      Alors je viens de lire rapidement le code des différentes parties du truc, et globalement, je vois rien de très compliqué, ni de code proprio, rien de bizarre.
      En fait, ce DRM utilise même des outils tout a fait classiques : curl, SSL, etc... En bref, chaque contenu DRMisé est crypté, et lorsqu'on a besoin de lire le contenu, il va chercher la clé sur un serveur de clé, qui lui donne (ou non ...) et décrypte le contenu. Mais rien sur le nombre de lectures, le nombre de copies, rien même pour empêcher VLC de dumper le flux dans un fichier ! (apparemment, hein, je n'ai fait qu'une lecture rapide)

      Et c'est là que je me suis dit qu'il y avait qqch de bizarre. Et je me suis dit qu'en fait, effectivement, les gens de chez Sun doivent très bien savoir qu'on ne PEUT PAS empêcher qqn de copier un contenu numérique une fois décrypté. L'astuce se trouve autre part que dans la technique. J'ai remarqué ça en voyant qu'une importance certaine était accordée au serveur de licence. Alors voilà ce que j'ai pensé (attention, énorme extrapolation de ce que j'ai lu) :

      J'ai remarqué qu'une clé privée pour l'utilisateur était utilisée pour négocier ces transactions. En fait, je pense que le cryptage comme on le pense en ce moment pour les DRM, c'est à dire que le contenu est codé avec la clé privée de Sony/Microsoft/etc ... et décodé avec leur clé publique, n'est pas utilisé ici. C'est plutôt l'inverse : chaque utilisateur envoie sa clé publique au serveur, qui va coder le contenu avec et l'envoyer à l'utilisateur (qui le décodera avec sa clé privée). A priori, cela ne change pas grand chose, on a le contenu et la clé (que ce soit dans le cas de la clé publique des Majors, ou de sa clé privée), on le décode. On a notre morceau décrypté, super.

      Mais c'est sur autre chose que vont jouer les majors (ou tout autre fournisseur de contenu DRMisé, car je pense que ça va très vite s'étendre) à mon avis : le serveur de clé justement. Comme on lui donne sa clé publique pour qu'il nous crypte le contenu, il nous identifie. Il peut donc choisir de nous refuser sur certains critères (qui seront bien cachés par les majors) comme le fait qu'on soupçonne qqn de faire circuler les fichiers en clair sur le P2P, ou autre. Vous allez me dire : mais comment savoir quel utilisateur (donc avec quelle clé) a "piraté" le contenu en le débarrassant de ses DRMs ? Je pense par exemple au water-marking. Et comme cela, on se retrouve à se voir refuser l'accès à tout contenu DRMisé. "Ho, pas grave, je vais recréer un compte" -> là je pense que justement, ça sera assez contrôlé, et on pourra également détecter les "récidivistes" ; "Ho, pas grave, je vais aller me fournir sur le P2P" -> oui mais pour fournir le P2P, il faut donc que certaines personnes "sacrifient" leur clé afin de décoder du contenu. Vous allez me dire, mais si tout le monde fait comme ça, les majors ne pourront plus suivre, elles abandonneront leur système. Mais c'est sans compter sur l'égoïsme humain, qui fera qu'au final personne ne voudra se "sacrifier", ou alors ce sera toujours les même; bref, comme toujours dans la vie réelle...

      Enfin voilà la petite réflexion qui m'est venue à l'esprit; je vais m'arrêter là pour l'instant pour éviter le post de 3km. Attention tout de même, ce que je viens de dire est à prendre avec des pincettes, je pense que je suis parti très loin de ce qu'est le code à la base, cela provient donc au final majoritairement de mon imagination. J'espère que ce n'est pas vraiment ça. Non, vraiment, il ne faut pas que ce soit ça...

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Les sources sont dispo

          Posté par  (site web personnel) . Évalué à 4.

          Il suffirait d'obliger l'utilisateur à "signer" le fichier lorsqu'il est décodé.
          En gros, quand l'utilisateur décrypte avec sa clé, l'empreinte de sa clé reste dans le fichier décodé.
          Le tour est joué, on pourra savoir si 1- le fichier a été crypté à moment ou un autre 2- À qui il appartient.

          En pratique, je ne vois pas du tout comment ce système là peut s'organiser. C'est sans compter que des fichiers mp3 circulent déjà, donc ça sera pour protéger les morceaux "nouveaux".
          Après, ça m'étonnerait que les CDs disparaissent aussi vite. Et tant qu'un logiciel poeut lire un CD au même titre qu'une chaîne, le contournement reste facile.

          Il faudra donc attendre la disparition totale des CDs et l'excusivité des fichiers protégés...

          De plus, dans le système dont on parle 2 post plus ahut, il faut que toute la chaîne soit dans le coup : les producteurs (OK), les palteformes de dl (OK), mais aussi tous les lecteurs qui obligeront l'utilisateur à avoir la license du fichier (WMP le fait, pas xmms ou play). L'OS mériterai même d'être dans le coup, pour empêcher la lecture des CDs non protégés !
          C'est le genre de système qui ne marche pas bien ...(ou qui marche uniquement à cause du(des) monopole(s))

          • [^] # Re: Les sources sont dispo

            Posté par  (site web personnel) . Évalué à 4.

            Dans le systeme présenté ci-dessus, le serveur chiffre avec la clef publique de l'utilisateur. Cependant, rien ne l'empêche a ce moment la de mettre une clef unique par stéganographie ;-) Du coup, retrouver la source devient beaucoup plus facile, chaque film diffusé étant unique.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 4.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Les sources sont dispo

                Posté par  (site web personnel) . Évalué à 3.

                Qui a dis que l'algo de la stegano était libre ? Comme ce code ne te sers a rien, il n'y a aucune raison que tu le connaisse. Cela n'empeche pas la lecture du film ni sa copie. Ca permet juste de tracer chaque copie de film de manière unique a la sortie de l'usine. D'ailleurs, je suis sur qu'il y a u truc d'équivalent sur les billets de banque et cela ne gène personne.

                Et même si l'algo de stegano était libre, comme tu ne sais pas ce qui est codé, par exemple ta clef publique chiffré par la clef privé de l'usine, ca t'avance a quoi. Je croyais, j'ai peut être tords, qu'il y avait des procédés de stéganographie inviolable aujourd'hui (inviolable au même sens que l'algorithme RSA dans un autre domaine).

                Mais depuis que j'ai fait pour premier post, j'ai l'impression que mon idée est identique a ce qu'ils appellement watermarking.

                • [^] # Re: Les sources sont dispo

                  Posté par  . Évalué à 3.

                  Dans le même style que les billets de banques, les feuilles d'impots. J'ai fais cet après midi une copie d'une feuille d'imposition avec mon imprimante, qui a ajouté des "copies" en filigranne. Il y a sûrement du watermark là dessous (et même de la détection de watermark par l'imprimante)

                  • [^] # Re: Les sources sont dispo

                    Posté par  . Évalué à 2.

                    Effectivement avec un photocopieur des mentions 'copie' apparaissent, mais il me semble que ça dépend de l'optique de la machine. Il me semble qu'avec un scanner ça ne marche plus.

                    • [^] # Re: Les sources sont dispo

                      Posté par  . Évalué à 2.

                      En l'occurence, c'était un scanner (je dis photocopie parce que c'est un combo scanner/impromante qui peut faire des scan/impressions en autonaume)

      • [^] # Re: Les sources sont dispo

        Posté par  (site web personnel) . Évalué à 2.

        Y a un truc avec le watermarking qui m'ennuie... si un le drm est libre, le watermarking le sera lui aussi vu qu'il fait partie de la solution drm. Donc on a l'algo qui rajoute le watermark et l'algo qui permet de le relire et d'avoir les informations qu'il contient... donc on a tout ce qu'il faut pour pouvoir enlever le watermarking et/ou l'endommager pour qu'il ne contienne plus d'info pertinentes..

        Je me trompè-je ou ? (non non pas là ;)

        • [^] # Re: Les sources sont dispo

          Posté par  (site web personnel) . Évalué à 3.

          Oui, et comme gpg est open source, on a donc accés à son algo, on peut donc facilement décoder n'importe quel message codé avec gpg sans la clé... :o)

          • [^] # Re: Les sources sont dispo

            Posté par  (site web personnel) . Évalué à 5.

            Tu as la clé... vu que tu décodes le contenu.

            • [^] # Re: Les sources sont dispo

              Posté par  (site web personnel) . Évalué à 2.

              Bon je vois qu'on plusse le commentaire du dessus qui est à côté de la plaque...

              Je répète donc on a la clé, on peut décoder le contenu, si il y a un système de watermarking il fait partie du drm, si ce n'était pas le cas, le drm ne peut être libre vu qu'une partie reste fermée. Le watermarking n'est pas un algo clé publique/clé privée, ça c'est l'autre partie, qui code le flux. Un algo de watermarking doit être réversible sinon on ne peut récupérer l'info. Maintenant le seul truc que je verrais qui pourrait fonctionner ce soit que le watermarking soit généré avec la clé publique du distributeur et code des info privée du receveur (genre sa clé publique qu'il a donnée pour encoder le flux pour lui). Mais la question est, est-ce qu'un watermarking basé sur une clé pour sa distribution dans l'image/video/son est aussi cryptographiquement sûr qu'un algo de cryptage ?

              • [^] # Re: Les sources sont dispo

                Posté par  . Évalué à 8.

                Ton watermarking est "réversible" vis-à-vis du filigrane stocké, mais pas vis-à-vis du support. En clair, tu dois pouvoir récupérer le watermark que tu as inséré dans le film, mais rien n'oblige à pouvoir récupérer le film épuré du filigrane.

              • [^] # Re: Les sources sont dispo

                Posté par  (site web personnel) . Évalué à 6.

                J'ai deux questions:

                Pourquoi veux tu que le watermarking fasse partie du DRM?

                Le distributeur peut parfaitement appliquer d'abord la watermark, puis ensuite encrypté le fichier par le système de DRM.

                C'est quand même deux choses différentes: le DRM empêche la lecture du fichier par n'importe qui. La watermark identifie le fichier sans en altérer audiblement le contenu, il reste donc lisible par n'importe qui.

                D'ou ma deuxième question, pourquoi veux tu que l'utilisateur possède la clef pour décoder la watermark puisqu'il n'en as pas besoin pour lire celui ci?

                Enfin, mon intervention concernait ta remarque plus générale sur le fait qu'un système fermé est plus sûr qu'un autre open source. L'expérience nous a montré que si l'algorithme est robuste, il n'y a aucune raison qu'il soit plus vulnérable en étant open source. Si il ne l'est pas, alors même fermé, il ne résistera pas longtemps aux attaques.

                La sécurité par l'obfuscation est illusoire.

                • [^] # Re: Les sources sont dispo

                  Posté par  . Évalué à 4.

                  Merci de l'avoir dit, c'est tout à fait ce que j'allais répondre. Je rajouterais que l'idée du watermarking, c'est une hypothèse de ma part.
                  J'ai pensé à ça car l'idée de Sun actuellement ne sert pas à grand chose en tant que tel (libérer un DRM et donner tous ses secrets ...) et que je me suis dis qu'il doit y avoir qqch d'autre derrière.

              • [^] # Re: Les sources sont dispo

                Posté par  (site web personnel) . Évalué à 3.

                Je n'aurai qu'une réponse :
                http://en.wikipedia.org/wiki/Digital_watermarking

                Le watermarking consiste à insérer dans le contenu une "marque" qui ne gène pas la perception, mais qui sera conservée tant que la copie ne dégrade pas trop la qualité. Ca peut être un son en ultrason ou en infrason pour la musique, ou une image incrusté dans les poids faibles du codage des couleurs pour une image.

                Ainsi, même en copiant le média par un moyen analogique (scanner, micro ...) la watermark est relativement bien conservée tant que la qualité de la copie est correcte. La watermark n'est pas enlevée au moment de l'écoute / du visionnage.

              • [^] # Re: Les sources sont dispo

                Posté par  . Évalué à 1.

                Mais ce watermarking, sauf erreur de ma part, ca doit être pas trop compliéqué d le faire sauter ou de le rendre inutilsable ... en faisant passer le fichier dumpé dans plusieurs formats de fichiers, chaque passe d'encodage devrait faire son boulot d'altération.
                Par exemple, je recoit un fichier musical DRMisé de Sun, je le dumpe avec xmms ou autre (donc mon fichier obtenu contient le watermarking). Je réencode le fichier en OGG, puis je le refais passer en MP3 (oui, je sais je vais y perdre un peu de qualité), je doute que le watermarking survive à un tel traitement.

                • [^] # Re: Les sources sont dispo

                  Posté par  . Évalué à 2.

                  L'objectif d'un bon watermarking, c'est justement de résister au maximum à ce genre de transformations, sauf en bourrinant tellement que plus personne ne veuille du fichier ... Après, c'est peut être effectivement pas facile à faire (j'y connais pas grand chose)

                • [^] # Re: Les sources sont dispo

                  Posté par  (site web personnel) . Évalué à 5.

                  Peut-être pour un watermarking utilisant des ultrasons... Mais imagine le watermarking suivant:

                  à chaque octet que tu veux insérer, tu multiplie par (ton_octet-128)/16000 la vitesse de lecture du fichier pendant une seconde. Le distributeur donne ensuite le fichier ainsi obtenu.

                  Personne ne s'en rendra compte à l'oreille, les encodeurs type MP3 ou OGG préservent suffisament le fichier pour le garder, et même si tu passes par des moyens analogique le watermarking est gardé.

                  Et il doit exister des moyens beaucoup plus subtils que ceux-ci

                  http://l-lang.org/ - Conception du langage L

                  • [^] # Re: Les sources sont dispo

                    Posté par  (site web personnel) . Évalué à 2.

                    si tu sais que ce genre de méthode a été utilisée, tu répètes la même opération avec random() à la place de ton octet, et paf le watermarking.
                    Le watermarking robuste est une cause perdue (cf mon message plus bas)

              • [^] # Re: Les sources sont dispo

                Posté par  (site web personnel) . Évalué à 2.

                Le Watermarking n'a pas besoin d'être réversible, puisque il me sembel que ça consiste à altérer le fichier tout en le laissant lisible... A priori on peut donc le lire sans avoir à décoder quoi que ce soit.

        • [^] # Re: Les sources sont dispo

          Posté par  (site web personnel) . Évalué à 6.

          Tu as les sources du client,mais pas celle du serveur, si le water-mark à lieu à se moment là, tu ne peux rien faire.

      • [^] # Re: Les sources sont dispo

        Posté par  (site web personnel) . Évalué à 4.

        En même temps, c'est un système de DRM, donc, si il ne fonctionnait pas correctement, (en pistant l'utilisateur du contenu), il ne servirait pas à grand chose... Il faut qu'il soit quand même un minimum crédible aux yeux des majors pour que celles ci l'acceptent.

        Après, à mon sens, les DRM, c'est comme les logiciels, soit on choisi d'utiliser des logiciels libres, soit des logiciels propriétaires, mais dans ce cas on accepte les conditions d'utilisations de ceux ci. Pour la musique, c'est pareil. Soit on écoute de la musique libre, soit de la musique des majors, et dans ce cas, on accepte aussi les conditions d'utilisations de celle ci, y compris qu'elle soit DRMisée et qu'on soit limité dans sa jouissance.

        L'avantage de la solution de Sun, c'est de laisser aux utilisateurs de logiciels libres ou de systèmes alternatifs le choix de la musique qu'ils veulent écouter en leur permettant d'écouter de la musique DRMisée.

        • [^] # Re: Les sources sont dispo

          Posté par  . Évalué à 3.

          En même temps, c'est un système de DRM, donc, si il ne fonctionnait pas correctement, (en pistant l'utilisateur du contenu), il ne servirait pas à grand chose...

          Bah pourtant c'est ce qui se passe actuellement, vu que toutes les protections ont été crackée à ma connaissance. L'important, c'est pas qu'il soit compètement efficace, c'est qu'il soit assez chiant pour emmerder l'utilisateur honnête... à mon avis.

      • [^] # Re: Les sources sont dispo

        Posté par  . Évalué à 4.

        Bon d'après ce que j'ai compris, la solution se base sur un système de cryptographie asymétrique. J'y vois quelques similitudes avec les utilisations que l'on peut avoir des certificats x509.

        En gros, lorsque l'on veut télécharger un fichier de musique, on doit fournir sa clé publique. Le fichier est alors chiffré avec cette clé, garantissant alors que seul la personne qui a fait la demande de la musique sera capable de la lire (de déchiffrer le fichier). Je ne vois pas ce que cela peut garantir de plus, car si tu décides de partager cette musique avec d'autres, il te suffit de déchiffrer le fichier et de le partager. Si des informations sont rajoutées dans le fichier, tu peux très bien les enlever, donc je ne vois pas comment on pourrait te retrouver.

        Tu parles alors de watermarking (http://www-rocq.inria.fr/codes/Watermarking/), que je ne connais pas alors je vais lire le lien pour essayer de comprendre un peu plus .... [lecture en cours].... Bon, c'était assez long, mais le document explique bien le watermarking. J'en déduis qu'un marchand de musique peut rajouter une marque dans le fichier originel, en utilisant par exemple le marquage aveugle (dans Généralités techniques). Comme le watermarking se veut invisible/inaudible (poru les images/musiques), l'utilisateur final peut ne pas s'en rendre compte. Le watermarking doit être fait avant le chiffrement par clé publique de l'acheteur.
        Cette technique peut marcher s'il n'existe pas de moyen de détection du watermarking et de suppression de cette marque. Sommes-nous sûr sur ce point ?

        Que se passe-t-il ensuite ? Le marchand récupère de la musique échangée illégalement. S'il utilise le marquage aveugle, il lui suffit avec une clé privée d'extraire le marquage du fichier. Et ainsi avoir des informations sur l'historique du fichier.

        Voila. C'est possible. Mais uniquement pour les fichiers vendus. Si tu as un CD-Audio et que tu l'encodes en MP3 pour l'écouter sur ton baladeur/autoradio..., et que tu le diffuses illégalement sur internet, les marchands/majors ne pourront rien contre, parce que ce fichier n'est pas marqué.
        On en déduit donc que le watermarking peut permettre de fliquer un fichier. Il ne peut pas permettre de rajouter des informations supplémentaires lié au DRM comme le nombre de copie max... car il faudrait alors que l'utilisateur puisse extraire la marque.

        PS: si les majors/marchands ne veulent plus te vendre de musique, suffit qu'elles mettent en place un système genre CRL (on en revient au système de certificats) qui listerait les clés publiques à ne pas utiliser.
        Plusieurs problèmes à résoudre dans ce cas : la taille des CRLs pourraient être très importantes, il faudrait alors avoir un système performant qui s'appuie par exemple sur des bases de données, et non des fichiers CRLS.
        Pour faire baisser la taille des CRLs, une solution serait de définir une durée de validité sur les clés publiques, cela poserait alors beaucoup de problème pour le consommateur !

        • [^] # Re: Les sources sont dispo

          Posté par  (site web personnel) . Évalué à 4.

          Plusieurs problèmes à résoudre dans ce cas : la taille des CRLs pourraient être très importantes, il faudrait alors avoir un système performant qui s'appuie par exemple sur des bases de données, et non des fichiers CRLS.

          Ca existe, ça s'appelle de l'OCSP (RFC 2560). En gros ça consiste à demander à un serveur le status de révocation d'un certificat, la réponse est signée par le répondeur OCSP à qui on fait confiance selon un politique prédéterminée.

        • [^] # Re: Les sources sont dispo

          Posté par  . Évalué à 4.

          Cette technique peut marcher s'il n'existe pas de moyen de détection du watermarking et de suppression de cette marque. Sommes-nous sûr sur ce point ?

          Un moyen auquel je viens de penser, serait de comparer bit à bit 2 fichiers décryptés obtenus par 2 personnes différentes. Ça se trouve, c'est déjà utilisé dans les DRM actuels fermés (je parle des DRMs sur la musique en ligne, comme indiqué plus haut, je vois pas comment on pourrait faire ça avec un CD puisqu'on ne sait pas (à priori) qui a acheté le CD).

          • [^] # Re: Les sources sont dispo

            Posté par  . Évalué à 4.

            Un moyen auquel je viens de penser, serait de comparer bit à bit 2 fichiers décryptés obtenus par 2 personnes différentes.
            Oui j'ai pensé a la meme chose et en remplacant les bits qui changent par d'autres valeurs, ca permettrait de tromper le watermark.

            Mais cette technique ne permet de decouvrir que quelques bits du watermark et il est tout a fait possible qu'apres modification des bits qui changent, il soit toujours possible de trouver que le fichier vennait des 2 personnes initiales.

          • [^] # Re: Les sources sont dispo

            Posté par  . Évalué à 0.

            Absolument pas : ce n'est pas comme si tu insérais des lettres dans un texte.
            Il suffit que l'encodeur soit différent, que le bitrate change, que la moindre option d'encodage change, pour que le fichier change du tout au tout. Impossible de comparer bit à bit, de toute façon la taille est différente.

        • [^] # Re: Les sources sont dispo

          Posté par  . Évalué à 2.

          Au rythme où on va, bientôt il faudra une pièce d'identité pour acheter un CD/des mp3s/un dvd/etc... dans un magasin, juste pour qu'on puisse te retrouver si tu oses le prêter à un copain.

          • [^] # Re: Les sources sont dispo

            Posté par  . Évalué à 2.

            Déjà, rien qu'en recroisant avec le numéro de carte bleue qui a payé le CD/DVD ça doit être possible. Enfin ça doit pas être légal, cf la CNIL et tout ça. Mais vu comme cette institution est respectée en ce moment, j'ai bien peur que ça arrive quand même un jour...
            Bref, payons nos CDs en liquide ! (et les CDs sans DRM bien sûr, les autres pas la peine de les payer)

      • [^] # Bon alors, le watermarking...

        Posté par  (site web personnel) . Évalué à 2.

        Effectivement, ça peut marcher, cette solution avec watermarking...

        Le seul problème, c'est que si tu es au courant qu'il y a watermarking, c'est très facile de l'enlever: vu que le watermarking est basé sur des informations inutiles et redondantes(puisque inaudibles), il resiste très mal à la compression. Par exemple, il est très facile de watermarker une image bmp, c'est déjà plus dur avec un jpeg.
        Il y a beaucoup de recherche pour rendre les algos de watermarking résistants (il y a de l'argent derrière!), mais en gros c'est tout du pipeau: dans l'absolu, c'est impossible (théorie de l'information à l'appui!) de faire un watermarking:
        -qui ne se voit pas
        -et qui résiste à la compression, en général
        Prenons un cas concret: on t'a donné un mp3 que tu soupçonnes d'être marqué: paf, tu le transcode en ogg, adieu le marquage!

    • [^] # Re: Les sources sont dispo

      Posté par  . Évalué à 2.

      J'ai jetté un coup d'oeil et j'ai rien vu de passionant :
      - le patch ne supporte que les flux ts
      - A première vu ça ressemble enormement à ceux qui est fait dans le domaine du dvb (ECM, EMM, ...)

  • # Orthographe

    Posté par  . Évalué à 2.

    <Disclaimer>
    Devant la recrudescence notament des fautes d'orthographes (c'est pas grave, j'en fais aussi), et particulièrement des écritures d'expressions particulières en phonétique, ("quand même" vs "comme même", etc ...) j'ai décidé de souligner dès que j'y penserait à répondre à un commentaire dont une faute d'orthographe fait changer le sens en soulignant ce changement de sens
    </Disclaimer>


    Elles sont disponibles en mp3 ? Ils vont pouvoir faire une sorte de Meta-DRM, un DRM sur des spec de DRM.

    • [^] # Re: Orthographe

      Posté par  . Évalué à 1.

      Tu a_ tord ! Car celà ne gaine person_e içi !

      Trève de plaisanterie, je te suis dans ta croisade. C'est d'autant plus lassant que ce sont toujours les mêmes fautes ! (surtout le tord ;-) )

  • # Les DRMs, c'est mal, point

    Posté par  (site web personnel) . Évalué à 4.

    Que ce soit open-source ou pas, les faits sont toujours la : il faut etre connecté à Internet, on est dependants d'un serveur...
    Tant que les DRM serviront pour des produits qu'on ACHETE, ils seront mauvais, open-source ou pas...
    (pour les produit qu'on LOUE, OK, admettons, un DRM open-source peut etre utile... Mais je doute qu'ils s'arretent la.)

    • [^] # Re: Les DRMs, c'est mal, point

      Posté par  . Évalué à 7.

      justement, le contenu à DRM que tu payes, tu achètes un droit d'utilisation, bref tu LOUES.

      ce qui me fait le refuser, c'est la pérénité du bazar. PC qui explose => dans le cul, fournisseur qui disparait après 6 mois ou 2 ans => dans le cul, prestataire technique quelque part dans la chaine qui fait un caca nerveux pour une raison quelconque => dans le cul, matériel déclaré obsolète ou plus à la mode par les fournisseurs => dans le cul...


      je ne crache pas totalement dessus, hein, il faudra juste que les tarifs proposés soient en rapport avec les risques que je perçois.

      • [^] # Re: Les DRMs, c'est mal, point

        Posté par  (site web personnel) . Évalué à 6.

        Je reprend : un morceau de musique dont j'achette le droit d'utilisation n'a pas a dependre d'un serveur.
        Ce n'est pas de la location, c'est de l'achat, de droit certes, mais ca reste de l'achat.
        Apple and co aimerait bien que cet achat de droit disparaisse... Pas d'accord. Surtout vu les prix de la location ;-)
        En taut cas, expliquez un maximum a votre entourage que itunes c'est de la location a durée non garantie, ca les fera reflechir ;-)

  • # Les « plates-formes légales »

    Posté par  (site web personnel) . Évalué à 3.

    En passant, le lien http://openmediacommons.org/ me redirige sur localhost je ne sais pas pourquoi ...

    Quelqu'un sait quand on aura des plates-formes légales utilisant ce DRM ?

    Personellement, même si je n'aime pas les DRM, j'ai l'impression que cela devient inévitable ... alors autant avoir un DRM qu'on puisse utiliser avec Linux et des logiciels libres.

    • [^] # Re: Les « plates-formes légales »

      Posté par  . Évalué à 2.

      alors autant avoir un DRM qu'on puisse utiliser avec Linux et des logiciels libres.

      Putain, mais le but d'un DRM c'est de limiter tes libertés ! Tu vois pas le problème avec "logiciel libre" ?
      Oui la GPL limite tes libertés car tu peux pas enculer le développeur en en faisant un logiciel proprio, mais cette limitation n'est pas technique, c'est juste une limitation légale. Comme avec la musique actuellement, il y a des lois sur le droit d'auteur pour limiter tes libertés de l'utiliser (pas la vendre à qqn si t'as pas les droits dessus, par exemple), on a pas besoin d'avoir des DRMs qui te prennent pour un gamin en te disant "bah puisque tu peux pas respecter une loi, je vais te foutre des claques avec mon bon gros DRM".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.