You only need your browser
No installation - No plugins
Easy to use
Safe and secure
See also:
Torrent-live: anti-spies, private torrents and dynamic blocklistThat's it, as simple, this will launch Peersm client in background, your files can now be downloaded by others anonymously for both and you are relaying anonymously bittorrent files for others.
For non windows system, please see Install Peersm client on Mac or Linux
Target - Serverless P2P
Peersm and Bittorrent
contact (at) peersm.com - Copyright © 2015 Peersm | Torrent blocklist | Burnett's 10 Million passwords
Utilisez juste votre navigateur
Pas d'installation - Pas de plugins
Facile à utiliser
Sûr et sécurisé
Voir aussi :
Torrent-live: anti-spies, private torrents and dynamic blocklistAussi simple que ça, ça lancera le client Peersm en tâche de fond, vos fichiers pourront être téléchargés par les autres de manière anonyme, autant pour vous que pour eux, et vous relayez anonymement pour les autres des fichiers bittorrent.
Pour les autres systèmes que Windows, voir Installer le client Peersm sur Mac ou Linux
Cible : un réseau P2P sans serveurs
Peersm et BitTorrent
contact (at) peersm.com - Copyright © 2015 Peersm | Torrent blocklist | Burnett's 10 Millions de mots de passe
The above image is often used to describe the problem:
It's still valid today: you can not easily exchange information without using a third party that might do something with it without your permission.
But that's not the only issue, most of existing systems do not protect you from being tracked and spied and do not protect your privacy, the systems that allow it are usually not easy to use.
P2P projects are great, but there is a technical inconvenient that you can not circumvent: the peers must know the IP addresses of each other, if not they can not communicate.
So, it's easy to know what you are doing, there is nothing you can do about this. Even worse, anybody can track you, not only some authorities or people that can ask your ISP.
That's why me made Peersm, it does allow to exchange anonymously information between peers or from the internet directly from your browser, the information is then distributed inside the browsers storage, the Peersm clients, the bittorrent network and can be shared between peers, the difference compared to current P2P systems being that nobody knows what you have and what you are doing.
The stream button does allow to stream anonymously audio and video files. You can send the video to your TV using for example Chromecast and the Cast extension for Chrome.
The peersm clients are facilitators that are doing what the browsers are doing but outside of them as background processes, so you can continue to share files if you close your browsers.
In addition they implement a bittorrent client and they bridge Peersm and torrents world, they are talking bittorrent and relaying the data to the anonymous peers that requested them, they do not become the seeders (ie they do not store the files) so people can not know what they have, the requesting peers become the seeders in Peersm world.
The rationale to use Peersm clients is that browsers can not talk directly to bittorrent clients, they are very easy to install and run (Window, Mac, Linux), please see Peersm client installer
For phase 1, the peers can download from different peers but as far as the initial source does not fail the download is performed from that one, the system switches to other peers only if the serving source fails.
Phase 2 is introducing download from different peers at the same time with support of several ORDBs. Files are sliced into small blocks retrieved from the peers, it is designed to allow normal and continuous streaming.
In addition each peer is now implementing inside his browser the functions of the anonymizer nodes and ORDBs, so any peer can become an anonymizer node or an ORDB.
The peers are now communicating using WebRTC (Web Real Time Communication) technology. No servers are required any longer, the peers are introducing themselves to each other, they are anonymizing and routing the traffic for each other.
This makes a complete serverless anonymous P2P system that can not be stopped.
For direct download (ie not P2P), Peersm and Tor nodes are still used.
Distributed inside browsers, Peersm clients, bittorrent network and the Web.
"Inside browsers" just means that downloaded or uploaded files are stored to a place on your disk that your browser can access, and therefore Peersm application, of course it is secured so other sites or apps can not access it. The contrary (ie copying from your browser storage to your disk) of course works too.
The advantage of using browsers is that they are on any device, easy to use and secure, no installation, they can now be used to relay data and replace servers..
Peersm concepts are a mix of Tor, I2P, Freenet and P2P projects like torrents, so Peersm does not work like Tor and is not Tor.
Peersm has chosen to use the Tor protocol which is known to be robust to secure the communications and to extend it to support P2P. Another advantage is to be able to use the existing Tor nodes and the existing Tor bridges supporting WebSockets.
Peersm is adding its own implementation of independent nodes into the network, bridges supporting WebSockets (see Peersm Bridges), normal Tor nodes and Peersm nodes.
Peersm is independant from the official Tor packages and the Tor Foundation.
If you are really interested to understand why, please take a look here.
The process right now is secured by another mechanism using encryption keys, in addition the application can work as a standalone one, so no need to retrieve the code from a server.
It's difficult to find a free domain name including 'peer' or 'peers', then we thought to 'Peersm' because it was available and if you change the place of the r you get its contrary: 'Prism', the NSA program.
In addition, the below geometrical figure is an antiprism polyhedron, this symbolizes the Peersm system defeating Prism or Prism like programs.
The application is a javascript one, so the code is visible inside your browser or here node-Tor, therefore it's quite easy to check what the application is doing, moreover if the debug mode is activated you see all the details where the application is connecting to and what nodes are used to substitute your real IP address.
Hash_names are used to identify a download, they are similar to infohash (magnet links) used in bittorrent network.
You can encrypt files that you have downloaded or uploaded, in that case you will get a private encryption key not known by anybody
The sender must provide to receivers the hash_name, the encryption key and the extension of the file.
Nothing, the messages flow of Peersm is described by the below image:
Peersm is based on the concept that you can only trust yourself, as explained in the following paragraph any strange thing that could do Peersm is quite easy to detect.
You can trust browsers (assuming you have deactivated some tracking default options) because they are so widely used that any defect, security leak or suspicious behavior is immediately detected by the community, reported publicly and corrected by browser vendors. They cannot afford to ignore it. Same goes for javascript. In addition, javascript code cannot be hidden so what Peersm is doing is more transparent than something that comes with an installation package, even from open source projects.
Detractors saying that javascript is insecure are just misinformed and not aware of common knowledge and best practices.
You can run a Peersm Bridge based on our implementation, very easy and simple to install and run, please see Installing node-Tor Bridge
It's advised to use the port 80 or 443 for WebSockets so the routers can be reached from any network (university, etc)
Then you give us the information about your router and we include it in the Bridges list.
You can run Peersm clients too and put/duplicate content inside to share it with others and bridge with bittorrent network, please see Installing Peersm client.
For the complete specifications and technical details, please look at node-Tor/Peersm on git
Distributing and accessing data inside browsers is of course not a unique idea of us, imagine how this is powerfull given the number of browsers in the world (2 Billions), see some other projects using this concept:
L'image ci-dessus est souvent utilisée pour résumer le problème.
C'est toujours vrai de nos jours, on ne peut pas facilement échanger des informations sans passer par un tiers qui pourrait utiliser ces informations à notre insu.
Mais ce n'est pas le seul problème, la plupart des systèmes ne protégent pas votre vie privée et n'empêchent pas d'être suivi ou espionné, ceux le permettant sont généralement inaccessibles en terme d'utilisation pour tout un chacun.
Malgré tous les avantages des projets P2P il existe un inconvénient qui pour des raisons techniques ne peut être contourné : les peers doivent connaitre leurs adresses IP respectives, sinon ils ne pourraient pas communiquer.
Donc il est facile de savoir ce que vous faites, rien ne peut l'empêcher, d'autant plus que n'importe qui peut vous tracer sans même avoir besoin d'avoir recours à votre fournisseur d'accès.
C'est pourquoi nous avons fait Peersm, Peersm permet d'échanger anonymement des informations sur internet ou entre les personnes directement à partir de son navigateur, l'information est alors distribuée dans les navigateurs, les clients Peersm, le réseau bittorent et peut être partagée entre les personnes, la différence étant par rapport aux systèmes P2P courant que personne ne sait ce que vous avez et ce que vous faites..
Le bouton 'Stream' permet de streamer anonymement des fichiers vidéo et audio. Vous pouvez envoyer le flux sur votre télé en utilisant par exemple Chromecast et l'extension Cast de Chrome.
Les clients Peersm sont des facilitateurs qui font la même chose que les navigateurs mais à l'extérieur en tâche de fond, ils permettent de continuer à partager des fichiers si vous fermez votre navigateur.
Ils contiennent en plus un client bittorrent qui permet de faire la passerelle avec le monde bittorrent, dans les deux sens, ils parlent bittorrent et relaient les données anonymement à ceux qui les ont demandées, ceux-ci deviennent alors les "seeders" dans le monde Peersm. Les clients Peersm ne deviennent pas les seeders (donc ne sauvegardent pas ce qu'ils relaient) afin que l'on ne sache pas ce qu'ils ont.
La raison d'utiliser les clients Peersm comme intermédiaires est que les navigateurs ne peuvent pas parler directement aux clients bittorrent, ils sont très faciles à installer et à utiliser (Windows, Mac, Linux), voir Installer un client Peersm
Pour la phase 1, les peers peuvent télécharger à partir de différents peers mais lorsqu'un téléchargement commence il se fait à partir d'un peer sélectionné au hasard, c'est seulement si un problème survient que le système choisit d'autres peers pour continuer le téléchargement.
La phase 2 introduit le téléchargement parallèle à partir de différents peers et de différents ORDBs. Les fichiers sont découpés en blocs de petite taille récupérés des peers, le système est prévu pour permettre le streaming normal ou continu.
Chaque peer implémente aussi maintenant dans son navigateur les fonctions des noeuds anonymisants et des ORDBs, donc chaque peer peut devenir un noeud anonymisant ou un ORDB.
Les peers communiquent en utilisant la techno WebRTC (Web Real Time Communication).
Le système n'a plus besoin de serveurs, les peers font connaissance entre eux, ils anonymisent et routent le trafic les uns pour les autres.
Il s'agit donc d'un système pur P2P anonyme sans serveurs, un système qui ne peut pas être stoppé.
Pour le téléchargement direct (donc non P2P), les noeuds Peersm et Tor sont toujours utilisés.
Distribués dans les navigateurs, les clients Peersm, le réseau bittorrent et le Web.
"Distribués dans les navigateurs" signifie tout simplement que les fichiers téléchargés sont stockés dans un endroit sur votre disque auquel le navigateur a accès et donc l'application Peersm, évidemment c'est sécurisé pour que d'autres applications web ou sites n'y ait pas accès. La manipulation inverse (ie copier de son navigateur vers son disque) fonctionne aussi évidemment.
L'avantage d'utiliser les navigateurs est qu'ils sont présents sur tous les équipements, faciles à utiliser et sécurisés, pas d'installation, ils peuvent maintenant être utilisés pour relayer des données et remplacer les serveurs.
Les concepts de Peersm sont un mixte des projets Tor, I2P, Freenet et P2P comme les torrents/emule, donc Peersm ne fonctionne pas comme Tor et n'est pas Tor.
Peersm a choisi d'utiliser le protocole Tor qui est connu pour être robuste pour sécuriser les échanges et de l'étendre pour supporter le P2P. Un autre avantage est de pouvoir utiliser les noeuds Tor existant et les bridges Tor existant supportant les WebSockets.
Peersm ajoute des noeuds indépendants basés sur sa propre implémentation dans le réseau Tor, des bridges supportant les WebSockets (voir Bridges Peersm), des noeuds Tor normaux et des noeuds Peersm.
Peersm est indépendant des packages officiels Tor et de la Fondation Tor.
Si vous voulez vraiment savoir pourquoi, regardez ici.
Le processus est sécurisé par un autre mécanisme utilisant des clés de chiffrement, d'autre part l'application peut fonctionner de manière autonome dans les navigateurs sans avoir à charger le code d'un serveur.
Il est difficile de trouver un nom de domaine contenant 'peer' ou 'peers', donc nous avons pensé à 'Peersm' parce que le domaine était disponible et si vous changez la place du r vous obtenez son contraire : 'Prism', le programme de la NSA.
La figure géométrique ci-dessous est un polyèdre antiprisme symbolisant le système Peersm mettant en échec Prism et les programmes équivalents.
Peersm est une application javascript, donc le code est visible à l'intérieur de votre navigateur et est public ici : node-Tor, ainsi il est très facile de voir ce que l'application fait, de plus l'application fournit tous les détails quant aux noeuds utilisés pour substituer votre adresse IP réelle..
Des Hash_names sont utilisés pour identifier un téléchargement, ils sont similaires aux infohash (magnet links) utilisés par bittorrent.
Vous pouvez chiffrer les fichiers que vous avez téléchargés dans votre navigateur, dans ce cas le système générera une clé connue de vous seul. L'émetteur doit envoyer au destinataire le hash_name, la clé de chiffrement et l'extension du fichier.
Rien du tout, le flux des messages est décrit dans l'image ci-dessous :
Peersm est basé sur le concept que vous ne faites confiance qu'à vous même, comme expliqué ci-dessous tout ce que Peersm pourrait faire d'étrange ou de suspect serait facilement détectable.
Vous pouvez faire confiance aux navigateurs (après pour certains avoir désactivé les options de tracking par défaut), car ils sont tellement répandus et utilisés que le moindre défaut ou problème de sécurité est détecté par la communauté, reporté publiquement et corrigé par les navigateurs. Ils ne peuvent pas se permettre de les ignorer. Il en va de même avec javascript. De plus le code javascript ne peut pas être dissimulé, il est donc plus transparent qu'une quelconque installation sur votre poste, même s'il s'agit d'un projet libre.
Certains détracteurs prétendant que javascript ne serait pas sécurisé sont mal informés, ignorants des pratiques courantes et de l'état de l'art.
Et, à nouveau, les ORDBs ne savent pas du tout à qui ils parlent ni ce qu'ils relaient.
Vous pouvez opérer un Bridge Peersm basé sur notre implémentation, trés simple, très facile à installer et à opérer, voir Installer node-Tor Bridge
Il est recommandé d'utiliser les ports 80 ou 443 pour les Bridges WebSockets afin qu'ils puissent être accessibles depuis n'importe quel réseau (universités, etc)
Vous nous envoyez alors les informations sur votre Bridge et nous l'ajoutons à la liste.
Vous pouvez installer des clients Peersm aussi et mettre/dupliquer des contenus pour les partager avec d'autres et faire le lien avec le réseau bittorrent, voir Installer un client Peersm.
Les spécifications complètes et les détails techniques sont sur: node-Tor/Peersm on git
Distribuer et relayer des données dans les navigateurs n'est évidemment pas une idée que nous sommes les seuls à avoir eue, à nouveau imaginez le potentiel avec aujourd'hui 2 Milliards de navigateurs dans le monde, d'autres projets utilisent le même concept :
Peersm is supporting adaptive streaming, if you want to know how to add a streeming media, please see at the end of this section.
| Hash_name (copy and paste) | Title |
|---|---|
| Any mp4 or webm file from Peersm, bittorrent or the web Use the infohash or magnet link for torrent files |
|
| magnet:?xt=urn:btih:AD51323FAC3285A981F3CDA21A7FAA061E5765C4 or magnet:?xt=urn:btih:49C338AA58DEE04262DEC7AE42D6FD48962C16A5 |
Star wreck: in the pirkinning 1h45 movie (creative common license) Stream from bittorrent network |
| 23f00f350c582a22ef88586f7eb5750ff0280ff0 (850 kbps) or e6fe169ee596322a73fba7ef95aeb480baee51a9 (600 kbps) |
Star wreck: in the pirkinning 1h45 movie (creative common license) Stream from Peersm network |
| 690660383ecfbf31f4bd694611f54ca659b3115c | Gravity official trailer Thanks to StreamRoot for the files |
| b7cf045231e98a0830eca886aa5dc05ac591ba0a | Youtube Google car video Direct download from youtube site |
You can send the video to your TV using for example Chromecast and the Cast extension for Chrome.
| Hash_name (copy and paste) | Title and file hash | Rename as | Size |
|---|---|---|---|
| http://www.peersm.com/map.jpg | Simple map | jpg | 1.1 MB |
| 6faddcd7f92ce3111cdf55f493ac66b0bdbaebdb | Simple map | jpg | 1.1 MB |
| bfee6892dd7a1cc5c167aa00f4d0544fc8549e22 | Collusion demo video | mp4 | 12 MB |
| 9883d361356345fb4b75910c425d320be487e64a | Peer-to-Peer Applications - From BitTorrent to (no) Privacy (INRIA A. Legout) | pptx | 13 MB |
| dceda85ea9b3a264d7ef530194d877575ed76296 | Apple iphone outstanding enrollment procedure | mp4 | 15 MB |
| a4716fa99cd3db4312c378154c8e8dcb0f9d9c6a | Free software for agriculture (Windows) - activation key: 20130318113224ess | exe | 26 MB |
| e01108a36227afffbf28a5a9797133e7316cd53a | Via'AGRI - User manual | 229 MB | |
| d722b248098062b81927ba5c97fe016f7a5581e3 or magnet:?xt=urn:btih:ef330b39f4801d25b4245212e75a38634bfc856e |
Star Wreck: in the pirkinning (Creative Common license) | avi | 541 MB |
| c3d31cc42c3e4b59d962b778fa5e0980e46d0153 |
Our videos - Seasons 2005-2014 | zip | 1 GB |
Tip: in order to keep the same hash_name that you have advertised for a file that you might have deleted from your browser storage or from your Peersm client and that you want to put back, rename the file on your computer before proceeding as: original_file_name#hash_name.ext
Unfortunately the "Web" has not foreseen to do usual streaming, what has been foreseen is to perform adaptive streaming, so the video files must have the corresponding format.
Peersm adapts automatically the format of usual audio/video files, but it can happen that the original file is not compatible, you can process this file as explained below.
Without being a video expert you can use ffmpeg and run the following very intuitive command:
This will create a .webm file that you can put in your Peersm client or that you can seed in bittorrent network.
If you want to know more about the above command, please take a look at Big Buck Bunny.
If you know something about adaptive streaming, then you can create a video.json file like:
Or for a webm file:
Or if files are on a web site:
Where the Representation fields match the tracks that you have in your video and the BaseURL is the hash_name of the media files in your Peersm client, or their infohash in bittorrent network (hash part of the magnet link) or their URLs.
Supported formats are mp4 and webm, you can use ffmpeg and MP4box to manipulate your files, the codecs used must be supported by the browsers.
The files must be fragmented, the typical command to achieve this is: MP4Box -dash 500 -frag 500 -rap video.mp4
Then put the video.json file in your Peersm client, this will become video#hash_name.json, or seed it in bittorrent, use the hash_name or infohash to stream the video.
Peersm supporte le streaming avec adaptation à la bande passante, voir à la fin de cette section comment ajouter un média.
| Hash_name (copy and paste) | Title |
|---|---|
| N'importe quel fichier au format mp4 ou webm, du réseau Peersm, bittorrent ou du web Utilisez l'infohash ou le lien magnet pour les torrents |
|
| magnet:?xt=urn:btih:AD51323FAC3285A981F3CDA21A7FAA061E5765C4 ou magnet:?xt=urn:btih:49C338AA58DEE04262DEC7AE42D6FD48962C16A5 |
Star wreck: in the pirkinning 1h45 movie (creative common license) Streaming avec le réseau bittorrent |
| 23f00f350c582a22ef88586f7eb5750ff0280ff0 (850 kbps) or e6fe169ee596322a73fba7ef95aeb480baee51a9 (600 kbps) |
Star wreck: in the pirkinning Film de 1h45 (licence creative common) Streaming avec le réseau Peersm |
| 690660383ecfbf31f4bd694611f54ca659b3115c | Gravity official trailer Merci à StreamRoot pour les fichiers |
| b7cf045231e98a0830eca886aa5dc05ac591ba0a | Youtube Google car video Téléchargement direct depuis le site youtube |
Vous pouvez envoyer la vidéo sur votre télé en utilisant par exemple Chromecast et l'extension Cast de Chrome.
| Hash_name (copier/coller) | Titre et hash | Renommer en | Taille |
|---|---|---|---|
| http://www.peersm.com/map.jpg | Simple map | jpg | 1.1 MB |
| 6faddcd7f92ce3111cdf55f493ac66b0bdbaebdb | Simple map | jpg | 1.1 MB |
| bfee6892dd7a1cc5c167aa00f4d0544fc8549e22 | Collusion demo video | mp4 | 12 MB |
| 9883d361356345fb4b75910c425d320be487e64a | Peer-to-Peer Applications - From BitTorrent to (no) Privacy (INRIA A. Legout) 14a4bdc3ff0542d1aa1818dae3c84055534e9adf |
pptx | 13 MB |
| dceda85ea9b3a264d7ef530194d877575ed76296 | Apple iphone outstanding enrollment procedure | mp4 | 15 MB |
| a4716fa99cd3db4312c378154c8e8dcb0f9d9c6a | Free software for agriculture (Windows) - activation key: 20130318113224ess | exe | 26 MB |
| e01108a36227afffbf28a5a9797133e7316cd53a | Via'AGRI - User Manual | 229 MB | |
| d722b248098062b81927ba5c97fe016f7a5581e3 or magnet:?xt=urn:btih:ef330b39f4801d25b4245212e75a38634bfc856e |
Star Wreck: in the pirkinning (Creative Common license) | avi | 541 MB |
| c3d31cc42c3e4b59d962b778fa5e0980e46d0153 |
Our videos - Seasons 2005-2014 | zip | 1 GB |
Astuce: si vous voulez garder le même hash_name qui est déjà connu pour un fichier que vous auriez enlevé de votre navigateur ou de votre client Persm et que vous voudriez remettre, il suffit de renommer le fichier avant de le remettre à disposition en : original_file_name#hash_name.ext
Malheureusement le "Web" n'a pas prévu que l'on puisse faire du streaming classique, ce qui a été prévu c'est de faire du streaming avec adaptation à la bande passante, donc les fichiers vidéo doivent être adaptés en conséquence.
Peersm adapte automatiquement ces fichiers, mais il se peut que le fichier d'origine ne soit pas compatible, dans ce cas vous pouvez le formater comme expliqué ci-dessous.
Sans avoir besoin d'être un expert vidéo vous pouvez utiliser ffmpeg et lancer la commande super intuitive suivante:
Ca va créer un fichier .webm que vous pouvez mettre dans votre client Peersm ou seeder via bittorrent.
Si vous voulez en savoir plus sur la commande ci-dessus, vous pouvez aller voir Big Buck Bunny.
Si vous vous y connaissez en adaptive streaming, vous pouvez créer un fichier video.json comme suit:
Ou pour un fichier webm:
Ou si les fichiers sont sur le web:
Où les champs Representation donnent les infos concernant les différentes pistes de la vidéo et le champ BaseURL correspond au hash_name des fichiers contenant ces pistes dans votre client Peersm, ou bien leur infohash dans bittorrent (la partie hash du lien magnet) ou bien leurs URLs.
Les formats supportés sont mp4 et webm, vous pouvez utiliser ffmpeg et MP4Box pour manipuler vos fichiers, les codecs utilisés doivent être supportés par les navigateurs.
Les fichiers doivent être fragmentés, la commande habituelle pour réaliser cela est : MP4Box -dash 500 -frag 500 -rap video.mp4
Mettez ensuite le fichier video.json dans votre client Peersm, il sera renommé en video#hash_name.json, ou bien sur bittorrent, utilisez ce hash_name ou bien le infohash pour streamer la vidéo.
This section is a compilation of the technical questions that we have received from different sources and our answers, we took it from the original text so there are some duplicates sometimes
A Standalone application inside browsers available on any device equipped with a modern browser, fix or mobile. That's not really a web app in the sense that it does not discuss with a web server but communicates independantly with the outside.
We mean two things by "standalone":
The app can be loaded directly inside its browser without the need of a server to load the code
The app works alone inside browsers, it does not need any server, like a firefox os app or a chrome app, the difference is that for Peersm it is designed to work in any browser, fix or mobile, and does not depend on any system, OS or specific browser.
It requires a browser that supports the latest HTML5 APIs (File, IndexedDB, WebCrypto, WebRTC, Media Source extensions) or a platform that supports the same functionalities than browsers or equivalent (firefox OS, Chrome OS, nodejs).
The Peersm clients, which are doing the same than browsers (reminder: they are used to maintain the continuity of the service in case not enough peers have their browser open) are based on nodejs and work on any platform supporting nodejs (PC, Mac, Linux)
Anyone can be concerned to exchange sensitive, private or public data (family, medics, lawyers, journalists, media, etc), it does not exist and is not even specified in any research/white paper.
The keys and certificates are ephemeral (ie they change each time the users launch the app), therefore they are not stored anywhere. As explained here: Id and Onion keys keys management follows the WebCrypto rules:
"In WebCrypto the keys are handled in an opaque format, you can not access them and you can not export them if extractable is false, except the public key whose extractable parameter is always true (fingerprint=exportKey(spki)+digest(), modulus: RsaKeyAlgorithm object that hangs off Key.algorithm). Keys do support the structured clone algorithm, so could be stored in indexedDB but, even if expensive, we generate a new pair for each session so users ID change and users can not be tracked based on their keys"
If WebCrypto is not to be used or not available, the keys just stay in memory during their lifetime and are not available from anything outside of the Peersm application.
WebSockets are used to allow the browsers to communicate with the outside world, typically for Peersm they allow to establish anonymized circuits with the Tor network for web fetching.
WebRTC is used so browsers can communicate and establish anonymized circuits between each others to exchange data, that's the only means available for browsers to discuss directly with each other, they can not do this using WebSockets.
So both are complementary for different purposes.
Yes for the P2P exchanges. The Tor network is far too small to envision any P2P system on top of it. So the peers in Peersm are implementing the Tor protocol and then constituting another "Tor network" (but not centralized as the Tor network is).
The legacy Tor network is only used to fetch the Web, which is a marginal case, the peers are connecting to the Tor nodes using WebSockets.
Peersm passes easily the great china firewall, browsers are difficult to block, because they change IP addresses often (as users behind a common ISP NAT) and they are using protocols that are widely used, censors could block the WebSocket and WebRTC protocols but they then take the risk to block a lot of other things, as of today nothing show that they are in a process to block such protocols.
Please see French Numerama article and the comment "Ça marche très bien de Chine, ça passe le grand firewall chinois sans problèmes." ("It's working very well from China and passes the great China firewall without any problems"), following this article some people based in China just tried it right away from there.
But it's not a surprise, it's unlikely that China or anybody else blocks entirely WebSockets and WebRTC.
The initial peers returned by the bridge could be compromised, therefore they could send only compromised peers.
But your ID does change for each session then if the peers are continuously returning peers that do not seem close enough to your ID, you could detect that they are compromised.
We have a study here ongoing to see how the bittorrent spies do behave, but unlike bittorrent it is not possible for peers that would like to compromise the DHT to choose their ID since it is the fingerprint of their public key.
The DHT represents the public table of all the peers, it's unlikely that it's entirely compromised.
If you don't trust the bridges you can choose your peers "manually" or use the peers introduction feature of the WebRTC DHT.
The users keys can not be accessed or used by a potential attacker.
WebRTC is using self-signed certificates for DTLS, these certificates are changed so you can not be tracked, the SDP (peer introduction) does include the fingerprint of the certificate, this is not enough to guarantee that there is not a MITM peer in the middle. Therefore the specifications are foreseeing to add another mechanism where the fingerprint of the DTLS certificate will be signed by a third party that knows you, typically a social network where you have an account.
This is of course far from protecting your anonymity and privacy and can not be used in Peersm context, so Peersm is using the Tor protocol Certs cells mechanism to make sure that you are talking to the peer with whom you have established the DTLS connection. This peer can still be a MITM but since you are extending the circuit to another peer known in the DHT, per the Tor protocol the possible MITM will not know what happens next, as mentionned above it becomes unlikely that the second peers are all compromised.
For the general principles, please see this discussion on webp2p mailing list Serverless Peersm and WebRTC
To summarize I was questioning in this discussion the assumptions that were made by others that WebRTC could really be serverless for the peers introduction, until I realized that this was quite simple: as illustrated in the thread you just need to get the peer information for only one peer which will then introduce others she knows.
These are the concepts of the "WebRTC DHT" where the peers can introduce each other without needing the bridges, the WebRTC introduction mechanism is just about passing a message (SDP offer) to the target and passing the reply (SDP answer) the other way, by any available means (bridges, peers, social network, etc), so here using the peers to relay the introduction messages.
In the case of Peersm, you just need a means to pass a SDP offer to one peer and get its SDP answer, this peer which will be the bootstrap peer and will let you know about others.
So, if the Peersm bridges are blocked, not accessible or suspicious, you can use any other means available (sms, email like the Tor project is doing for bridges discovery, twitter, fb, etc) to exchange the SDP messages and connect to one trusted peer which will then tell you about others.
If we compare to all the attacks/threats studied in the context of the Tor network for example, most of them can not apply to Peersm. Because most of the attacks are linked to the inherent dangerousness of browsing the web and related implications (code injection to deanonymize you, etc), Peersm does not browse, just fetches, which is very different.
You could fetch something bad which could hurt you, but that would be more a user mistake rather than a weakness of the system itself, for regular content the system validates the pieces, so bad content can not be injected.
If we take the correlation attacks where several peers in the path are colluding to deanonymize you, as explained here: Security
"The initial peers returned by the bridge could be compromised, therefore they could send only compromised peers.
But your ID does change for each session then if the peers are continuously returning peers that do not seem close enough to your ID, you could detect that they are compromised.
...
Peersm is using the Tor protocol Certs cells mechanism explained above to make sure that you are talking to the peer with whom you have established the DTLS connection. This peer can still be a MITM but since you are extending the circuit to another peer known in the DHT, per the Tor protocol the possible MITM will not know what happens next, as mentioned above it becomes unlikely that the second peers are all compromised."
Indeed, since the fingerprint of the peers are the fingerprint of their public key, they can not choose it to spoof the peers database, or at least we don't know how to do this, even if one peer is a compromised one, it can not continuously return bad peers in order for your path to go through colluding peers, then it will just be one bad peer in the path that will just not know what happens per the Tor protocol.
An attacker can know about the peers participating to the network (but not necessarily all since some can hide for manual selection as explained previously), but has no way to know what they are doing.
In the Tor network, the exit nodes are the possible MITMs per excellence (and design), therefore in Peersm network the peers relaying the data for others could be the MITMs too, but since the reference of the content (hash_name) is linked to the initial seeder's keys, they can not spoof the content. If the initial seeder did not use Peersm feature to add another encryption layer to the content, they can see it in the clear but again don't know where it's coming from and where it's going.
The only way for censors to block Peersm would be to completely block WebSockets and WebRTC, which seems unlikely.
And up to now, the main threat we can see would be a browser and/or windows/OS bug, but even for this case we don't really see how it can hurt you more than locally, ie breaking something on your device but without deanonymizing you.
The service is not centralized at all. The first point of contact to retrieve the app is indeed the Peersm servers, which can be easily blocked.
That's why we introduced the concept of the standalone app explained above, the code does not need to be retrieved from Peersm servers but from any other available places (mirrors, email, etc) where the code has been validated.
Please take a look at this thread Liberationtech 1 where (aggressive and misinformed people) are trying to challenge these principles, without success: Liberationtech 2 and Liberationtech 3
Please note that we do explain jointly with the code loading "issue" (which we show is not specific to Peersm but applies to any project) the possibility for people to check precisely what the Peersm code is doing, since it's a javascript one and can not be hidden.
No but everything is public and we are communicating about it on many mailing lists ready to challenge the concepts.
And we have presented it to different research team/people.
We did not get so far any negative comments, apparently most of the people find the concepts very interesting.
Except the traditional comment, which applies to any project: we must load the application (here the javascript code), how to be sure we get the right one?
There are no technical solutions for this issue, except checking with third parties we trust through different channels that we have the right code, Peersm will provide a package so the code does not have to be necessarly loaded from the Peersm site.
On another hand, even if not open source for now, the code is public, and as a javascript code it is trivial for any serious javascript dev to check what it is doing.
This discussion or this one can show how some people supposedly experts can be wrong about this topic.
Currently the code is visible but not open source, although it has been requested many times. In the context of a project like Peersm we think it has to become open source at a certain point of time.
But the project is free of charge for the users and would be free of charge for other projects using the same code, we would like to insure the sunstaibality of the project and related investments since two years, so the project (and the underlying techno node-Tor will be open source once we have reached our funding target.
Maybe we can get some help from people working on other WebRTC projects to have real peers but the plan is to emulate numerous WebRTC peers using the Peersm clients running as numerous processes on our servers, the test environment in question would be something like 1000 peers.
The intent of Peersm is an anonymous bittorrent network distributed inside browsers, this is new and the state of the art regarding this matter is quasi null, so for now we would recommend to use it for “normal” things, if people risk their life they should not use it. So we can not guess neither test all the threats but from previous research on the Tor and bittorrent networks we can know what they could be for some.
For Peersm the threat model is different, Peersm does not browse which eliminates most of the issues that the Tor network has, it is not centralized like the Tor network and the expected size of the network is much bigger, it’s globally an advantage which makes difficult massive attacks such as correlation/sybil/fake/spoofing attacks but it can turn into a disadvantage when it comes to detect more subtle attacks.
Some concepts in Peersm are really new, unlike the Tor network there are only two hops between the peers and there are no guards concepts, because as explained in the specifications node-Tor more than two hops for a p2p system seems unlikely, but we can revert to three if it appears necessary, the guard concept is not necessary for two hops and it’s difficult for the peers that can not choose their fingerprints to constantly propose themselves as a close peer. This is discussed here: tor-talk - I have a quick question about security of tor with 3 nodes and we can see from the Tor project members comments that the guards/3 hops concepts are not totally determinist, and despite of their opinion in this thread it matters that a node knows that it is the first one, because it can deanonymize those that are connected to it, that’s why Peersm will not use the CREATE_FAST cells, the nodes can not know in what position they are (unlike the Tor network the first node can not check among a finite known list of relays if the previous one is a relay or an user).
As detailed in the spec, two hops is not necessarily the path that will follow the messages, the content discovery system (which is not the DHT only) makes that a queried peer can extend the path to others it is connected too and ultimately extend to new connections, limited to 5 more hops, it makes it very difficult to trace.
Maybe one threat not clearly detailed is the possibility of spoofing/polluting the network (ie a Sybil like attack) since in Peersm network the peers that are announcing things are doing this for others, unlike the bittorrent network where it’s impossible for common users to announce for others, so some attackers could attract other peers by announcing what they are expecting.
I have a study ongoing on the bittorrent network with torrent-live for this case that I will release soon, it is about discovering, following and blocking all the spies in the bittorrent network, the same approach will be used for Peersm, please see below for the Sybil attack question.
The webRTC DHT concepts are new too, it does not exist, the purpose of it is to modify the usual DHT behavior so peers can introduce each others without needing servers.
So, probably the threats issues will be empirical, it’s difficult to guess what years of research on the Tor network has still not solved, and we can notice that years of research on p2p projects only succeeded to ship something not even doing what Peersm is already doing, but I don’t think that extending the current bittorrent protocol for Tor use is a good idea, a new protocol like Peersm capable of bridging with the current bittorrent network should replace it, and maybe some Peersm concepts can be reused for bitcoins.
Not sure what is meant here. Peersm is sandboxed inside browsers, if the browsers leak then the attacks can leak.
As explained above Peersm is different from the Tor network and these concepts do not apply, Peersm is a totally decentralized, uncontrollable and unstoppable network.
If the authorities can monitor and recognize the traffic as a Peersm one, then there is nothing to do except using more obfuscation means, this does not really matter in this case whether the user is a relay too. The list of relays is not centralized like the Tor network, so not easy to get as a whole, but the authorities could walk the DHT and collect the peers. Now they all act as users/relays/exit, modifying this behavior would allow the peers to freeride and the network will stop working. So, it seems difficult for a decentralized system to split the users and relays functions, or it would be something like the current Peersm release (ie with well-known relays), how to choose those that will be relays and those that will be users only?
The Tor project has the same problem with their flash proxies where it’s trivial to get the users identities by polling the facilitators, which I have verified for real and is explained here: Client enumeration p13, the paper explains that the attack can be mitigated by running a lot of proxies, in theory, but the paradox is that those that are using flash proxies are really those that are censored, and their IP addresses are much more exposed than all other users, everybody can get it, so maybe that’s not an issue, as explained above the Tor relays can easily enumerate clients too.
A peer session time will be how long a peer has a tab open in its browser running Peersm. Since each peer has to be connected to some Tor/Peersm bridges (for web download), the bridges will know about them and will implement themselves a DHT, they will be used to bootstrap the peer discovery and populate the WebRTC DHT by the peers afterwards.
It’s impossible I believe at this stage to guess the churn rate, this is not specific to Peersm but all WebRTC projects, now there is not the notion of “one circuit” in Peersm which is problematic if the peers go away, the pieces are retrieved from different peers and paths which are renewed if they break knowing that the system maintains and renews constantly spare paths too.
And the Peersm clients are stable processes that are acting as browsers and are there to maintain the network running if too many peers close their browsers, as well as bridging with the bittorrent network.
Peersm has no other choice than using what WebRTC offers, so using STUN servers for NAT traversal (TURN relay servers are not really considered for now since they do what the current version of Peersm is doing), I drawed something about this some time ago: WebRTC drawing, at that time the drawing was showing that the signaling servers (the Tor/Peersm bridges) were the perfect MITM and tracking body but not any longer with the WebRTC DHT concepts, I don’t think it’s an issue that the STUN servers know about the peers.
No, it’s explained in the specs how the insecure WebRTC DTLS cerificates are secured by the Tor CERTS cells mechanism, this insures that you are talking to the one with whom you have established the DTLS connection, which can be a MITM too, but that will not know what happens next per the Tor protocol, exactly like the Tor project.
Some details about WebRTC security in my reply here WebRTC security
Unlike bittorrent the peers can not easily choose their identity since it is the fingerprint of their public key renewed for each session, so they can not trivially insert themselves into the Tor circuits paths of others, but they can easily announce whatever they like to attract others, that’s part of the study mentioned above, the method will block most of the suspicious peers but not all if the attack is really targeted and performed by someone that has enough resources, the attack will not allow to monitor what other peers are doing but can allow to distribute fake or wrong/bad/evil content, performing this attack would require a lot of resources to attract all the peers requesting a given content since the attacker would sign the content with it’s private key and therefore no pieces should come from a non attacker peer (because the signature will not match), this is possible but seems difficult to perform.
Please keep in mind that the technologies used are new inside browsers (mainly Media Source, File and indexedDB APIs) but this is working well. There are known issues mentioned below not related to the application itself but to the implementation of these APIs inside browsers, they have been reported to Mozilla and Google. Peersm has been developped and tested with Firefox and Chrome, which does not mean it does not work with other browsers, it just not has been tested yet.
Chrome for streaming and Firefox for download, awaiting Google to finish implementing IndexedDB should support storing File/Blob objects
See preceeding section, most likely you are using a browser that is not supporting yet the required features for Peersm or the database is broken, please see "Error opening database" message below.
Or you are using some extensions like adblock that are (wrongly) blocking some fields like the referer, pease deactivate them.
Or you are a victim of that bug with Chrome, we can not reproduce it, please contact us to help solving it.
Tor is already inside your browser with Peersm, so it's useless to use the Tor Browser. If you absolutely want to use the Tor Browser (and then use Tor inside Tor), then launch it, open in parallel the latest release of Firefox and configure the proxy (Options/Advances/Network) to 127.0.0.1 port 9150, then use the latest release of Firefox to load Peersm (until the Tor Browser has updated to release 26 of Firefox).
It is advised to check the save key box and keep the debug box checked if you want to see/check what the application is doing.
See the Links section.
Note: the application is doing much more complicated than HTTPS and is supporting already SSL/TLS, so it's not a big deal to include it but https is just not implemented yet for direct download since it does not seem to present any interest.
The database can get broken, see indexedDB broken - UnknownError - Error opening Database, if this happens, follow Firefox profile to find your profile directory and delete the peersm.com files in indexedDB or storage/persistent directories, or follow what is written here Clear Storage button in page info permissions.
Probably the system does not find the file in Peersm, Bittorent networks or on the Web, or something unexpected happened.
When downloading a file, Peersm stores each part received and then concatenates everything when the download ends (following Google and Mozilla advises, see IndexedDB, Blobs and partial Blobs - Large Files), this means that you can not lose data if something unexpected happens. For large files you might experience some delays at the end of the download before the file appears, this might be related to this bug report indexedDB and/or Blob constructor - Blob incremental storage seems very slow for large files.
For large files it can happen that the progress bar does not show any progress during some time, it does not mean that the download is not in progress any longer, just wait and if really after some time the bar is still frozen then stop the download and resume it.
When clicking on "Open/Save" for a downloaded file, it can happen that the browser does not render correctly the content, for a movie for example, this has been reported here: createObjectURL incorrect rendering.
Just save the file on your disk and open it from there.
Normally the system should recover whatever happens, on the browser side if you feel that something is not going well (download does not start or does not progress any longer, circuits are breaking or can not go live, etc...) then stop the downloads in progress (if any) and refresh the page.
For phase 1, if the download is really too slow, then, no luck, you have probably a slow peer in the path, stop the download, refresh the page to establish a new circuit and resume the download.
On ORDB side, even if it has becomen unlikely it could still happen that the ORDB thinks that a connection to a peer through the anonymizer network is still alive while it is not, so it can happen that the ORDB tries several time to initiate a download from this peer, you can then experience some delays but normally the ORDB will realize that the peer is gone and try another one.
You can run a Tor Bridge based on our implementation, very easy and simple to install, please see Installing node-Tor Bridge
You can run one or several Peersm clients to share files with others without having to let your browser open and to bridge with bittorrent network, please see Installing Peersm client
Please report issues/ideas/enhancement requests to: contact (at) peersm.com
Les technologies utilisées sont nouvelles dans les navigateurs (principalement File et indexedDB APIs), mais Peersm fonctionne bien. Il existe des problèmes connus qui ne sont pas le fait de Peersm mais liés à l'implémentation de ces APIs dans les navigateurs et qui ont été reportés à Mozilla et à Google. Peersm a été développé et testé avec Firefox et Chrome ce qui ne veut pas dire qu'il ne fonctionne pas ailleurs mais ça n'a pas été testé jusqu'à présent.
Chrome pour le streaming, Firefox pour le téléchargement, dans l'attente que Google finisse d'implémenter IndexedDB should support storing File/Blob objects
Voir la section précédente, probablement vous utilisez un navigateur qui ne supporte pas toutes les fonctionnalités nécessaires pour Peersm ou bien la base de données est corrompue, voir ci-dessous "Error opening database".
Ou vous utilisez une extension/plugin de type adblock qui bloque par erreur le referer, il faut les désactiver.
Ou bien vous êtes victime de ce bug avec Chrone, nous n'arrivons pas à le reproduire, merci de nous contacter si cela arrive afin d'aider à le résoudre.
Avec Peersm Tor est déjà dans votre navigateur, donc il est inutile d'utiliser le Tor browser. Si vous voulez absolument l'utiliser, et donc utiliser Tor dans Tor, lancez le Tor browser, ouvrez en parallele la dernière version de Firefox et configurez le proxy (Options/Advanced/Network) comme suit: IP 127.0.0.1, port 9150, utilisez ensuite la dernière version de Firefox pour charger Peersm. Vous pourrez utiliser le Tor browser sans avoir à faire cette manip lorsque le Tor Browser utilisera au moins la version 26 de Firefox.
Il est conseillé de cocher la case "Save key" et de laisser la case "debug" cochée pour éventuellement vérifier ce que fait l'application.
Voir la section Liens.
Note: l'application fait beaucoup plus compliqué que HTTPS et supporte SSL/TLS, mais HTTPS n'est pas implémenté pour les téléchargements directs car ne semblant pas présenter d'intérêt.
La base de données peut devenir corrompue, voir le rapport de Bug indexedDB broken - UnknownError - Error opening Database, si cela se produit, suivez Firefox profile pour trouver où se trouve le répertoire contenant votre profile Firefox et supprimez les fichiers relatifs à peersm.com dans les répertoires indexedDB ou storage/persistent, ou bien suivez ce qui est indiqué ici Clear Storage button in page info permissions.
Probablement le système ne trouve pas le fichier dans le monde Peersm, Bittorrent ou Web, ou quelque chose d'inattendu s'est produit.
Au cours d'un téléchargement Peersm enregistre toutes les données reçues et les concaténe à la fin (suivant les recommandations de Mozilla et Google, voir IndexedDB, Blobs and partial Blobs - Large Files), cela signifie que vous ne pouvez pas perdre ce que vous avez déjà téléchargé si quelque chose d'inattendu se produit pendant le téléchargement. Pour des fichiers de taille importante il faut un certain temps à la fin du téléchargement avant que le fichier intégral soit reconstitué, c'est peut être lié à ce rapport de bug : indexedDB and/or Blob constructor - Blob incremental storage seems very slow for large files.
Pour des fichiers de taille importante il se peut qu'à certains moments la barre de progression reste figée, cela ne veut pas nécessairement dire que le téléchargement ne progresse plus, attendez un peu et si réellement après un certain temps la barre ne progresse toujours pas alors stoppez le téléchargement et reprenez le.
Après avoir cliqué sur "Open/Save" pour un fichier téléchargé, il se peut que le navigateur n'ouvre pas correctement le fichier, pour un film par exemple qui restera figé, le problème a été remonté ici: createObjectURL incorrect rendering.
Sauvez juste le fichier sur votre disque et ouvrez le depuis celui-ci.
Normalement le système est censé se récupérer de n'importe quelle situation, cependant si du côté navigateur les choses ne semblent pas fonctionner normalement (le téléchargement ne démarre pas, les circuits n'arrivent pas à s'établir, etc) alors stoppez le téléchargement s'il y a lieu et rafraichissez la page.
Si le téléchargement est vraiment trop lent, alors pas de chance, il y a probablement un noeud lent dans le chemin des circuits, stoppez le téléchargement et rafraichissez la page pour établir de nouveaux circuits, reprenez ensuite le téléchargement.
Du côté ORDB, même si c'est devenu improbable, il se peut que l'ORDB pense qu'un circuit est toujours valide alors que non et tente d'initier un téléchargement à partir de celui-ci à plusieurs reprises induisant un délai au démarrage du téléchargement, mais normalement l'ORDB réalisera que le circuit n'est plus bon et en essaiera un autre.
Vous pouvez opérer un Bridge Tor basé sur notre implémentation, très simple et très facile à installer et à opérer, voir Installing node-Tor Bridge
Vous pouvez lancer un ou plusieurs clients Peersm pour partager anonymement des fichiers sans avoir à laisser les navigateurs ouverts et faire le lien avec le réseau bittorrent, très simple et très facile à installer aussi, voir Installing Peersm client
Merci de nous contacter à : contact (at) peersm.com