Next Generation Internet (NGI) est une initiative lancée en 2016 par la Commission Européenne. Elle vise à développer les technologies de l’internet du futur qui soient responsables et respectueuses des citoyens. Celle-ci se concrétise par l’ouverture d’appels à projets qui financeront les Internet Innovators provenant des académies, des start-ups, PME, personnes physiques …à concevoir de nouvelles solutions technologiques qui relèveront des défis identifiés par les projets NGI.Bruxelles notait d'ailleurs :
« Aujourd'hui, Internet est la clef de presque toutes les activités sociales ou économiques. Dans 10 ans, il sera encore plus essentiel pour la société et l'économie du monde entier. Pourtant, Internet reste confronté à des préoccupations et à des défis. Il y a des inquiétudes concernant les données personnelles et la transparence. Et, Internet devrait fournir de meilleurs services et une plus grande implication et participation .»
« Il est essentiel que la prochaine génération d'Internet soit conçue pour les humains, afin qu'elle puisse réaliser son plein potentiel à la fois pour la société et l'économie. L'initiative Next Generation Internet vise à façonner le futur Internet en tant qu'écosystème de plates-formes interopérables qui incarne les valeurs chères à l'Europe : ouverture, inclusivité, transparence, confidentialité, coopération et protection des données .»
NGI-POINTER vise à trouver des « architectes NGI » ambitieux pour changer le tissu sous-jacent d'Internet et du Web, en soutenant des projets ascendants prometteurs capables de construire, en plus d'une recherche de pointe, des protocoles et des outils pour aider à la transition pratique ou à la migration vers des technologies nouvelles ou mises à jour, tout en gardant les valeurs européennes au cœur. Le projet a démarré en janvier 2020 et se terminera en décembre 2022.
C'est par le biais de cette initiative que HTTP Toolkit va bénéficier d'un financement dans le cadre du programme de recherche et d'innovation Horizon de l'UE, pour s'étendre au-delà de HTTP et offrir les mêmes fonctionnalités d'interception, de débogage et de test pour les applications construites sur le Web décentralisé. Cela va être une énorme opportunité d'investir dans l'expansion de HTTP Toolkit pour prendre en charge de nouvelles technologies très intéressantes, et d'étendre les fonctionnalités de base existantes pour le faire en cours de route.
Internet va continuer à évoluer. L'UE veut financer des projets, en particulier des projets open source, pour s'assurer que les évolutions futures sont conçues en gardant à l'esprit des questions clés telles que la confidentialité et la sécurité dès le départ, et pour s'assurer que les projets européens ouvrent la voie à leur construction.
La décentralisation du web est un pas important dans cette direction. En décentralisant les services, il est possible de donner aux utilisateurs le contrôle de leurs propres données, faciliter la protection de la vie privée, donner aux utilisateurs plus de pouvoir pour publier du contenu pour eux-mêmes et améliorer la résilience et les performances des services Internet en cours de route.
HTTP Toolkit s'intègre ici, car il est open source, il est européen, il fournit déjà des outils pour prendre en charge la transparence et la confidentialité (HTTP Toolkit a été utilisé pour la recherche sur la confidentialité par des organisations du FT à Privacy International, plus une grande partie de la base d'utilisateurs sont des chercheurs en sécurité, en particulier pour Android), et il est donc parfaitement placé pour fournir des outils pour ce type de décentralisation.
Dans un billet sur le blog de HTTP Toolkit, Tim Perry a tenté d'expliquer l'importance de ce projet en se concentrant spécifiquement sur 3 protocoles principaux qui forment aujourd'hui l'épine dorsale du web décentralisé : IPFS, WebRTC & Ethereum.
Pour chacun de ces protocoles, les technologies essentielles sont désormais utilisables, mais l'écosystème au sens large et l'adoption en sont encore à leurs balbutiements. Selon Perry, il est clair que la plupart des développeurs Web traditionnels n'utilisent pas actuellement ces technologies pour créer des applications décentralisées de niveau production.
Il y a plusieurs raisons à cela, mais l'une est le manque d'outils de développement de haute qualité. Pour passer des architectures client/serveur traditionnelles à la création d'applications décentralisées, les développeurs doivent remplacer de nombreux outils de débogage et de test quotidiens par une journalisation manuelle, des scripts personnalisés et des conjectures. Ce manque d'outillage rend le développement décentralisé beaucoup plus difficile.
L'objectif ici est de résoudre ce problème, en fournissant des outils modernes pour l'avenir du Web.
Il est financé dans le cadre du projet NGI Pointer qui finance Tim Perry en tant qu'individu pour travailler dessus pendant un an, avec toutes les sorties résultantes disponibles sous des licences libres et open source (bien sûr, HTTP Toolkit est déjà commodément à 100 % open source, donc ça ne change rien du tout).
Pourquoi ces protocoles ?
Ces trois protocoles ont été choisis, car ils font partie des technologies de décentralisation les plus populaires et les plus matures pour le Web aujourd'hui, couvrant un large éventail de fonctionnalités : persistance (IPFS), communication peer-to-peer (WebRTC) et paiements/calculs distribués (Ethereum).
Si vous ne les connaissez pas, voici un bref résumé (fortement simplifié) de chacun :
IPFS
IPFS est un réseau à adresse de contenu, contrairement à HTTP, où le contenu est adressé par rapport au serveur qui le publie. Au lieu de dire « Salut exemple.fr, je voudrais hello.html », les clients disent « Salut tout le monde, je voudrais le contenu avec le hachage ABCDEF ».
Le contenu est ensuite diffusé par quiconque en dispose, qu'il s'agisse de quelqu'un d'autre sur votre réseau local, d'un nœud IPFS hébergé près de chez vous (peut-être par votre FAI) ou d'un nœud IPFS hébergé par l'éditeur d'origine. C'est le même contenu quoi qu'il en soit (vérifiable à l'aide du hachage), mais permettre à ce contenu d'être largement distribué signifie qu'il est possible de :
- utiliser IPFS pendant les partitions réseau (tant que quelqu'un sur votre réseau a le contenu que vous voulez, vous pouvez le charger, même si le reste d'Internet n'est pas disponible) ;
- accéder au contenu même si l'éditeur d'origine est entièrement hors ligne, tant que quelqu'un l'a mis en cache quelque part ;
- améliorer la latence pour le contenu populaire (quand il est probable que quelqu'un près de chez vous l'ait déjà) ;
- réduire les pics de trafic sur les serveurs des éditeurs (si le contenu est populaire, vous n'avez pas besoin d'aller chez l'éditeur d'origine pour l'obtenir).
À bien des égards, vous pouvez considérer cela comme étant techniquement similaire à Bittorrent - le contenu est chargé à partir du groupe de personnes qui l'ont actuellement disponible, et non à partir d'une seule source, et les performances s'améliorent avec la popularité.
Il est également très facile de publier sur IPFS, ce qui permet de publier de nouveaux contenus immédiatement accessibles directement à partir d'un navigateur Web, sans aucun concept de serveur ou de fournisseur d'hébergement nécessaire.
IPFS a attiré de plus en plus d'attention ces dernières années, avec un support natif publié à la fois dans Brave et Opera au cours des 12 derniers mois, et une passerelle HTTP officielle (pour la compatibilité des clients HTTP uniquement) mise à disposition par Cloudflare pour permettre l'utilisation avec des clients qui ne ne supporte pas IPFS. IPFS peut également être utilisé dans d'autres navigateurs à l'aide de l'extension IPFS Companion (Chrome, Firefox).
Ensemble, cela crée un réseau de distribution et de publication de contenu polyvalent, fournissant une bonne base pour la persistance et l'hébergement de contenu pour les applications Web sans serveur central et sans point de défaillance unique.
WebRTC
WebRTC est un protocole peer-to-peer généralement utilisé via son API Web JavaScript standard, pris en charge dès aujourd'hui dans tous les navigateurs modernes.
Il est déjà largement utilisé pour la vidéo et l'audio, alimentant de nombreuses applications de chat vidéo sur le Web. Il permet la communication peer-to-peer entre les pages Web, ce qui signifie que la vidéo peut être envoyée directement entre deux utilisateurs sur le même site, sans passer par un serveur central, améliorant la latence et réduisant la charge du serveur.
En plus de cela, WebRTC prend également en charge les canaux de données, permettant aux pages Web d'envoyer directement des messages arbitraires entre elles. Considérez-les comme des Websockets d'utilisateur à utilisateur, mais sans serveur requis.
C'est incroyablement puissant pour les applications décentralisées : vous pouvez utiliser WebRTC pour permettre aux utilisateurs d'interagir directement, sans avoir besoin d'aucun serveur !
En utilisant cela, il est facile d'imaginer une salle de discussion entièrement décentralisée, peut-être avec la page elle-même et son JavaScript servi sur IPFS, où chaque message est simplement envoyé directement entre pairs et stocké uniquement dans leurs navigateurs. Il est également possible d'aller plus loin, même en créant des applications où une base de données complète est stockée côté client, avec des modifications synchronisées directement entre les pairs via WebRTC.
Ethereum
Ethereum est une crypto-monnaie largement utilisée, la deuxième après Bitcoin en valeur totale, et traite beaucoup plus de transactions par jour que Bitcoin et la plupart des autres crypto-monnaies populaires (actuellement ~ 1,3 million de transactions par jour, contre ~ 250 000 pour Bitcoin).
La caractéristique la plus notable d'Ethereum va cependant au-delà des simples transferts d'argent : Ethereum peut héberger et exécuter des contrats intelligents, agissant effectivement comme un ordinateur décentralisé. Le code de ces contrats est entièrement public et auditable, et il est exécuté par les mineurs du réseau, qui exécutent le code et l'état de mise à jour sur la blockchain de la même manière qu'ils exécutent les transactions financières demandées et enregistrent le résultat sur la blockchain.
Ceci est important, car il transforme Ethereum d'une simple monnaie en une plate-forme, permettant de stocker et de muter de manière atomique l'état de l'application dans un système entièrement décentralisé, sans serveurs ni points de défaillance uniques requis.
Vous pouvez utiliser les contrats intelligents d'Ethereum pour créer des choses comme des caisses SaaS décentralisées (envoyer X argent à une adresse, votre compte peut désormais utiliser des fonctionnalités payantes), pour transférer de manière atomique des ressources blockchain entre les utilisateurs de votre application, pour créer des systèmes sur lesquels vos utilisateurs peuvent voter. fonctionnalités prévues, ou pour fournir une API qui interroge et expose l'état hébergé par la blockchain de votre application.
Opera et Brave prennent tous deux en charge les portefeuilles Ethereum de manière native, et d'autres navigateurs peuvent le faire à l'aide d'extensions de portefeuille telles que Metamask. Alternativement, les pages peuvent interagir avec le réseau directement via un fournisseur d'API HTTP Ethereum hébergé comme Infura.io.
Notamment, ces clients et d'autres clients Ethereum fonctionnent généralement tous en communiquant avec l'API JSON-RPC d'un nœud Ethereum. C'est devenu une norme de facto, et la même API est également prise en charge par de nombreuses plates-formes similaires, telles que Theta, GoChain, Moonbeam et autres. Bien que ceux-ci ne soient pas la cible principale ici, ils devraient être pris en charge automatiquement, ainsi que toute autre plate-forme future conçue pour prendre en charge la même API.
Il y a une mise en garde ici : Ethereum (et d'autres crypto) a un impact environnemental substantiel que Tim Perry n'est pas désireux d'encourager. Cela dit, Ethereum devrait actuellement passer à la preuve de participation pour réduire considérablement cela très prochainement (la date limite actuelle est décembre 2021).
Quel est le problème aujourd'hui ?
Ces protocoles sont tous très bien en théorie, mais pour le moment, il est très difficile de créer des applications sérieuses, car les navigateurs et autres outils ne fournissent aucun type de support auquel vous êtes habitué lorsque vous travaillez avec HTTP et d'autres technologies dominantes.
Cela signifie que si vous créez une application Web à l'aide de ceux-ci, il est très difficile de déboguer ou de tester. Vous ne pouvez pas facilement :
- voir le contenu des données envoyées via les canaux de données WebRTC, du tout ;
- ajouter de la latence pour découvrir comment votre application gère les récupérations ou les délais d'attente IPFS lents ;
- fractionner un contrat intelligent Ethereum pour effectuer des tests ou un prototypage ;
- remplacer rapidement certains contenus IPFS pour les tests, sans tout republier et sans mettre à jour tous les hachages ;
- arrêter une transaction Ethereum pour tester un autre résultat ;
- injecter un message dans un canal WebRTC.
Pour Tim Perry :
« C'est une douleur énorme, qui crée des frictions constantes, et c'est loin des fonctionnalités auxquelles les développeurs Web sont habitués sur le Web grand public alimenté par HTTP. »
« Ce n'est pas seulement mauvais pour les développeurs cependant. Enquêter sur les applications pour voir ce qu'elles font exactement et fouiller dedans est extrêmement important pour les chercheurs en sécurité et en confidentialité, et sans outil, le trafic pour chacun de ces protocoles est aujourd'hui presque invisible et intouchable. À mesure que leur utilisation augmente, cela pose un risque sérieux pour la recherche de sécurité et la transparence sur le Web. .»
« Heureusement, HTTP Toolkit dispose déjà de la technologie pour prendre en charge ce type de débogage avec HTTP, il est déjà utilisé dans ce type de recherche sur la sécurité et la confidentialité sur le Web d'aujourd'hui, et il devrait être très possible d'étendre cette fonctionnalité pour couvrir ces protocoles décentralisés à l'avenir aussi ».
Comment cela va fonctionner ?
L'idée de base est que HTTP Toolkit s'installera entre votre navigateur et le reste du réseau, et interceptera chacun de ces protocoles et transmettra leurs interactions au reste du réseau, mais vous permettra d'inspecter ces interactions et potentiellement de les modifier. ou injecter des messages en cours de route.
Pour y parvenir, HTTP Toolkit à l'intention de :
Publier des bibliothèques d'interception autonomes
La première étape pour construire ceci est d'étendre Mockttp pour fournir une API pratique que tout le monde peut utiliser pour créer un proxy pour ces protocoles, puis pour vérifier et simuler leurs interactions.
Ces bibliothèques fourniront la base pour la gestion du trafic dans HTTP Toolkit et seront utilisables de manière autonome et autonome (tout comme Mockttp). Cela permet aux développeurs d'applications d'intercepter les interactions IPFS, WebRTC et Ethereum dans leur propre code afin de vérifier et de se moquer du comportement dans les tests automatisés, ou de créer d'autres types de proxys de réécriture automatisés au-dessus de ces protocoles.
Ils seront publiés sous forme de bibliothèques autonomes, une pour chaque protocole. En tant que maquette rapide pour Ethereum par exemple, si la nouvelle bibliothèque s'appelle "Mockthereum" (à confirmer), vous pourrez peut-être écrire du code comme :
Il s'agit d'une simple extension de l'API Mockttp existante, ajoutant simplement une méthode simple pour se moquer des requêtes Ethereum reconnues. Vous pouvez imaginer d'autres méthodes comme :
- mockEthNode.rejectTransactionsTo(address)
- mockIPFSNode.withContent(hash, content)
- mockWebRTCPeer.echoAllMessages()
Intercepter automatiquement le trafic
Avec les bibliothèques autonomes, HTTP Toolkit pourrait inspecter et transformer le trafic une fois qu'il lui parviendra, mais devra toujours rediriger le trafic vers ses proxys pour le faire.
Les étapes pratiques de mise en œuvre qui sont :
- injecter la configuration dans les navigateurs cibles pour proxy le trafic HTTP d'Ethereum et IPFS via HTTP Toolkit au démarrage ;
- créer une extension de navigateur interceptant WebRTC ;
- injecter l'extension WebRTC dans les navigateurs pour intercepter les connexions WebRTC p2p.
Avec cela en place, pour tout navigateur lancé, Ethereum, IPFS et WebRTC fonctionneront tous exactement comme d'habitude, mais tunnellisés via un code qui peut librement transformer et inspecter tout ce qu'ils font. Les requêtes HTTP brutes pour Ethereum et IPFS apparaîtront immédiatement dans HTTP Toolkit, et les requêtes WebRTC seront proxy transparentes, mais invisibles.
Construire une interface utilisateur pour explorer le trafic collecté et définir des règles pour le transformer
Un
e fois que tout le trafic est sous notre contrôle, HTTP Toolkit peut commencer à faire des choses avec. Voici quelques maquettes rapides
Ci-dessous, vous pouvez voir le trafic d'une application Web qui utilise HTTP, IPFS, WebRTC et Ethereum, étendant l'interface utilisateur existante de HTTP Toolkit pour afficher les interactions de tous ces protocoles avec leurs métadonnées clés, le tout au même endroit :
De plus, l'interface utilisateur du générateur de règles de HTTP Toolkit sera étendue pour exposer les gestionnaires d'interaction de chaque bibliothèque autonome dans l'interface utilisateur :
N'oubliez pas que ce sont des maquettes ! L'interface utilisateur réelle variera.
Quand ?
Tim Perry indique une implémentation prévue au cours des prochaines semaines. La première étape consiste à mettre en place une feuille de route détaillée avant octobre de cette année, puis le projet se déroulera sur un an jusqu'en octobre 2022.
Source : HTTP Toolkit
Et vous ?
Que pensez-vous du programme NGI-POINTER de l'UE ? Que pensez-vous de HTTP Toolkit ? Que pensez-vous de ces différents protocoles (Ethereum, IPFS, WebRTC) ? Quelle lecture faites-vous de ces informations ?