P2P : Trident Media Guard veut polluer le streaming de flux vidéo illicites

P2P : Trident Media Guard veut polluer le streaming de flux vidéo illicites

Le flux enchanté

Avatar de l'auteur
Marc Rees

Publié dans

Droit

26/06/2013 3 minutes
141

P2P : Trident Media Guard veut polluer le streaming de flux vidéo illicites

Les travaux de Trident Media Guard pour aiguiser la régulation des réseaux peer-to-peer ne cessent décidément pas. Le prestataire des ayants droit chargé de flasher les adresses IP en amont de la Hadopi a fait publier en France ce 19 juin une demande de brevet visant à « ralentir, voire éliminer, la propagation illégale d’un contenu vidéo protégé et diffusé en streaming dans un réseau pair-à-pair. »

TMG trident média guard streaming P2PExtrait du brevet TMG

Pour le prestataire des cinq principales sociétés de collecte et de répartition en France, l’idée défendue dans ce brevet vise à perturber la propagation d'un flux streaming dans un réseau P2P par l’envoi de faux blocs dans ces échanges. « De par l’envoi d’au moins un faux bloc au pair cherchant à récupérer le contenu vidéo pour remplir une fenêtre de lecture, on cause une dégradation de la qualité de ce contenu vidéo ». L’idée est ainsi de s'intercaler dans ces échanges et de pourrir les flux P2P streamés provenant par exemple des chaînes TV payantes. Comment ? En plaçant des images figées, déjà diffusées ou saccadées, voir des publicités…ou des messages d’avertissement.

TMG a une petite tenue de camouflage dans ses valises : « Après connexion au pair et avant envoi de faux bloc(s), le procédé peut comporter l’étape selon laquelle on envoie au pair pendant une période prédéterminée un ou plusieurs blocs du contenu vidéo, de manière à permettre au pair de récupérer ledit contenu ». Ainsi, TMG propose d’envoyer entre 100 et 500 Mo de contenu légitime avant d’empoisonner les flux. « Cette étape peut permettre de réduire les risques d’être démasqué par les pairs du réseau cherchant à récupérer le contenu vidéo, d’assurer des taux de confiance et de crédibilité importants, d’être mieux intégré au réseau, et de se placer au sommet du réseau pour la distribution des blocs ».

Ce brevet publié en France le 19 juin dernier avait été préalablement déposé à l’échelle internationale en 2011. Il n’est d'ailleurs pas le seul au ceinturon de Trident Media Guard. Parmi les nombreux autres dépôts dans le secteur du P2P, signalons cette précédente invention publiée cette fois en avril 2013. Elle vise « un procédé de collecte de renseignements d’un réseau pair-à-pair ». Dans un but informatif, assure TMG, cette invention permet de savoir « quels sont les contenus les plus téléchargés et les plus reproduits dans le réseau pair à pair ». Dans un but répressif, elle consiste cette fois à « déterminer quels sont les pairs du réseau pair à pair qui téléchargent illégalement du contenu protégé par des droits de propriété intellectuelle. »

 

Ces procédés ont systématiquement Bastien Casalta comme co-inventeur. L'intéressé est par ailleurs administrateur de Trident Media Guard aux côtés de l'acteur Thierry Lhermitte.

Écrit par Marc Rees

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (141)


On leur dit que streamer en P2P on sait pas encore faire ?



<img data-src=" />








Neeko a écrit :



On leur dit que streamer en P2P on sait pas encore faire ?

<img data-src=" />







Je crois que c’est possible avec le client µtorrent.









oXis a écrit :



Je crois que c’est possible avec le client µtorrent.





C’est sûr, et ça marche très bien ! <img data-src=" />



Bon, avant de dire quoi que ce soit, je me permet de poser ici quelques question élémentaires à ceux qui s’y connaissent.



Leur procédé, cela me rappelle une attaque type man-in-the-middle. D’où ma première question : ça ne se détecte pas, ce genre de truc ? Car en injectant les données corrompues depuis un autre point que celui de départ, on voit deux IP d’émission à l’arrivée au lieu d’une, et on peut en théorie ban celle qui fout la merde. Qu’en est-il dans la pratique ?



D’autre part, est-ce qu’il y a des contrôles d’intégrité sur les flux émis en streaming ? Si non, est-ce qu’on peut en mettre ? Car à ce moment-là, les données corrompues sont envoyées à /dev/null dès réception une fois détectées et, potentiellement, la méthode vendue par TMG serait inefficace.



Et enfin, avec des flux chiffrés, ils font comment ?










oXis a écrit :



Je crois que c’est possible avec le client µtorrent.







je confirme



C’est son fond de commerce il a raison. Je suis sûr que son rêve est l’éclosion lente d’un nouveau réseau pour vendre encore plus de solutions anti piratage.

Il n’y a pas de petit profits.


Déposer un brevet pour un truc comme ça :-o

Surtout qu’à part TMG, qui va s’en servir ?

Et puis les fichiers qu’on télécharge et qui ne correspondent pas au nom, ça ne date pas d’hier…


Certes ça peut pourrir le streaming, mais pour les patients qui attendent le fichier complet, leur procédé ne tient pas car on le grille avec le hash fourni la plupart du temps par les sites. Alors qu’ils ne soient les fournisseurs du flux originel, je ne vois pas trop comment ça va tenir la route leur truc.








Commentaire_supprime a écrit :



Bon, avant de dire quoi que ce soit, je me permet de poser ici quelques question élémentaires à ceux qui s’y connaissent.



Leur procédé, cela me rappelle une attaque type man-in-the-middle. D’où ma première question : ça ne se détecte pas, ce genre de truc ? Car en injectant les données corrompues depuis un autre point que celui de départ, on voit deux IP d’émission à l’arrivée au lieu d’une, et on peut en théorie ban celle qui fout la merde. Qu’en est-il dans la pratique ?



D’autre part, est-ce qu’il y a des contrôles d’intégrité sur les flux émis en streaming ? Si non, est-ce qu’on peut en mettre ? Car à ce moment-là, les données corrompues sont envoyées à /dev/null dès réception une fois détectées et, potentiellement, la méthode vendue par TMG serait inefficace.



Et enfin, avec des flux chiffrés, ils font comment ?





Le théorie voudrait qu’à partir d’un certain taux, le peer qui émet les pièces corrompue soit aux final banni. Enfin ce que j’ai pu comprendre du comportement de certains client et tracker torrent.



Le bon côté le la chose c’est que pour les 500 premiers méga on aura des serveurs rapide pour nous envoyer les données <img data-src=" />








oXis a écrit :



Le bon côté le la chose c’est que pour les 500 premiers méga on aura des serveurs rapide pour nous envoyer les données <img data-src=" />







+1 !



Et avec un bon script kivabien, on pourra récupérer à toute blinde des données par tranche de 500 Mo !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



C’est un peu la même technique pour le P2P classique ou ils pourrissent les recherches avec des fakes.



Mais des solutions type PeerGuard les garderont à distance sans soucis, donc je doute de l’efficassité réelle de la manoeuvre.








OlivierJ a écrit :



Déposer un brevet pour un truc comme ça :-o

Surtout qu’à part TMG, qui va s’en servir ?

Et puis les fichiers qu’on télécharge et qui ne correspondent pas au nom, ça ne date pas d’hier…







brevet pour pouvoir mettre leurs pubs dans les flux, avant que google n’y pense ou ne reprennent tout simplement le principe









oXis a écrit :



Je crois que c’est possible avec le client µtorrent.







pas seulement, il y en a pas mal d’autres, dont sopcast









Bejarid a écrit :



C’est un peu la même technique pour le P2P classique ou ils pourrissent les recherches avec des fakes.



Mais des solutions type PeerGuard les garderont à distance sans soucis, donc je doute de l’efficassité réelle de la manoeuvre.







Sans compter que s’ils emploient les mêmes IP que pour la surveillance du P2P, il suffira d’une bonne règle dans le pare-feu pour les envoyer chier…







garvek a écrit :



Certes ça peut pourrir le streaming, mais pour les patients qui attendent le fichier complet, leur procédé ne tient pas car on le grille avec le hash fourni la plupart du temps par les sites. Alors qu’ils ne soient les fournisseurs du flux originel, je ne vois pas trop comment ça va tenir la route leur truc.











feuille_de_lune a écrit :



Le théorie voudrait qu’à partir d’un certain taux, le peer qui émet les pièces corrompue soit aux final banni. Enfin ce que j’ai pu comprendre du comportement de certains client et tracker torrent.







Merci. <img data-src=" />



Je note au passage que pour les flux chiffrés, personne n’a répondu…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



A terme, les clients p2p intègreront juste un système de blacklisting plus intelligent, c’est tout… à chaque mesure sa contremesure…








Commentaire_supprime a écrit :



Leur procédé, cela me rappelle une attaque type man-in-the-middle. D’où ma première question : ça ne se détecte pas, ce genre de truc ? Car en injectant les données corrompues depuis un autre point que celui de départ, on voit deux IP d’émission à l’arrivée au lieu d’une, et on peut en théorie ban celle qui fout la merde. Qu’en est-il dans la pratique ?





