Minitel : résurrection du serveur EDTA

Dans mon précédent billet portant sur du "hacking" Minitel, je parlais de la marche à suivre pour héberger un serveur Minitel derrière une ligne téléphonique, à l'aide d'un modem et d'un serveur applicatif.

Pendant ce temps, j'ai eu l'occasion de suivre les travaux d'Alexandre Montaron (alias « Ca/\/al »), qui a monté EDTA, son propre serveur Minitel privé à l'époque où c'était encore le seul mode de communication "en ligne" accessible au public français.

Lorsqu'il m'a envoyé un mail, il y a six semaines, pour me dire qu'il avait remis sur pied une machine avec des backups (de fin 1992 !) faisant tourner le serveur, c'était là une invitation à allumer le Minitel 1B trônant encore sur mon bureau, rebrancher le câble série, et partir à l'aventure.

J'aurais aussi pu accéder à EDTA en me logguant directement par telnet depuis une console Linux, mais j'étais désireux de l'expérience d'origine, avec la poussivité des 1 200 bauds, en niveaux de gris sur l'écran CRT du terminal d'origine.

À cheval entre deux époques

Le serveur n'est hélas pas toujours actif. Mais lorsqu'il l'est, il est accessible aussi bien par Telnet (avec une interface similaire à ncurses qu'on peut utiliser dans un Xterm) que par netcat (redirigé vers un port série pour un accès en "mode Vidéotex").

C'est un serveur dont on pourrait dire qu'il est à cheval entre deux époques, l'époque « Minitel » et l'époque « Internet ».

Je n'ai eu l'occasion de m'y connecter qu'une fois, donc il m'est hélas impossible de publier des photos de mon Minitel affichant EDTA comme j'aurais souhaité le faire. Mais ce fut néanmoins une expérience particulièrement fascinante.

La première chose qui frappe est la lenteur de l'affichage. Malgré tous les efforts d'optimisation du code Vidéotex, on se heurte rapidement aux limitations du matériel de l'époque. Le débit descendant équivaut à 120 caractères par seconde en l'absence de codes couleur, de lettres accentuées ou d'effets (pseudo-)graphiques. Il s'agissait d'une époque où il était encore difficile d'imaginer qu'on puisse disposer trente ans plus tard de connexions à Internet un million de fois plus rapides et que l'on pourrait rester en ligne en permanence, le tout sans occuper la ligne téléphonique. Au fur et à mesure que j'évolue dans les différents menus du serveur, le temps que la page s'affiche me laisse le temps de réfléchir au choix que je ferai. Le temps d'affichage invite à la patience et à réfléchir avant de faire son choix, comme s'il s'agissait d'une partie d'échecs.

Une chose est sûre : il fallait se munir de patience pour se connecter sur ce genre de serveurs, et se réserver un petit crénau horaire dévoué à la rédaction de messages sur ce que nous appellerions maintenant un forum. À l'époque, il fallait exécuter le rituel consistant à composer le numéro du serveur privé et de prier que ses trois lignes ne soient pas déjà occupées par d'autres utilisateurs. Enfin, le temps est compté : tout d'abord par France Télécom (sans objet dans mon cas, car je me connectais via netcat), mais aussi par le serveur privé, pour assurer une certaine équité entre les utilisateurs et éviter que trop d'utilisateurs simultanés, que ce soit par cupidité ou par négligence, s'accaparent les trois lignes téléphoniques dont disposait EDTA à l'époque. Le système n'hésite pas à déconnecter abruptement tout utilisateur dépassant vingt minutes de connexion ; le décompte des minutes restantes avant la fin de la session étant indiqué tout en haut de l'écran.

Une sorte de voyage temporel

C'est néanmoins un drôle de sentiment qui m'envahit lorsque j'arpente les menus d'EDTA. Le fait que le disque dur de la machine d'origine ait rendu l'âme et que les seules backups disponibles remontent à fin 1992 donnent une impression désolée. La lecture des forums témoigne d'une présence assidue des membres qui étaient encore dessus à l'époque, jusqu'à ce que tout s'arrête brusquement. Mettre les pieds pour la première fois sur ce serveur vingt-trois ans après la date de son archivage ne donne pas seulement l'illusion d'être un étranger, mais aussi celui d'être un voyageur temporel.

D'un seul coup, mon Minitel fait un bip, et le mot « Missive ! » s'affiche sur la ligne tout en haut de l'écran. Ca/\/al savait que j'étais là et cherchait à me parler ! Il m'a fallu un peu de temps avant de comprendre que cette indication signifiait qu'il fallait que je me rende sur la page « Multi-dialogue » pour lire mon message. Mais lui était connecté en Telnet, et ayant délibérément choisi l'inconfort du vrai terminal, je ne pouvais pas naviguer aussi rapidement que lui.

