Première requête de take down pour 0bin


Vous vous souvenez, 0bin, ce pastebin chiffré côté client écrit en Python ? Le but était de protéger, non pas l’utilisateur, mais l’hébergeur, d’une attaque en justice. La théorie est qu’il ne peut en effet être tenu de modérer ce qu’il ne peut consulter.

Et bien on vient de recevoir notre première demande légale de retrait de liens.

Petit retour sur les faits, pistes de réflexion et appel à commentaires.

Le take down

La demande ne nous est pas parvenue directement, ni même par notre hébergeur, mais via notre fournisseur de nom de domaine, en l’occurrence pour 0bin.net, l’américain namecheap.

Techniquement, nous ne sommes pas aux USA, et nos serveurs ne le sont pas non plus. Pour Max, “c’est idiot de se prendre un procès pour un site qui rapporte pas”. Moi je dirais plutôt que le risque, c’est de perdre le nom de domaine qui est quand même super cool, mais ma première réaction a plutôt été “nannnnnnn, faut pas censurer”. Au final, on quand même retiré les pastes, puisqu’ils contenaient des liens de téléchargement de contenus protégés par le droit d’auteur.

Voici les demandes que nous avons reçu :

2.) Identify the copyrighted work claimed to have been infringed
You link to this copyrighted material (music albums):

DANNY PRESZ – Inicio – (2013)
ORQUESTA BRONKO & SHAKAITO – 30 Aniversario-Homenaje – (2013)
CHARLIE CRUZ – Huellas – (2013)
MONGORAMA – Baila Que Baila – (2013)
CONJUNTO SABROSURA – Moña Pa’ Mi Bongó – (2013)
V. A. – Sergio George’s Salsa Giants – (2013)
Victor Manuelle – Me Llamaré Tuyo – (2013)

3.) Provide us the exact location of the infringing file with the exact link
On your servers here (re-directing to 180upload.com):

http://0bin.net/paste/7eefb6647bb1e606ef95eaa219e4f2de8ef98d5a#GipoKK++q7p3t+56MQPQa7Tm50Vq3BTATm0a9CsiBE0=
http://0bin.net/paste/d3d3db7281b32d1d9ba4be1f0166c0e6681b7904#yuYfcO5g83WDQ7xgF8l39AhHJH4N+XfzMv6Th1IoiVo=
http://0bin.net/paste/4185de7d1d5acc69f149472edb6395603786e622#s22bq9IkdWlm7vajb4+ryNvQLAe79tYZqrICzaexw1E=
http://0bin.net/paste/df3bf3537bec0d54c1fc2d469307d91674172072#uTszh1/Om8baR/hsvWpLyMm50vgwRoRRsMkMbgVouTo=
http://0bin.net/paste/1cbb4a2796db7015412353e9cc6818cd16673338#spj9KqFNfCeMR/VNN5IVof4Sax9njevkcIBuesNWTmE=
http://0bin.net/paste/f67fd84d81bdfeb5da8a529a1064d143c8831fe6#uadJcY9uIaGbJ7oXUZ8kcXXpiktHjwkhE9XUH3TC+9U=
http://0bin.net/paste/a1043ecdf4fe1d1a4d55aedc5d9409f1767223ef#QaT1pCopGaxs9ZC07N+0cmVg6aRoiL9uY3GOPvuUx7w=

4.) Provide us the web address under which the link has been published
The links are shared here in public:
http://bypachayo.blogspot.de/

J’ai groupé les mails en un seul, mais il y en a eu 3. Notez qu’ils avaient accès aux liens avec la clé de chiffrement, puisqu’ils étaient posté publiquement sur un blog. De plus, l’identification a probablement été manuelle étant donné la nature de 0bin.

L’état de 0bin

0bin n’est pas un outil de lutte contre la censure ou de contournement légal. Il n’est pas armé pour le cas où la demande de take down arrive avec le lien complet, clé incluse, car il a été exposé ainsi sur le Net.

