Le transfert de fichiers en 2014

Supposons que l'on ait un fichier, ou un ensemble de fichiers (au besoin rassemblés dans une archive), sur un ordinateur que je vais appeler Alpha, parce que ce serait dégradant de lui donner un prénom féminin.

Le problème dont il va être question dans tout cet article va être de faire en sorte de copier ces fichiers sur un autre ordinateur, que je désignerai par Bravo, qui peut appartenir ou non à la même personne qu'Alpha.

On va considérer que ces données sont d'une taille raisonnable pour les standards actuels.

Quelle est la façon la plus pratique de s'y prendre ?

En général, le plus pratique est de passer par une mémoire flash (ou « clef ») USB. Même si la plupart des ordinateurs sont connectés sur un réseau, c'est dire le triste état des logiciels et de leurs interfaces à notre époque.

Il n'y a pas grand chose à dire sur cette solution éprouvée. Supposons donc que, pour une raison ou pour une autre, par exemple à cause de la distance entre les deux ordinateurs ou les craintes de transmissions virales, cette solution ne soit pas acceptable.

La solution la plus pratique est généralement de passer par un serveur HTTP accessible en réseau (ce qui suppose donc que ces deux ordinateurs soient connectés à un réseau).

C'est (encore) dire le triste état de l'informatique actuelle, utiliser un protocole de transfert d'hyper-textes pour transférer des fichiers.

Ça doit plutôt bien fonctionner, vu qu'il y a un marché raisonnable pour faire précisément ça, entre DropBox, Google Drive, One, etc.

Qu'il faille faire intervenir un troisième ordinateur, disons Sierra, pourquoi pas, ce n'est pas pire qu'une mémoire flash ou qu'un fournisseur d'accès à internet. Mais qu'il faille faire intervenir une personne morale supplémentaire, avec un droit de regard direct sur mes fichiers, ça me gène un peu plus. Pour paraphraser Benjamin Bayart, qu'est-ce que mes données foutent sur pas-ma machine ?

J'ai donc entrepris d'écrire un serveur web à cet effet, que j'ai publié en logiciel libre, parce que tout le monde s'en fout éperdument et donc je n'ai aucun risque de le voir forké ou de me faire démonter publiquement. Le dépôt fossil n'est pas encore montrable, mais le miroir sur GitHub est tout à fait fonctionnel.

Il s'agit donc d'un serveur de fichiers publiquement accessible sur le grand 'ternet (et en réseau local, pour peu que l'on l'y déploie). Il est assez évident qu'un serveur de fichiers ouvert à tous les vents va rapidement être abusé, donc il faut trouver un moyen de le sécuriser, mais sans gêner les utilisateurs légitimes.

Ce dernier point exclut les systèmes de comptes et les autres identifications fortes : pour être utile, il faut que ce soit simple et efficace pour un utilisateur quelconque, qu'il contrôle Alpha ou Bravo. Il ne reste donc guère que l'utilisation d'un secret quelque part dans l'URL.

Comme l'utilisateur quelconque peut jouer le rôle d'Alpha, cela implique que techniquement, n'importe qui peut envoyer un fichier, sans aucun contrôle. Pour garder le contrôle, il ne me reste donc que la possibilité de cacher le lien de téléchargement d'un fichier envoyé.

En fait s'il fallait vraiment contrôler avant l'envoi, il resterait la possibilité de créer des quota, avec une identification dans l'URL avant de recevoir le formulaire HTML. Je finirai peut-être par y venir, mais ça implique une interface d'administration pour moi, soit par HTTP avec la complexité de distinguer les utilisateurs quelconque des administrateurs, soit par un autre moyen qui suppose que je ne sois pas coincée derrière un firewall idiot. Avec la difficulté supplémentaire de communiquer ce qui est valide au front-end qui accepte le formulaire avant de donner le contrôle à mon application.

Comment cacher le lien de téléchargement ? En incorporant un secret dans son URL, connu seulement de l'opérateur du serveur (c'est-à-dire moi). Mais sans utiliser d'informations trop profondément cachées dans le serveur, pour pouvoir calculer l'URL sans avoir besoin du serveur.

Quelque chose d'imprévisible modulé par un secret, ça fait immédiatement penser au HMAC. Mais pas un HMAC du fichier, parce que si j'avais le fichier, je n'aurais pas besoin qu'on me l'envoie. Donc plutôt un HMAC du hash du fichier, plus facile à faire parvenir par d'autres canaux.

Le hash du fichier sert en même temps à construire l'URL d'un rapport de téléchargement, aimablement fourni à l'envoyeur, pour qu'il puisse vérifier que l'envoi s'est bien passé en comparait les hash, et au recevoir pour lire commentaires et nom original.

Autre astuce : le HMAC se comporte en fait comme un répertoire, en servant le fichier quelque soit le suffixe, ce qui permet de donner un nom arbitraire (pas forcément le même qu'à l'envoi) au fichier reçu.

Enfin, mon expérience personnelle avec le partage de fichier en utilisant un répertoire servi par HTTP, est que les fichiers s'y accumule et que ce n'est pas toujours facile de retrouver lesquels peuvent être effacés. Donc avec ce serveur, en plus du commentaire qui aide à resituer le fichier, j'attache une date d'expiration, au delà de laquelle le fichier est effacé.

Mon instance est disponible sur upload.instinctive.eu, que je préfère ne pas lier pour éviter les robots pénibles qui n'auraient que faire de robots.txt. Attention, c'est très moche, je n'ai pas encore pris le temps de lui donner une apparence décente (mais c'est moins moche que la page de LibreSSL).

Commentaires

1. Le samedi 23 août 2014 à 23:36, par Mireille :

C'est nul.

2. Le vendredi 29 août 2014 à 12:23, par Gaby :

C'est toi qu'est nulle Mireille.

Vas-y ma chérie continue t'es la meilleure !

-- Ta plus grande fan.

3. Le mercredi 3 septembre 2014 à 20:55, par Natacha :

Gaby, mille mercis, aussi bien pour le commentaire public que le message personnel \o/

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.