Le système de multi-dialogue qu'a fait Ca/\/al ressemble un peu à une version dépouillée d'IRC, pour ceux qui savent encore ce que c'est. Imaginez un logiciel de messagerie instantanée, mais qui n'affiche pas l'historique des messages. Seuls le dernier message de son interlocuteur et celui qu'on est en train d'écrire apparaissent à l'écran. De plus, si l'interlocuteur envoie un autre message pendant qu'on répond au premier, on ne le voit pas instantanément apparaître à l'écran ; il faut alors abandonner son message en cours pour le lire, ou le terminer pour répondre de manière décalée à la missive suivante.

Le système est rudimentaire, mais efficace. Le seul point délicat reste le clavier du Minitel, qui exige un petit temps d'adaptation et de ne pas dépasser les 7,5 caractères par seconde du fait du débit ascendant de 75 bauds et l'absence de mémoire tampon entre le clavier et le modem. De plus, je suis obligé de maintenir la touche "Maj" enfoncée lorsque j'écris, car le Minitel est en mode « Verr. Maj. » par défaut et n'a pas de touche pour le désactiver.

Et pourtant, c'est comme ça qu'on communiquait, il y a vingt-cinq ans.

Mode d'emploi

Je finirai sur une note plus technique, pour vous expliquer comment j'ai fait pour pouvoir profiter de ce serveur avec un vrai Minitel relié à une machine sous Linux.

Tout d'abord, il faut régler les paramètres du port série. Dans mon exemple, il s'agit de /dev/ttyS0 ; substituez-y le bon chemin, en particulier si vous utilisez un convertisseur RS232 vers USB. Les réglages se font avec la commande suivante :

# stty -F /dev/ttyS0 1200 raw cs7 parenb -parodd opost onlcr cread \
  hupcl -echo -echoe -echok

Le Minitel active l'écho local lorsque son modem est raccroché (autrement dit, lorsque la lettre F est affichée en haut à droite de l'écran). Or, en temps normal, cet écho local est désactivé et c'est le serveur distant qui s'occupe du "retour" visuel lorsqu'on frappe au clavier. Il faut donc désactiver l'écho local à la main : appuyez sur Fnct et T simultanément, relâchez ces touches et tapez E et c'est chose faite. Sinon, tout ce que vous taperez s'affichera en double.

Enfin, la dernière étape pour profiter du spectacle est de saisir la commande de connexion :

# nc edta.hd.free.fr 4586 > /dev/ttyS0 < /dev/ttyS0

