Retraité depuis mai 2010, il a obtenu son éméritat lui permettant de continuer à enseigner. Il est aussi auto-entrepreneur depuis le 1er juin 2009 dans le domaine du conseil en informatique, réseau et sécurité.
C'est vers ce chercheur talentueux que la Hadopi s'est tournée pour la rédaction des spécifications fonctionnelles pour la labellisation des outils de sécurisation dont elle a la charge. La suite de l'article propose un aperçu de sa position philosophique concernant la neutralité des réseaux, et analysera la façon dont ses recherches s'articulent avec le projet de la Hadopi. Position de M. Riguidel concernant la neutralité des réseaux
À l'occasion d'un entretien par l'ARCEP, M. Riguidel prend position concernant la « neutralité des réseaux ». Il y explique que la notion de neutralité des réseaux recouvre l'idée d'un réseau qui transporte des bits indifférenciés. Il associe cette indifférenciation au fait que l'intelligence est à la périphérie, à savoir dans l'application qui émet ou reçoit ces données indifférenciées, et non dans le réseau qui ne fait que les transporter. La neutralité des réseaux correspond donc à un réseau qui a la forme d'un « maillage ». Cette neutralité des réseaux ainsi définie recouvre selon lui une « vieille conception de l'Internet et des réseaux ».
Selon un constat de fait, cette neutralité des réseaux est vieille car elle fût effective au début de l'Internet, mais ne l'est plus. Comme les réseaux évoluent, cette neutralité a permis « l'émergence de portails », par quoi « Internet aujourd'hui c'est Google, c'est Facebook, c'est YouTube, c'est Amazon, etc. » L'émergence de ces portails est « une espèce de confisquation du réseau, on passe sous le joug d'un portail », ce que M. Riguidel appelle « de l'anti-Internet, la négation du réseau ».
Selon un constat de droit, la neutralité des réseaux est vieille car elle ne permet plus de définir ce que l'on voudrait que soit le réseau dans l'avenir. D'abord, au sens où ceux qui défendent la neutralité du réseau sont, selon M. Riguidel, ceux qui en ont profité pour faire émerger des portails qui nient in fine cette neutralité. Mais aussi et surtout en ce sens que pour être plus juste, le réseau doit pouvoir, dans l'avenir, savoir faire la différence entre les paquets qu'il transporte. La notion de bits indifférenciés est « un coup d'arrêt à toute l'évolution riche que l'on pourrait avoir de l'Internet ». En effet, contre la neutralité des réseaux, il prône des « communications efficaces et équitables », ce qui suppose de permettre au réseau de définir des priorités dans le transport des communications : « il faut différencier des applications de télé-chirurgie, des applications de messagerie, des applications en temps réel, des applications pour les pompiers et la gendarmerie ». Permettre au réseau de différencier les paquets IP, c'est mettre l'intelligence au cœur du réseau — dans le transport — et non en périphérie. C'est rendre le réseau « intelligent ».
Cette différenciation apparaît nécessaire car « il faut arrêter de penser que l'informatique est infinie, que la bande passante est infinie ». C'est dans cette optique d'un réseau amené à être saturé qu'il lui est nécessaire de savoir différencier les paquets qu'il transporte. C'est pourquoi les recherches actuelles portent sur le « DPI, le Deep Packet Inspection, qui justement inspecte, analyse, les paquets IP pour les différencier ». Mais le réseau ne peut devenir « intelligent » par la seule technologie, l'aide des pouvoirs publics est elle-aussi nécessaire. Ceux-ci doivent favoriser l'émergence d'applications utilisant le réseau avec intelligence. Ceci passe par ailleurs par une opération de vérité sur les prix : « Selon que l'on télécharge beaucoup ou pas, selon que l'on a besoin d'applications sécurisées ou pas, de beaucoup de latence ou pas, le tarif n'est pas le même car on utilise des instruments différents ».
Ainsi, la position de M. Riguidel concernant la neutralité du net est plus fine qu'il y paraît au premier abord.
La neutralité du réseau est critiquée pour deux raisons :
- d'abord parce qu'elle conduit à l'émergence de portails qui annihilent cette neutralité,
- ensuite parce qu'en raison d'une saturation prévisible du réseau, celui-ci se verra dans l'obligation d'attribuer des priorités à certains paquets.
Ces deux raisons sont cependant elles-mêmes susceptibles d'être critiquées :
- La négation du réseau par les portails, loin d'être une conséquence directe de l'originelle neutralité des réseaux pourrait être au contraire le fait d'un manque d'obstination des pouvoirs publics à défendre cette neutralité. Le portail s'impose car il répond à une demande. Mais une fois imposé, il subsiste par inertie, et devient incontournable car le service qu'il fournit repose sur un protocole fermé. La défense de protocoles inter-opérables partout où naît un monopole permettrait au réseau de se ré-équilibrer vers sa périphérie. Par exemple, un protocole ouvert de dialogue entre un libraire et un client potentiel pourrait contourner Amazon, et donner un peu d'air à nos librairies de quartier.
- L'argument de la future saturation des réseaux justifiant la nécessaire inspection des paquets est fallacieux puisqu'il confond quantité et qualité. M. Riguidel voudrait faire croire que certains contenus coûtent plus d'effort au réseau pour les transporter que d'autres : c'est faux, le réseau fournit le même effort quelle que soit la qualité de l'information, son effort est fonction de la seule quantité. Si les réseaux saturent, c'est la quantité de l'information transmise qu'il faut réguler et non leur qualité. Ce n'est donc pas selon l'exemple du véhicule prioritaire qu'il faut comprendre cette régulation, mais selon l'exemple de l'appel d'urgence gratuit. Si les réseaux saturent, nous pourrions être soumis à un maximum d'échange, et avoir droit à échanger certaines information vitales hors de ce quota. Il est donc inutile de surveiller le contenu de l'information échangée pour faire face à cette saturation, il suffit d'en contrôler la quantité.
Quoi qu'il en soit, nous retrouvons ses positions philosophique concernant le réseau dans le document de consultation relatif au projet de spécifications fonctionnelles des moyens de sécurisation de la HADOPI. Rendre le réseau conscient des paquets qu'il transporte, c'est là justement le rôle du logiciel de sécurisation. Ce logiciel ne prévoit pour l'instant de le faire que chez l'utilisateur final du réseau, mais ce premier pas est certainement décisif. Pour rendre le réseau « intelligent », ce logiciel doit pratiquer une inspection des paquets entrant et sortant, et introduit donc la DPI dans nos usages de l'Internet.
En ce premier stade, il se contente de reconnaître les paquets entrant et sortant, et d'en informer l'usager, mais, pour avancer dans la direction que M. Riguidel voudrait donner à l'Internet, il est possible qu'en un second stade, grâce à un système de tatouage, un logiciel plus évolué facilite la reconnaissance par un tiers du contenu des paquets. À partir de paquets ainsi tatoués, il sera possible d'affirmer des règles de priorité entre les paquets.
M. Riguidel et la HADOPI
M. Riguidel adopte donc des positions théoriques de nature à plaire aux ayants droit et possède en outre des qualités d'ingénieur qui justifient qu'il soit choisi par la HADOPI pour déterminer les spécificités fonctionnelles des logiciels susceptibles d'être labellisés comme étant des outils de sécurisation de la connexion Internet. Mais si la HADOPI a l'adresse de choisir cette personne qui est experte en ce domaine — il ne fait aucun doute qu'elle le soit —, elle a par ailleurs la maladresse de choisir une personne qui est loin d'avoir la neutralité nécessaire concernant un sujet aussi sensible que la surveillance de notre usage quotidien de l'Internet.
Le 4 décembre 2009, un brevet a en effet été déposé aux noms de messieurs Riguidel, Ladouari, et Laurier.
- Philippe Laurier est économiste, collègue de M. Riguidel car enseignant à l'École Nationale Supérieure des Télécommunications en charge de l'aide à la création d'entreprises innovantes.
- Laurent Ladouari est d'abord conseiller technique pour les Nouvelles Technologies nommé au cabinet de la ministre Christine Albanel en septembre 2007 ; il rejoint ensuite le secrétariat à l'économie numérique d'Eric Besson le 1er avril 2008, prenant en charge les questions liées aux contenus, au droit d'auteur et à la copie privée.
Au fait des technologies de l'Internet, ces trois personnes sont donc capables de prévoir l'évolution future de l'Internet ; mais, proches des sphères décisionnaires, elles sont en outre en position de prévoir l'évolution du droit, sinon de l'influencer. L'analyse que fait PC-inpact de ce brevet permet de constater à quel point le brevet semble prévu pour répondre d'avance aux attentes de la HADOPI.
Les auteurs du brevet constatent d'abord que « les réseaux [...] voient la coexistence d'usages licites ou illicites, amicaux ou intempestif ». Contre les usages illicites ou intempestifs, le brevet décrit donc un procédé de « traçabilité et de résurgence de flux pseudonymisés sur des réseaux de communication, et [un] procédé d’émission de flux informatif apte à sécuriser le trafic de données et ses destinataires ». Cette traçabilité est nommée griffage, et permet ensuite « d’inspecter le trafic du réseau, sans vérifier initialement le contenu des utilisateurs et sans toucher à ce contenu ». Il s'agira alors d'éliminer « si besoin après des filtrages en cascades (en série et/ou en parallèle), un volume important de flux présumés ayant une plus [faible] probabilité de correspondance avec l'objet de la recherche. Ne restera alors qu'à se focaliser prioritairement sur le flux résiduel détecté dans les tamis successifs, utilisant par exemple dans ce cas de figure des protocoles non associés à cette intervention ou ce secret [protocoles ne pratiquant pas le griffage], pour l'ausculter davantage ».
Pour que l'ensemble soit efficace, il faut cependant que les utilisateurs d'Internet s'accordent pour « griffer » les paquets. Comment inciter les utilisateurs à se laisser ainsi griffer le contenu ou les flux ? » demande PC-inpact. Le brevet répond : « L'analyse de comportement est par exemple effectuée en priorité sur les flux n'ayant pas de griffage masquant rapporté à un support de communication pourvu d'un cryptonyme. L'usager peut être utilement informé de cette particularité, en vue de l'inciter à se doter d'un cryptonyme. L'efficacité du procédé tient en partie à ce qu'un taux élevé de personnes volontairement homologuées permet de faciliter des recherches en restreignant d'autant le champ résiduel à observer en priorité ». Ainsi, si une majorité d'usagers griffent leurs paquets, les paquets non griffés feront figure d'exception. Ces exceptions sont aisément repérables, et sous elles, il est possible de repérer un usage illégitime et condamnable d'un contenu, ou, si l'usage est légitime, il est possible d'inciter l'usager à griffer les paquets qu'il transmet.
Le brevet suppose donc que les usagers soient incités à griffer leurs paquets. En un sens, HADOPI pourrait répondre à cela de deux façons : le logiciel de sécurisation promu par M. Riguidel nous informe de toute transaction qui pourrait ne pas être légale. On peut penser que les auteurs du brevet trouveraient plus efficace qu'il nous informe de toute transaction non griffée. HADOPI, par l'envoi de mails, nous informe de son côté de toute transaction qui n'est pas régulière. Ici aussi, on peut avancer qu'à terme, HADOPI pourrait trouver nécessaire de nous informer de toute transaction non griffée.
Conclusion
La pensée de M. Riguidel concernant les réseaux, ainsi que le brevet qu'il a déposé en 2009 décrivent un ensemble de procédures beaucoup plus ambitieuses que le simple logiciel de sécurisation proposé par HADOPI. En ce sens, M. Riguidel ne semble pas profiter de la situation qui est la sienne au sein de la HADOPI pour imposer la technologie qu'il a breveté. Il est cependant troublant de constater que les préconisations faites par la HADOPI sont un premier pas important dans la direction de cet Internet rêvé par M. Riguidel. Si cette vision de l'Internet parvenait à s'imposer, la technologie qu'il a breveté pourrait alors s'avérer incontournable. Dans cette situation, il est à craindre que M. Riguidel ne puisse porter un regard neutre sur les technologies à labelliser.
Il est par ailleurs regrettable que les préconisations décisives qu'il fera concernant l'Internet de demain ne fassent pas l'objet d'une confrontation de points de vues : la HADOPI ne semble pas avoir prévu d'écouter les défenseurs de la « neutralité des réseaux » en contrepoint des discours de M. Riguidel.
PS : Permission est donnée à quiconque de diffuser et modifier cette dépêche, à condition d'en citer les sources.
Aller plus loin
- Curriculum-vitae de M. Riguidel (295 clics)
- Spécifications du logiciel Hadopi (53 clics)
- Hadopi, la Deep Packet Inspection et M. Riguidel (44 clics)
- Analyse du brevet de M. Riguidel consacré à la lutte contre le téléchargement illégal (42 clics)
- Le brevet en question (25 clics)
- Entretien avec M. Riguidel par Numérama (27 clics)
# Sur son CV
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Je suis le seul à ne pas parser cette phrase ?
# Typo
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
[^] # Re: Typo
Posté par Olivier (site web personnel) . Évalué à 1.
[1] tout le monde n’utilise pas le bépo ici ?
[^] # Re: Typo
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Typo
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Typo
Posté par Sygne (site web personnel) . Évalué à -1.
* sans espace le guillemet ouvrant voit son code utf-8 découpé, et est donc invalide.
* avec espace insécable idem.
* certains navigateurs (dont le mien: midori) ne comprennent pas les espaces insécables.
Par ailleurs, il fut un temps où j'avais mappé l'espace insécable et l'espace fine sur Shift-Espace et Alt-Espace: résultat, j'en insérais par inadvertance dans mes scripts, ce qui fût un plaisir à débugger. Du coup, j'ai radié l'espace insécable de mon clavier et j'écris à la canadienne (j'insère la ponctuation sans espace), mon traitement de texte les rajoute là où c'est nécessaire.
[^] # Re: Typo
Posté par Antoine . Évalué à 2.
Suffirait que le moteur de Linuxfr applique automatiquement certaines règles de typographie française, ce que certains logiciels font depuis des années (SPIP depuis dix ans).
[^] # Re: Typo
Posté par Brioche4012 (site web personnel) . Évalué à 2.
c'est pourtant simple:
« Blah blah blah »
donnera les guillemets avec espaces insécables et tout le tralala sans soucis d'encodage.
[^] # Re: Typo
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Typo
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Typo
Posté par Boa Treize (site web personnel) . Évalué à 3.
Je ne parierais pas dessus, avec Templeet y'a toujours des surprises. :-) (Et il y a un souci d'encodage : celui-ci est particulièrement illisible quand les caractères s'accumulent. Déjà qu'on se prend la tête avec les listes et les br/ que Templeet ajoute automatiquement...)
# En vrac
Posté par vjm . Évalué à 10.
- la notion de communication efficaces et équitables c'es pas une invention de Ridiguel, c'est juste l'un des principaux champs de recherche en ingénierie réseau depuis 30 ans. Suffit de faire une recherche sur google pour flow fairness ou tcp fairness. Ca fait partie du problème plus vaste d'allocation des ressources sur un réseau qui est l'un des champs de recherche majeurs souhaité par l'Internet Architecture Board genre là : http://groups.csail.mit.edu/ana/Publications/DevelopingaNext(...) . C'est suffisamment d'actualité pour donner lieu à des débats houleux et récents autour de propositions radicales : http://tools.ietf.org/html/draft-briscoe-tsvarea-fair-02
- faire de la différentiation de services, c'est vieux comme IP. Y'a eu le champ Precedence, y'a eu ToS, maintenant on a DiffServ, etc. Bref on veut faire de la QoS depuis le début. Simplement parce que différents flux ont différentes contraintes (latence, débit, gigue, etc.). C'est pas l'antithèse de la neutralité des réseaux. De toute façon la neutralité est une notion politique plus que technique, le principe end-to-end qui est à son origine est beaucoup moins rigoureux (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen(...) qui dit que des fois il vaut mieux implémenter une fonction dans le réseau plutôt que dans l'application si ça améliore les performances...) tout comme la culture de pragmatisme qui règne à l'IETF. Comme Lawrence Lessig l'a déjà expliqué, le problème c'est pas la notion de services différenciés, c'est que l'opérateur en profite pour favoriser son contenu ou celui de ses partenaires commerciaux (source : http://online.wsj.com/article/SB122929270127905065.html ). Il faut juste que la QoS reste entre les mains des utilisateurs finaux et on est bon.
- l'intelligence dans le réseau ça fait un bout de temps qu'il y en a. Il existe plus depuis longtemps ce réseau idiot idéalisé. Il y a des tas d'éléments actifs qui maintiennent des états concernant les flux en cours. Or la notion du réseau idiot c'est qu'il ne devait pas maintenir d'états, c'est la source de l'opposition entre IP et ATM, entre les ingé réseaux et les téléphonistes. Mais depuis on a des firewalls, du NAT, de la QoS, du policy-based routing (i.e. pas que basé sur des critères purement techniques), du traffic engineering, etc. Ca fait bien longtemps que le réseau est intelligent. Et encore une fois, il peut y avoir de bonnes raisons. Le problème c'est si ça sert pour faire la discrimination qui réduit la liberté d'expression ou d'entreprendre. Bref c'est un problème d'appliquer les lois qui existent déjà dans un cadre nouveau.
Sur les critiques qui sont formulées de la pensée supposée de Ridiguel :
- Très bonne remarque, les pouvoirs publics auraient dû faire le forcing sur l'interopérabilité et les standards ouverts et on aurait une offre beaucoup plus variée et plus de compétition ce qui compenserait les dérives actuelles notamment sur la vie privée.
- Sur ton second point en gros tu plaides le retour aux quotas de trafic avec certaines classes de trafic hors quota. Ca m'étonnerait que le consommateur suive et en tout cas je vois mal le moindre opérateur s'y risquer. Et ce que tu décris ça impose quand même d'avoir une classification à un endroit, au plus proche de la source. Mais c'est exactement comme ça que fonctionne la QoS. Nul besoin d'opposer quantité et qualité, tu parles de la même chose. D'ailleurs, un réseau je peux le saturer même sans envoyer énormément de donnée. Il suffit d'avoir des flux non coopératifs qui foutent en l'air l'équité et du point de vue d'un flux individuel ça revient à avoir un réseau saturé (ex : http://www.cs.northwestern.edu/~akuzma/rice/shrew/ ou http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf ). Donc au final, j'ai quand même besoin d'avoir des buffers différents dans mes équipements réseau pour appliquer des algorithmes de gestion de file d'attente ou pour ordonnancer différemment les flux en fonction de ce que chacun a réellement besoin, ne serait-ce que pour garantir à ta classe "appel d'urgence" de pouvoir continuer à passer pendant que je rejette le trafic en vrac qui a dépassé le quota mais qui continue à venir me saturer une interface. Pour tout ça, soit les flux ont été taggués en amont et je fais confiance soit je cherche des heuristiques dans le paquet (i.e. de la DPI dans le cas plus extrême mais ça peut aussi être juste l'équivalent de NBAR de Cisco, cf. http://www1.cisco.com/en/US/products/ps6616/products_ios_pro(...) ). En tous cas il suffit pas juste de dire "il faut envoyer moins !". Le problème c'est d'empêcher que les opérateurs choisissent les politiques de QoS eux-mêmes sous couvert d'accords commerciaux parce que ça désavantage le consommateur mais sinon y'a rien d'intrinsèquement mauvais à faire de la QoS et donc de la différentiation.
Globalement je trouve que c'est faire bien grand cas de ce bonhomme qui ne dit rien de bien intéressant et qui est loin d'avoir l'aura que cet article semble vouloir lui attribuer. Il est juste particulièrement opportuniste.
PS : je vais me faire descendre mais je trouve en plus que les spécifications fonctionnelles des moyens de sécurisation HADOPI sont bien. Elles serviront juste à labelliser et ce qui est décrit c'est grosso modo ce que sait faire un Symantec Endpoint Protection et assimilés. Il est sans arrêt dit que l'utilisateur peut contrôler la politique de sécurité. Le seul truc supplémentaire par rapport à l'offre commerciale existante c'est 1) le coup de la copie des logs signés pour avoir une valeur en justice et 2) en plus des listes d'url commerciales, on aura des listes d'url gouvernementales mais a priori publiques ne serait-ce que pour des raisons purement techniques (genre le logiciel peut être open source et l'utilisateur garde le contrôle de la politique de sécurité). Limite ça va améliorer l'équipement en outils de sécurité sur les postes des français. En tous cas j'ai pas vu en quoi c'était un mouchard...
Pff trop long tout ça, désolé.
[^] # Re: En vrac
Posté par patrick_g (site web personnel) . Évalué à 8.
Mais extrêmement intéressant, donc merci !
[^] # Re: En vrac
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
La saturation peut être éviter avec de l'investissement et donc pas besoin de QoS dans ce cas là.
"La première sécurité est la liberté"
[^] # Re: En vrac
Posté par Antoine . Évalué à 3.
Surtout que, je ne sais pas pour vous, mais de mon côté on ne la voit pas arriver, la saturation. Depuis la bulle Internet, les opérateurs ont tendance à provisionner beaucoup de bande passante, et les débits domestiques ont explosé.
[^] # Re: En vrac
Posté par Sygne (site web personnel) . Évalué à 3.
Sur les critiques qui sont formulées contre la pensée de Ridiguel:
* Je pense personnellement que le premier point est finalement assez fragile: l'hégémonie de Google et de Youtube ne sera pas réduite par des protocoles inter-opérables...
* Quant au second point, outre les remarques techniques que tu proposes contre lesquelles je n'ai rien à dire, mon opinion personnelle n'est pas de plaider le retour au quotas de trafic puisqu'à mon avis la saturation du réseau est loin d'arriver. Par contre, si l'hypothèse d'une prochaine saturation du réseau est confirmée, j'aimerais trouver un argument qui contrebalance celui du filtrage proposé par M. Ridiguel. Celui du quota est effectivement très gênant, quel autre argument proposer alors?
Enfin, si je fais cas de ce bonhomme, c'est avant tout parce qu'il me semble être un représentant exemplaire de cet internet que je ne souhaite pas, et qu'il a de l'influence sur les sphères décisionnaires. Je serais heureux qu'il ait moins d'influence, et que sa pensée soit publiquement critiquée. Or, pour cela il faut d'abord qu'il soit connu, et que sa pensée soit présentée de la façon la plus rigoureuse possible pour que les critiques qui y sont faites aient de la force (on ne critique pas une pensée en commençant par en présenter une image affaiblie).
[^] # Re: En vrac
Posté par vjm . Évalué à 9.
L'argument à avancer c'est que les opérateurs sont de gros hypocrites. En 2000 suite à la bulle Internet, ils se sont retrouvés avec une surcapacité monstrueuse du coup ils ont cassé les prix et se sont bien gardés d'investir dans l'infrastructure pendant des années. Bref, ils se sont gavés. Par contre ça accéléré le processus de maturation du marché des opérateurs dans lequel il est désormais devenus très difficiles de dégager des profits confortables (c'est un cas classique d'économie industrielle de mon point de vue).
Maintenant que l'usage rattrape la capacité, ils pleurnichent qu'ils ont besoin de faire des investissements et pour ça ils essayent de tirer de l'argent à tout le monde : aux consommateurs en lui fournissant des services additionnels exclusifs ou en se lançant dans la production de contenu (genre Orange qui est producteur de cinéma maintenant...) et aux fournisseurs de contenus sous prétexte qu'ils utilisent la bande passante que les consommateurs sont pourtant déjà censé avoir payé.
Or, essayer d'augmenter la capacité pour faire face à de la saturation c'est une solution de facilité très coûteuse et pas forcément très intelligente parce que c'est très difficile de calculer de quelle capacité tu as ou vas avoir besoin. La meilleure solution ce serait plutôt d'investir agressivement dans la recherche en réseau pour améliorer un peu le comportement de certains protocoles par rapport à l'usage moderne et aux contraintes des ISP.
Mais tant qu'on avait de la surcapacité, ça intéressait pas grande monde de travailler sur ce genre de recherche. Heureusement ça se réveille depuis deux ans. Quelques exemples prometteurs pour moi :
- http://en.wikipedia.org/wiki/Proactive_network_Provider_Part(...)
- http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN
- https://datatracker.ietf.org/wg/ledbat/charter/
- Il y a aussi pas mal d'applications qui profiteraient très bien d'arrêter d'utiliser HTTP comme protocole de transport universel et développer SCTP ce serait pas inintéressant
Et pour ce qui est de la différentiation de services (de la QoS quoi), ça peut aussi être une solution tant que ce sont les extrémités qui définissent les classes à prioritiser ou pas et pas l'ISP en fonction d'accord commerciaux.
[^] # Re: En vrac
Posté par Sygne (site web personnel) . Évalué à 3.
Je suis vraiment très heureux de lire les arguments que tu apportes: ils sont une réponse précise et technique aux discours de Riguidel. À vrai dire, c'est le genre de choses que je voulais lire en postant cet article.
Il me faudra du temps pour éplucher et comprendre les liens que tu cites. J'ai pourtant d'ores et déj'ai deux question à te poser:
1) À deux reprises, tu affirmes que la décision doit résider à la périphérie du réseau: dans ton premier post, lorsque tu indiques que la qualité de service n'est pas antinomique avec la neutralité des réseaux à condition que cela «reste entre les mains des utilisateurs finaux»; et dans ton second post, lorsque tu mets en évidence le fait que la QOS peut-être une réponse à la saturation des réseaux, «tant que ce sont les extrémités qui définissent les classes à prioritiser ou pas et pas l'ISP en fonction d'accord commerciaux».
Je crois comprendre que le fait que la décision réside dans la périphérie suppose deux éléments:
* une procédure technique, positive, grâce à laquelle les extrémités déterminent les ordres de priorité.
* une procédure légale, négative, empêchant un opérateur d'imposer ses règles de priorités.
Est-ce bien le cas, ou peut-on considérer qu'il y a des procédures techniques qui garantissent qu'aucun opérateur n'impose ses règles de priorité?
2) Faute d'avoir lu le pdf concernant le principe end-to-end, j'ai l'impression que le concept de neutralité des réseaux ne recouvre plus celui d'intelligence à la périphérie pour le simple fait que le réseau prend d'ores et déjà des décisions sur les contenus qu'il transporte, et ce sans nuire à sa neutralité. Pourtant, à deux reprises tu indiques que la décision concernant les priorités doit être décidée à la périphérie (quitte à être relayée par le réseau même): n'est-ce pas finalement considérer que la neutralité du réseau suppose le principe end-to-end? Es-tu certain que ton discours n'assimile pas in fine neutralité et end-to-end?
[^] # Re: En vrac
Posté par vjm . Évalué à 4.
Tu as parfaitement compris qu'il faut une procédure technique pour définir les classes (par exemple là où je travaille on fait ça artisanalement avec Completel pour qu'ils respectent nos règles de QoS LAN en les transportant à travers leur WAN MPLS) et une forme quelconque de régulation pour encadrer l'usage de la discrimination du trafic.
Mais il manque encore un autre élément qui est la raison pour laquelle la QoS ne s'effectue qu'au sein d'un même réseau : pour être vraiment end-to-end, il faut que le marquage QoS soit transitif, qu'il soit respecté même quand le flux traverse un autre réseau, typiquement ceux des transitaires IP entre les deux extrémités. Et ça, ça suppose de rajouter un niveau de complexité aux accords de transit et de peerings entre opérateurs voire fournisseurs de contenus. C'est très compliqué et ça n'a jamais pris malheureusement.
Sinon il y a un moyen plus simple et plus radicale de sauvegarder la neutralité : interdire l'intégration verticale (cf. http://fr.wikipedia.org/wiki/Int%C3%A9gration_verticale dans notre cas pas d'opérateur fournisseur de contenus) et appliquer la séparation fonctionnelle (dissocier l'infrastructure physique et les services, cf http://www.arcep.fr/uploads/tx_gspublication/lettre55.pdf ). On peut rêver.
[^] # Re: En vrac
Posté par Ginko . Évalué à 2.
>pour être vraiment end-to-end, il faut que le marquage QoS soit transitif, qu'il soit respecté même quand le flux traverse un autre réseau, typiquement ceux des transitaires IP entre les deux extrémités.
Même si une telle infrastructure était mise en place, qu'est-ce qui obligerait tel ou tel opérateur à respecter ce marquage QoS?
Je veux dire: un opérateur pourrait respecter globalement le marquage des flux qui arrivent sur son réseau, tant que ce marquage n'entre pas en conflit avec sa propre politique QoS (influencée par ses divers parteunariats). Dans un tel cas de conflit, il donnerait la priorité à sa propre politique QoS... qu'est-ce que l'utilisateur pourrait y faire? (si tant est qu'il puisse le mettre en évidence).
D'ailleurs, tu indiques toi-même qu'un exemple de mise en place est basé sur la confiance:
>là où je travaille on fait ça artisanalement avec Completel pour qu'ils respectent nos règles de QoS LAN en les transportant à travers leur WAN MPLS
Et d'autre part: Peut être que des applications open source ou libres respecteraient une certaine priorisation... mais des applications propiétaires, j'en doute. Elles se mettraient toutes en priorité maximale et au final, on se retrouverait comme sans QoS.
Il faudrait donc un outil au niveau du PC genre pare-feu qui règlerait cette QoS, c'est bien cela? Qu'est-ce qui empêcherait alors quelqu'un de mettre sa mule ou son torrent en priorité maximale?
>Sinon il y a un moyen plus simple et plus radicale de sauvegarder la neutralité : interdire l'intégration verticale (cf. http://fr.wikipedia.org/wiki/Int%C3%A9gration_verticale dans notre cas pas d'opérateur fournisseur de contenus) et appliquer la séparation fonctionnelle (dissocier l'infrastructure physique et les services, cf http://www.arcep.fr/uploads/tx_gspublication/lettre55.pdf ). On peut rêver.
On peut rêver, oui.
Less is more
[^] # Re: En vrac
Posté par vjm . Évalué à 1.
- Ce n'est pas l'application qui décide de son marquage mais l'utilisateur de l'application. Idéalement tu as un équipement que tu contrôles qui fait le marquage en sortie de ton réseau et le réseau de l'ISP se contente de respecter les classes de QoS. Pour un particulier le marquage pourrait être fait directement le poste ou la box ou le DSLAM ou le routeur de collecte, avec les associations classe/type de trafic définies via une interface web simple. J'ai un Linksys à la maison qui a une gestion embryonnaire de la QoS mais ça sert à rien puisque c'est pas exploité par le réseau de l'opérateur derrière.
[^] # Re: En vrac
Posté par Sygne (site web personnel) . Évalué à 4.
* Le concept « end-to-end » est un concept régulateur des procédures techniques mises en œuvres sur le réseau. Il affirme en un premier sens que l'intelligence est à la périphérie du réseau (chez l'utilisateur final).
* Il est contrebalancé par le concept d' « intelligence du réseau »: dans certains cas, la qualité du transport suppose que le réseau sache différencier les paquets, et les transporter différemment d'autres paquets.
* Ceci-étant, un second sens du concept « end-to-end » doit-être proposé: Si la qualité de service suppose que le réseau soit intelligent et qu'il différencie les paquets, il faut cependant que l'ordre des priorités du transport des paquet soit décidée à la périphérie.
* Le concept de neutralité des réseaux est quant à lui un concept juridique: Il faut des lois interdisant au réseau de contrevenir aux décisions prises en périphérie.
* Alors que le « end-to-end » a été choisi dans un but technique, la neutralité des réseaux est nécessaire dans un but éthique.
Est-ce correct?
[^] # Re: En vrac
Posté par vjm . Évalué à 4.
Pour compléter, le principe end-to-end a été posé au moment de la création de TCP/IP (un des auteurs de l'article séminal c'est Dave Clark, un des fondateurs de l'IETF). Il pose effectivement un principe technique qui est que certaines fonctions nécessitent de toute façon la coopération des extrémités donc autant tout mettre à l'extrémité par souci d'efficacité. C'est le concept fondateur de TCP. Mais il n'exclut pas en soit de mettre une intelligence dans le réseau (qui était la façon de faire traditionnelle dans le monde des télécoms). Et la pratique et le pragmatisme ont fait qu'on a introduit des éléments actifs donc intelligents dans le réseau. Mais end-to-end a été un considéré comme un élément essentiel du succès d'Internet. Combiné à Ethernet il a permis de réduire drastiquement le coût des équipements réseau en les simplifiant. Dans le même temps, il a déporté l'innovation technologique vers les extrémités. Il devenait possible de déployer des applications sans coordination avec le réseau, juste en les mettant en place sur les extrémités. C'est de là que vient l'expression que le succès d'Internet vient du fait qu'il est un réseau idiot avec l'intelligence en périphérie. C'est globalement vrai même si c'est une généralisation un peu abusive, cf. http://www.faqs.org/rfcs/rfc3724.html .
D'un autre côté, il y a un concept juridique anglo-saxon qui est celui de common carrier (cf . http://en.wikipedia.org/wiki/Common_carrier ). Ce statut un peu particulier impose de fournir un service sans discrimination. Aux USA, les opérateurs de télécommunications au sens traditionnel sont des common carriers mais pas les opérateurs de réseaux informatiques. Ils sont néanmoins tous régulés par la FCC qui est un peu l'équivalent d'une fusion de l'ARCEP et du CSA. En France, il y un principe vaguement similaire qui est dans le Code des Postes et des Communications Électroniques (CPCE) qui dit qu'un opérateur de communications électroniques doivent respecter le secret des correspondances et la neutralité au regard du contenu des messages transmis. À ma connaissance ça n'a jamais vraiment servi, ne serait-ce que parce que les pouvoirs d'enquête et de sanction de l'ARCEP ne sont pas très développés.
Maintenant nous sommes dans les années 2000. Entre le développement du haut débit, l'évolution des usages (vidéo notamment) et le débat autour de la contrefaçon, certains ISP se mettent à intervenir sur leur réseau pour décider quel trafic peut circuler. C'est notamment le scandale Comcast qui ralentit voire bloque BitTorrent en 2007. Il y a aussi une évolution juridique et industrielle aux USA qui fait que le marché des ISP devient grosso modo un duopoles là où il y avait une très forte compétition.
Et là le principe technique de end-to-end et le principe juridique de common carrier se rencontrent. On se rend que ce qui faisait le succès d'Internet (la compétition très libre en grande partie grâce aux end-to-end) est menacé. Donc on ressort le principe de neutralité du réseau (à l'IETF on parle de transparence du réseau) et on se met à s'en servir comme argument à la fois technique et juridique. Aux USA le débat prend la forme de demande pour que les ISP soient régulés comme des common carriers (avec les obligations de neutralité qui vont avec) ce que la FCC a essayé de faire l'an dernier si je me souviens bien avant d'être débouté en justice au titre qu'elle n'a pas le droit de décider ça toute seule (il faut une loi je crois aux dernières nouvelles).
Mais comme Internet est global, la problématique concerne tout le monde et le débat est arrivé en Europe, notamment grâce à des gens un peu visionnaires comme Benjamin Bayart. Mais ici, très typiquement, on se méfie bien plus (à raison) de l'intervention de l'État que des actions d'entreprises donc le débat de la neutralité s'inscrit plus contre les initiatives gouvernementales comme HADOPI mais aussi LOPPSI ou l'ARJEL.
[^] # Re: En vrac
Posté par Antoine . Évalué à 5.
Il faudrait déjà savoir quelle est la répartition du trafic.
Il y a environ 5 ans, la moitié du trafic français était du peer-to-peer (source gros opérateur), si me je souviens bien.
Aujourd'hui, j'imagine que le peer-to-peer a peut-être un peu régressé, mais que Youtube & co ont explosé. Certes, c'est du HTTP, mais avec un overhead d'encapsulation théoriquement très faible vu que les fichiers sont énormes.
[^] # Re: En vrac
Posté par vjm . Évalué à 4.
Sinon pour ce qui est des ratios de trafic, il y a le projet ATLAS qui a des données assez fiables : http://www.arbornetworks.com/en/arbor-networks-the-universit(...)
• Rise of the 'Hyper Giants': Five years ago, Internet traffic was proportionally distributed across tens of thousands of enterprise managed web sites and servers around the world. Today, most content has increasingly migrated to a small number of very large hosting, cloud and content providers. Out of the 40,000 routed end sites in the Internet, 30 large companies – "hyper giants" like Limelight, Facebook, Google, Microsoft and YouTube – now generate and consume a disproportionate 30% of all Internet traffic.
[^] # Re: En vrac
Posté par benoar . Évalué à 5.
Je vais un peu dévier du sujet, mais en ce qui concerne le financement des FAI, pourquoi tant de monde (j'ai l'impression) est-il opposé à la facturation au débit utilisé ? Pour moi ce n'est pas un critère qui casse le principe de neutralité, et permettrait d'éviter que les FAI aient cet argument fallacieux du « ils abusent de l'illimité ! » (c'est écrit illimité, comment pourrais-je en abuser ?)
Toute l'industrie d'Internet en dehors des clients finaux (surtout en France) se facture au débit, principalement au 95è pourcentile : pourquoi ne pourrait-il pas en être de même pour les abonnés finaux ? Ainsi, je ne verrai pas comment les FAI pourraient se prévaloire d'un manque de ressources financières …
[^] # Re: En vrac
Posté par Antoine . Évalué à 5.
Un argument pratique est qu'autant il est facile de prévoir et maîtriser combien de temps on passe à utiliser un moyen de communication (cas du téléphone), autant il est difficile de prévoir et maîtriser quelle quantité de données va être transportée, vu que ça dépend de la façon dont le fournisseur de services (l'éditeur du site Web, par exemple) a implémenté son offre. Pour le particulier moyen, c'est probablement un cauchemar.
Sinon, dans l'idéal, ce serait une bonne chose, parce qu'en plus ça ferait revenir l'Internet vers une culture du texte (infiniment plus léger que les vidéos et autres kikoolol multimédia).
[^] # Re: En vrac
Posté par benoar . Évalué à 3.
Je n'y avais pas pensé. Mais peut-être est-il temps d'éduquer les gens là-dessus ? On incite bien les gens à ne pas consommer trop d'eau et d'électricité, on leur explique qu'un congélateur ça pompe, qu'il faut y aller doucement sur le chauffage. Bon, certains font la sourde oreille et l'ignorent, mais au final ils le payent, au sens propre. Pourquoi n'en serait-il pas de même pour Internet ?
Sinon, dans l'idéal, ce serait une bonne chose, parce qu'en plus ça ferait revenir l'Internet vers une culture du texte (infiniment plus léger que les vidéos et autres kikoolol multimédia).
Faut pas exagérer non plus, on peut « consommer » raisonnablement de la vidéo pour le prix d'un abonnement classique. Chez FDN, où certes on mutualise la BP, on paye au 95è pourcentile pour tous les abonnés et on s'en tire avec des prix raisonnables.
Mais effectivement, ça inciterai peut-être plus les gens à voir quels sites « consomment » beaucoup (il manque peut-être des outils pour ça) et donc contraindrait les concepteurs à améliorer ce point.
[^] # Re: En vrac
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: En vrac
Posté par syj . Évalué à 3.
Les flux RSS sont un bonne exemple de protocoles inter-opérables qui a remis en cause les portails d'informations traditionnel et qui a permis l'arrivé de nouveau portail.
Le côté partage flux texte et de photo de Facebook pourrait par exemple être remis en cause. Par un serveur de flux RSS dont l'accès est contrôlé par des certificats.
Et je prends le parie d'ailleurs que si Google veut un jour s'imposer sur Facebook , il devra proposer et inciter d'autre site concurrent de Facebook à faire de même.
[^] # Re: En vrac
Posté par Sygne (site web personnel) . Évalué à 1.
Concernant Facebook, on peut concevoir assez facilement qu'un protocole bien pensé d'échanges amicaux au quotidien puisse lui faire de l'ombre.
Concernant google — je pense au moteur de recherche — , la tâche est beaucoup plus difficile par contre. Cependant, il y a quelques mois, un journal parlait d'un moteur de recherche expérimental décentralisé (et libre): il s'agit surtout d'un logiciel permettant l'indexation de sites, associé à un protocole de partage des index. Bref, un protocole qui pourrait faire de l'ombre au moteur de recherche hégémonique.
[^] # Re: En vrac
Posté par vjm . Évalué à 3.
[^] # Re: En vrac
Posté par cdeblesson . Évalué à 4.
PS : je vais me faire descendre mais je trouve en plus que les spécifications fonctionnelles des moyens de sécurisation HADOPI sont bien. Elles serviront juste à labelliser et ce qui est décrit c'est grosso modo ce que sait faire un Symantec Endpoint Protection et assimilés. Il est sans arrêt dit que l'utilisateur peut contrôler la politique de sécurité. Le seul truc supplémentaire par rapport à l'offre commerciale existante c'est 1) le coup de la copie des logs signés pour avoir une valeur en justice et 2) en plus des listes d'url commerciales, on aura des listes d'url gouvernementales mais a priori publiques ne serait-ce que pour des raisons purement techniques (genre le logiciel peut être open source et l'utilisateur garde le contrôle de la politique de sécurité). Limite ça va améliorer l'équipement en outils de sécurité sur les postes des français. En tous cas j'ai pas vu en quoi c'était un mouchard...
Moi je ne trouve pas ça bien:
- Un logiciel commercial comme "Symantec Enpoint Protection", tu es libre de l'utiliser ou pas, tu ne te retrouves pas en insécurité juridique su tu n'en veux pas.
- De ce que j'ai lu, les logs ne sont pas justes signés, ils sont chiffrés, donc tu ne sais pas ce qu'il y a dedans.
- Des listes d'URL (noires, grises, blanches), euh... j'ai juste du mal à imaginer pire.
- Un logiciel qui scanne ma machine pour tracer et désactiver les applications/protocoles qui n'auront pas le sceau républicain me prive du contrôle de mon système.
Bref, si pour être en sécurité (juridique) il faut utiliser ce genre de logiciel, je ne vois plus l'intérêt d'un système libre, autant remplacer mon pc par un ipad, ah si, bientôt il ne sera plus dans l'OS mais dans la box.
Je te concède que le terme "mouchard" est inapproprié.
Je suis d'une nature pessimiste mais je mesure la chance d'avoir connu un internet neutre et libre.
[^] # Re: En vrac
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ils sont signés, mais on ne sait pas trop par qui.
Ils sont chiffrés, par la clef publique du fournisseur.
Et ils sont disponibles en clair également, c'est obligatoire.
[^] # Re: En vrac
Posté par Guillaume Knispel . Évalué à 9.
Ils y a bien des grandes gesticulations dans les specs à la "le logiciel est sûr, incontournable, blablabla, les logs qu'il génère sont infalsifiable, kikoolol" mais l'auteur à le bon goût de ne pas expliquer comment atteindre de tels objectifs inatteignables (et heureusement qu'il a ce bon goût, sans quoi il se serait couvert de ridicule en évoquant des techniques inéfficaces (au sens mathématique, la loi .fr ayant je crois introduit un nouveau sens récursif dégénéré au terme "efficace", pur reflet de l'état de dégénérescence mentale de ceux qui la ponde)).
Reste que vu ces specs et justement ces conditions impossible à atteindre, aucun logiciel ne devrait théoriquement être formellement certifié. Étant donné qu'il y en aura évidemment, j'en déduis que tous les logiciels certifiés seront hors de ces specs. Comme je vois mal ces incantations disparaître (ça se remarquerait trop), je crains que cette loi n'entraîne encore une fois des tonnes de choses stupides et mathématiquement fausses, ce qui me fait extrêmement peur car cela introduit nécessairement de l'arbitraire dans la justice.
Maudits soient tous ceux qui concourent à une telle situation (et ce cher professeur en fait clairement parti), car ils ne font qu'accélérer la décadence de la civilisation, et risquent de porter la responsabilité de grands malheurs futurs.
[^] # Re: En vrac
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Norton, le pire du pire devant l'Éternel, et il y en aura toujours pour pigeonner les entreprises en installant cette merde, ou la conséquence du fait que les gens ne connaissent rien en informatique…
Mais si ça ne vous suffit pas, alors Symantec vous annonce qu'un nouveau virus découvert il y a peu va atteindre le zéro du disque et peut détruire votre ordinateur, et aucune solution n'a été trouvée pour éviter ce virus (normal puisqu'il n'existe pas). N'oubliez pas de faire passer ce mail à 42 ou 300 personnes de votre entourage.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: En vrac
Posté par syj . Évalué à 1.
Quand tu lances un exécutable, il regarde çà signature et il te dit combien de personne sur Internet l'ont déjà exécuté.
C'est une très bonne méthode pour éviter les malwares qui ont tendance à s'altérer pour changer leur signature et ne pas être détecté par les antivirus trop facilement.
[^] # Re: En vrac
Posté par yellowiscool . Évalué à 4.
Ils peuvent dire à Adobe : «on a 95% des photoshop qui sont piratés. Dans ces 95%, 70% sont piratés avec la version que l'on trouve sur tel site, 20% avec l'autre méthode, et 10% de hack que l'on a pas identifié.».
Envoyé depuis mon lapin.
[^] # Re: En vrac
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
C'est une bonne idée… dans un monde idéal où tout le monde fait confiance à Norton. On se porterait mieux si les éditeurs de suites logicielles antimalwares du même niveau que Symantec arrêtaient de persister dans la médiocrité (McAffee).
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# On a trouvé
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Il dirige des recherches sur la sécurité de l’Internet du futur, les infrastructures de confiance, le tatouage et la protection de contenus (multimédia et logiciel), les architectures et politiques de sécurité. Il a déposé plusieurs brevets sur les pare-feu, le tatouage et le téléchargement illégal. Il est à l'origine du mot « tatouage » en sécurité informatique.
"La première sécurité est la liberté"
[^] # Re: On a trouvé
Posté par Gniarf . Évalué à 3.
et Super Pirate aussi, on dirait.
[^] # Re: On a trouvé
Posté par Sygne (site web personnel) . Évalué à 1.
« Il a déposé plusieurs brevets: sur les pare-feu, le tatouage et contre le téléchargement illégal.»
# Pour assurer une priorisation des réseaux ...
Posté par syj . Évalué à 2.
Il suffit à mon avis de construire un réseau privé priorisé et filtré dont l'entré se trouve dans chaque DSLAM.
Je connais pas les capacité des modem DSL qui se trouve dans les DSLAM mais je pense qu'on peut au moins configuré 2 route IP.
- Une route vers Internet qui est utilisé pour les inter-connexion classique de réseau.
- Une route vers un réseau privé Français où chaque FAI filtre le flux de paquet entrant de manière à garantir qu'un usager ne va pas surcharger l'ensemble du réseau au détriment des autres géré par le FAI. Après l'état gère des filtres interne de manière à garantir et à prioriser les émetteurs: pompier, force de l'ordre, ... vis à vis du public.
- A charge de la république d'amener ce réseau dans chaque DSLAM et de le gérer correctement.
- A charge au FAI de se connecter dessus et de respecter les règles de contrôle de flux d'entrée
D'un point de vue Défense, cela me parait nécessaire d'investir dans ce type d'infrastructure pour éviter le problème qu'a rencontré la Georgie en cas de guerre ou les sites gouvernementaux ont été saturé bloquant toute communication à l'intérieur du pays.
[^] # Re: Pour assurer une priorisation des réseaux ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pour assurer une priorisation des réseaux ...
Posté par syj . Évalué à 2.
Mais le vrai risque est plutôt un potentiel réseau de machine zombie qui servirait l'assaillant de l'intérieur qui lanceront D-DOS sur certains système paralysant le pays.
En limitant le trafic par usager, on peut se prémunir de ce type d'attaque.
Une fois ce type d'infrastructure mise en place, il serait plus facile à mon avis d'intervenir localement au cas où la limitation serait trop haute.
# Juste une chose
Posté par llaxe . Évalué à 2.
Je veux bien croire que le logiciel Hadopi-édition-spéciale sera à l'épreuve de toute malice de la part de l'utilisateur. Mais dans le cas où les griffes puissent être déposées sans contrôle complet, pour télécharger à fond, ne sera-t-il pas très simple de griffer les paquets qui transporte musique, film, etc... ?
[^] # Re: Juste une chose
Posté par Sygne (site web personnel) . Évalué à 2.
La notion de griffe est très ambigüe dans le texte de PcInpact:
* Est-ce un identifiant du contenu du paquet (musique copyrightée ou libre)?
* Est-ce simplement un identifiant des caractéristiques dans lesquelles le paquet est émis?
* Est-elle émise en tout début de chaîne (sur le cd contenant le morceau de musique)?
* Ou est-elle émise lors de l'émission du contenu numérique sur le réseau?
Bref, il faut lire le brevet pour en savoir plus...
Quoi qu'il en soit, il ne faut pas confondre ce brevet et les procédures techniques proposées par la Hadopi: la Hadopi va beaucoup moins loin que ne va le brevet, même s'il y a des ressemblances.
Pour finir, s'il y a une question à se poser à propos d'un tel brevet, c'est à mon avis celle de sa validité. Qu'est-ce qui est breveté ici: un logiciel? Nous savons tous ici que le brevet logiciel n'est pas valide en Europe...
# Ridiguel ou Riguidel
Posté par Anb . Évalué à 4.
[^] # Re: Ridiguel ou Riguidel
Posté par patrick_g (site web personnel) . Évalué à 3.
Corrigé.
# Portails
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Parce qu'il n'existe pas (encore) d'équivalent simple décentralisé!
Les portails permettent de chatter/blogger/partager des fichiers/... depuis n'importe quel PC avec une liste restreinte d'amis avec une seule authentification et sans laisser tourner chez soi un gros serveur difficile à administrer et consommateur d'électricité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.