L’adresse IP d’émission est déclarative, c’est ton ordinateur qui, quand il complète la trame, met ton adresse IP. Tu peux lui demander de mettre l’IP que tu veux.



C’est tout a fait possible de prendre la liste des pairs qui partagent un fichier, et se faire passer pour ces pairs, et envoyer des données corrompues : au bout d’un certain temps, tu banniras alors les pairs qui auraient pus te partager ce fichier.



la solution - plus lourde - est alors de ne pas identifier ces utilisateurs par leurs adresses IP, mais par un autre moyen ( genre clé publique / clé privé)



Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.



Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…


Ca ne sert à rien.<img data-src=" />








Neeko a écrit :



On leur dit que streamer en P2P on sait pas encore faire ?



<img data-src=" />





On te dis que ça se fait bcp <img data-src=" /><img data-src=" />



même les solution légale comme Spotify le fait <img data-src=" />



<img data-src=" /> mais ça sert à rien…<img data-src=" />


Si tous les pays font une queue d’attente pour contrôler youtube avec de multiples contrôles automatisés, ça ne m’étonne plus de voir qu’un tiers, quelque soit le streaming, une seule vidéo <img data-src=" /> et parfois attendre, ou clicker sur une position du temps différente, avant de voir la suite, par ce qu’en ayant 8gb de ram et bien ça rame le streaming sur Youtube, alors qu’avant c’était nickel (faut pas s’étonner que certains téléchargent en quantité, ils peuvent le voir ensuite sans coupure <img data-src=" /><img data-src=" /> (aux Ralentisseurs)


Il me semble en effet que c’est quelque chose qui est prévu dans le protocole bittorrent en dévaluant les pairs qui envoient des paquets non valides. A ceci, une solution de type PeerBlock rendrait leur “solution” totalement inefficace. Ca sent surtout l’entubage d’administratifs car d’un point de vu technique, c’est inefficace (ou plus simplement de la poudre aux yeux pour justifier un nouveau contrat)


C’est toujours sympa de pourrir le réseau et générer du trafic pour de la merde.

C’est pas interdit ce genre de pratique ? En tout cas ça devrait…








2show7 a écrit :



Si tous les pays font une queue d’attente pour contrôler youtube avec de multiples contrôles automatisés, ça ne m’étonne plus de voir qu’un tiers, quelque soit le streaming, une seule vidéo <img data-src=" /> et parfois attendre, ou clicker sur une position du temps différente, avant de voir la suite, par ce qu’en ayant 8gb de ram et bien ça rame le streaming sur Youtube, alors qu’avant c’était nickel (faut pas s’étonner que certains téléchargent en quantité, ils peuvent le voir ensuite sans coupure <img data-src=" /><img data-src=" /> (aux Ralentisseurs)





Qui à un traducteur ?



J’ai cru voir le mot youtube dans ce charabia : youtube n’est pas en P2P donc aucunement touché par cette solution

Tu auras beau avoir toute la ram du monde, youtube n’ira pas plus vite, c’est le “réseau de tuyaux” qui est à mettre en cause.



+1, c’est pas illégal de brouiller une transmission, quelle qu’elle soit ?








canti a écrit :



Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.



Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…







Je suis assez intéressé par ce que tu nous dis là.

Je ne connais pas plus que ça les spec’ du P2P. Du coup, comment ça fonctionne globalement ?




  • il y a d’abord un échange de hash ? (“Voici le hash du paquet que je vais t’envoyer”. “Ok, bien reçu”. “Voici maintenant le paquet”.). Ceci pour chaque paquet ?

  • Si le hash est transmis directement avec le paquet (c’est une partie des données), il devient tout à fait inutile non ? (Je modifie les données de la trame, je recalcule le hash et j’envoie. Lorsque le client va comparer le hash et celui qu’il a calculé à partir de données, ce sera le même…)

  • dans ce cas ici, ne pourrions nous pas supposer un mécanisme comme suit : des premiers “vrais” paquets sont transmis par des IP. Là, TMG s’invite dans l’envoie des paquets (“moi moi moi, j’en ai, je peux en envoyer!”) : TMG prend des paquets bidons (qui ne correspondent donc pas au fichier souhaité), génère le hash et envoie le bazar. Cela devrait rouler non ?









canti a écrit :



Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.



Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…







En effet, et ca s’apelle une collision, et c’est pas facile a trouver normalement ca <img data-src=" />



Peerblock, et votre streaming est PUR… de toute pollution de TMG. <img data-src=" />








Bejarid a écrit :



Mais des solutions type PeerGuard les garderont à distance sans soucis, donc je doute de l’efficassité réelle de la manoeuvre.







les gars faudrait un peu se reveiller quand meme <img data-src=" />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.












malock a écrit :



Je suis assez intéressé par ce que tu nous dis là.

Je ne connais pas plus que ça les spec’ du P2P. Du coup, comment ça fonctionne globalement ?




  • il y a d’abord un échange de hash ? (“Voici le hash du paquet que je vais t’envoyer”. “Ok, bien reçu”. “Voici maintenant le paquet”.). Ceci pour chaque paquet ?

  • Si le hash est transmis directement avec le paquet (c’est une partie des données), il devient tout à fait inutile non ? (Je modifie les données de la trame, je recalcule le hash et j’envoie. Lorsque le client va comparer le hash et celui qu’il a calculé à partir de données, ce sera le même…)

  • dans ce cas ici, ne pourrions nous pas supposer un mécanisme comme suit : des premiers “vrais” paquets sont transmis par des IP. Là, TMG s’invite dans l’envoie des paquets (“moi moi moi, j’en ai, je peux en envoyer!”) : TMG prend des paquets bidons (qui ne correspondent donc pas au fichier souhaité), génère le hash et envoie le bazar. Cela devrait rouler non ?







    le hash des blocks est contenue dans le fichier torrent, donc a moins de corrompre le torrent …









alf a écrit :



En effet, et ca s’apelle une collision, et c’est pas facile a trouver normalement ca <img data-src=" />







euh oui, mais dans le cas du streaming live, tu peux pas vraiment prédire les hash dans le futur, donc le hash sert juste à valider le paquet courant, non? dans ce cas n’importe quelle donnée hashée correctement sera valide, même si elle fait foirer la vidéo derrière en rajoutant un sale bruit dedans.



Il faudrait faire un système de majorité des hashs entre plusieurs fournisseurs en live pour éliminer ceux qui divergent, mais ça peut impacter l’aspect temps réel du streaming, et rajouter des données à échanger …







alf a écrit :



le hash des blocks est contenue dans le fichier torrent, donc a moins de corrompre le torrent …







on parle de streaming live, donc impossible de les connaître avant leur génération







saf04 a écrit :



les gars faudrait un peu se reveiller quand meme <img data-src=" />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.







nan mais chut, ça me fait toujours marrer de voir commentaire supprimé répéter en boucle l’inverse en mode méthode coué :p









tazvld a écrit :



Qui à un traducteur ?



J’ai cru voir le mot youtube dans ce charabia : youtube n’est pas en P2P donc aucunement touché par cette solution

Tu auras beau avoir toute la ram du monde, youtube n’ira pas plus vite, c’est le “réseau de tuyaux” qui est à mettre en cause.







Si tu suis tout ce qui se dit ici, je comprends, mais qu’a dit Hadopi, après le P2P, ce serait le streaming, qu’ils le fassent sur du P2P ou ailleurs, c’est pareil non ? (ils n’ont pas spécifié que sur le P2P que je sache)









jb18v a écrit :



+1, c’est pas illégal de brouiller une transmission, quelle qu’elle soit ?







En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.



Cinq ans d’emprisonnement et 75 K€ d’amende potentiellement. Si TMG perturbe du streaming P2P légal avec un requérant sans pitié en face, ça va faire mal…



Si je comprends l’idée, ils précalculent une modif sur un shunk de sorte que sont hash ne soit pas altéré puis balance ce shunk corrompu sur le réseau a des pairs qui le retransmettront à d’autres (vu que le hash ne change pas, les clients ne devrait y voir que du feu) ?



Je dois avoir zapper quelque chose, nan ?








alf a écrit :



le hash des blocks est contenue dans le fichier torrent, donc a moins de corrompre le torrent …







Ah bah voilà, c’est juste la donnée qu’il me manquait…

Merci.









malock a écrit :



Je suis assez intéressé par ce que tu nous dis là.

Je ne connais pas plus que ça les spec’ du P2P. Du coup, comment ça fonctionne globalement ?




  • il y a d’abord un échange de hash ? (“Voici le hash du paquet que je vais t’envoyer”. “Ok, bien reçu”. “Voici maintenant le paquet”.). Ceci pour chaque paquet ?

  • Si le hash est transmis directement avec le paquet (c’est une partie des données), il devient tout à fait inutile non ? (Je modifie les données de la trame, je recalcule le hash et j’envoie. Lorsque le client va comparer le hash et celui qu’il a calculé à partir de données, ce sera le même…)

  • dans ce cas ici, ne pourrions nous pas supposer un mécanisme comme suit : des premiers “vrais” paquets sont transmis par des IP. Là, TMG s’invite dans l’envoie des paquets (“moi moi moi, j’en ai, je peux en envoyer!”) : TMG prend des paquets bidons (qui ne correspondent donc pas au fichier souhaité), génère le hash et envoie le bazar. Cela devrait rouler non ?







    maaaaaaiiiiiis tes questions sonnent un peu bizzarre là <img data-src=" />:P si t’étais pas abonné, je te soupçonnerais de bosser chez eux <img data-src=" />



    sinon heuuu donc le plan c’est de diffuser des matériaux sous copyright pour embêter ceux qui diffusent des matériaux sous copyright ?



    et sinon sinon on a le droit de breveter juste une idée ? ou ils ont déjà un logiciel tout prêt et c’est ça qu’ils ont breveté ?









