Home » Idioties, Legislation

On va bien se marrer avec les tribunaux

6 août 2010 11 commentaires
tags : , ,
Download PDF

Ça y est, on (les fournisseurs d’accès à internet) sait enfin avec quelle sauce on va être mangé grâce à l’ARJEL (autorité de régulation des jeux en ligne, ils sont aux jeux en ligne ce qu’HADOPI est à la musique et au cinéma, et ce que la LOPPSI devrait être à tout le reste).

Par ordonnance de référé du 6 aout 2010, le tribunal de grande instance de Paris condamne les societés Numericable, Orange, SFR, Free, Bouygues Telecom, Darty et Auchan Telecom à suspendre tout accès depuis le territoire français au site stanjames.com par tout moyen possible, y compris couteux et intrusif.

C’est chouette, pour fêter le 1000em opérateur télécom déclaré à l’ARCEP (voir ici), les 7 plus gros sont obligé de filtrer un site. Heureusement qu’on peut encore utiliser les 993 autres.

C’est quoi, déjà, la graaaande phrase de la France ? Y’a pas « égalité » dedans ? non, j’ai du me tromper … en tout cas, ces 7 la, ils sont moins égaux que les autres (pour une fois).

11 Comments »

  • S. said:

    en tout cas a 22h42 depuis Orange ca marche toujours :)

    Pas pret vous avez dit ?

  • Melperol said:

    Juste pour compléter, je rappelle qu’une décision de référé est une décision d’urgence qui ne juge pas sur le fond… Il faut donc s’attendre a des suites :)

    Et sinon, on constatera dans la bonne humeur comme le mois d’aout est néfaste à la justice française, et aux greffiers en particulier, grace à ce superbe estrait du dispositif, page 24 :

    « mettre en oeuvre ou faire mettre en oeuvre sans délai, toute mesure de mettre en oeuvre toutes mesures propres à empêcher l’accès… »

  • Bruno (author) said:

    Ils sont fatigués, les pauvres ! Vivement la plage :)

  • Léo said:

    Bah c’est peine perdue pour l’ARJEL. Même s’ils parviennent à empêcher l’accès à ce site, ça reste une goute d’eau dans la mer. Il y a encore des centaines (milliers?) de sites de paris sportifs, jeux de casino et poker qui échappent à leur contrôle (encore heureux!).

  • corrector said:

    « empêcher l’accès » via un proxy quelconque?

    C’est strictement impossible!

  • Bruno (author) said:

    Empêcher l’accès, pour un FAI, ca peut se faire de multiples façons. Null-routage de l’IP qui héberge le site, insertion de fausses informations dans le DNS (contournable par l’utilisation d’un autre DNS), inspection des paquets avec envoi d’un TCP RST au client lorsqu’un méchant paquet est détecté …

  • corrector said:

    « inspection des paquets avec envoi d’un TCP RST au client lorsqu’un méchant paquet est détecté »

    Au pire des cas, il est *très facile* de filtrer les RST par pare-feu.

    Plus fin, on peut ignorer les faux RST au niveau TCP. Il suffit d’insérer un petit délais!

  • Bruno (author) said:

    C’est pas nécessairement à la porté de Mme Michu … pour l’instant :)

  • Melperol said:

    Mayday Mayday !
    J’ai relu la décision et je me rend compte que j’ai fait une redoutable erreur en lisant en diagonale (et en faisant autre chose) la derniere fois…
    Il ne s’agit pas d’une ordonnance de référé mais d’une JUGEMENT EN LA FORME DES REFERES et ça change tout, puisque pour le coup c’est bien un jugement sur le fond, c’est la teuhon.
    Pardon pardon.
    Et je vous invite à lire l’article de Maître Eolas d’aujourd’hui sur le sujet, qui explique notament la différence, et la portée possible de ce jugement

    http://www.maitre-eolas.fr/post/2010/08/18/L-affaire-StanJames.com-(TGI-Paris%2C-6-ao%C3%BBt-2010)

  • corrector said:

    « C’est pas nécessairement à la porté de Mme Michu … pour l’instant :) »

    Il suffirait de retarder les RST, mais je n’ai rien trouvé, ni comme option, ni dans iptables comme fonction retard. (Bon on peut sortir le paquet sur une interface tun, mettre un programme qui fait ligne retard, le remet dans un tun, mais beurk.)

    Idéalement, il faudrait accepter un RST, donc l’envoyer à TCP, que TCP vérifie qu’il est valable (in window), puis que TCP le mette en attente quelques secondes, et si après la fin du délais rien n’a été reçu par ce TCP, le prendre en compte; sinon, vérifier qu’il est toujours valable : si oui, le remettre en attente, sinon, générer une alerte, augmenter le délais précité, et ignorer le RST.

    Élémentaire!

  • corrector said:

    « blablabla RST blablabla »

    Et pareil pour FIN, pendant qu’on y est!

    Les deux ont la propriété que rien ne sera reçu *après*. (Attention à la signification de « après »!)

    Plus délicat, le segment normal bidonné. C’est comme un puzzle, avec des pièces tombées d’un autre. Certainement traitable.

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.


2 + = sept