Il ne permet pas non plus de prévenir l’utilisateur du retrait de ses liens : tout le monde va tomber sur une 404 jusqu’à ce que l’auteur soit averti, et il ne comprendra pas ce qui s’est passé.

Ici, on a eu la chance d’avoir un seul blog, donc je suis allé poster un commentaire dessus pour lui expliquer la situation. Mon espagnol est un peu rouillé d’ailleurs.

On voit aussi que 0bin, et Internet en général, est mal compris : le mec utilisait l’outil pour poster un lien par paste, qu’il linkait ensuite sur son site. Qu’espérait-il ? Camoufler quelque chose ? A-t-il compris comment marchait le service ? A quoi il était destiné ?

La seule bonne nouvelle dans tout ça, c’est qu’on a rajouté un script qui supprime permet de supprimer un paste en Python.

Et après ?

Même si les liens étaient illégaux (d’ailleurs je n’ai aucune connaissance pour vérifier que l’injonction de retrait est elle, légale), cela fait toujours un peu chier de devoir retirer quelque chose. Cette fois, on n’a pas recopié l’information ailleurs, mais peut être qu’on aurait dû.

La vraie question c’est : est-ce qu’on veut ajouter des fonctionnalités de résistance contre la censure à 0bin ? Est-ce que ce but est vraiment complémentaire à l’objectif initial ? Est-ce que les utilisateurs en ont besoin ? Est-ce que ça ne va pas transformer le logiciel en un truc qui n’a rien à voir ?

Et si oui, que mettre en place ? De mon chapeau, j’ai déjà quelques idées :

  • Mettre en place une instance sur Tor et faire un script ou une fonctionnalité de transfert sur celle-ci en cas de take down notice.
  • Ajouter de la réplication, et lier plusieurs instances qui se font confiance entre elles via une API.
  • Ajouter une fonctionnalité de liens périssables (temps, nombre de cliques…), pour que les gens puissent partager des liens de 0bin des pages publiques sans donner l’URL réelle.
  • Permettre un faux retrait, c’est à dire un retraire temporaire, mais les liens sont réactivés plus tard ?
  • Pouvoir protéger un paste par un mot de passe.

Mais rien de tout ça ne règle le problème de notre cher fan de Danny Presz. D’ailleurs faut-il résoudre son problème ? Et si oui, est-ce le rôle de 0bin ?

J’ai horreur de terminer une article comme ça, ça fait vraiment pute à commentaires sur un blog cheap, mais qu’est-ce que vous en pensez ?