malock a écrit :



Ah bah voilà, c’est juste la donnée qu’il me manquait…

Merci.







cf mon commentaire ci-dessus, ce n’est pas du tout applicable dans le cas abordé, on ne connait pas le contenu du flux streamé, c’est le principe.



Au passage c’est dit dès le début du brevet, que dans le cas du streaming les réseaux p2p désactivaient ce genre de sécurité inutilisable, et donc ouvraient la faille à leur invention



Je me pose une grosse question où TMG va t il choper les vrais données du début ? Ils vont demander un accès privilégier au labellisé PUR ? Si oui on ne risque rien l’offre est tellement pauvre que ça ne se verras même pas.

Accès aux serveurs des ayant-droits ? Si oui, ça risque d’être casse gueule, je vois bien le coup que certains petit malins vont remonter jusqu’à TMG puis chopper les infos sur les serveurs des ayant-droits.

Quand à la dernière solution, qui consiste à récupérer le film avant de pourrir les flux, ils ont pas intérêt à se faire chopper par eux même.



Impatient de voir ça.



/popcorn








saf04 a écrit :



les gars faudrait un peu se reveiller quand meme <img data-src=" />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.





Ils ont un problème dans leur algo de détection, dans ce cas.









Tim-timmy a écrit :



on parle de streaming live, donc impossible de les connaître avant leur génération







sous torrent avant de lancer ton streaming, il te faut le fichier torrent. qui contient un hash général ou chaque piece recue va etre comparée et rejetée si fausse ou corrompue.









Tim-timmy a écrit :



on parle de streaming live, donc impossible de les connaître avant leur génération







Tu parle de streaming live, mais pas l’article. Qui plus est, qui irait pourrir un streaming live … a part pour casser les pieds des honnêtes gens ?

L’utilisation de streaming live c’est pas du tipiak a ce que je sache (ça doit bien exister en tipiak, mais ça doit être plutôt marginal).









jb18v a écrit :



+1, c’est pas illégal de brouiller une transmission, quelle qu’elle soit ?





Si, mais pas pour les forces de l’ordre ou l’armée…







…ou la milice privée.(c’est le cas de TMG):S



Encore que… les flics en “infiltration” peuvent être amené à “apater” des gens mais si la justice décide que l’apatage a été trop loin et est devenu de l’incitation alors un bon avocat pourra faire sauter l’accusation…



Enfin, crypté ou non, les hashs (qui ne sont pas transmis en même temps que les paquets mais qui sont dans la “description” du torrent) permettent d’identifier un paquet faux mais on ne saura pas si c’est volontaire ou non. Pour chaque paquet réseau (et il en faut N pour transmettre un morceau de fichier P2P) il y a un contrôle (style parité ou somme de contrôle) de bas niveau qui permet de savoir si les données ont été corrompues au niveau de la couche technique (sur les fils)









Tim-timmy a écrit :



cf mon commentaire ci-dessus, ce n’est pas du tout applicable dans le cas abordé, on ne connait pas le contenu du flux streamé, c’est le principe.







Euh ok. Bin j’ai pas compris ton commentaire… (c’est que j’y connais que dalle hein, on est d’accord)

Streaming-live ? C’est à dire ?

Moi ce que je crois savoir, c’est que les spec’ du P2P indique que l’échange de paquet est régi par la notion de rareté (on distribue d’abord les paquets les plus rares). Il y a aussi d’autre façon de faire : distribuer les paquets dans l’ordre (je “sais” ça car j’ai “bricolé” un bout de code avec un pote qui voulait se faire du streaming via P2P). Avec la seconde solution, on se retrouve à streamer via P2P non ?



Dans tous les cas, il faut tout de même récupérer un tracker dans lequel l’ensemble des paquets constituant le fichier final est indiqué (ainsi que leur hash) non ?







camszdzs a écrit :



maaaaaaiiiiiis tes questions sonnent un peu bizzarre là <img data-src=" />:P si t’étais pas abonné, je te soupçonnerais de bosser chez eux <img data-src=" />







Non non ! J’y connais pas grand chose et je suis juste intéressé par être un peu moins ignorant sur le sujet <img data-src=" />









alf a écrit :



Tu parle de streaming live, mais pas l’article. Qui plus est, qui irait pourrir un streaming live … a part pour casser les pieds des honnêtes gens ?

L’utilisation de streaming live c’est pas du tipiak a ce que je sache (ça doit bien exister en tipiak, mais ça doit être plutôt marginal).









. L’idée est ainsi de s’intercaler dans ces échanges et de pourrir les flux P2P streamés provenant par exemple des chaînes TV payantes. Comment ? En plaçant des images figées, déjà diffusées ou saccadées, voir des publicités…ou des messages d’avertissement.



après j’y peux rien si vous ne lisez pas les articles, ni les brevets cités :p Ils y citent clairement les réseaux IPTV comme cibles, genre sopcast, PPLive ou autres… Et si, le streaming live ça permet de chopper par exemple les chaines payantes pour le sport, en général … voire pour tout le reste en fait…



Les FAI ayant droits, ça ne vous aide pas plus ? Gros débit sur une IP, surveillance approfondie








Tim-timmy a écrit :



on parle de streaming live, donc impossible de les connaître avant leur génération







Non,on parle de Streaming via les réseau p2p,si tu veux corrompre une vidéo en streaming live déjà ça passe rarement par des protocole de p2p,mais plutôt sur des infrastructure centralisé et deuxio j’ai jamais vu ou entendu parler d’une méthode de transmission de streaming live utilisant des réseaux acentré comme le p2p









DarKCallistO a écrit :



Non,on parle de Streaming via les réseau p2p,si tu veux corrompre une vidéo en streaming live déjà ça passe rarement par des protocole de p2p,mais plutôt sur des infrastructure centralisé et deuxio j’ai jamais vu ou entendu parler d’une méthode de transmission de streaming live utilisant des réseaux acentré comme le p2p







non.

cf l’article, la source (page 3, donc l’introduction, elle est même en français si ça vous fait peur), ou mon commentaire avant . Bon aprem.









Tim-timmy a écrit :



après j’y peux rien si vous ne lisez pas les articles, ni les brevets cités :p Ils y citent clairement les réseaux IPTV comme cibles, genre sopcast, PPLive ou autres… Et si, le streaming live ça permet de chopper par exemple les chaines payantes pour le sport, en général … voire pour tout le reste en fait…







OK, mea culpa, j’ai sauté ce passage :)

Il me semblait juste que cette utilisation était marginale.



Mais je me rappelle effectivement d’un pote qui regardait des matchs de sport dans un player video p2p.

La qualité étant vraiment médiocre, je ne pensait pas que ça puisse être vraiment utilisé par tant de personnes que ca …



très gentil ce thierry lhermitte ….. enfin <img data-src=" />

ce type, je l ‘ ai banni.


par contre un truc que je pige pas…

quand l’article parle de flux streamés provenant de chaines tv payantes.

on est en temps reel (ca existe ??) ou en dans le cas de streaming p2p d’emissions ou series déjà diffusées ?








saf04 a écrit :



par contre un truc que je pige pas…

quand l’article parle de flux streamés provenant de chaines tv payantes.

on est en temps reel (ca existe ??) ou en dans le cas de streaming p2p d’emissions ou series déjà diffusées ?







temps réel … regarde ce que fait sopcast par exemple.



Si pour cela, les FAIs pouvaient également brider, ce serait pas mal <img data-src=" />








Tim-timmy a écrit :



cf mon commentaire ci-dessus, ce n’est pas du tout applicable dans le cas abordé, on ne connait pas le contenu du flux streamé, c’est le principe.



Au passage c’est dit dès le début du brevet, que dans le cas du streaming les réseaux p2p désactivaient ce genre de sécurité inutilisable, et donc ouvraient la faille à leur invention







du stream P2P en live, je n’avais jamais entendu parler, c’est interessant…

pour moi la solution sera de s’assurer de la fiabilité d’un peer, et le banir au besoin… mais c’est vrai que se pose alors la question d’identification de ce “faussaire”



corrigez moi si je me trompe mais à la lecture du brevet tout ce dont ils parlent c’est leur idée, en fait ?



brevet basé sur l’idée super novatrice de pourrir les réseau p2p avec des contenus qui ne sont pas ce que l’utilisateur croit…wow…



on peut rajouter le patent trolling à la liste de leur pechés:o



