Lut.im, un service d’hébergement d’images gratuit, libre et anonyme

Que celui qui n’a jamais voulu partager simplement une capture d’écran lève le doigt. Personne ?

Logo de LUTIm

Le partage d’images nous confronte souvent à divers problèmes :

  • un email prend du temps (retrouver l’adresse du destinataire, l’envoi, etc.) ;
  • un email prend de la place. Ce n’est pas grand chose, mais pour une image jetable, c’est de l’espace disque perdu, que ce soit dans le dossier « Envoyé » de l’expéditeur ou celui du destinataire. Oui, on peut supprimer le mail, mais c’est encore une action à effectuer.
  • une solution commme imgur nous ramène au sempiternel problème des Conditions Générales d’Utilisation imbitables, pas traduites et qu’on ne lit de toute façon jamais en entier. Pour ce genre de service, on risque de fournir certains droits à l’hébergeur… et ça c’est pas cool !
  • un owncloud (ou équivalent) fera bien le travail, au prix d’une certaine complexité de partage et de liens à la longueur ahurissante.

Pour répondre à cette problèmatique, j’ai codé LUTIm (prononcez comme lutin). Écrit en Perl avec le framework Mojolicious, utilisant le Twitter Bootstrap, un sous ensemble de Font Awesome et un plugin jQuery légèrement modifié pour la gestion du glisser/déposer, LUTIm est un logiciel libre (licence AGPL) de partage d’image anonyme et gratuit.

Capture d'écran de l'interface de LUTIm

Le principe est simple : on glisse/dépose des images (ou via le sélecteur de fichier classique) et on récupère 3 liens :

  • un lien vers l’image (utilisable dans une balise img par exemple) ;
  • un lien de téléchargement de l’image (pour éviter le Clic droit > Enregistrer sous) ;
  • un lien vers une page qui affiche l’image et qui est utilisable sur Twitter (l’image apparaîtra dans le tweet).

Des options du formulaire d’envoi permettent de supprimer automatiquement les images après la première consultation ou après 24h.

Bien évidemment, pour des questions légales, il n’est pas possible d’avoir un service totalement anonyme : les IPs des envoyeurs d’image et celles des consulteurs sont enregistrées dans les logs, mais c’est quelque chose de tout à fait habituel sur tout site web. Les IPs des envoyeurs ainsi que celle du dernier consulteur sont enregistrées dans la base SQLite pour accélerer la recherche d’informations en cas de requète judiciaire (je sais comme il peut être fastidieux et long de chercher dans des logs).

Lors de la suppression automatique d’une image, le fichier est bel et bien supprimé, mais son entrée en base de données persiste et contient l’empreinte SHA512 du fichier.

De par sa nature libre, vous pouvez bien évidemment installer et utiliser très facilement LUTIm sur votre propre serveur, mais vous pouvez aussi vous contenter d’utiliser l’instance officielle : http://lut.im

LUTIm est disponible en français et en anglais, la langue étant choisie selon les préférences du navigateur. Toutes les bonnes volontés sont les bienvenues pour proposer d’autres langues !

Enfin, LUTIm propose un plugin pour Shutter, logiciel de capture d’écran, pour permettre à celui-ci d’envoyer les capture sur http://lut.im directement (plugin à installer soi-même, le site du projet ayant l’air cassé, je n’ai pu leur remonter le plugin).