Avec un peu de chance, vous tomberez pile à un moment où le serveur est allumé (il ne l'est pas toujours) ; dans ce cas, il ne reste plus qu'à l'explorer et à l'admirer.

Conclusion

Le travail de Ca/\/al reste tout de même fascinant, même après toutes ces années pendant lesquelles on décrétait le Minitel comme obsolète. Mais nos deux initiatives respectives vont en réalité ensemble : d'une part, j'avais réussi à mettre en place l'infrastructure nécessaire pour mettre en place un serveur Minitel ; d'autre part, Ca/\/al fournit une implémentation d'un serveur Minitel, mais dépourvu en l'état d'interface avec la téléphonie analogique.

Chapeau bas, en tout cas, pour avoir pris le temps de refaire découvrir les arcanes d'un tel microserveur Minitel.

YouTube et Content ID : une copie à revoir sans attendre

Cela fait maintenant presque un an depuis que j'ai supprimé mon compte YouTube. Il s'agissait d'une décision initialement prise sur un coup de tête, mais avec le recul, je me rends compte que c'était la conséquence d'un ressenti d'une expérience de plus en plus nauséabonde sur le site. Cela a eu pour conséquence de casser une vidéo que j'avais en « embed » en guise d'illustration sur un de mes articles, mais que je n'ai pas eu le temps de remplacer.

Ah, qu'est-ce que j'aurais bien aimé pouvoir saisir ÇA dans leur formulaire...
Parfois, j'aurais bien aimé faire ça.

Le fautif principal de cette mauvaise expérience pour moi est Content ID. Ce système est initialement prévu pour empêcher les utilisateurs de soumettre du contenu en violation des droits d'auteur d'autrui. Les détenteurs des droits d'auteur peuvent y soumettre des fichiers de référence, et Content ID se charge alors de scanner systématiquement toute nouvelle vidéo publiée sur le site pour trouver des correspondances. En cas de correspondance, une réclamation automatique est envoyée à celui qui a uploadé la vidéo en question ; la vidéo peut alors être bloquée ou se voit truffée de publicités au profit des « ayants-droits ».

Je comprends l'initiative, mais celle-ci est hélas totalement pervertie par un système mal conçu, fonctionnant dans un mode de présomption de culpabilité et avec des voies de recours plus que lacunaires. Certaines de ces situations m'ont rendu extrêmement furieux ; mais au lieu d'écrire un article injurieux envers Content ID comme il en existe des cents et des milles, je vais calmement détailler dans cet article mes propres déboires liés à Content ID, et tenterai d'y apporter des commentaires constructifs et sans animosité.

Je ne me considère pas cinéaste, et je ne faisais heureusement pas partie de ceux qui vivent exclusivement des revenus générés via YouTube. Je suis juste un amateur qui aime bien avoir une caméra dans les pattes de temps en temps. En particulier, lorsque je sonorise mes vidéos avec des morceaux de musique, je m'assure de pouvoir le faire en toute légalité et choisis généralement des œuvres CreativeCommons.

Sale pirate

Premièrement, j'avais eu l'occasion d'enregistrer un concert de musique classique pour lequel j'avais la permission de filmer. En la postant sur YouTube, une partie de la bande son est identifiée comme du contenu appartenant à Universal (UMG Publishing Group, plus exactement). Or, non seulement il s'agissait d'une interprétation unique d'un morceau de Dvořák, dont la musique fait désormais partie du domaine public, mais le morceau avait en plus été identifié comme du Vivaldi. J'ai dû contester cette réclamation deux fois : la première fois, j'avais rédigé ma contestation de manière un peu maladroite et Universal avait alors refusé de retirer sa plainte. Ce n'est qu'en supprimant la vidéo, en la réuploadant à nouveau et en répétant le même processus en prenant cette fois le temps de rédiger mon message soigneusement et en sourçant toutes mes affirmations qu'Universal a daigné se retirer. Au total, une vingtaine d'heures de perdues sur ce genre de futilités, en comptant le temps d'uploader la vidéo d'une heure et demie sur la petite connexion ADSL que j'avais à l'époque. À raison de deux fois deux gigaoctets à 100 ko/s, un calcul plus détaillé sera laissé en tant qu'exercice du lecteur.

Deuxièmement, il m'est arrivé plusieurs fois d'avoir vu de la musique CreativeCommons identifiée comme telle, mais avec un propriétaire répondant au doux nom de « AdRev for a 3rd party ». Ces réclamations, qui suscitent à juste titre de nombreuses interrogations, ont toujours été retirées par la suite après contestation, où je précisais toujours que ce AdRev n'était pas le dépositaire des droits d'auteur et que cette réclamation était sans objet.

D'après ce que j'ai compris, AdRev est juste un intermédiaire qui permet à des compositeurs de monétiser l'inclusion de leurs musiques dans des œuvres dérivées. Or certains de ces morceaux sont sous licence CreativeCommons BY-NC-SA, ce qui m'oblige donc de sortir mes vidéos sous cette même licence. Or cette licence interdit toute exploitation commerciale. Dans ce cas, AdRev serait en violation de ma propre licence en touchant de l'argent sur mon travail sans mon autorisation.

Là où le bât blesse est que, lors d'une fausse identification (ce qui m'est arrivé pas moins d'une fois sur deux !), il est tout bonnement impossible de trouver dans le formulaire de contestation une case qui signifie « L'œuvre identifiée n'est pas la bonne » et qui me permettrait de saisir la référence correcte. Dans ces cas-là, j'ai toujours coché la case « J'ai une licence ou une autorisation écrite » même si dans les faits, je n'ai absolument rien de tout cela : après tout, nul besoin de posséder de licence pour une œuvre qui n'a pas servi à la réalisation de sa vidéo. Il n'y a donc pas d'autre choix que de commettre un délit de parjure pour obtenir le respect de ses droits dans cette situation.

La capture d'écran ci-dessous illustre avec justesse à quel point mes options en cas de contestation sont ridicules.

Liste des voies de recours
Il leur manque des cases. (Image tirée des forums Jamendo)

Cependant, cela reste impressionnant de voir que Google a malgré tout tenté l'aventure de mettre en place ce genre de systèmes. Il ne leur manquerait plus de substituer à la langue de bois un peu d'humilité face à ses dysfonction­nements.

Une technologie mal utilisée

En me fondant sur mes propres expériences et les témoignages que j'ai pu lire ou entendre, mes suggestions pour améliorer Content ID sont les suivantes :

  1. Pour chaque réclamation à l'encontre d'une vidéo, permettre de vérifier que l'entité revendicatrice soit bien dans son bon droit. Par exemple, il est difficile de savoir pourquoi AdRev serait habilitée à administrer les droits d'un morceau sous une licence CreativeCommons interdisant l'exploitation commerciale.

    YouTube doit être plus transparent pour que ses utilisateurs puissent rédiger des messages de contestation informées et relever plus facilement les cas de fraude. Une possibilité serait donc d'imposer la publication des documents de cession de droits ou toute autre preuve similaire. Le corollaire serait de considérer nulle et non avenue toute réclamation sans preuve et de lourdement sanctionner les contrevenants, aussi puissants qu'ils soient.

    Il faudra également ajouter deux cases dans le formulaire de contestation : « Je conteste la paternité de ce contenu » pour demander des preuves que l'entité a bien le droit d'exploiter l'œuvre litigieuse, et « Cette réclamation est entièrement infondée » pour tous les autres cas.

  2. Ne pas refaire à l'identique les réclamations déjà retirées. Par exemple, si une œuvre avait été identifiée à 5 min 39 s et que la réclamation est retirée, ce serait bien de ne pas me harceler à nouveau six mois plus tard à propos de la même œuvre, cette fois identifiée à 5 min 40 s. Je ne suis hélas pas allé jusqu'à voir s'ils allaient continuer à me faire autant de réclamations qu'il y a de secondes dans la vidéo. Le fait que ce soit un robot qui génère ce genre de réclamations rend la situation particulièrement pathétique.

  3. Admettre la possibilité de faux positifs ou de mauvaises identifications. Cela signifie surtout ajouter une case correspondante à ce cas de figure dans le formulaire de contestation. Il est inconcevable de penser que ce genre de systèmes soit infaillible ; ce sont des êtres humains tout aussi faillibles qui l'ont développé. La plus fondamentale des évidences est donc d'envisager la possibilité que Content ID se soit « trompé ». Supposer le contraire est naïf et arrogant.

  4. Conserver une présomption d'innocence à tout moment. Content ID prend une position de juge et de partie en supprimant immédiatement et sans aucun procès toute vidéo suspecte, au lieu de laisser à l'utilisateur l'ayant uploadée la possibilité de se défendre avant le verdict final.

    Même si une réclamation automatique n'entraîne pas systématiquement la suppression de la vidéo, elle supprime néan­moins les revenus publicitaires versées au propriétaire de la vidéo, ce qui est extrêmement grave étant donné qu'un certain nombre de YouTubeurs vivent exclusivement de ce site. Le propriétaire de la vidéo n'est en outre jamais dédommagé lorsque la réclamation est retirée.

    Le système actuel laisse 30 jours calendaires à l'entité revendicatrice d'examiner une revendication contestée. Il faudrait renverser cela : il incombe à cette entité elle-même d'examiner sous 30 jours calendaires toute vidéo repérée par Content ID. Tant pis s'il faut employer plus de petites mains qu'avec le système actuel. La présomption d'innocence doit s'appliquer à tous en toutes circonstances.

  5. Être exempt de réclamations Content ID ne devrait pas être un prérequis pour sortir sa vidéo sous CreativeCommons CC-BY. Content ID repère également des morceaux de musique sous CreativeCommons. Selon la variante de Creative­Commons, il est tout à fait légal de sonoriser sa vidéo avec un tel morceau. Dans ce cas, on peut indiquer que la vidéo que l'on publie est sous licence CreativeCommons CC-BY.

    En revanche, l'option « licence CC-BY » n'est pas disponible si Content ID a trouvé des contenus tiers dans la vidéo concernée. J'ignore quelle est la justification, mais quelle qu'elle soit, elle est illogique et stupide.

  6. Ajouter des informations de licence aux fichiers de référence. Avec le système actuel, les détenteurs de droits d'auteur sur les œuvres qui sont soumises à la base de données des fichiers de référence n'ont que trois options concernant la politique à appliquer en cas de corres­pondance : bloquer, monétiser en insérant de la publicité, et laisser passer.

    Cependant, cela me semble insuffisant. Le système présume que les fichiers de référence sont tous sous une licence « tous droits réservés », qui interdit toute réutilisation sans autorisation sauf dans les cas prévus par la loi. Demander quelle politique appliquer ne suffit pas ; il faudrait également demander aux détenteurs de préciser si le contenu est sous CreativeCommons, et si oui, quelle variante.

    Cela aurait également l'avantage de réduire sensiblement les faux positifs liés aux contenus CreativeCommons qui sont réutilisés dans une vidéo YouTube.

    J'irais même jusqu'à dire que si YouTube veut permettre à ses utilisateurs de publier leurs vidéos sous licence CreativeCommons, il faudrait aller jusqu'au bout et leur donner le choix de toutes les autres variantes, comme BY-ND ou BY-NC-SA. La situation actuelle suggère que YouTube considère cela plus comme un pis-aller qu'une vraie fonctionnalité.

Conclusion

YouTube considère que les utilisateurs qui sont dans leur bon droit ne rentrent que dans quatre catégories :

  • le cas du contenu original ;
  • le cas où on détient une licence ou une autorisation pour inclure le contenu ;
  • le cas où la loi autorise la réutilisation du contenu (ex. « fair use ») ;
  • le cas où le contenu est dans le domaine public.

J'ai pourtant mis en évidence qu'il y a beaucoup d'autres cas, et que les situations où une réclamation de copyright n'a pas lieu d'être sont plus nombreuses que cela.

Les déboires liés à ce système sont nombreux, et bien que cela n'ait pas été le cas pour moi, il semble apparent que Content ID soit devenu un instrument de censure malgré lui.

Comme toute technologie, Content ID est à double tranchant. Je ne peux que constater que cela fait au moins cinq ans que cette technologie est mal utilisée et qu'elle cause plus de problèmes qu'elle n'en résoud. Elle met trop de pouvoir entre les mains des soi-disants « ayants-droits », à qui on donne bien trop de droits que ce qu'autorise la loi. Il faut garder à l'esprit que ni la loi américaine ni la loi française n'imposent aux plateformes d'hébergement de vidéos comme YouTube de mettre en place un système comme Content ID.

Les problématiques liées au droit d'auteur sont trop complexes pour être laissées à des machines. J'aimerais juste pouvoir faire des vidéos tranquillement, sans être embêté inutilement pour des pécadilles alors que je suis parfaitement dans mon bon droit. Je prends déjà suffisamment le temps pour m'assurer que j'ai légalement le droit de publier une vidéo avant de le faire. Ne me faites pas perdre des jours de travail à me débarrasser d'accusations frivoles de contrefaçon. Après tout, j'ai mieux à faire.

Posté par x0r à 1 commentaire • Tags : copyright youtube content id fingerprint

Orange voit rouge

EDIT : Archive.org n'a eu le temps de mirrorer qu'une version obsolète de siproxd_orange souffrant d'un bug bloquant au login. Ce n'est pas la peine d'essayer de le faire marcher et je ne répondrai pas aux mails ou commentaires à ce propos.

C'est avec peine et regret que j'ai pris la décision de suspendre pour une durée indéterminée tous les liens de téléchargement de siproxd_orange, ainsi que l'accès à son dépôt BitBucket.

Je fais en effet l'objet de pressions de la part d'Orange visant à me faire cesser le développement et la diffusion de siproxd_orange. Après avoir consulté plusieurs personnes dont un avocat spécialisé en droit d'auteur, j'ai estimé plus prudent d'abandonner la diffusion de ce projet.

Je tiens d'abord à remercier toutes les personnes qui ont manifesté leur intérêt pour siproxd_orange, que ce soit en le téléchargeant, en postant des liens vers ce blog sur d'autres sites, en commentant sur les nombreux billets à ce sujet ou en rapportant des bugs. Mais je tiens aussi à ajouter que cela ne signifie aucunement la fin de l'aventure.

Ma motivation : l'interopérabilité

Ma motivation principale était celle d'utiliser un PBX Asterisk sous Linux sur ma ligne Livebox.

La solution la plus simple était d'utiliser l'interface analogique en enfichant une carte FXO/FXS dans la machine, mais cette solution n'est pas sans lacunes. En effet, la Livebox ne signale pas l'état décroché ou raccroché de la ligne à l'aide de signaux électriques. Ce défaut peut entraîner des problèmes potentiellement graves : par exemple, sans hacks à base de « busydetect », le PBX maintient la ligne occupée indéfiniment lorsque la personne à l'autre bout de la ligne raccroche en premier.

En voulant écrire des scripts de supervision Livebox pour Nagios, je suis tombé sur une interface qui exposait une partie des paramètres SIP utilisés par la box : proxy SIP sortant, login, etc., mais bien évidemment pas de mots de passe.

J'ai ensuite constaté que l'application Livephone pour Windows s'enregistrait directement auprès des serveurs SIP d'Orange, à condition de lui fournir les identifiants de l'espace client Orange.

J'ai alors décidé de creuser plus loin afin de savoir quels étaient les identifiants SIP utilisés pour s'authentifier auprès du proxy SIP Orange. Il s'avère que le client SIP officiel n'utilise aucun mot de passe, mais obtient un des secrets nécessaires pour l'échange RFC 2617 (authentification HTTP Digest) par une méthode totalement propre à Orange. Ces secrets étaient impossibles à obtenir sans décompiler l'application d'origine. Impossible donc d'exploiter sa ligne SIP sans autre chose que les applications proposées par Orange.

C'est en modifiant le processus d'authentification qu'Orange cassait l'interopérabilité avec les autres implémentations SIP conformes à la RFC 3261, empêchant ceux-ci de s'enregistrer directement auprès de l'infrastructure d'Orange.

Je m'inscrivais donc dans une double démarche d'interopérabilité : la possibilité d'utiliser un terminal SIP « RFC 3261 » avec ma ligne téléphonique comprise dans l'abonnement que je paye d'une part, et la réimplémentation des extensions propriétaires d'Orange sous Linux et FreeBSD d'autre part.

L'exception de décompilation

C'est dans cette démarche d'interopérabilité que j'estimais être en droit de me prévaloir des dispositions de l'article L122-6-1 du Code de la propriété intellectuelle, qui dispose entre autres que :

IV. La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes :

1° Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ;

2° Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1° ci-dessus ;

3° Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité.

Les informations ainsi obtenues ne peuvent être :

1° Ni utilisées à des fins autres que la réalisation de l'interopérabilité du logiciel créé de façon indépendante ;

2° Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante ;

3° Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.

Le seul aspect qui posait vraiment problème, c'était la question de savoir si j'avais le droit de mettre à disposition le code source de siproxd_orange, qui contenait du coup des informations d'interopérabilité obtenues par décompilation. J'étais en outre obligé de diffuser le code source, car siproxd est sous licence GPL et son système de plugins fonctionne par édition de liens dynamiques. Mais les jurisprudences autour de l'exception de décompilation sont rares et il incomberait à moi de prouver que mon travail satisfaisait toutes les conditions pour me prévaloir de cette exception, ce qui n'est pas certain. L'article de François Pellegrini à ce propos est une lecture intéressante.

J'avais donc prédit avec justesse que la réalisation de ce plugin pour siproxd était « à la limite de la légalité ». La question de savoir si mon travail était licite ou illicite était ténue.

J'ai pris des risques en proposant siproxd_orange ici. J'aurais pu faire le choix de continuer malgré les pressions et, si nécessaire, me défendre au tribunal. Mais dans le pire cas, je risquerais de perdre plus que juste la mention « néant » dans mon casier judiciaire.

Conclusion

Je suis vraiment triste de devoir prendre ce genre de décisions. Je suis triste à l'idée de décevoir le grand nombre de personnes qui semblaient intéressés par ce projet. Mais je suis surtout triste de devoir prendre des décisions contraires à mes valeurs de curiosité scientifique et de partage du savoir.

Il s'agissait de mon plus gros projet de rétroingénierie jusqu'à maintenant. Même en mettant hors ligne les archives des sources de siproxd_orange, je n'accepterai pas l'idée d'avoir sacrifié tous ces week-ends, toutes ces soirées et toutes ces pages de mon cahier de brouillon en vain.

L'étape d'après serait d'obtenir les informations nécessaires à l'interopérabilité par une autre voie que la décompilation, par une méthode qui m'autoriserait à les publier. Je n'en dirai pas plus ; je sais désormais que des salariés d'Orange ouvertement hostiles à ce projet me lisent.

En tout cas, je n'ai pas dit mon dernier mot.

Posté par x0r à 44 commentaires • Tags : sip orange livebox siproxd_orange voip legal décompilation reverse engineering

siproxd-orange version 0.2.1

Mise à jour : RIP siproxd_orange :(

En cette veille de journée de deuil national, la version 0.2.1 de siproxd_orange est désormais disponible au téléchargement.

Cette version est une release "hotfix", corrigeant plusieurs bugs dont un bloquant. Orange a en effet décidé à partir d'aujourd'hui d'interdire l'accès au client Livephone sous Windows, qui était en téléchargement jusqu'à il y a quelques mois. Or siproxd_orange se faisait encore passer pour le client Windows, d'où une impossibilité de s'authentifier.

D'autres bugs plus ou moins importants ont également été résolus dans la foulée ; l'un d'entre eux empêchait encore une fois le bon fonctionnement des appels entrants dans certaines situations.

Téléchargements

Vous pouvez télécharger les archives à l'une des adresses suivantes :

x0r.fr en deuil

J'ai décidé d'habiller x0r.fr en noir pour les journées du 7 et 8 janvier 2015, afin d'exprimer toute mes pensées et mes condoléances aux victimes de l'attentat abject survenu dans les bureaux de Charlie Hebdo. J'ai du mal à trouver les mots qui traduiraient le mieux ce que je ressens en ce moment.

J'évite habituellement toute polémique sur ce site Web ; une de ses grandes lignes éditoriales est d'être neutre, encyclopédique et factuel dès que possible. Néanmoins, il me paraît opportun de se rappeler qu'il a parfois fallu verser du sang afin d'obtenir les libertés dont nous jouissons aujourd'hui et qu'il est nécessaire de les défendre à tout prix pour que nous puissions continuer à faire ce que nous aimons dans la vie en toute sérénité.

En tant que blogueur, même si j'ai toujours publié des billets purement techniques ici, je me sens particulièrement concerné par cette grave atteinte à la liberté de la presse. Une chose est sûre selon moi : les conséquences politiques de cet acte seront lourdes, et ces conséquences toucheront sans aucun doute tout le monde, d'une manière ou d'une autre.

Posté par x0r à 0 commentaire • Tags : sip orange voip livephone hack

Autohébergement : le dilemme du matériel

J'avais déjà théorisé dans un post précédent les raisons pour lesquelles l'autohébergement pourrait peut-être revenir en vogue parmi les personnes les plus curieuses ou les plus sensibilisées aux problématiques sous-jacentes.

L'une des considérations principales et là où se font les choix techniques les plus importants est le choix du matériel serveur ; j'entends dans ce cas par « serveur » toute machine remplissant la fonction de serveur, fournissant des services accessibles à des postes dits « clients », et non pas le matériel spécialement dédié à cette fonction (type Dell PowerEdge ou HP ProLiant pour ne citer que quelques-uns).

L'autohébergement ne consiste pas nécessairement à transformer son domicile en datacenter avec des dizaines de serveurs et une climatisation qui tournent à fond les ballons. Dans la plupart des cas, il n'y en a absolument pas besoin. Le but est simplement d'héberger ses propres services informatiques tout en gardant la maîtrise totale sur l'infrastructure. Les exemples de services autohébergés sont nombreux :

  • consulter et stocker ses e-mails sur un serveur mail chez soi au lieu de dépendre d'un prestataire externe ;
  • héberger un site Web ;
  • centraliser le stockage de fichiers multimédia ;
  • déployer de la voix sur IP chez soi pour des besoins spécifiques en téléphonie...

Je ne parlerai pas des avantages et des inconvénients de l'autohébergement, car je suppose que le choix a déjà été fait ; cet article s'adresse surtout à ceux qui s'interrogent sur les choix matériels. Néanmoins, il convient de rappeler qu'un des avantages principaux de l'autohébergement est celui de la maîtrise intégrale du matériel réseau et serveur chez soi, et qu'il est donc possible de choisir le matériel adapté parmi une gamme très large de possibilités.

Avant de commencer, je précise que mes prises de position dans cet article sont le fruit de choix que j'ai moi-même faits face à mes propres besoins et à ma propre situation, et que les meilleurs choix pour moi ne sont pas forcément les meilleurs pour vous.

Le matériel serveur

Comme je le disais, on dispose d'une large gamme de possibilités quant à la machine jouant le rôle de serveur, mais il est possible de les diviser en trois catégories :

  • le matériel dit "embarqué" : par exemple, un Raspberry Pi, ou une plateforme matérielle comme celles de Soekris. Ces matériels ont l'avantage d'être minimalistes, silencieux, très peu encombrants et de consommer très peu (quelques watts), mais les pièces de rechange risquent d'être difficiles à trouver ou d'être onéreuses ;

  • les PC de bureau : une machine neuve construite à cet effet, ou un vieux PC de bureau d'un âge compris entre 6 et 10 ans dont on a peut-être augmenté le stockage ou la RAM, font l'affaire selon les besoins. Les pièces de rechange sont très faciles à trouver, relativement peu chères, et de telles machines tiennent aisément des uptimes tout à fait respectables qui se comptent en centaines de jours.

  • les matériels dédiés « serveur » : si on a un peu plus de budget, la possibilité de s'isoler du bruit, et des colocataires complaisants, un serveur d'occasion pourrait être une option. Il s'agit de matériel vendu aux entreprises, donc moins sujet à l'« obsolescence programmée », ayant comme atout principal la fiabilité et laisse la possibilité de se procurer des pièces détachées pendant longtemps.

Personnellement, j'ai fait le choix de partir sur un PC de bureau, autant par opportunisme que par manque d'argent (il s'agissait d'une machine qu'un voisin voulait mettre aux encombrants alors qu'il suffisait de remplacer l'alimentation et ajouter des disques durs et une carte graphique, et j'étais étudiant à l'époque), mais cette machine a été très fiable jusqu'à maintenant et a déjà dépassé 400 jours consécutifs d'uptime.

Le matériel réseau

J'entends par matériel réseau tout l'équipement nécessaire pour la mise en réseau de ses machines, c'est-à-dire les commutateurs (switchs) et les routeurs. Il faut au moins un routeur et, dans la plupart des cas, au moins un switch.

Le routeur doit permettre la redirection de ports, ou un "mode DMZ". Je suis parti sur un TP-Link TL-WR1043ND, étant donné qu'il propose du wifi N et un routage NAT IPv4 en gigabit tout en restant tout à fait abordable, et marche assez bien avec la toute dernière version d'OpenWRT. Je préfère reflasher mes routeurs avec OpenWRT, car cela permet parfois de débloquer des fonctionnalités absentes du firmware initial, comme la prise en charge de VLANs ou la prise en charge d'IPv6. Il y a cependant peut-être de meilleurs choix possibles en ce moment.

J'ai personnellement horreur du Wi-Fi parce que j'ai le sentiment que ça ne marche jamais de manière robuste, donc je préfère tout câbler. Pour cette raison, j'avais pris deux switchs TP-Link SG-1008D complètement passifs, qui sont bon marché et font bien leur travail, mais je les ai depuis remplacés par des TP-Link TL-SG3210 qui sont administrables, ont plus de fonctionnalités et gèrent les VLAN.

Heureusement, la plupart du matériel réseau, aussi bien ceux destinés au grand public que certains destinés aux PME, fonctionne sans ventilateur et se fait relativement discret.

Le matériel que je mentionne suffit largement pour un réseau "simple", mais comme je suis en train de mettre en place de la VoIP, j'ai envie de jouer avec des VLAN séparés pour la voix et les données notamment. Mais l'essentiel reste de retenir que pour héberger des services chez soi, il n'y a nul besoin de mettre 2 000 € dans du matériel réseau.

Étant donné l'obsolescence du protocole IPv4, je choisis si possible du matériel compatible IPv6, même si Orange ne le propose pas encore aux particuliers au moment où j'écris ces lignes. Les deux exceptions notables chez moi sont mes téléphones IP et mon imprimante réseau, mais ceux-là seront remplacés à un moment opportun.

Le facteur d'acceptation conjugale

J'ai déjà entendu l'histoire d'un collègue qui s'est retrouvé devant le dilemme suivant : jeter le contenu entier d'une baie 42U qu'il possédait chez lui, ou se retrouver divorcé de son épouse. Il avait alors choisi de jeter sa baie 42U, mais cela n'a pas pu empêcher le divorce.

On sort ici peut-être du cadre strictement technique, mais il s'agit d'un sujet qui peut aussi bien stimuler que tuer dans l'œuf tout projet d'autohébergement.

Le Spousal Acceptance Factor (que je traduirais par « facteur d'acceptation conjugale ») est le terme généralement utilisé pour exprimer la probabilité de l'approbation d'un projet de bricolage par les autres personnes du foyer. Cela ne s'applique pas qu'à l'autohébergement, mais à n'importe quel projet, comme de la domotique ou la mise en place de téléphonie IP. Le terme le plus répandu est Wife Acceptance Factor, mais je préfère employer un terme non genré.

Il est tout à fait regrettable de voir que certaines personnes utilisent ce terme sans le définir de manière précise (ou retiennent des critères entièrement subjectifs), voire de manière méprisante. C'est pourquoi je souhaite aller un peu plus loin que de basses considérations sexistes qui masqueraient le vrai problème.

Le point commun de toutes les sources évoquant ce facteur que j'ai pu lire montre que cela peut se résumer à une liste de critères dont une partie est mesurable. Cette liste de critères semble hélas être établie de manière purement empirique. Une partie des critères que j'ai retenue moi-même pour mes achats de (nouveau) matériel est la suivante :

  • pas trop de LEDs trop lumineuses, afin de pouvoir dormir la nuit (en particulier lorsqu'on habite dans un appartement à une seule pièce, ce qui était mon cas pendant mes études) ;

  • bruit négligeable en fonctionnement nominal (pas plus de 30 dB(A) à un mètre), donc minimiser les ventilateurs et leur vitesse de rotation, et privilégier le matériel sans ventilateurs si possible, afin de ne pas subir le bruit permanent des ventilateurs et pouvoir dormir la nuit ;

  • emprise au sol la plus petite possible, pour pouvoir être posé discrètement dans la pièce de son choix ;

  • de manière générale, une esthétique discrète ;

  • en dernier, mais pas des moindres : une « bonne » fiabilité (i.e. un taux de disponibilité d'au moins 99,8%) du matériel et des services fournis, pour que cela reste intéressant. En deux ans et malgré un déménagement l'année dernière, mon serveur a su tenir un taux de 99,5%, et je dois approcher les 99,9% rien que cette année.

Conclusion

Il est donc tout à fait possible d'opter pour du matériel discret, relativement peu onéreux et suffisamment performant pour la plupart de ses projets d'autohébergement.

Même si la question du matériel est essentielle, ce n'est pas le seul problème à résoudre lorsqu'on met en place un tel projet. L'étape suivante reste la conception du réseau et les choix logiciels, qui feront peut-être l'objet d'un autre article dans le futur.

Posté par x0r à 7 commentaires • Tags : autohebergement linux sysadmin serveur