alors au final c’est plutôt très positif, ça va surtout compliquer les tentatives d’autres acteurs de pourrir les réseaux <img data-src=" />



mais on devrait pas avoir le droit de poser un brevet pour une idée, surtout pour une idée qui a rien de neuve. c’est ce qui me gène le plus au final dans cette actu :(








Tim-timmy a écrit :



temps réel … regarde ce que fait sopcast par exemple.







ha ok je comprend beaucoup mieux l’article maintenant. merci.









saf04 a écrit :



par contre un truc que je pige pas…

quand l’article parle de flux streamés provenant de chaines tv payantes.

on est en temps reel (ca existe ??) ou en dans le cas de streaming p2p d’emissions ou series déjà diffusées ?







c’est du temps réel décalé de quelques secondes a plusieurs minute.









saf04 a écrit :



les gars faudrait un peu se reveiller quand meme <img data-src=" />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.







moi aussi <img data-src=" />









saf04 a écrit :



les gars faudrait un peu se reveiller quand meme <img data-src=" />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.





Ces solutions font pas dans la dentelle hein…



Les gars qui les maintiennent arrivent plutot bien à suivre les IPs utilisé par TMG et cie, et après, ils se font pas chier, ils bloquent un range d’ip complet.



Clairement ils bloquent des innocents dans l’affaire mais n’en ont cure, et le fait est que ça marche (même si ça réduit ton nombre de pair sur lequel tu peux pomper). Bien sur faut updater ça régulièrement :)









oXis a écrit :



Je crois que c’est possible avec le client µtorrent.







Ah, c’est allé super vite alors… encore l’année dernière ya un mec qui a sorti une idée pour y arriver… et plus de nouvelles depuis.



Edit :https://korben.info/bittorrent-live.html



Mouais, apparemment, ya encore du boulot, c’est pas en se focalisant là dessus qu’ils vont avancer… Je doute que beaucoup de gens l’utilisent.









Tim-timmy a écrit :



non.

cf l’article, la source (page 3, donc l’introduction, elle est même en français si ça vous fait peur), ou mon commentaire avant . Bon aprem.







Oui,donc une utilisation quasi marginal dans le p2p.



Mouais, et pendant ce temps là, le DDL…








Tim-timmy a écrit :



non.

cf l’article, la source (page 3, donc l’introduction, elle est même en français si ça vous fait peur), ou mon commentaire avant . Bon aprem.





+1 d’ailleurs :



“L’invention tire parti du fait que dans les réseaux pair à pair diffusant du contenu vidéo en streaming, la fenêtre de lecture que chaque pair cherche à remplir doit être remplie dans une durée donnée qui est généralement très courte, étant par exemple de l’ordre de 2 à 3 minutes. Cette contrainte temporelle a pour conséquence la faiblesse, voire la non-existence des mécanismes de vérification de l’origine des blocs reçus et de leur validité dans de tels réseaux pair à pair, du fait de leur coût en temps et en occupation du processeur du terminal associé à chaque pair du réseau”.



Tant qu’à faire autant mettre LE truc sur lequel repose toute l’“invention”.

Cette condition n’est pas remplie, leur “invention” tombe à l’eau. D’ailleurs c’est tellement une invention que le contre existe déjà et est déjà implémenté pour les torrents “classiques”… Ils profitent juste d’une limitation technique dû au type de contenu pour breveter une technique qui existait il y a + de 10 ans quand les premiers logiciels p2p sont sortis (et qu’il n’y avait pas de contrôle d’intégrité justement).



De plus pour moi c’est un brevet logiciel leur truc. Les 4 dernières pages avant les revendications sont juste un algo écrit en français (donc chiant à lire). Et avant ça explique les conditions nécessaires pour que ça fonctionne et les utilisations que ça pourrait avoir.



Et je donne un bon point à celui qui trouve le point “c’est pour protéger les petits nenfants” dans le brevet.









Commentaire_supprime a écrit :



Je note au passage que pour les flux chiffrés, personne n’a répondu…





Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).



Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.









Alucard63 a écrit :



Ca ne sert à rien.<img data-src=" />







Pourquoi une pub m’agresse quand je clique sur ton lien?









fitfat a écrit :



Ils ont un problème dans leur algo de détection, dans ce cas.







+1. Parce qu’un VPN, ça fait bien relais de données dans les deux sens, mais pour le passer afin d’appliquer des protocoles custom sur le réseau, ça me paraît assez sportif.



Mais chut, on ne va pas dire qu’il suffit d’une bonne règle de pare-feu pour envoyer chier l’usine à gaz mise en place par TMG, surtout de la part des propagandistes des zéyandrouah…









HarmattanBlow a écrit :



Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).



Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.







Question bête : le chiffrement, comment est-ce qu’ils le cassent ?



C’est pas de dissimulation de protocole dont je parle, mais de transmissions de données chiffrées entre A et B. Et X, il fait comment son man-in-the-middle dans ce cas s’il n’a pas la clef de déchiffrement des données~? Et surtout, comment peut-il savoir que les données chiffrées qu’il voit passer sont du P2P, et non des ordres de vente boursiers, par exemple ?









Khalev a écrit :



Et je donne un bon point à celui qui trouve le point “c’est pour protéger les petits nenfants” dans le brevet.







“Parmi ces chaines télévisées, certaines peuvent etre a accées protégé, par exemple des droits d’accés payants ou par la souscription à un abonnement payant ou non. Le contenu vidéo que le pair cherche a récupérer peut etre diffusé en streaming sur une de ces chaines télévisées.”



en fait c’est pour pas que ton fiston il streame le premier samedi du mois…









HarmattanBlow a écrit :



Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).



Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.







non, tu parles d’identification de pirate, alors que ce n’est pas le sujet de la news (qui est plus la dégradation du P2P).

Le cryptage permet d’éviter le problème indiqué ici, car il empêche TMG de se faire passer pour ton interlocuteur légitime. leurs attaques se résume alors à du DoS (ils surcharges ta connection, et c’est cher à faire pour des millions de “pirates”)



C_S je te la fait facon courte:



on est dans le cas d’un streaming ou la donnée arrive et est quasiment utilisée en temps reel.



soit les données ont le temps d’etre verifiées et rejetées et cela crée un ralentissement enorme si c’est fait a grande echelle.

soit la donnée est lue avant d’etre verifiée et la tu affiches ce que tu veux, le temps que la verification des données interviennent. mais ce laps de temps n’est valable vraiment que sur quelques secondes maxi.



donc bref je sens plutôt leur truc pour ralentir les flux et donc la qualité des streamings. mais le coup de leur message, ca marchera une fois sur mille au bas mot…



edit: canti t’as tout faux.











HarmattanBlow a écrit :



Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).



Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.





Oui enfin cet état de fait est assez facile à résoudre avec des tiers de confiance… Crypter c’est bien, s’assurer qu’on discute en crypté avec la bonne personne c’est mieux.

Bref rien de non contournable ni de définitif.









saf04 a écrit :



C_S je te la fait facon courte:



on est dans le cas d’un streaming ou la donnée arrive et est quasiment utilisée en temps reel.



soit les données ont le temps d’etre verifiées et rejetées et cela crée un ralentissement enorme si c’est fait a grande echelle.

soit la donnée est lue avant d’etre verifiée et la tu affiches ce que tu veux, le temps que la verification des données interviennent. mais ce laps de temps n’est valable vraiment que sur quelques secondes maxi.



donc bref je sens plutôt leur truc pour ralentir les flux et donc la qualité des streamings. mais le coup de leur message, ca marchera une fois sur mille au bas mot…







Eh bien, merci pour la précision <img data-src=" />



Car tout chiffrement nécessite forcément des cycles processeur et du temps de traitement et, dans le cadre de flux vidéo, faire ça en temps réel, c’est un poil tendu…



Après, pour la mise en application de la solution de TMG et, surtout, pour son pouvoir de nuisance effectif, je demande à voir en conditions réelles avant d’en dire quoi que ce soit de plus…



Ah ouai ils veulent polluer le P2P ?



Ca me ferait marrer que quelqu’un dépose un gros tas de lisier devant leurs locaux, histoire de les polluer un peu eux aussi <img data-src=" />








Commentaire_supprime a écrit :



Question bête : le chiffrement, comment est-ce qu’ils le cassent ?



C’est pas de dissimulation de protocole dont je parle, mais de transmissions de données chiffrées entre A et B.





Non, il s’agit de P2P. Quand tu regardes une vidéo en streaming depuis le site machin, tu reçois les données de machin mais aussi des autres utilisateurs qui regardent le même contenu (même chose sous Steam, sous le Blizzard Downloader et compagnie).



Ils ne se font donc pas passer pour un utilisateur normal du réseau.







canti a écrit :



Le cryptage permet d’éviter le problème indiqué ici, car il empêche TMG de se faire passer pour ton interlocuteur légitime.





En quoi cela l’empêche t-il ? Qui définit ce qu’est un utilisateur légitime ? Comment distingues-tu un vrai utilisateur du réseau d’un faux utilisateur du réseau ?