43 thoughts on “Première requête de take down pour 0bin

  • arthro

    Oui, je pense que la possibilité de créer des alias serait une bonne idée. Avec peut-être une date de péremption différente. Ca masquerait l’adresse du paste original, et comme ça, impossible de supprimer la source si on ne peut pas la retrouver à partir de l’alias.
    Par contre pour les mots de passe, je ne sais pas trop. L’URL est elle-même le mot de passe. Donc un peu inutile d’en rajouter un, puisqu’il faudrait le transmettre à côté du lien. Le seul avantage serait qu’un mot de passe peut être plus facile à transmettre IRL qu’une adresse Obin qu’ont pourrait ainsi doner publiquement sur la toile.

  • Benjamin

    – L’injonction ne vaut rien pour toi : elle est écrite en anglais ;)
    – Je ne suis pas sûr que cela suffise pour montrer que le contenu soit “manifestement illégal” (ce que dit la LCEN de 2004)
    – mais à votre place j’aurais fait pareil : trop de risque de perdre le domaine

    conseil => changer de registrar et enregistrer le domaine chez un registrar du même pays que l’hébergeur (NL) ou de France (vu que vous êtes français) ça vous protégera mieux du n’importe quoi US qui consiste à faire tomber des domaines sans aucun recours ni procès …

    bises,

  • sil

    On résume : le gars met les infos dans un coffre fort mais laisse pendre la clef sur la clenche de la porte. On ne peut rien faire pour lui.

    Le seul moyen serait effectivement un 0bin.onion. Ainsi, il serait impossible de contacter l’hébergeur qui n’aurait aucune connaissance du contenu des pastes.

  • maethor

    À mon avis, ce n’est pas le rôle de 0bin de pallier à la bétise de certains. Je ne pense pas que complexifier l’outil, et notamment son interface, soit une bonne idée.

    J’ai moi-même reçu une take down notice pour un zerobin (http://paste.aquilenet.fr). À vrai dire, c’est sebsauvage qui l’a reçu et nous l’a transmis… n’importe quoi :D. Après plusieurs relances, nous avons répondu que le contenu expirera au bout d’un mois, et que nous ne pouvons rien faire de plus. On n’a pas eu plus de nouvelles.

    On a aussi reçu et une requête de la police belge pour obtenir l’IP qui a publié un contenu. On lui a répondu qu’il devrait se rapprocher de la police française pour obtenir un mandat… Pas de nouvelles depuis.

    Ajouter un mot de passe… Mais pour quoi faire ? C’est l’URL, le mot de passe !
    Faux retrait, ça me parait bien risqué, ça pourrait être vu comme du foutage de gueule, et paf le domaine.

    Par contre, je désactive toujours la possibilité de poster des paste à vie. Pour moi, les pastebin sont des outils de publication volatile, pas définitive. Limiter la durée de vie à un mois permet de bien mettre ça en avant. D’ailleurs, idée d’évolution, j’aurais aimé pouvoir le faire depuis la conf ;)

  • François

    Ce que je ne comprends pas, c’est la raison pour laquelle on vous a ciblé. Qu’ils demandent à l’auteur du blog ou mieux, à l’hébergeur de fichier, ce serait compréhensible, mais là, vous n’êtes qu’un intermédiaire (peut être pas unique d’ailleurs).

    * le mdp ne revient pas au même que la clé de chiffrement ?
    * Pas certain d’avoir bien compris l’usage de tor que tu veux faire.

    Rien à voir, mais ça me fait penser à coquelicot (cf conf PSES2013) qui permet hébergement de fichier avec chiffrement coté serveur, dont le fonctionnement (me semble) est similaire à 0bin.

  • cym13

    La seule idée qui me plaît vraiment ce sont les liens périssables. Il est à noter avant tout que je considère que le but de 0bin est plus d’empécher la lecture par un tiers que de soutenir une contre-censure après que les données aient été censurées.

    – Je ne vois pas l’intéret d’avoir un site TOR qui soit une simple copie d’un site normal. Je manque peut-être de clairvoyance sur ce point ci.

    – La réplication c’est le bien mais le processus de confiance… Disons soit ce sont des inconnus auquel cas il est facile pour le gouvernement de s’infiltrer et de voir les données même si les détruire est plus difficile.

    – Le faux-retrait présente aussi le problème que le contenu a déjà été vu du gouvernement mais en plus l’auteur fait quoi ? S’il publie les liens à nouveau et que l’état s’en rend compte ça va être pour votre pomme et vous allez risquer plus qu’avant (mentir à la justice ça ne lui plaît pas).

    – Le paste avec mot de passe… Tout a déjà été dit dessus par arthro.

    Par contre le paste accessible seulement avant un certain nombre de clics ça j’aime. Mais un gars comme lui qui veut héberger les liens pour les montrer aux gens ne peut pas utiliser ce genre de fonctionnalité car il souhaite un maximum de vues. Mais pour les autres c’est très bien ^^

  • sil

    L’intérêt du site TOR est que l’hébergeur n’est pas directement contactable. Ainsi, il est plus difficile de l’informer qu’il héberge du contenu illégal, ce qu’il ignore de toute façon.

  • desfrenes

    Il y a déjà la clef de chiffrement dans le #, pourquoi pas mettre aussi mettre le contenu sous sa forme chiffrée dans l’URL ?

    – Plus rien à stocker sur le serveur
    – Plus rien à retirer !

  • cym13

    @sil
    Je n’avais pas vu les choses sous cet angle effectivement, mais ce n’est pas
    comme s’il n’existait pas déjà des zerobins sous TOR. Si quelqu’un veut
    vraiment ce genre de service, n’irait-il pas directement dessus ?

    @desfrenes
    Ça s’appelle un message chiffré non ? Et à ce jeu là PGP s’en sort mieux que
    ce que S&M pourront mettre en place (sans offense).

  • desfrenes

    oui, enfin pgp comme ça spontanément c’est pas hyper madame michu friendly, alors que 0bin oui (clicodrome, tout ça…).

  • marko

    @desfrenes il existe un truc dans ce genre shortly .

    Les avantages sont ceux que tu as cité, par contre l’inconvénient majeur c’est qu’il y a une limite à la taille des urls donc une limite au texte que tu peux déposer (limite variable selon les navigateurs).

  • cym13

    @desfrenes

    OK pour PGP versus Michu, mais en soit des services de chiffrement il y en a plein la toile pour simplifier le processus. Par contre là on parle d’un chiffrement sans mot de passe !

    Non seulement il n’est pas plus facile de copier le message pour le sauvegarder (copier un message ou une url de 2000 caractères ça revient au même) mais en plus le message est directement accessible à tout ceux qui prendront la peine de vouloir le déchiffrer.

    Honnêtement, je ne vois pas l’intéret.

  • cym13

    En fait tu proposes que l’url contienne le message et le serveur contienne la clé ?

    Ça pourrait marcher. Il faudrait se coltiner des urls d’une page mais ça pourrait marcher. Et là le server ne stock plus rien de compromettant.

    Maintenant je ne voit toujours pas ce que ça apporte vraiment par rapport à des services de chiffrement en ligne. Et ça n’a plus grand chose à voir avec le 0bin de départ.

  • sil

    Si on était vicieux, on pourrait imaginer un système ou le contenu serait reparti entre plusieurs hébergeurs. Les chemins des différentes parties du message seraient passes en arguments dans l’URL, le script qui se chargerait de les merger et de les envoyer au client qui déchiffrerait le message entier.

    Prises individuellement, les différentes parties du contenu ne voudraient rien dire, même avec la clef. Il serait plus difficile d’attaquer un hébergeur en particulier, ou même tous les hébergeurs réunis.

  • desfrenes

    “En fait tu proposes que l’url contienne le message et le serveur contienne la clé ?”

    Non, pas du tout, ni clef ni message sur le serveur, tout dans l’url, à charge à l’auteur d’inclure la clef ou non (vaut mieux pas si on veut que ça soit efficace ^^)

  • cym13

    @sil

    J’aime bien l’idée, mais que faire si l’un des serveurs tombe ? Est-ce que ça ne rendrait pas des dizaines de messages illisibles ?

    @desfrenes

    Mouais, j’ai déjà dit ce que je pensais à ce sujet. Par contre, je trouve finalement que l’idée de stocker la clé et pas le message sur le serveur n’est pas bonne en ceci qu’elle n’apporte rien. Il faut la clé et le message chiffré pour lire le message. Par contre, je pense plus important de protéger le message de lectures non souhaitées que de la censure (ne serait-ce que parce qu’il est difficile de censurer un message dont on a pas connaissance). Dans cette optique, laisser le message même chiffré en liberté me dérange. La clé au moins ne peut donner le message de départ.

  • cym13

    @desfrenes

    Non, en fait je vais préciser.

    Si la clé est avec le message chiffré dans l’url, quel est l’intéret par rapport à avoir juste le message déchiffré ?

    Si la clé n’est pas avec le message chiffré mais que ce dernier est dans l’url, quel est l’intéret par rapport à n’importe quel autre service de chiffrage ?

    Ce sont de vrais questions si tu as de vrais réponses.

  • sil

    @cym13

    Il est envisageable de stocker le contenu de manière redondante. Ca complique un peu les choses mais bon.

  • desfrenes

    “Si la clé est avec le message chiffré dans l’url, quel est l’intéret par rapport à avoir juste le message déchiffré ?”

    En dehors d’une très relative discrétion, aucun intérêt, mais ce n’est pas pas ce que je recommande, voir plus haut. Je ne connais les services de chiffrage dont tu parles donc je ne peux pas te renseigner.

    En l’état on peut aussi se demander l’intérêt de 0bin tout simplement. Depuis la page du projet:

    “The idea is that one can (probably…) not be legally entitled to moderate the pastebin content as he/she has no way to decrypt it.”

    Comme on vient de le voir, c’est très fragile…

  • cym13

    Pour les services je n’en ai pas vraiment en tête, mais une rapide recherche me donne des choses comme encrypt-easy et infoencrypt (dont on ne sait rien du chiffrement utilisé mais qui sont ce que j’imaginais en terme d’interraction utilisateur).

    Et oui, je pense aussi que le concept même de 0bin est à réfléchir. Jusqu’à présent le chiffrement était pour protéger l’hébergeur plus que l’auteur du paste. Doit-on faire plus contre la censure ? J’ai tendance à penser UNIX (fait une chose mais fait-là bien) et je pense que ce n’est pas le but d’un service de paste de s’occuper de cela. Par contre, il serait intéressant de penser à une interraction possible avec des outils comme freenet qui sont spécifiquement conçus pour contrecarrer la censure.

  • freakzoid

    La théorie est qu’il ne peut en effet être tenu de modérer ce qu’il ne peut consulter.

    A partir du moment où l’utilisateur publie la clé, ce principe ne tient plus et si c’est illégal c’est logique que vous le retiriez.
    Le problème vient de l’utilisateur, la clé ne doit pas être public .. Si vous mettez une restriction sur le nombre de clics etc vous restreignez dans les mêmes temps les autres utilisateurs

  • Etienne

    Ce que dit Benjamin me semble sensé: changer de registrar pour un français. Y sont relous les américains avec la propriété intellectuelle. Au moins vous saurez mieux quels sont les éventuels risques et serez sans doute mieux protégé.

    Ce que propose maethor est pas mal aussi, sauf que c’est dommage de perdre du contenu qui, par exemple, est référencé dans ce blog (l’un ou l’autre snipet ou quoi).

    Donc peut-être mettre une durée par défaut de disons 2 mois, mais laisser la possibilité de l’augmenter, et supprimer les pastes sur simple demande si ils expirent après la durée par défaut (non, pas supprimer, remplacer le contenu par la demande de suppression, comme ça pas de 404). Si ils expirent avant les trois mois, laisser couler: ils auront disparu avant que les emmerdes arrivent.

    Après, on peut se demander si le chiffrage sert encore à quelque chose, le but étant justement de pouvoir dire: “rien à voir avec tout ça, peut rien faire pour vous”

  • roro

    Je pensais que 0bin, c’était pour poster du code ou du bla bla.
    Que foutait de la musique ou des liens de musique dans cette histoire ?

  • kontre

    C’est pour poster du texte brut. Après ce texte peut-être n’importe quoi !

    Poster un lien 0bin avec la clé en public permet d’éviter la lecture du contenu par des robots (qui n’exécutent pas le JS). Mais ça n’empêche pas la vérification manuelle…

  • Sam Post author

    En fait depuis la version précédente, 0bin permet aussi de poster des images.

  • Pickle

    Je crois que les gens, ou du moins un utilisateur lambda pense qu’en mettant ses liens de téléchargement, le contenu de ce qu’il a mis serait protégé des regards indiscrets.

    Je pense qu’ils pensent ainsi. En fait les données sont juste cryptées pour éviter que l’hébergeur aille fouiner dedans, et de se dire ‘les données sont protégées, on ne peut pas savoir ce qu’il y a à l’intérieur’, enfin un peu comme fait Mega(upload) quoi.

    Sauf qu’en utilisant ce genre de service ainsi, à savoir : on upload le dernier blockbuster, puis je fais péter l’url à tout le monde… eh bien le chiffrement devient juste useless.

    Pour limiter les effets collatéraux dû à ce genre de comportement, on peut imaginer un système de duplication et (faux) retrait automatique. Je m’explique :D

    Major X va sur 0bin, il découvre du contenu illicite
    Major X va tenter de contacter l’hébergeur, sauf qu’il y a un gros bouton ‘Signaler violation droits d’auteurs’. Alors il clique dessus, quelques instants après, l’url pour accéder au contenu est modifiée (et l’auteur sera notifié par email de la nouvelle adresse). De même, Major X sera notifié que le contenu a bien été supprimé et il pourra retourner tranquillement sur YouP…

    Ils vécurent heureux et eurent pour beaucoup de téléchargements.

  • sil

    Sauf que si Major X se déguise en Jean-Kevin, la supercherie va éclater au grand jour.

  • josé

    suggestion : permettre le clone d’un paste avec une nouvelle clé de chiffrement ?

    Une sorte de fork quoi.

  • Sam Post author

    C’est déjà possible avec la fonction “clone”, mais elle est buggée depuis la dernière version.

  • Pickle

    En fait, il n’y a même pas besoin de dupliquer le contenu. Il suffit de modifier le lien qui pointe dessus.

    a = b = 'url'
    a = None
  • Sam Post author

    C’est un peu plus complexe que ça : l’url est lié au nom de fichier, il faut donc regénerer un uuid, checker qu’il n’est pas utilisé, et renommer le fichier. Mais clone permet de faire plus que ça, par exemple de proposer une version éditée du paste original.

  • JEEK

    J’arrive après la guerre, mais bon…après la guerre, il y a encore la guerre !
    héhé’

    Bon alors je vais tacher de ne pas être trop tranchant mais :

    1- l’utilisateur en question est un âne, 0bin n’est clairement pas l’outil pour cette utilisation (il n’aurait même pas à couiner pour la perte des liens, il se sort ses p’tits doigts et puis voilà) ;

    2- z’avez eu raison de zapper les trucs (c’est vicieux un pénaliste, faut pas chercher à biaiser avec eux) ;

    3- le coup du lien qui se la joue Mac Leod (je meurs mais je reviens d’un coup de quikening), je ne le conseille pas des masses (vous ai je déjà dit qu’un pénaliste, c’est vicieux ?), un pénaliste drozophiloculteur à tendance sodomiaque pourrait faire ressortir le truc et faire assimiler ça à…une récidive (ce qui a tendance à brancher l’overdrive vers le maximum des peines quand ça gicle en juridiction pénale…si si) ;

    4- une évolution de 0bin ? baaaaaah pour en faire quoi ? un outil de diffusion de liens ? bof bof bof… z’allez quand même pas gérer de la crypto asymétrique sur 0bin pour que des Jean-Kevin LeBoulay (tiens, un jour faudra que j’arrête d’utiliser cette identité dans mes exemples de cours, j’vais surement finir par avoir un stagiaire qui se nomme comme ça ! lol) puisse faire looter des liens vers du pr0n de licorne rose qui chie des arc-en-ciels (ou de poney hein, j’suis pas sectaire) ?

    5- je sais, j’suis pas constructif ce soir (merde c’est déjà un peu plus tard que le soir mais cépagrave), quoique j’ai réussi à rester “on topic” en lâchant le mot pr0n ;

    6- vous ai je déjà dit que c’était vicieux un pénaliste ? et ne croyez pas que les français soient moins vicieux que les américains ;

    7- euuuh je ne sais plus ce que je voulais mettre en 7 mais bon, ça devait être rigolo je crois (ou pas)…

    Bon, si mon commentaire à faire sourire…c’est déjà ça ; pour le reste, je ne pense pas qu’il y ait à faire évoluer 0bin pour que ça réponde aux mêmes besoins que ceux de notre dévoreur de tapas.
    ;-)

  • Sam Post author

    Ok, finalement la majorité des avis exprimés semblent aller dans ce sens.

  • sil

    Autant je trouve la politique d’Online avec les noeuds Tor douteuse, c’est comme si ton bailleur te virait de chez toi parce qu’il te suspecte de tourner des films de pornographie infantile dans son appart. Autant, lorsqu’on recoit une plainte avec des arguments plausibles quand à la fraude, il est normal de retirer le contenu.

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.