On va bien se marrer avec les tribunaux

Ç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).


Publié

dans

,

par

Étiquettes :

Commentaires

11 réponses à « On va bien se marrer avec les tribunaux »

  1. Avatar de S.

    en tout cas a 22h42 depuis Orange ca marche toujours 🙂

    Pas pret vous avez dit ?

  2. Avatar de Melperol

    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… »

    1. Avatar de Bruno
      Bruno

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

  3. Avatar de Léo
    Léo

    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!).

  4. Avatar de corrector
    corrector

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

    C’est strictement impossible!

    1. Avatar de Bruno
      Bruno

      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é …

  5. Avatar de corrector
    corrector

    « 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!

    1. Avatar de Bruno
      Bruno

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

  6. Avatar de Melperol

    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)

  7. Avatar de corrector
    corrector

    « 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!

  8. Avatar de corrector
    corrector

    « 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.

Laisser un commentaire

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