Même si le site de streaming offre un mécanisme pour être le seul à fournir les identités légitimes, qu’est-ce qui empêche TMG de se faire passer aux yeux du site de streaming pour un utilisateur légitime ? Au pire le site de streaming pourrait stipuler dans ses termes du service que cette usage n’est pas toléré mais les sites ricains n’auront qu’à utiliser la même astuce que : profiter des barrières juridiques internationales.



Il y a peut-être un problème légal. Il n’y a aucun problème technique.







tass_ a écrit :



Oui enfin cet état de fait est assez facile à résoudre avec des tiers de confiance… Crypter c’est bien, s’assurer qu’on discute en crypté avec la bonne personne c’est mieux.





Mais comment un tiers de confiance peut-il techniquement garantir la légitimité d’un utilisateur parmi des centaines de millions ? Mettre un place un système de “délation” dans les clients (“tel client est peut-être un pollueur”) ? Ce mécanisme peut lui-même être exploité pour nuire au réseau.



Rien de définitif, non, mais rien de trivial à combattre et une course aux armements en perspective. Enfin, si TMG s’y met vraiment, ce dont je doute.









HarmattanBlow a écrit :



En quoi cela l’empêche t-il ? Qui définit ce qu’est un utilisateur légitime ? Comment distingues-tu un vrai utilisateur du réseau d’un faux utilisateur du réseau ?



Même si le site de streaming offre un mécanisme pour être le seul à fournir les identités légitimes, qu’est-ce qui empêche TMG de se faire passer aux yeux du site de streaming pour un utilisateur légitime ? Au pire le site de streaming pourrait stipuler dans ses termes du service que cette usage n’est pas toléré mais les sites ricains n’auront qu’à utiliser la même astuce que : profiter des barrières juridiques internationales.



Il y a peut-être un problème légal. Il n’y a aucun problème technique.





Ha mais là on s’éloigne de la technique oui, les tiers de confiance doivent être établis par une autre entité, décorrélée le plus possible du site de p2p, et bien sûr l’entité de confiance doit pouvoir changer à chaque fichier (ie avant qu’elle ne soit repérée et infestée).

On en revient à la réduction des peers oui, et aux systèmes fermés type boards de warez, ce qui est un peu en contradiction avec le principe du p2p certes <img data-src=" />









saf04 a écrit :



“Parmi ces chaines télévisées, certaines peuvent etre a accées protégé, par exemple des droits d’accés payants ou par la souscription à un abonnement payant ou non. Le contenu vidéo que le pair cherche a récupérer peut etre diffusé en streaming sur une de ces chaines télévisées.”



en fait c’est pour pas que ton fiston il streame le premier samedi du mois…





Perdu, c’est beaucoup plus direct que ça!





En variante, l’envoi au pair de faux blocs peut être conditionné à un profil utilisateur de l’utilisateur du terminal associé au pair. Ce profil comprend par exemple des informations telles que l’âge de l’utilisateur, de façon à ne pas permettre la visualisation par des enfants de programmes violents, par exemple.





Par contre là on a 0 explications sur l’identification des profils utilisateur (faut dire que le problème est un peu plus complexe que d’envoyer de la merde aléatoirement 2% du temps). Je rappelle que le logiciel a juste le rôle d’un pair qui reçoit une demande d’un bloc par une adresse IP random et qui envoie ou non un bloc correspondant.

Alors, soit le client Torrent enverrait un ID utilisateur avec ses demandes et chaque pair posséderait des infos personnelles sur chaque utilisateur de service de streaming P2P de France (c’est la CNIL qui va s’amuser à autoriser tous ces fichiers).

Soit c’est chaque service qui gère ça lui-même au niveau de son tracker : l’utilisateur renseigne l’âge associé à son compte, et le tracker décide, ou non, de donner les infos pour qu’il puisse récupérer le stream en question. Ce qui est tout de même un poil plus simple.



Ou encore plus débile : chaque pair avant d’envoyer son bloc demande au tracker s’il a le droit ou pas en se basant sur un ID utilisateur. Vous les voyez venir les possibilités de DDOS par amplification là?









Commentaire_supprime a écrit :



Car tout chiffrement nécessite forcément des cycles processeur et du temps de traitement et, dans le cadre de flux vidéo, faire ça en temps réel, c’est un poil tendu….







y’a aucun chiffrement dans l’histoire…



tmg se fait passer pour un utilisateur lamba. il t’envoie deux trois bon bout de fichier, puis un moisi.

si tu as de la chance, ton bout moisi est dans le buffer du logiciel et il est rejeté, ce qui te ralenti. sinon il est en affichage temps reel et tu vois le bout moisi avant qu’il ne soit vérifié.



y’a aucun cryptage, cassage de truc ou chais pas quoi.



edit: khalev, j’avais pas lu jusqu’au bout, mais c’est violent de clowneries en fait…



Sabotage de donner, intrusion dans la vie privée de l’utilisateur, c’est beau la sécurité, enfin celle des ayant droits hein ..








HarmattanBlow a écrit :



En quoi cela l’empêche t-il ? Qui définit ce qu’est un utilisateur légitime ? Comment distingues-tu un vrai utilisateur du réseau d’un faux utilisateur du réseau ?



Même si le site de streaming offre un mécanisme pour être le seul à fournir les identités légitimes, qu’est-ce qui empêche TMG de se faire passer aux yeux du site de streaming pour un utilisateur légitime ? Au pire le site de streaming pourrait stipuler dans ses termes du service que cette usage n’est pas toléré mais les sites ricains n’auront qu’à utiliser la même astuce que : profiter des barrières juridiques internationales.



Il y a peut-être un problème légal. Il n’y a aucun problème technique.







j’ai l’impression qu’on mélange un peu tout dans cette discution ….



&gt;&gt; si TMG est un utilisateur lambda, avec sa vraie adresse IP, et qu’il envoie de fausses données, il gènera le receveur, mais il pourra être identifié (pas forcement évident, mais faisable), et son IP bannie



   ==&gt;  pas un GROS problème pour TMG ils ont qu'a changé d'adresse, mais lourd tout de même, et c'est une solution qui réduira leurs force d'attaque    





&gt;&gt; si TMG usurpe l’IP d’un expéditeur normal, il peut réussir à déranger le receveur, et faire bannir l’expéditeur normal



 ==&gt; c'est un vrai problème pour le réseau, car si ils arrivent a faire bannir tout les gros partageurs, ils peuvent étouffer le réseau   

==&gt; c'est la que le cryptage peut être intéressante : . Si tu établies une communication crypté avec un pair, ils ne peuvent pas usurper son identité pour le faire bannir a leurs places. Ca sera difficile a TMG d'intercépter les clés, car ils ne sont pas Man in the middle, mais en périphérie du réseau








tazvld a écrit :



Il me semble en effet que c’est quelque chose qui est prévu dans le protocole bittorrent en dévaluant les pairs qui envoient des paquets non valides. A ceci, une solution de type PeerBlock rendrait leur “solution” totalement inefficace. Ca sent surtout l’entubage d’administratifs car d’un point de vu technique, c’est inefficace (ou plus simplement de la poudre aux yeux pour justifier un nouveau contrat)





Ca pourrait servir à faire un DoS en envoyant de la m*de avec un spoof d’IP sur un pair valide.









canti a écrit :



Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.



Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…







C’est pas que c’est “pas évident”, c’est juste impossible…

Si le hash est identique (attention, je dis bien le hash, pas le fichier), quand il sera comparé au fichier, il y aura que 2 solutions :




  • le fichier correspond au hash, donc il n’a pas bougé d’un bit

  • le fichier est corrompu/empoisonné/whatever, on retélécharge le chunk



    Dans le pire des cas, on va choper les chunk qui corrompus sur d’autres pairs et c’est réglé.



    Le principe du p2p c’est justement d’aller choper les infos là où elles sont dispo ! TMG ou ton voisin, meme combat.



    Ca sent bien le pipot quand meme ce brevet









Commentaire_supprime a écrit :



En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.



Cinq ans d’emprisonnement et 75 K€ d’amende potentiellement. Si TMG perturbe du streaming P2P légal avec un requérant sans pitié en face, ça va faire mal…





Contact entre les directions et shuuuut…

Communication du côté client : nous avons une légère perturbation, c’est pas nous c’est un stagiaire <img data-src=" />









Constance a écrit :



C’est toujours sympa de pourrir le réseau et générer du trafic pour de la merde.

C’est pas interdit ce genre de pratique ? En tout cas ça devrait…







C’est pas déjà le cas avec Youtube et cie <img data-src=" />









saf04 a écrit :



y’a aucun chiffrement dans l’histoire…



tmg se fait passer pour un utilisateur lamba. il t’envoie deux trois bon bout de fichier, puis un moisi.

si tu as de la chance, ton bout moisi est dans le buffer du logiciel et il est rejeté, ce qui te ralenti. sinon il est en affichage temps reel et tu vois le bout moisi avant qu’il ne soit vérifié.



y’a aucun cryptage, cassage de truc ou chais pas quoi.





On pourrait par contre je pense assez aisément imaginer de signer les paquets: par exemple, chaque client du réseau P2P dispose d’une clé (genre OpenPGP) et signe les paquets qu’il envoie. S’il s’avère que le paquet est véreux, un gros mauvais point, sinon un bon point. Si un client a un trop mauvais ratio, ses envois sont ignorés voire il est complètement bloqué.