12 réflexions au sujet de « Lut.im, un service d’hébergement d’images gratuit, libre et anonyme »

  1. Bonjour,
    Le site lut.im est extra, facile d’accès, pratique et confortable d’utilisation. Merci pour cela.

    J’ai une suggestion à faire : ne serait-il pas possible d’avoir un courrier en retour donnant les liens de l’image uploadée ? On pourrait ainsi archiver facilement les liens d’une façon automatisée.

    Merci encore,
    Cordialement.

    1. Je vais mettre en place un lien de partage par mail : il n’y aura qu’à vous envoyer un mail. Je ne souhaite pas mettre de mail automatique, je m’exposerai sinon à devenir une plate-forme de spam.

      Amicalement,

  2. Très bonne initiative. Merci ! Est-il possible d’uploader plusieurs images en une seule fois ? On a rarement une seule image à partager. Deuxième question: Y a-t-il une limite de volume de stockage (en particulier pour les durées illimitées) ?

    1. Oui et oui.

      Oui, on peut envoyer plusieurs images en même temps, et oui, il y a une limite de 10Mio par image, mais cela ne varie pas, que l’image soit en durée illimitée ou non.

      1. Bonsoir,
        D’emblée je vous souhaite bonne année 2015 à vous tous (les Lutim’s en particulier :). Puis, je souhaiterais vous demander si l’on peut partager un dossier d’images en entier tel que c’est possible sur G…Drive ? Si c’est le cas, est-ce que vous pouvez nous l’indiquer s’il vous plaît? (au lieu de piocher un à un les liens vers des photos individuelles)
        Cordialement.

        1. Bonne année à toi aussi.

          Non, il n’est pas possible de partager un dossier, par contre on peut déposer toutes les images d’un dossier d’un coup. Par contre, oui, après ça fait un paquet d’url à récupérer.

  3. I love this tool, however, the Firefox app doesn’t work well with my phone. It refreshes every time I select an image from my gallery
    please advice on how to fix this

  4. This solves an interesting use case to me.

    Question about self-hosting:
    Is there a way to restrict the users with access to this, while keeping support for the Android app? (If not, I would be interested in this. I don’t want to open up for misuse from strangers on the internet.) Maybe using standard HTTP auth?

    About the encryption scheme:
    The way you’re encrypting the content is broken and doesn’t work.

    a) all crypto happens on the server, so plaintext can be intercepted there.
    Who do you try to protect the plaintext from?
    It’s trivial to patch the software server-side to record keys or plaintext.
    b) key generation is broken in multiple ways.
    (random number generation is not cryptographically safe,
    and the possible key space is tiny. Do not build your own crypto.)

    That being said, I don’t care about the server-side file encryption if I want to self-host. Just please do not make security claims about the file encryption; a public Lut.im hoster can see these images if he wants to, and it might be better if users know that.

    -R

    1. > Is there a way to restrict the users with access to this, while keeping support for the Android app?

      I dunno, but that’s a thing I’m working on.

      > all crypto happens on the server, so plaintext can be intercepted there.

      Yep. I know. But there’s no way to be able to be able to use a Lutim image URL in a `<img />` tag otherwise.

      > random number generation is not cryptographically safe

      Right. Just pushed a patch to change that.

      > possible key space is tiny

      Something I wanted to fix a long time ago and forgotten. Fixed too.

      > Just please do not make security claims about the file encryption;

      Where did I do that? On the index page, I just said that the file is encrypted, I don’t say a word about encryption in the about page, and on the README, I say explicitly that the encryption is made on the server.

      Anyway, thanks for your comments. And don’t forgot: patches are welcome on https://git.framasoft.org/luc/lutim

      1. Thanks for looking into it;
        are you sure key sizes other than 8 even work? Looking up the Blowfish algorithm, it seems that keys are supposed to be 64 bit, which happens to coincide with your key size setting. (It also seems like it would be more reasonable to set the default much higher, so that new users don’t need to reconfigure.)

        I can just recommend the NaCL library (and its library bindings). It seems to be considered trustworthy and has a plain simple interface that keeps you away from misconfiguration.

        > Yep. I know. But there’s no way to be able to be able to use a Lutim image URL in a «  tag otherwise.

        Yes, ok. This is difficult.

        Another small thing that I noticed; Make sure noone is accidentally keeping these /d/ links around on his github, otherwise you might get hit by a wild-running web crawler. Or, in other words: state-modifying requests should better require a POST; web-crawlers don’t do that, and browsers restrict POST requests to protect against XSS.

        -R

        PS: You might be interested in looking up HMAC hash algorithms; with those, you can avoid storing the deletion tokens (and keep a server-side secret instead).

        1. > are you sure key sizes other than 8 even work?

          Yes, I tested with a 16 chars key before pushing. And I just tested it with a 17 chars right now (before remembering I already tested id).

          > Or, in other words: state-modifying requests should better require a POST; web-crawlers don’t do that, and browsers restrict POST requests to protect against XSS.

          I need to think about it, since it’s always hard to break an API.

          > You might be interested in looking up HMAC hash algorithms

          Hum, maybe later: I’ve got a lot of work :p

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *