JustDropFile

Comment ça marche

JustDropFile est un transfert de fichiers pair à pair qui tourne entièrement dans le navigateur. Cette page explique chaque étape sans approximation, pour que tu décides toi-même si tu lui fais confiance.

1

Tu déposes un fichier et tu obtiens un lien

Ton navigateur génère deux valeurs aléatoires : un identifiant de session de 128 bits et une clé de chiffrement de 256 bits. Il construit un lien du type justdropfile.com/r/#session.cle. Toute l'identité du transfert se trouve après le signe #, ce qu'on appelle le fragment, et les navigateurs n'envoient jamais le fragment à un serveur. À ce stade, rien n'a quitté ton appareil à part une connexion WebSocket vers notre service de signalisation portant l'identifiant de session.

  • •Le QR code est le même lien, dessiné localement.
  • •Le lien est valable 20 minutes si personne ne l'ouvre, puis la session est détruite.
2

Ils ouvrent le lien, et les navigateurs se trouvent

Le navigateur récepteur lit le fragment, se connecte au service de signalisation avec le même identifiant de session, et les deux navigateurs échangent des descripteurs de connexion (SDP et candidats ICE) par son intermédiaire. C'est le seul rôle du serveur : faire passer quelques kilooctets de poignée de main entre exactement deux pairs. Il refuse un troisième, ne journalise pas les descripteurs, et supprime la session à l'instant où les pairs se connectent.

Technical note:

Le service de signalisation est un Cloudflare Worker avec un Durable Object par session. La création de session est limitée en fréquence par IP. Seuls des compteurs agrégés sont journalisés, jamais le contenu des descripteurs.

3

Une connexion directe est tentée en premier

WebRTC essaie trois routes dans l'ordre : un chemin direct sur le réseau local, un chemin direct à travers internet en utilisant STUN pour découvrir les adresses publiques, et enfin un relais. La plupart des réseaux domestiques et mobiles autorisent l'une des deux premières. La connexion elle-même est chiffrée avec DTLS comme l'exige WebRTC.

  • •Les connexions directes n'ont pas de limite de taille.
  • •Après la connexion, la page vérifie quelle route a été choisie et affiche « directe » ou « relayée ».
4

Si la connexion directe échoue, un relais chiffré prend le relais

Certains réseaux de bureau, d'hôpital, de campus et d'hôtel bloquent complètement les connexions directes entre pairs. Dans ce cas, le trafic est relayé via Cloudflare TURN. Le relais transmet du texte chiffré ; il n'a pas la clé. Les identifiants de relais sont générés par session par notre worker et expirent, donc le relais ne peut pas être détourné comme proxy gratuit. Les transferts relayés sont limités à 2 Go parce que les octets relayés coûtent de l'argent.

Technical note:

Cloudflare TURN est utilisé avec des identifiants à courte durée de vie générés par session. Si même le relais est bloqué, la page te le dit et suggère un autre réseau ou un partage de connexion mobile.

5

Le destinataire voit la liste des fichiers et accepte

Avant qu'un seul octet de fichier ne bouge, l'expéditeur transmet un manifeste chiffré : noms, tailles et types de fichiers. Il passe par la connexion entre pairs, pas par la signalisation, donc notre serveur ne le voit jamais. Le destinataire peut refuser. En acceptant, le navigateur récepteur ouvre un emplacement pour écrire le fichier : un dossier que tu choisis (Chrome et Edge sur ordinateur) ou le stockage privé sur disque du navigateur (Safari, Firefox, Android), de sorte que le fichier est écrit sur le disque au fur et à mesure plutôt que gardé en mémoire.

6

Les fichiers passent par morceaux chiffrés

L'expéditeur lit le fichier par tranches de 64 Ko maximum, chiffre chaque tranche avec AES-GCM en utilisant la clé du lien, et l'envoie sur un canal de données WebRTC. Chaque morceau porte son numéro de fichier et sa position comme données authentifiées, donc un morceau corrompu, manquant, réordonné ou rejoué échoue à la vérification. À la fin de chaque fichier, l'expéditeur envoie un décompte et un total d'octets signés ; le destinataire confirme les deux avant d'accuser réception. Les fichiers sont envoyés l'un après l'autre sur une seule connexion.

  • •Aucun côté ne garde jamais un fichier entier en mémoire. Les transferts de plusieurs gigaoctets fonctionnent sur téléphone.
  • •L'expéditeur respecte la contre-pression du canal, donc un destinataire lent ralentit l'expéditeur au lieu de remplir sa mémoire.
  • •Si la connexion tombe, le transfert échoue clairement et l'expéditeur peut créer un nouveau lien. Il n'y a pas de reprise dans cette version.

Vérifie par toi-même

Ouvre les outils de développement de ton navigateur, va dans l'onglet Réseau et lance un transfert. Tu verras un WebSocket vers l'hôte de signalisation transportant de petits messages JSON, et rien d'autre : aucune requête d'upload, aucun octet de fichier. Le transfert lui-même apparaît dans les internes WebRTC (chrome://webrtc-internals dans Chrome), où tu peux aussi confirmer si la paire de candidats choisie est directe ou relayée.

La clé n'apparaît dans aucune requête parce qu'elle est dans le fragment de l'URL. Tu peux le confirmer dans le même onglet Réseau : la requête vers l'hôte de signalisation contient l'identifiant de session et rien après le point.

Ce que cette conception ne peut pas faire

  • •Elle ne peut pas livrer à quelqu'un qui est hors ligne. Il n'y a pas de stockage, donc les deux côtés doivent être présents.
  • •Elle ne peut pas cacher ton adresse IP à l'autre participant. Les connexions entre pairs fonctionnent en échangeant des adresses.
  • •Elle ne peut pas passer à travers un réseau qui bloque à la fois les connexions directes et les relais TURN.
  • •Elle ne peut pas reprendre un transfert interrompu. Tu recommences avec un nouveau lien.