Pour aller un peu plus loin on peut aussi imaginer que, en parrallèle des paquets de contenus, l’ensemble des clients échangent des info de checksum des paquets et leurs stats concernant les mauvais clients (qui seraient pondérées par la réputation +/- ajustées mauellement).









Commentaire_supprime a écrit :



En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.



Cinq ans d’emprisonnement et 75 K€ d’amende potentiellement. Si TMG perturbe du streaming P2P légal avec un requérant sans pitié en face, ça va faire mal…







Même s’ils perturbent du P2P ‘illégal’, ils seraient en violation de la loi. C’est un peu comme activer un brouilleur près d’un club d’aéromodélisme sous prétexte que des modèles réduits ont volé en dehors des heures autorisées.









ISFNoah a écrit :



invention rigolote…







c’est déjà comme ca que ca marche depuis le debut du p2p …









doudawak a écrit :



C’est pas que c’est “pas évident”, c’est juste impossible…

Si le hash est identique (attention, je dis bien le hash, pas le fichier), quand il sera comparé au fichier, il y aura que 2 solutions :




  • le fichier correspond au hash, donc il n’a pas bougé d’un bit

  • le fichier est corrompu/empoisonné/whatever, on retélécharge le chunk



    Dans le pire des cas, on va choper les chunk qui corrompus sur d’autres pairs et c’est réglé.







    attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.



    c’est justement là que c’est difficile… enfin bon, c’est pas mon mode de consommation, donc il peuvent s’attaquer à ça <img data-src=" />









canti a écrit :



attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.







faudrait penser a lire les commentaires…

que cela soit en streamé ou pas, bitorrent verifie chaque morceau recu grace a un hash contenu dans le fichier de lancement.









saf04 a écrit :



c’est déjà comme ca que ca marche depuis le debut du p2p …





Ah ? Les paquets ont toujours été signés depuis le début du P2P ? Mouais, je suis dubitatif… <img data-src=" />









canti a écrit :



attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.



c’est justement là que c’est difficile… enfin bon, c’est pas mon mode de consommation, donc il peuvent s’attaquer à ça <img data-src=" />





Tu fais du 2 parmis 3.



Tu demandes 3 hash du même bloc à 3 clients différents et tu télécharges le bloc chez un de ceux qui à un hash que tu retrouves au moins 2 fois. Faut juste voir les délais que ça implique au niveau du calcul du hash. Après on a pas besoin non plus du plus gros hashage existant. Il ne conserve son intérêt que pendant 20 minutes grand max dans le cas d’un streaming live.









saf04 a écrit :



faudrait penser a lire les commentaires…

que cela soit en streamé ou pas, bitorrent verifie chaque morceau recu grace a un hash contenu dans le fichier de lancement.







oui, mais on ne parle pas de bittorent, faudrait penser a lire les commentaires….



on parle de stream live, donc tu n’a pas de fichier de lancement contenant les hash attendues, parceque l’expéditeur ne sait pas ce qui va arriver



le “stream” de bittorent, et juste une lecture au fur et a mesure d’un fichier connu, pas la retransmition d’une chaine de TV









canti a écrit :



attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.







le hash juste par bloc est spécifié dans le fichier .torrent



dès que tu es en possession de celui-ci, tu es capable de détecter les informations incorrectes. Dès lors qu’un host enverrait massivement des blocs erronés, il pourrait être blacklisté par un client un peu intelligent.









ragoutoutou a écrit :



le hash juste par bloc est spécifié dans le fichier .torrent



dès que tu es en possession de celui-ci, tu es capable de détecter les informations incorrectes. Dès lors qu’un host enverrait massivement des blocs erronés, il pourrait être blacklisté par un client un peu intelligent.







pas si tu stream en live, l’expéditeur ne connait pas le contenu du fichier qu’il va streamer au moment où il génére le fichier torrent ( on en parlait au début, vous débrquez les mecs ? ^^ )













doudawak a écrit :



C’est pas que c’est “pas évident”, c’est juste impossible…

Si le hash est identique (attention, je dis bien le hash, pas le fichier), quand il sera comparé au fichier, il y aura que 2 solutions :




  • le fichier correspond au hash, donc il n’a pas bougé d’un bit

  • le fichier est corrompu/empoisonné/whatever, on retélécharge le chunk



    Dans le pire des cas, on va choper les chunk qui corrompus sur d’autres pairs et c’est réglé.



    Le principe du p2p c’est justement d’aller choper les infos là où elles sont dispo ! TMG ou ton voisin, meme combat.



    Ca sent bien le pipot quand meme ce brevet





    C’est pas du pipeau, ils partent sûrement sur le postulat que les échanges P2P ne sont pas protégés et tolèrent peu les erreurs.

    Ce qui est globalement une grosse connerie.



    De toute manière avec les Hash ça me semble bien trop inefficient comme méthode. Je suis quasiment certain que ce n’est pas les premiers à tenter l’expérience et que si l’on cherche bien dans d’autres pays on doit trouver le même procédé.









canti a écrit :



oui, mais on ne parle pas de bittorent, faudrait penser a lire les commentaires….







et si on parle pas de bittorrent on parle de quoi alors ?

de la technologie d’echange visée par ce brevet ?



ho zut c’est bittorrent.









Enyths a écrit :



C’est pas du pipeau, ils partent sûrement sur le postulat que les échanges P2P ne sont pas protégés et tolèrent peu les erreurs.

Ce qui est globalement une grosse connerie.





Dans le brevet c’est LA condition sur laquelle tout repose:





“L’invention tire parti du fait que dans les réseaux pair à pair diffusant du contenu vidéo en streaming, la fenêtre de lecture que chaque pair cherche à remplir doit être remplie dans une durée donnée qui est généralement très courte, étant par exemple de l’ordre de 2 à 3 minutes. Cette contrainte temporelle a pour conséquence la faiblesse, voire la non-existence des mécanismes de vérification de l’origine des blocs reçus et de leur validité dans de tels réseaux pair à pair, du fait de leur coût en temps et en occupation du processeur du terminal associé à chaque pair du réseau”.










saf04 a écrit :



et si on parle pas de bittorrent on parle de quoi alors ?

de la technologie d’echange visée par ce brevet ?



ho zut c’est bittorrent.





on parle de techno comme sopcast, qui stream du temps reel.



le protocole est surement proche de BT, mais ne peux pas utiliser un fichier torrent pour déclarer les hash par chunk.









canti a écrit :



oui, mais on ne parle pas de bittorent, faudrait penser a lire les commentaires….



on parle de stream live, donc tu n’a pas de fichier de lancement contenant les hash attendues, parceque l’expéditeur ne sait pas ce qui va arriver







Et de quelle technologie de stream live on parle alors??? Parceque les sois-disant contremesures de TMG, ça n’est que du vent tant qu’il n’y a pas un protocole spécifique à empoisonner.



Et pour info, du stream live en p2p, c’est tout à fait possible à protéger si les blocs sont signés par l’émetteur: le client commence à lire et choppe la clef publique de l’émetteur dans les premiers blocs, et ensuite rejette tous les blocs ne correspondant pas à cette clef publique.



M. Thierry Lhermitte, tu me feras décidément toujours rire, car peu importe la casquette que tu revêts (acteur, financeur de tmg, …) elles me font vraiment toute rire.

<img data-src=" />

Sacré rigolo va (dis je en lui tapotant une tape amicale sur le dos)








ragoutoutou a écrit :



Et de quelle technologie de stream live on parle alors??? Parceque les sois-disant contremesures de TMG, ça n’est que du vent tant qu’il n’y a pas un protocole spécifique à empoisonner.



Et pour info, du stream live en p2p, c’est tout à fait possible à protéger si les blocs sont signés par l’émetteur: le client commence à lire et choppe la clef publique de l’émetteur dans les premiers blocs, et ensuite rejette tous les blocs ne correspondant pas à cette clef publique.







visiblement sopcast , mais je ne connais pas plus ( c’est cité commentaire #14)

j’ai l’impression de me répéter, je vais arreter de répondre rapidement, et attendre de bufferiser les questions pour répondre en bloc <img data-src=" />









Khalev a écrit :



Tu fais du 2 parmis 3.



Tu demandes 3 hash du même bloc à 3 clients différents et tu télécharges le bloc chez un de ceux qui à un hash que tu retrouves au moins 2 fois. Faut juste voir les délais que ça implique au niveau du calcul du hash. Après on a pas besoin non plus du plus gros hashage existant. Il ne conserve son intérêt que pendant 20 minutes grand max dans le cas d’un streaming live.





Ca serait pas mal ça comme solution en effet. Pas forcément 2 sur 3 mais oui récupérer les hash de toutes les sources qui proposent ce bloc et récupérer un de ceux dont le hash est majoritaire.

A moins d’avoir plus de sources de TMG que de “normales” je pense que ça peut marcher… Et ça ne devrait pas prendre tant de temps proc que ça…

Généralement c’est quand même le réseau qui bride le stream, et là on ne télécharge en plus que des hash, autant dire des quantités négligeables.. Reste le temps incompressible de l’échange avec les sources… mais rien n’empeche de pouvoir régler le nombre de sources dont on vérifie le hash.









canti a écrit :



non, tu parles d’identification de pirate, alors que ce n’est pas le sujet de la news (qui est plus la dégradation du P2P).

Le cryptage permet d’éviter le problème indiqué ici, car il empêche TMG de se faire passer pour ton interlocuteur légitime. leurs attaques se résume alors à du DoS (ils surcharges ta connection, et c’est cher à faire pour des millions de “pirates”)







HarmattanBlow a écrit :



Le cryptage







<img data-src=" />









psn00ps a écrit :



<img data-src=" />





<img data-src=" />










canti a écrit :



visiblement sopcast , mais je ne connais pas plus ( c’est cité commentaire #14)

j’ai l’impression de me répéter, je vais arreter de répondre rapidement, et attendre de bufferiser les questions pour répondre en bloc <img data-src=" />









Ces réseaux IPTV mettent en oeuvre leur propre logiciel, par exemple PPLive, SopCast,TV Ants, PPStream ou encore Stream Torrent. Ces réseaux utilisent par exemple la technologie Bittorent selon laquelle un contenu vidéo est divisé en blocs.





Page 3 du brevet. <img data-src=" />









Khalev a écrit :



Page 3 du brevet. <img data-src=" />





tu noteras qu’ils en récupère la technologieBitTorent, pas qu’ils utilisent BitTorrent. <img data-src=" />

en particulier, ils n’utilisent pas de fichier .torrent, et ne vérifient pas le hash par rapport a une table de hash connu. Après c’est similaire a BT









canti a écrit :



tu noteras qu’ils en récupère la technologieBitTorent, pas qu’ils utilisent BitTorrent. <img data-src=" />

en particulier, ils n’utilisent pas de fichier .torrent, et ne vérifient pas le hash par rapport a une table de hash connu. Après c’est similaire a BT







tu peux aller lire le brevet au lieu de blablater ? tu verras bien ce que tmg explique.









Commentaire_supprime a écrit :



Question bête : le chiffrement, comment est-ce qu’ils le cassent ?



C’est pas de dissimulation de protocole dont je parle, mais de transmissions de données chiffrées entre A et B. Et X, il fait comment son man-in-the-middle dans ce cas s’il n’a pas la clef de déchiffrement des données~? Et surtout, comment peut-il savoir que les données chiffrées qu’il voit passer sont du P2P, et non des ordres de vente boursiers, par exemple ?







Y a rien a casser !

Le principe du chiffrement en simplifié :











canti a écrit :



tu noteras qu’ils en récupère la technologieBitTorent, pas qu’ils utilisent BitTorrent. <img data-src=" />

en particulier, ils n’utilisent pas de fichier .torrent, et ne vérifient pas le hash par rapport a une table de hash connu. Après c’est similaire a BT





C’est bien ce que je mettais en gras, mais ça va quand même à l’encontre de ce que tu disais.



Enfin c’est surtout que tu débattais sur un truc qui n’a pas d’intérêt dans le cas qui nous intéresse.









saf04 a écrit :



tu peux aller lire le brevet au lieu de blablater ? tu verras bien ce que tmg explique.







j’ai pas le temps de lire des conneries dans un jargon juridique (après tout, c’est écrit par des avocat, par par des ingé/dev).



Mais si tu veux bien m’expliquer en 2 lignes comment tu fait pour générer un .torrent avec la liste des hash qui passeront sur un chaine de TV streamé, dans les 3 prochaines heures, je penses que tu pourras concurrencer Mme Soleil.



J’ai lut tout les commentaires de la news ( ce qui visiblement pas ton cas, vu que tu me reexplique que les .torrent contiennent les hash, alors que je l’explique dans les 1ers commentaire) alors si tu peux faire l’effort de m’expliquer, je te promet que je ferais l’effort de te lire









doudawak a écrit :



Y a rien a casser !

Le principe du chiffrement en simplifié :




  • échange de clé PUBLIQUE en clair

  • échange de clé PRIVEE encryptée

  • communication chiffrée



    Y a un article super bien expliqué chez le site du zéro :http://www.siteduzero.com/informatique/tutoriels/reprenez-le-controle-a-l-aide-d…





    Mais s’il y a cryptage alors TMG ne peut plus faire de spoofing d’IP et se faire passer pour un utilisateur connu du service, on en revient donc au ban d’une source qui envoie trop de données corrompues.



    Donc si je résumes :



  • flux crypté =&gt; ban des sources après un nombre de blocs faux.

  • flux en clair =&gt; récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre.



    Un faille à ce raisonnement ?









doudawak a écrit :



Y a rien a casser !

Le principe du chiffrement en simplifié :











Khalev a écrit :



Enfin c’est surtout que tu débattais sur un truc qui n’a pas d’intérêt dans le cas qui nous intéresse.







c’est quand meme pas ma faute si je me fait traiter de débile parceque je ne sais pas que les hash sont dans le fichier, alors que je l’explique au début, et que depuis 30 commentaires, les gens ont compris que dans la techno dont on parle il n’y a pas de .torrent et de liste de hash, parcequ’on ne peut pas prévoir ce qui passera au stream <img data-src=" />









tass_ a écrit :





  • flux crypté =&gt; ban des sources après un nombre de blocs faux.

    […]

    Un faille à ce raisonnement ?





    Oui: tu confonds chiffrement et signature <img data-src=" />









canti a écrit :



j’ai pas le temps de lire des conneries dans un jargon juridique (après tout, c’est écrit par des avocat, par par des ingé/dev).



Mais si tu veux bien m’expliquer en 2 lignes comment tu fait pour générer un .torrent avec la liste des hash qui passeront sur un chaine de TV streamé, dans les 3 prochaines heures, je penses que tu pourras concurrencer Mme Soleil.



J’ai lut tout les commentaires de la news ( ce qui visiblement pas ton cas, vu que tu me reexplique que les .torrent contiennent les hash, alors que je l’explique dans les 1ers commentaire) alors si tu peux faire l’effort de m’expliquer, je te promet que je ferais l’effort de te lire







je ne dit pas que je sais comment le faire…

je te dis que c’est dont tmg parle dans son brevet, notamment page 4 pour evoquer la necessité d’envoyer beaucoup de blocs fiables avant pour rester un pair fiable dans les echanges.









ISFNoah a écrit :



Oui: tu confonds chiffrement et signature <img data-src=" />





pas de signature sans chiffrement





ISFNoah a écrit :



“récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre”

=&gt; Je pense pas que TMG s’amuserait à s’autogriller en indiquant spontanément le hash du paquet modifié au lieu du hash du paquet d’origine







si ils mettent le bon hash, tu verras que le paquet est mauvais une fois télechargé, et tu ne l’afficheras pas a l’utilisateur ( et par la même occasion, tu ne le partageras pas). c’est plus du DoS que de la corruption de flux video









ISFNoah a écrit :



Oui: tu confonds chiffrement et signature <img data-src=" />





=&gt; Je pense pas que TMG s’amuserait à s’autogriller en indiquant spontanément le hash du paquet modifié au lieu du hash du paquet d’origine





Tu veux dirent que le contenu de leur bloc ne correspondrait pas au hash du bloc ? Tu veux dire que quand on dit :



“Cette contrainte temporelle a pour conséquence la faiblesse, voire la non-existence des mécanismes de vérification de l’origine des blocs reçus et de leur validité dans de tels réseaux pair à pair”



Ca veut dire que l’application ne vérifie même pas que le contenu d’un bloc est valide par rapport au hash contenu dans ce même bloc ? L’horreur en effet xD… le streaming p2p n’est pas du tout au point si c’est le cas…



edit :et je vois pas en quoi je parle de signature… je parle bien d’un flux crypté : la source t’envoie du contenu crypté que affiches grâce à sa clé publique.









Enyths a écrit :



C’est pas du pipeau, ils partent sûrement sur le postulat que les échanges P2P ne sont pas protégés et tolèrent peu les erreurs.

Ce qui est globalement une grosse connerie.



De toute manière avec les Hash ça me semble bien trop inefficient comme méthode. Je suis quasiment certain que ce n’est pas les premiers à tenter l’expérience et que si l’on cherche bien dans d’autres pays on doit trouver le même procédé.







Excuses moi, tu m’a tué. C’est pas du pipot, c’est une connerie alors =)









tass_ a écrit :



Mais s’il y a cryptage alors TMG ne peut plus faire de spoofing d’IP et se faire passer pour un utilisateur connu du service, on en revient donc au ban d’une source qui envoie trop de données corrompues.



Donc si je résumes :





  • flux crypté =&gt; ban des sources après un nombre de blocs faux.

  • flux en clair =&gt; récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre.



    Un faille à ce raisonnement ?







    Tu peux envoyer en clair des blocs signés… ça peut être moins violent pour le cpu (tu ne chiffre pas le contenu du bloc, tu fais un somme de contrôle et tu la signes avant de la rajouter dans l’entête du bloc avant de l’envoyer)… si un peer t’envoie des blocs avec une signature défectueuse, tu le met en blacklist puisqu’il était supposé faire les mêmes contrôles que toi avant de relayer les blocs. Avec un système pareil, un parasitage comme celui breveté par TMG a un impact totalement négligeable.









canti a écrit :



pas de signature sans chiffrement





Dans ce sens oui, mais dans l’autre non







canti a écrit :



si ils mettent le bon hash, tu verras que le paquet est mauvais une fois télechargé, et tu ne l’afficheras pas a l’utilisateur ( et par la même occasion, tu ne le partageras pas). c’est plus du DoS que de la corruption de flux video





Effectivement.. reste qu’il faut tout de même recevoir le hash d’un nombre suffisant d’autres sources et ce avant même de télécharger le paquet, donc pour du streaming la latence peut vite s’accumuler, comme ça.



En gros c’est juste la corruption de fichier, mais appliquée au streaming parce que ça ne marche pas en torrent normal.



Les parties corrompues sont détectées et l’émetteur finit par être juste blacklisté par le client.



Il suffit d’ajouter un système de vérification de l’intégrité des parties “à la volée” pour régler la question…








saf04 a écrit :



je ne dit pas que je sais comment le faire…

je te dis que c’est dont tmg parle dans son brevet, notamment page 4 pour evoquer la necessité d’envoyer beaucoup de blocs fiables avant pour rester un pair fiable dans les echanges.







dans la pratique, le bloc “faux” sera fiable (avec un hash et un chunk de donnée correspondant), ca sera par contre difficile de voir que cette donnée video n’est pas celle qui était prévue.



après c’est sur qu’il ne faut pas inonder le réseau de merde, sinon on t’identifie tout de suite ^^









ISFNoah a écrit :



Effectivement.. reste qu’il faut tout de même recevoir le hash d’un nombre suffisant d’autres sources et ce avant même de télécharger le paquet, donc pour du streaming la latence peut vite s’accumuler, comme ça.







mais ca veut dire que pour déranger durablement 10000 utilisateurs, ils faut innonder d’autant leur bande passante : c’est plus du Denial of service, que de la corruption, dont on parle ici









ragoutoutou a écrit :



Et de quelle technologie de stream live on parle alors??? Parceque les sois-disant contremesures de TMG, ça n’est que du vent tant qu’il n’y a pas un protocole spécifique à empoisonner.



Et pour info, du stream live en p2p, c’est tout à fait possible à protéger si les blocs sont signés par l’émetteur: le client commence à lire et choppe la clef publique de l’émetteur dans les premiers blocs, et ensuite rejette tous les blocs ne correspondant pas à cette clef publique.







Ah ben tiens, j’allais demander si quelque chose dans ce genre était possible.



Après, pour la mise en oeuvre du zinzin, je demande à voir ça en conditions réelles. J’ai peut-être tort mais je ne suis pas convaincu de la pertinence du truc…









tass_ a écrit :



Mais s’il y a cryptage alors TMG ne peut plus faire de spoofing d’IP et se faire passer pour un utilisateur connu du service, on en revient donc au ban d’une source qui envoie trop de données corrompues.



Donc si je résumes :





  • flux crypté =&gt; ban des sources après un nombre de blocs faux.

  • flux en clair =&gt; récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre.



    Un faille à ce raisonnement ?







    Te prends pas trop la tete avec un cryptage des échanges p2p. Ca veut simplement dire qu’il y a une couche réseau supplémentaire, ca ne change rien à la nature de l’échange.



    Tous les pairs qui s’échagent doivent pouvoir communiquer avec le meme “langage”. aussi bien en clair qu’en crypté. La seule différence, c’est qu’un man in the middle est pas possible en crypté.



    La, le brevet dit pas “on se mets entre les 2 pairs”, il dit “je me fais passer pour un pair”. ne confonds pas les 2









Khalev a écrit :



Et?



Cool TMG enverra ses faux blocs de façon sécurisé. Wouhou…







C’est pile ce que je viens de dire, y a pas raison de parler de cryptage ici… c’était pour expliquer le concept rapidement, pas donner rason a TMG.. OMG =)









tass_ a écrit :



edit :et je vois pas en quoi je parle de signature… je parle bien d’un flux crypté : la source t’envoie du contenu crypté que affiches grâce à sa clé publique.





La source chiffre le contenu avec ta clé publique et tu la déchiffres avec ta clé privée. Mais bon s’il n’y a pas de signature, ça sert à rien pour détecter les paquets volontairement altérés.







canti a écrit :



mais ca veut dire que pour déranger durablement 10000 utilisateurs, ils faut innonder d’autant leur bande passante : c’est plus du Denial of service, que de la corruption, dont on parle ici





Oui, TMG tout en finesse ;)



Quel est la différence entre cette histoire et avoir une milice privée qui patrouillerait les rues pour faire régner sa loi ?



Une chose est certaines, on a toujours pas de pétrole.








ISFNoah a écrit :



Effectivement.. reste qu’il faut tout de même recevoir le hash d’un nombre suffisant d’autres sources et ce avant même de télécharger le paquet, donc pour du streaming la latence peut vite s’accumuler, comme ça.





Je sais pas, je suis pas assez calé pour le déterminer…

Après on peut régler le nombre de hash à récupérer en fonction de la latence.









TaigaIV a écrit :



Quel est la différence entre cette histoire et avoir une milice privée qui patrouillerait les rues pour faire régner sa loi ?



Une chose est certaines, on a toujours pas de pétrole.







quand ils te chopent, ca fait moins mal au nez <img data-src=" />









canti a écrit :



quand ils te chopent, ca fait moins mal au nez <img data-src=" />







Enfin la ils sont partis pour t’éclater les yeux, je ne suis pas certains que ce soit mieux. <img data-src=" />









doudawak a écrit :



Te prends pas trop la tete avec un cryptage des échanges p2p. Ca veut simplement dire qu’il y a une couche réseau supplémentaire, ca ne change rien à la nature de l’échange.



Tous les pairs qui s’échagent doivent pouvoir communiquer avec le meme “langage”. aussi bien en clair qu’en crypté. La seule différence, c’est qu’un man in the middle est pas possible en crypté.



La, le brevet dit pas “on se mets entre les 2 pairs”, il dit “je me fais passer pour un pair”. ne confonds pas les 2





Pour la partie “cryptée” je répondais à je sais plus qui qui disait que TMG pouvait se faire passer pour un utilisateur lambda du réseau et donc échanger normalement avec nous sans “casser” un quelconque cryptage.

Je dis donc bien qu’en cas de cryptage TMG peut se faire passer pour un des pairs mais pas pour un pair de confiance (spoof l’id d’un utilisateur connu) et que donc le ban pur et dur n’aurait pas d’effet de bord sur des sources fiables.

Alors que dans un échange non crypté, usurper l’id d’un utilisateur fiable est faisable.









doudawak a écrit :



Excuses moi, tu m’a tué. C’est pas du pipot, c’est une connerie alors =)





La méthode n’est pas du pipeau car elle est envisageable.

C’est une grosse connerie car les protocoles s’ils sont vraiment encore sensibles à ce type d’attaque peuvent très bien être sécurisés. Et tout ça va nous coûter encore très cher dans nos chères finances d’état.









AntonyToku a écrit :



Pourquoi une pub m’agresse quand je clique sur ton lien?





Parce que t’as pas AdBlock?<img data-src=" />





Ainsi, TMG propose d’envoyer entre 100 et 500 Mo de contenu légitime avant d’empoisonner les flux





????



Bah, tant mieux alors…Ca fait au moins 100500 Mo de contenu récupéré. Pour les autres blocs, bah ils viendront d’une autre source. Et, en bonus, la source TMG sera black listée pour la prochaine fois.


Ils n’arrêtent pas a foutre leur merde et polluer le net ces gars de TMG et en plus on leurs paie avec votre argent! <img data-src=" />

N’oubliez pas a configurer correctement votre VPN <img data-src=" />


Je donne 1 mois au developpeur pour ce mettre a niveau .

Et il vont commencer maintenant donc cela sera pret avant .



Simple de le torrent un clef prive .

Et tous les hash de block sont signe avec la clef sur torrent .

Si on recois un bloc valide mais donc la signature ne va pas . Hop poubelle et blacklist .


Ils innovent, c’est bien <img data-src=" />


<img data-src=" />désolé d’avoir occulté le premier mot du titre (aussi bien que l’article lui-même). L’article traitait bien que du P2P



La fatigue m’a égaré <img data-src=" />



<img data-src=" />




En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.





http://europa.eu/legislation_summaries/information_society/internet/l33193_fr.ht…



http://www.droit24.fr/a/comment-sont-sanctionnées-les-infractions-informati…


et donc si on a la malheur de streamer une video crée par nous meme qui a le meme hash qu’unre video illicite on fait comment ? <img data-src=" />








Laskov a écrit :



et donc si on a la malheur de streamer une video crée par nous meme qui a le meme hash qu’unre video illicite on fait comment ? <img data-src=" />





Si tu arrives à cela, je te conseille le loto ou l’euromillion <img data-src=" />