Lut.im, un service d’hé­ber­ge­ment d’images gratuit, libre et anonyme

Que celui qui n’a jamais voulu parta­ger simple­ment 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 (retrou­ver l’adresse du desti­na­taire, l’en­voi, etc.) ;
  • un email prend de la place. Ce n’est pas grand chose, mais pour une image jetable, c’est de l’es­pace disque perdu, que ce soit dans le dossier “Envoyé” de l’ex­pé­di­teur ou celui du desti­na­taire. Oui, on peut suppri­mer le mail, mais c’est encore une action à effec­tuer.
  • une solu­tion commme imgur nous ramène au sempi­ter­nel problème des Condi­tions Géné­rales d’Uti­li­sa­tion imbi­tables, pas traduites et qu’on ne lit de toute façon jamais en entier. Pour ce genre de service, on risque de four­nir certains droits à l’hé­ber­geur… et ça c’est pas cool !
  • un owncloud (ou équi­valent) fera bien le travail, au prix d’une certaine complexité de partage et de liens à la longueur ahuris­sante.

Pour répondre à cette problè­ma­tique, j’ai codé LUTIm (pronon­cez comme lutin). Écrit en Perl avec le frame­work Mojo­li­cious, utili­sant le Twit­ter Boots­trap, un sous ensemble de Font Awesome et un plugin jQuery légè­re­ment modi­fié pour la gestion du glis­ser/dépo­ser, LUTIm est un logi­ciel libre (licence AGPL) de partage d’image anonyme et gratuit.

Capture d'écran de l'interface de LUTIm

Le prin­cipe est simple : on glisse/dépose des images (ou via le sélec­teur de fichier clas­sique) et on récu­père 3 liens :

  • un lien vers l’image (utili­sable dans une balise img par exemple) ;
  • un lien de télé­char­ge­ment de l’image (pour éviter le Clic droit > Enre­gis­trer sous) ;
  • un lien vers une page qui affiche l’image et qui est utili­sable sur Twit­ter (l’image appa­raî­tra dans le tweet).

Des options du formu­laire d’en­voi permettent de suppri­mer auto­ma­tique­ment les images après la première consul­ta­tion ou après 24h.

Bien évidem­ment, pour des ques­tions légales, il n’est pas possible d’avoir un service tota­le­ment anonyme : les IPs des envoyeurs d’image et celles des consul­teurs sont enre­gis­trées dans les logs, mais c’est quelque chose de tout à fait habi­tuel sur tout site web. Les IPs des envoyeurs ainsi que celle du dernier consul­teur sont enre­gis­trées dans la base SQLite pour accé­le­rer la recherche d’in­for­ma­tions en cas de requète judi­ciaire (je sais comme il peut être fasti­dieux et long de cher­cher dans des logs).

Lors de la suppres­sion auto­ma­tique d’une image, le fichier est bel et bien supprimé, mais son entrée en base de données persiste et contient l’em­preinte SHA512 du fichier.

De par sa nature libre, vous pouvez bien évidem­ment instal­ler et utili­ser très faci­le­ment LUTIm sur votre propre serveur, mais vous pouvez aussi vous conten­ter d’uti­li­ser l’ins­tance offi­cielle : http://lut.im

LUTIm est dispo­nible en français et en anglais, la langue étant choi­sie selon les préfé­rences du navi­ga­teur. Toutes les bonnes volon­tés sont les bien­ve­nues pour propo­ser d’autres langues !

Enfin, LUTIm propose un plugin pour Shut­ter, logi­ciel de capture d’écran, pour permettre à celui-ci d’en­voyer les capture sur http://lut.im direc­te­ment (plugin à instal­ler soi-même, le site du projet ayant l’air cassé, je n’ai pu leur remon­ter le plugin).

Me soutenir sur Tipeee Me soutenir sur Liberapay

12 réflexions au sujet de « Lut.im, un service d’hé­ber­ge­ment 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 *