Connexion
UGREEN m'a envoyé sa station de charge Nexode Pro 300W il y a quelques semaines, et elle n'a plus quitté mon bureau depuis. Le bloc remplace à lui seul le chargeur du MacBook, celui du téléphone et les alimentations qui traînaient derrière l'écran, avec 300W à répartir sur huit sorties.
Dans le détail, la bête aligne six ports USB-C, un port USB-A pour dépanner et une sortie DC de 240W, cette prise ronde qui alimente certains PC portables gourmands. Les trois premiers ports USB-C montent chacun à 140W grâce au PD 3.1, la norme de charge rapide la plus musclée du moment, les deux suivants plafonnent à 100W et le dernier à 30W.
Tout ça tient dans un boîtier raisonnable grâce au GaN, le nitrure de gallium qui remplace le silicium dans les chargeurs récents et qui chauffe beaucoup moins à puissance égale. UGREEN annonce un rendement de 93 %, et après des semaines à charger un MacBook Pro, un iPhone et une tablette en même temps, le bloc est à peine tiède.
Côté vitesse, le constructeur annonce un MacBook Pro M5 rechargé à 56 % en 30 minutes, un iPhone 17 Pro Max à 65 % dans le même temps, et même deux MacBook Pro à 50 % en moins d'une demi-heure. En pratique, mon portable reprend des couleurs le temps d'un thé, et je n'ai jamais vu la station broncher avec cinq appareils branchés.
Le petit écran TFT affiche en temps réel la puissance tirée par chaque port, et une appli en WiFi permet de suivre tout ça à distance, de régler chaque sortie et de choisir entre cinq modes de charge. Gadget ? Peut-être. Mais je passe mon temps à regarder les watts défiler, c'est plus fort que moi.
Attention quand même, il vous faudra aussi lui réserver une vraie place, ce n'est pas un chargeur qu'on glisse dans un sac, il est fait pour rester posé là.
Niveau prix justement, la station est affichée en ce moment à 126 euros au lieu de 170 sur Amazon , environ un quart de remise, alors qu'elle était lancée cet été autour de 200 dollars. Du coup, la facture devient nettement plus digeste pour qui veut faire le ménage dans ses chargeurs.
Il est disponible par ici sur Amazon , et je vous le recommande vivement.
Depuis que X a shooté Nitter et XCancel à grands coups de lettres d'avocat fin août, lire X sans compte c'est redevenu une méga galère. Mais il reste pourtant un outil que plein de gens utilisent sans le savoir, parce qu'il tourne dans les coulisses de Discord et Telegram. Son nom ?
FxTwitter !À la base, le projet FxEmbed , qui fait tourner FxTwitter et FixupX, sert à réparer les aperçus de liens X. Vous mettez fx devant twitter.com (ou fixup devant x.com) et Discord affiche enfin la vidéo, le sondage ou toutes les images du post. Sauf que derrière, il y a surtout une API publique et gratuite, api.fxtwitter.com, qui affiche n'importe quel post public en JSON sans avoir besoin de compte ou de clé API facturé une couille. Ché Elon !
Alors oui, les rageux diront que x.com affiche encore n'importe quel post isolé à un visiteur déconnecté, même les longs, mais sur un profil, ça s'arrête à 5 posts avant de vous demander de "Continuer sur X". Et surtout, ça ne vous affichera pas les vidéos et ça ne vous permettra pas d'avoir ça sous la forme d'un flux RSS.
Alors que FxTwitter, lui, nous sort tout ça sans avoir à ouvrir x.com !
Maintenant pour nos tests, prenons un vieux de la vieille, un vétéran, le post numéro 20 de @jack, publié le 21 mars 2006 et dont l'URL est x.com/jack/status/20. Le nombre à la fin, c'est l'identifiant du post.
Collez tout simplement cet identifiant au cul de api.fxtwitter.com/2/status/ et ouvrez ça dans votre navigateur :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
https://api.fxtwitter.com/2/status/20
Et vous obtiendrez un gros pavé en JSON avec dedans le texte du post dans le champ "text", l'auteur dans "author", et un peu plus bas vous trouvez les likes, les reposts, les réponses et la date.
Le post 20 de @jack vu par l'API : le texte dans le champ text, l'auteur juste en dessous.
Et si vous avez la flemme de recopier l'identifiant (vous êtes toujours dans l'abus, vous ^^), remplacez simplement x.com par api.fxtwitter.com dans l'adresse complète du post et voilà ! Ça marche à tous les coups, même si c'est le retour de l'ancienne version de l'API, conservée pour la compatibilité.
Pour utiliser ça avec un script, je vous conseille d'utiliser curl pour faire la requête et jq pour trier tout ça ( jq, c'est le petit utilitaire qui extrait un champ précis d'un JSON ).
Ainsi, pour n'afficher que le texte du post :
curl -s "https://api.fxtwitter.com/2/status/20" | jq -r '.status.text'
Et si le post n'est pas en français, ajoutez ?lang=fr à l'adresse et hop, magie magie, l'API glisse alors un bloc "translation" dans la réponse, avec le texte en français :
curl -s "https://api.fxtwitter.com/2/status/20?lang=fr" | jq -r '.status.translation.text'
Le texte d'origine du post 20, puis sa traduction demandée avec ?lang=fr.
La traduction provient de X lui-même quand elle existe (sur ce post, le champ "provider" indiquait "grok"), sinon l'API se rabat avec joie sur un service de traduction. Et pour un profil, c'est le même principe avec /2/profile/ : api.fxtwitter.com/2/profile/jack qui affichera la bio de @jack, son nombre d'abonnés et sa date d'inscription. Les autres "routes" qui récupèrent les fils, les abonnés ou les médias d'un compte sont dans la documentation de l'API .
Elle est pas belle la vie ?
Maintenant, on va rentrer dans le dur parce qu'ici, pour récupérer une vidéo, vous n'avez pas besoin d'API. Suffit de jouer avec l'adresse.
Mettez d. devant fxtwitter.com et le lien vous renverra directement le fichier, sans HTML autour. Avec curl, ça donne ça (le -L sert à suivre la redirection) :
curl -L -o video.mp4 "https://d.fxtwitter.com/NASA/status/2102748685792596449"
Grâce à ça, on peut par exemple récupérer le MP4 de cette vidéo bien kitchou de 30 secondes de la NASA. Et ajouter .mp4 à la fin d'une adresse fxtwitter.com fera la même chose. Et pour choisir la qualité, jetez un œil au JSON du post, où la liste des formats de media.videos donne chaque version de la vidéo avec son adresse et son bitrate.
Dernier truc que je trouve pratique avec cet outil c'est que chaque compte public peut avoir son flux RSS. Il suffit d'ajouter /feed.xml après le nom du compte :
https://fxtwitter.com/korben/feed.xml
Collez ensuite ça dans votre lecteur RSS et vous suivrez le compte X de vos rêves sans avoir à y mettre les pieds. Le flux remonte ainsi les 90 derniers posts par défaut, et le paramètre ?count= permet de réduire ce nombre ou de l'augmenter jusqu'à 100 maximum. Et si vous remplacez feed.xml par media.xml vous ne verrez dans le flux que les posts contenant des photos ou des vidéos. Et si vous ajoutez ?with_replies=1 vous verrez aussi les réponses.
Maintenant ce qui peut être relou, c'est que l'API n'encaisse que 1 000 requêtes par minute et par adresse IP. Par contre, si vous pensiez absorber tout x.com sans la moindre vergogne, vous allez vite vous retrouver coincé.
Attention aussi au domaine que vous tapez. Les seuls officiels sont fxtwitter.com, twittpr.com, fixupx.com, xfixup.com et fxbsky.app pour Bluesky. Je précise ça parce qu'il y a eu, par exemple un fxtwiter.com avec un t en moins, qui a été signalé sur le dépôt du projet et qui renvoyait les gens vers des arnaques.
Comme d'hab, une faute de frappe et c'est le drame... Soyez très vigilants.
Maintenant, si vous êtes un petit peu curieux comme moi, vous vous êtes sûrement demandé comment FxTwitter récupérait tout ça ??
Eh bien, comme le fait Nitter, ou plutôt comme le faisait Nitter , il récupère les données en utilisant de vrais comptes X sur lesquels il répartit les requêtes. Et comme c'est ce qui a été reproché à Nitter, je me dis qu'il y a des chances qu'à un moment FxEmbed soit visé aussi.
On verra bien, mais si un jour le service tombe, sachez que le code est bien dispo sous licence MIT, donc vous pouvez le faire tourner chez vous sans problème dans un Docker. Et si vous n'utilisez pas de compte X connecté dessus, ça marchera quand même avec, c'est vrai, des limites de requêtes plus basses et surtout sans accès au contenu NSFW (Et ça, je sais que ça vous rend super triste.)
Source : GitHub
Il y a 2 jours, GrapheneOS que vous connaissez tous parce que c'est l'Android que la police déteste, a détaillé une fonction baptisée secure paste, qui change la façon dont Android sert le contenu du presse-papiers aux applications. Le principe c'est qu'une application peut relire ce qu'elle a copié elle-même, mais rien de ce que les autres ont copié.
Android dans sa version de base n'est pas resté les bras croisés sur ce sujet, mais il s'est arrêté en chemin et depuis Android 10, seules l'application affichée à l'écran et le clavier par défaut peuvent lire le presse-papiers, ce qui a fermé la porte à celles qui tournent en arrière-plan. Puis Android 12 a ajouté une notification à la première lecture d'un contenu venu d'ailleurs, et enfin Android 13 vide le presse-papiers au bout d'un moment.
Mais depuis, plus rien...
Le trou qui reste, Microsoft l'a documenté en mars 2023. La version 7.9.2 de l'application SHEIN (oui, le site de fringues), téléchargée plus de cent millions de fois, lisait périodiquement le presse-papiers, et si elle y trouvait en même temps un signe dollar et un "://", elle expédiait le contenu vers un serveur distant.
Et la restriction d'Android 10 n'a rien empêché, tout simplement parce que l'application tournait au premier plan. Le comportement problématique de l'app SHEIN a ensuite disparu en mai 2022, après un signalement à Google, mais le problème de fond n'a jamais été réglé. Et j'imagine que d'autres apps actuellement sur le PlayStore appliquent la même technique sans que personne ne l'ait encore remarqué.
Secure paste de GrapheneOS s'attaque donc à ça en changeant la règle plutôt qu'en ajoutant un avertissement, et cette fois être affiché à l'écran ne donne plus droit à rien. Une application privée d'accès sait toujours qu'un élément est disponible, et peut en inspecter le type, l'horodatage de copie et la présence de mise en forme. Mais le contenu lui-même, son libellé et ses données annexes ne lui sont plus offerts sur un plateau d'argent.
Et le "collage" continue de marcher lui, parce que c'est vous qui l'autorisez. Que vous colliez depuis la barre de sélection de texte, depuis le clavier, depuis un service d'accessibilité ou avec un raccourci clavier, le système délivre une autorisation courte, liée à l'application qui reçoit et à l'élément en cours. Et pour les applications qui dessinent leur propre barre de sélection, comme celles codées en Flutter, un bouton "Coller" est visible dans le clavier par défaut.
Le plus vif d'esprit qui me lisent sont déjà debouts sur leur chaise et hurlent à travers leur écran : Et comment ça se passe pour "couper" ? Qui décide ?? Hé bien le réglage existe en version globale et par application, et il est autorisé par défaut, pour ne rien casser des applications déjà installées. Autrement dit, personne ne sera protégé sans l'avoir décidé et c'est à vous d'aller basculer en collage seulement celles à qui vous ne faites pas confiance.
Maintenant, calmez-vous les groupies de GrapheneOS parce que rien de tout ça n'est encore livré. Le code est visible dans une pull request ouverte depuis le 22 août dernier mais toujours pas fusionnée. GrapheneOS dit vouloir l'intégrer bientôt, sans donner de date et le mécanisme ne porte que sur la lecture, donc il ne dira rien des applications qui écrivent dans le presse-papiers pour y remplacer ce que vous venez de copier (coucou les détourneurs de transactions crypto)...
La même annonce parle aussi de l'application Messaging, dont l'interface vient d'être refaite en Compose, et le projet lâche au passage un chantier autrement plus lourd : faire du RCS directement dedans, chiffrement de bout en bout compris, pour ne plus avoir besoin de Google Messages. Héhé... Aujourd'hui, RCS marche très bien sur GrapheneOS, mais uniquement avec l'application de Google et sa couche Google Play isolée et c'est de ça dont ils veulent se passer.
Comme le RCS n'est pas une plateforme ouverte en pratique (pas autant que le SMS et le MMS quoi) et que tout cela repose sur l'infrastructure de Google et des opérateurs, le plan, c'est donc de refaire d'abord la partie que Google Messages assure, en gardant Google Play isolé pour l'activation, puis de s'en passer chez les opérateurs qui le permettent... à condition qu'ils acceptent le client de GrapheneOS, ce qui n'est pas gagné...
Quand je pense que Google, ces grands hypocrites qui ont passé des années à réclamer qu'Apple adopte RCS au nom de l'ouverture, coupe lui-même le service depuis 2024 sur les téléphones rootés et une partie des ROM alternatives. GrapheneOS y échappe mais ça donne quand même l'idée de l'accueil qu'un client maison pourrait espérer... On verra bien.
Mais bon, si vous êtes sur GrapheneOS, je serais vous, je surveillerais cette histoire de presse-papiers sécurisé parce que quand ça arrivera, vous serez encore plus béton face aux apps problématiques.
Source : le fil d'annonce de GrapheneOS et Android Authority
Vous avez un Mac et un PC Windows sur le même bureau, et à chaque fois qu'il faut faire passer une commande de l'un à l'autre, vous vous envoyez un message Slack à vous-même, ou vous ouvrez un fichier texte dans un dossier partagé. Hé oui, avouez, c'est le lose un peu quand même. Heureusement, UniClipboard règle exactement ce problème ! Vous copiez ici, vous collez là-bas, et basta !
La première fois que vous utilisez UniClipboard, vous choisissez une phrase de passe, vos machines rejoignent le même espace avec un code d'invitation, et le presse-papiers circule entre elles. Pas de compte à vous créer et surtout, texte, images et fichiers passent d'une machine à l'autre sans souci.
L'outil vous permet même de conserver un historique local dans lequel vous pouvez faire des recherches hyper rapidement, à l'aide d'un raccourci clavier.
Entre 2 ordinateurs sur le même réseau ça fonctionne super bien mais quand deux machines ne se voient pas directement, elles passent par un relais, et ce relais n'a aucune clé : il ne transporte que du chiffré. Maintenant, si l'idée même de passer par un intermédiaire vous hérisse le poil, y'a un mode LAN-only qui coupe tout chemin sortant de votre réseau. Comme ça vous êtes pépouze.
Derrière, le chiffrement, c'est du classique avec du XChaCha20-Poly1305 sur le texte et les images, une identité Ed25519 par appareil, du QUIC pour le transport. Votre phrase de passe, elle, ne chiffre rien directement mais passe par Argon2id pour déverrouiller la clé maîtresse de votre espace, et c'est cette clé-là qui fait le boulot.
Après si vous ajoutez votre téléphone, là, le décor change car comme l'explique la documentation d'appairage , le téléphone n'est rien d'autre qu'un client HTTP SyncClipboard et absolument pas un pair iroh.
Le mobile c'est juste du HTTP sans TLS et tout passe en clair entre celui-ci et le service web que votre ordinateur a ouvert sur votre réseau local. Le téléphone s'y connecte avec un identifiant et un mot de passe mais en ce qui concerne le chiffrement du transport, c'est à vous de le monter derrière un reverse proxy.
Bref, n'activez pas cet écouteur mobile sur le Wi-Fi d'un café ou d'un aéroport, parce que n'importe qui sur le même réseau pourra lire ce qui passe. Et ce qui passe, je vous le rappelle, c'est votre presse-papiers...
C'est sous licence AGPL, c'est gratuit, ça tourne sur macOS, Windows et Linux, mais par contre, le seul audit dont ils parlent est interne. Donc, utilisez-le, mais uniquement pour vos commandes et bouts de code entre deux ordis et pas vraiment pour des choses sensibles, et encore moins sur mobile.
Le 24 août dernier, X Corp. a envoyé une lettre de mise en demeure au développeur de Nitter et une autre à celui de XCancel (une instance célèbre de Nitter). Le délai accordé était très court (environ 24h), et depuis, les deux services sont hors ligne.
Alors que s'est-il passé ?
Nitter, c'était sept ans de travail bénévole pour lire les posts publics de Twitter puis de X sans avoir besoin de compte, sans pub, sans JavaScript et surtout sans laisser son adresse IP à Elon Musk et ses sbires. On remplaçait x.com par nitter.net dans l'URL, et on lisait ce qui nous intéressait. Y'avait même des extensions de redirection automatique qui le faisaient pas à notre place. Et XCancel qui venait de fêter ses 2 ans, c'était tout pareil !
Aujourd'hui la page d'accueil de XCancel affiche ces 4 lignes qui disent en gros que le service est arrêté jusqu'à nouvel ordre. Celle de Nitter n'est pas plus bavarde et son mainteneur, zedeus, cherche un avocat et refuse de commenter.
Notez qu'aucun tribunal n'a été saisi et qu'une simple lettre a suffi.
Ce que X reproche à ces 2 services, c'est un "usage illicite et un contournement de son API", plus une violation du Texas Harmful Access by Computer Act et du Lanham Act. TechCrunch, qui a pu lire le courrier , rapporte une accusation plus précise qui est que Nitter aurait accédé à des comptes X et à des jetons de session pour récupérer le contenu en douce.
Aux États-Unis, en tout cas, "aspirer" des pages web publiques n'a rien de criminel. Mais le problème, c'est que Nitter ne fonctionne plus comme ça depuis des années. Si on analyse son code, on se rend compte que depuis que Twitter a supprimé les comptes invités début 2024, Zedeus, le développeur de Nitter, a mis en place un tout autre système.
Pour contourner les limites imposées par X.com, il a développé un script tools/get_session.py qui prend en arguments un identifiant X, un mot de passe, un secret à double facteur et un chemin de fichier.
Et là-dedans, il embarque en dur une paire de clés API, se déclare auprès des serveurs de X comme LE client Twitter officiel pour Android en version 10.21 tournant sur un OnePlus A3010, fait passer le flux de connexion par cloudscraper, génère le code à double facteur à la volée, et récupère un jeton OAuth qu'il écrit ensuite dans un fichier.
Au niveau des identifiants, c'est l'hébergeur de l'instance qui les fournit puisque depuis la coupure de 2024, faire tourner Nitter imposait de le relier à un vrai compte X. On est donc très loin du robot anonyme qui lit une page publique. C'est un client officiel simulé, avec des identifiants valides, et c'est exactement ça que la lettre de mise en demeure décrit.
Donc voilà, le problème est bien plus compliqué que du scraping simple. Ce sera donc à un juge de trancher sur le fond.
Depuis, le dépôt GitHub est passé en lecture seule, archivé et selon Zedeus, d'autres instances ont reçu des courriers du même genre. De son côté, X ne s'est pas encore exprimé publiquement sur cette affaire.
Reste la question qui nous intéresse : On fait comment pour lire la merde fasciste de X sans compte maintenant ? Bah honnêtement, y'a pas grand-chose... Moi, je vous recommande d'arrêter d'aller là-dessus pour votre propre bien-être. Mais si vraiment vous êtes accro, le pont ActivityPub bird.makeup répond toujours présent et permet de suivre un compte X public depuis Mastodon. Toutefois, il ne vous affichera pas un fil de discussion direct dans le navigateur comme le faisait XCancel ou Nitter.
Après pour un post précis, il reste éventuellement la Wayback Machine, à condition que quelqu'un ait archivé le tweet avant. Sinon, bah faudra vous reconnecter sur X à l'ancienne avec votre compte...
Source : Techdirt
Dans la série "la religion c'est que des problèmes", voici un épisode que je n'avais pas vu venir. Click to Pray, l'application de prière officielle du Pape, a servi gratos les noms, les adresses mail et les dates de naissance de ses 719 517 inscrits à qui voulait bien les demander.
C'est le chercheur BobDaHacker qui a signalé le trou début janvier et si vous savez compter, oui oui, il a bien fallu 6 mois pour que quelqu'un daigne le boucher. Que voulez-vous, les voies du Seigneur sont impénétrables et visiblement sa boîte mail aussi.
L'appli avait été lancée par le pape François en 2019 depuis le balcon de la place Saint-Pierre, tablette brandie devant la foule. Elle appartient au Réseau Mondial de Prière du Pape, une fondation du Vatican, et tourne sur iOS, Android et en version web en 7 langues.
La faille se situait au niveau de l'adresse api.clicktopray.org/user/users/{id} qui renvoyait la fiche complète de n'importe quel compte, prénom, nom, pays, adresse mail, date de naissance et rôle. Aucune authentification demandée, il suffisait de taper l'adresse dans un navigateur.
Source : BobDaHacker
Les identifiants étant séquentiels et le débit n'étant pas limité, une simple boucle sur les 719 517 numéros suffisait à aspirer le fichier entier. Une requête par fidèle, comme pour l' ANTS ^^. Vous le savez maintenant, ça s'appelle un IDOR, pour Insecure Direct Object Reference et c'est quand le serveur vérifie que vous êtes bien connecté, mais jamais que les données réclamées vous appartiennent. Eh bien ici, il ne vérifiait même pas la première moitié.
BobDaHacker explique pourquoi la boulette revient sans arrêt : "la plupart des frameworks gèrent l'authentification pour vous, mais pas l'autorisation. Ils vérifient "est-ce que cette personne est connectée ?", mais pas "est-ce qu'elle a le droit de voir cette ressource précise ?"". Pourtant c'est la base, mais bon, bref...
Ce type de contrôle d'accès défaillant trône en tête de l'OWASP Top 10 depuis 2021, et l'IDOR en est probablement la variante la plus répandue. Pour apprendre à les repérer, je vous avais même montré WebGoat .
Ce qui est marrant, c'est que dans la base, le champ date de naissance s'appelle borned_date, ce qui n'est de l'anglais dans aucune langue. Et le rôle attribué au fidèle lambda, c'est "PRAYER". Votre fonction de péon sur l'application de prière du Pape, c'est donc prière. Ahaha !
Le vrai risque maintenant n'est pas vraiment la fuite en elle-même, mais plutôt ce qu'un escroc va pouvoir faire avec 700 000 adresses de ces gens inscrits pour prier, avec une institution de confiance à usurper. Un mail annonçant que le Saint-Père sollicite votre attention urgente, avec un lien qui imite celui du Saint-Siège, ça fonctionnera très bien je pense...
Dark Reading, qui a confirmé la faille de son côté, a noté que les identifiants les plus bas sont ceux des employés. Les premiers exposés étaient donc ceux qui auraient dû corriger. Mais le bouquet les amis, c'est l'authentification des mails. Ceux de l'appli ratent les contrôles de domaine, SPF, DKIM ou DMARC étant mal réglés, au point que la boîte du chercheur les a marqués comme suspects.
L'application officielle du Vatican envoyant donc déjà des mails qui ressemblent à du hameçonnage, un escroc qui n'aurait pas peur d'aller en enfer, n'a même pas besoin de soigner son imitation.
Arrive la partie qui pique de cette remontée de vuln... Le 3 janvier, BobDaHacker écrit à 9 personnes, l'adresse info générale, 6 membres du staff de clicktopray.org + 2 contacts du Réseau Mondial de Prière.
Puis il attend mais aucune réponse ne vient.
Alors rien ne bouge durant 6 mois. Puis en juillet il passe le dossier à Nate Nelson, de Dark Reading, qui contacte le service de presse. Silence là aussi. Alors l'article sort le 24 juillet, et Ô miracle (ça arrive parfois, oui oui) la faille est bouchée dans la foulée, sans un mot. Le chercheur l'a appris dans les commentaires Reddit qui parlaient de sa découverte.
Mais je vous garde le meilleur pour la fin, attendez... Ce que vous ne savez pas c'est que le Vatican s'est doté de son propre règlement de protection des données personnelles en avril 2024. Ça s'appelle le décret n° DCLVII et il réclame des "mesures de sécurité appropriées" et désigne nommément ceux qui doivent les appliquer. Ce décret a bien été promulgué, puis visiblement rangé dans un tiroir.
Ah et visiblement, l'URL qui leake continue toujours de répondre sans authentification mais ne renvoie plus que l'identifiant, le prénom et le nom. L'adresse mail a disparu, comme la date de naissance et le pays. Donc c'est un genre de demi-correctif puisque les noms restent énumérables un par un sans le moindre compte. Le chercheur juge ça acceptable sur une plateforme où l'on prie "ensemble". Moué, pourquoi pas.
Voilà, donc si vous avez un compte là-bas, partez du principe que votre adresse mail a circulé et que vous risquez d'avoir des appels du Pape, voire de Dieu lui-même qui vous demandera sûrement un virement en urgence. Je vais prier pour vous afin que ça n'arrive pas, mais sachez que ce scénario de la lose, je vous en parlais déjà à propos de la divulgation coordonnée de vulnérabilités , et il ne change jamais. Le chercheur alerte, l'éditeur ignore, et c'est la presse qui finit par débloquer....
Et BobDaHacker, lui, attend toujours son merci. Snif...
Un site sans cookie de mesure d'audience et sans bandeau de consentement, c'est reposant je trouve... Sauf qu'à cause de ça, bah je ne savais plus trop combien de gens venaient me lire tous les jours. Relou hein ?
C'était ma situation depuis un moment déjà, vu que tout ce qui servait à mesurer l'audience a dégagé de korben.info il y a un bon bout de temps. Alors faute de mieux, je me suis rabattu sur AWStats, qui lit bêtement les logs Apache du serveur mais bon, c'est pas terrible, parce qu'avec le cache de Cloudflare, il y a une grosse partie de mon trafic qui n'est pas pris en compte.
En effet, quand Cloudflare possède une copie valide de la page dans son cache, il peut la renvoyer directement sans contacter le serveur d'origine. Vous êtes donc bien un visiteur réel, mais Apache ne voit aucune requête et AWStats ne vous comptabilise pas. Du coup, tous les outils fondés exclusivement sur les logs d'origine sous-estiment la part du trafic absorbée par le cache.
Après il y a bien le classique Google Analytics, mais bon même configuré en mode full RGPD, ça reste Google et ça appelle quand même un service tiers aux US... Vous connaissez aussi déjà des alternatives propres, puisque je vous ai parlé de Matomo, Plausible et de Vince Analytics , mais elles ajoutent toutes une mesure côté navigateur, avec un script, un pixel ou un stockage local (le localstorage) et moi, je ne voulais aucun outil d'audience de plus dans vos pages !
De son côté, Cloudflare lui, voit chaque requête HTTP qui atteint son réseau, y compris celles auxquelles son cache répond. Ses chiffres couvrent donc beaucoup mieux le trafic HTTP que mes logs d'origine. Le souci, c'est que son dashboard, je ne l'aime pas. Je le trouve incomplet, mal foutu, chiant à utiliser, et il ne montre pas ce que j'ai envie de voir.
Donc, histoire d'avoir ce que je voulais, j'ai fini par coder le mien. Enfin, entièrement vibe codé et ça tourne aussi bien sur un serveur qu'en local sur une machine de bureau.
Petite parenthèse pendant que j'y suis, vous ne le savez peut-être pas mais depuis que ChatGPT a débarqué dans nos vies fin 2022, tout ce que je développe moi-même sur ce site et l'ensemble de mes outils internes sont vibes codés avec des LLMs comme ceux d'OpenAI et d'Anthropic. C'était une purge au tout début et maintenant ça s'est tellement amélioré et je me suis tellement spécialisé là-dedans, que le code n'est devenu qu'une formalité. Ne hurlez pas, mon site est statique et j'envoie pas de fusée dans l'espace !
Mon collecteur s'exécute en local, cause à une API, et il n'envoie pas une seule ligne de mesure dans votre navigateur. Bref, que mon backend soit écrit avec un LLM, à la main ou en Brainfuck, vous chargez exactement la même chose de mon outil de stats, c'est-à-dire rien du tout. La garantie est donc architecturale et pas une question de talent.
Et surtout, mon outil de stats n'ajoute aucune mesure dans votre navigateur. Aucun JavaScript ni cookie supplémentaire n'est posé par mon outil. À la place, il lit l'API GraphQL Analytics de Cloudflare, en lecture seule et récupère des compteurs déjà agrégés par jour et par dimension. Cela veut dire par exemple, que quand je récupère le nombre "nombre d'IP distinctes par jour", je ne récupère pas les IPs en tant que telles mais juste un total que Cloudflare me communique et qu'il a déjà traité en amont.
Et vous n'êtes pas obligés de me croire sur parole, parce que c'est vérifiable en 10 secondes... Ouvrez l'inspecteur de votre navigateur, onglet Réseau, et rechargez cette page. Vous ne verrez aucun script de mesure d'audience, aucun appel vers un domaine tiers et aucune iframe. Même les vidéos YouTube ne se chargent qu'au moment où vous cliquez sur la vignette. Le seul truc qui bouge, c'est le compteur du footer qui télécharge un nombre, sans rien renvoyer derrière.
Attention, ce n'est pas à confondre avec Cloudflare Web Analytics et ses mesures RUM (Real User Monitoring) puisque cette fonctionnalité injecte un bout de JavaScript pour mesurer les performances ressenties dans le navigateur. Chez moi, c'est désactivé tout ça.
Maintenant soyons clairs sur un point, parce que c'est l'objection évidente et qu'elle est parfaitement légitime... Cloudflare, lui, voit bien votre adresse IP. Pas à cause de mon outil de stats, mais parce que c'est un reverse proxy et que c'est mécaniquement ce qui se passe dès qu'un site est derrière un CDN. Votre requête arrive chez eux avant d'arriver chez moi, sinon ils ne pourraient ni router, ni mettre en cache, ni bloquer une attaque. Mon outil ne change rien à ça, il se contente de lire des totaux déjà calculés et je ne récupère jamais la moindre IP. Tout est détaillé dans mes CGU, avec les bases légales, les durées et la liste des cookies de sécurité, si vous voulez le détail complet.
Mon outil et le compteur que vous pouvez retrouver dans le footer de mon site reposent sur les requêtes collectées côté serveur chez Cloudflare et sans l'analyse web, je ne peux juste pas suivre par exemple un parcours utilisateur, connaitre un taux de rebond ou évaluer les temps de chargement mesurés chez les lecteurs. Rien de grave donc...
Maintenant, il y a un souci chez Cloudflare, c'est que selon le jeu de données et le forfait que vous payez ou non, le détail ne reste interrogeable que durant une fenêtre limitée de temps. Mon outil doit donc passer chaque jour récupérer les agrégats encore disponibles et les stocker dans une base SQLite sur mon serveur ou en local, selon la façon dont on l'a déployé.
Ça me permet de garder mon propre historique agrégé. J'ai aussi activé le Super Bot Fight Mode de Cloudflare, qui réduit une large partie du trafic automatisé, mais attention, ça ne me donne pas pour autant des stats sans aucun bot. Les crawlers autorisés comme Googlebot et ceux qui passent entre les mailles du filet restent comptabilisés dans mes chiffres, exactement comme avec tous les autres outils de mesure web. Et je préfère le dire clairement plutôt que de vous vendre des chiffres "propres" qui ne le sont jamais totalement, vu qu'un filtre anti-bot ne peut retirer que les bots qu'il a détectés.
À côté de ça, j'ai aussi branché ma Google Search Console, et là non plus sans installer la moindre bibliothèque tierce... Je signe moi-même un JWT en RS256 avec le module crypto natif de Node, je l'échange contre un jeton d'accès chez Google, et le compte de service que j'utilise est restreint au scope lecture seule. Ça m'apporte des statistiques agrégées sur les impressions, les positions, les requêtes de recherche et surtout Discover !!
Si je devais résumer ça, je dirais que Cloudflare estime le volume de trafic et que Search Console montre quelles recherches produisent des impressions et des clics, même si sans aucun tracking en place, ça n'explique évidemment pas la motivation de chaque lecteur. Mais osef ! Et comme Cloudflare embarque aussi son pare-feu, j'en profite pour rapatrier des statistiques sur les événements de sécurité et les routes attaquées, comme ça, je peux tout voir au même endroit.
Maintenant, le vrai plaisir, c'est de pouvoir afficher ce que je veux dans mon propre dashboard. Par exemple, la répartition par langue, les navigateurs, d'où provient le trafic avec un joli petit camembert, les pays, l'état de mon cache, la bande passante, etc. Et quand j'ai un nouveau besoin qui me pête dans le cerveau, je peux ajouter une vue rapidement et je ne m'encombre pas de ce qui ne me sert pas.
Sans traceur placé chez vous, je ne connais donc pas les sessions, le taux de rebond, le parcours de lecture, les entonnoirs de conversion, donc impossible de savoir si vous êtes revenu hier, ni dans quel ordre vous avez lu 3 articles. Mais je m'en tape complètement puisque ces métriques ne m'ont jamais servi à rien.
Ce que je veux connaitre, c'est surtout l'ordre de grandeur de l'audience et le nombre de pages demandées. Le parcours individuel et les entonnoirs de conversion, c'est surtout un besoin de régie publicitaire ou de site e-commerce, et pas d'un site comme le mien. Quand on sait que les bandeaux de cookies nous coûtent 575 millions d'heures perdues collectivement, et que l'Europe réfléchit enfin à les alléger , s'en passer n'est pas vraiment une punition.
Bref, mes stats sont maintenant plus digestes que celles d'AWStats, sans avoir à vous tracker ou vous faire charger quoi que ce soit. Ça me va donc très bien. Et si vous voulez un avant-goût de la technique derrière l'outil, j'ai montré récemment comment vous faire un compteur de fréquentation gratuit , donc n'hésitez pas à y jeter un œil...
Dropbox vient de sortir un plugin pour Claude Code , et leur idée c'est de pouvoir brancher vos fichiers Dropbox directement dans vos sessions de dev Claude Code / Cowork.
Alors je me suis demandé à quoi ça pouvait bien servir et voici ce que j'ai compris. Une fois que le plugin est en place, ça permet à Claude Code d'aller piocher dans votre Dropbox vos docs techniques, vos cahiers des charges, votre code...etc pour s'en faire du contexte. Tout devient de la matière fraiche pour corriger ou générer du code et quand c'est fini, ce qui est produit peut être à son tour stocké sur Dropbox.
Le plugin sait récupérer les fichiers en fonction de leur nom, de mots clés, de leur emplacement et bien sûr en fonction de leurs méta données. Même vos liens partagés il sait comment les gérer. Bref, il fait tout simplement le passe-plats entre tout le bordel que vous stockez sur Dropbox et Claude Code.
Cela dit, gardez la tête froide parce que tout ce que l'IA lit part sur les serveurs d'Anthropic pour être traité. Donc évitez quand même de le lâcher sur le dossier qui contient vos contrats, vos mots de passe ou vos données clients. Lui autoriser juste un dossier dédié avec ce que vous acceptez de partager, ce sera plus sain.
Pour l'installer, ça se passe dans Claude Code sur le web. Vous filez dans le menu Personnaliser, Connecteurs puis vous cherchez Dropbox en parcourant les plugins et vous cliquez sur ajouter. Une auth OAuth plus tard (vos identifiants Dropbox habituels), c'est branché. Un petit /reload-plugins et le plugin s'active alors dans la session en cours.
En plus de ce plugin, Dropbox propose également un serveur MCP classique en ligne de commande qui est un peu plus souple et surtout peut se brancher dans Cursor, Claude Desktop ou Devin.
Un bémol quand même, c'est pas open bar... sniiif. Eh oui, Dropbox plafonne tout ça à 5 Mo par fichier lu ou créé via l'intégration, et le contenu pondu par Claude ne se sauvegarde qu'en texte (.txt, .md, .html, .py), et pas en image ni en PDF. Quant aux limites de débit de l'API, on ne les connaît pas.
Bref, pour les gros fichiers ou les binaires, faudra donc passer par autre chose.
Si vous vivez dans Claude Code et que votre vie est rangée dans Dropbox, ça vaut peut-être le coup de jeter un œil ici.
Tarek, fidèle lecteur de Korben.info m'a envoyé un mail pour me présenter TenMatch , un site web qu'il a codé qui permet de trouver un tournoi de tennis près de chez vous.
Vous le savez, le sport et moi, ça fait 2, alors peu de risque que j'utilise son site. Mais je sais que parmi vous, y'en a qui pratiquent cette forme étrange de ping pong où on est sur la table, comme disait l'autre, alors ça va surement venir se rajouter à vos bookmarks.
La problématique dont s'occupe TenMatch, c'est donc de rechercher pour vous un tournoi du TenUp, qui est l'outil officiel mais reconnu comme une chianlie à utilisé (je vous fais confiance là dessus, j'en sais rien). TenMatch va donc piocher dans les mêmes données publiques de la FFT, les resynchronise chaque nuit, et vous les ressert avec de vrais filtres.
Vous sélectionnez votre classement, la surface que vous voulez, la proximité avec un lieu et même le budget que vous avez, vu qu'une inscription c'est en général 20 balles.
Vous obtenez alors une liste avec les tournois, date par date et vous n'avez plus qu'à vous y inscrire via TenUp. Bref, TenMatch fait le tri, la Fédé encaisse, tout le monde est content.
Bref, si vous tapez dans la baballe, allez jeter un œil à TenMatch. Moi je retourne à mon sport de prédilection, rester assis à vous pondre des articles incroyables !! Et merci à Tarek pour le partage.
Vous supprimez une clé API Google qui a fuité , et l'interface vous confirme que c'est bien réglé, que la clé ne fonctionne plus. Alors vous commencez à vous détendre en vous disant que vous avez bien fait votre boulot.
BAH NAN !
Car vous ne le savez pas, mais cette clé va continuer de fonctionner encore durant 23 minutes. C'est en tout cas ce qu'ont mesuré les chercheurs d'Aikido Security en testant ce truc tout bête de révoquer une clé, puis de taper sur l'API en boucle pour voir quand ça s'arrêtait vraiment.
Et résultat des courses, une clé API classique survit en moyenne 16 minutes après sa suppression, et jusqu'à 23 minutes dans le pire des cas. Cela veut dire que pendant tout ce temps, un attaquant qui a récupéré votre clé peut continuer de l'utiliser peinard. Et vous n'avez aucun moyen de couper plus vite, ni même de savoir quand ça s'arrête pour de bon.
Ce sont les clés API de Schrödinger le bordel... Techniquement comme vous vous en doutez, c'est surtout une histoire de propagation car Google ne tue pas la clé d'un coup sur tous ses serveurs, mais l'info se diffuse petit à petit, et chaque serveur arrête de l'accepter à son rythme. Le souci, c'est que ce délai et largement suffisant par exemple pour vider un bucket pendant que vous pensez que le danger est écarté.
Le plus beau, c'est que Google sait parfaitement faire vite quand il veut puisque les clés de compte de service, elles, sont coupées en 5 secondes. et les clés Gemini récentes en 1 minute. Du coup, ces 16 minutes de moyenne sur les vieilles clés API n'ont rien d'une fatalité technique... c'est juste un choix ! Aikido a bien sûr remonté le problème, et Google a bizarrement classé le ticket en « won't fix », en expliquant que ce délai de propagation était une propriété connue du système, et pas une faille de sécurité.
Donc si vous gérez des clés Google en prod, partez du principe qu'une clé compromise reste exploitable une bonne demi-heure après sa révocation. Et surtout, mettez en place des plafonds de dépenses bien serrés sur votre projet parce que le vrai cauchemar, c'est moins l'accès que la facture qui débarque ensuite. On a déjà vu des devs se prendre des notes à cinq chiffres à cause d'une clé qui traîne, et des utilisateurs Google Cloud facturés par erreur .
Source : Aikido Security
On est vendredi, j'ai un mal de tête carabiné mais je me pose quand même devant l'ordi pour vous annoncer une bonne nouvelle ! Firefox 151 sur desktop vient enfin d'implémenter une fonctionnalité que Mozilla refusait catégoriquement de supporter depuis 6 ans : le support de l'API Web Serial.
Alors non, c'est pas un gros mot, hein, ça veut surtout dire qu'un site web ouvert avec Firefox peut maintenant lire et écrire directement sur du matériel que vous branchez en USB, genre un Arduino, un ESP32, une imprimante 3D, une clé crypto ou que sais-je encore, sans que vous ayez à installer le moindre logiciel ou pilote.
Le cas d'usage le plus parlant, c'est le flashage de microcontrôleurs. Avant, pour mettre un firmware sur un ESP32, il fallait installer esptool en Python, ou l'IDE Arduino, galérer avec les drivers série, choisir le bon port à la main. Maintenant des outils comme ESPHome ou Home Assistant font tout ça depuis un onglet, en quelques clics. Vous branchez la carte, le site demande l'autorisation d'accéder au port, et c'est réglé. Adafruit fait pareil pour installer CircuitPython sur ses cartes ESP32-S2.
Et pour comprendre pourquoi c'est une vraie bonne nouvelle, il faut se rappeler d'où on vient. Chrome propose quand même Web Serial depuis 2021 mais Mozilla a toujours considéré qu'un accès série accordait trop de contrôle sur un appareil, sans la moindre authentification. Et ils n'ont pas tord... D'ailleurs Apple, de son côté, campe toujours sur cette position et qualifie carrément la spec de dangereuse, notamment à cause des risques de fingerprinting .
Mais ce qui a fait bouger Mozilla, c'est un revirement progressif en interne. En 2022, Bobby Holley, le CTO de Firefox, a rouvert le dossier, puis en 2024, il a posé ses conditions, à savoir un mécanisme de contrôle par add-on et un consentement clairement formulé. Et le résultat, on peut le voir dans l'implémentation finale, puisque l'autorisation marche par site et par port. C'est bien puisqu'un site ne voit absolument rien tant que vous ne lui donnez pas la main, et ne récupère aucune liste des appareils branchés, ni aucune info de fingerprinting exploitable au-delà du port que vous sélectionnez vous-même.
J'étais le premier à pester contre Mozilla pour cette absence de support. Parfois je les trouve trop prudent, au delà du raisonnable, ce qui les mets en décalage avec ce que proposent les autres et ce qui fait leur fait perdre bêtement des parts de marché.
Mais c'est vrai aussi que la prudence sur ce genre d'API qui touche directement au hardware, c'est ce qu'on attend tous d'un navigateur qui mise tout sur le respect de la vie privée de ses utilisateurs. D'ailleurs, pour les parano ou les admins système (oui c'est pareil ^^), sachez qu'en environnement Firefox Enterprise, Web Serial est désactivé par défaut.
Au-delà du flashage de cartes, les usages réels sont déjà très nombreux. Un ingénieur de Mozilla, Florian Quèze, s'en sert par exemple pour lire la consommation d'un compteur USB d'énergie standard (du genre AVHzY C3 ou Joy-IT TC66C) et balancer les données directement dans le Firefox Profiler. Les imprimantes 3D, les briques LEGO programmables, les Raspberry Pi Pico, tout ce petit monde cause série et devient ainsi pilotable depuis une page web.
D'ailleurs je vous parlais récemment de CANviz, qui analyse le bus CAN de votre bagnole directement dans le navigateur, hé bien c'est typiquement le genre de truc que Web Serial rend possible sans app native.
Après la spec Web Serial traîne toujours au Web Incubator Community Group, donc rien n'est gravé dans le marbre mais cela dit, Mozilla pousse pour une vraie standardisation via le WHATWG, ce qui n'était pas gagné vu d'où on est parti.
Voilà, allez, je vous laisse, j'ai un dafalgan qui m'attend ^^
Votre vieux Galaxy S5 qui prend fort la poussière dans un tiroir, mérite mieux je crois !
Un dev, Capcom6 a mis en ligne SMS Gateway for Android , une app Kotlin sous licence Apache 2.0 qui transforme n'importe quel smartphone (Android 5.0+) en passerelle SMS programmable. Cela vous permet de récupérer une API REST pour ensuite envoyer et recevoir vos SMS avec votre propre téléphone et votre propre SIM et ainsi vous passer de services payants équivalents.
Il y a 3 modes au choix. Le mode local quand l'app lance un serveur HTTP sur le port 8080, accessible depuis votre réseau. Le mode cloud où l'app se connecte au service tiers api.sms-gate.app, ce qui est pratique pour ceux qui ont une IP dynamique ou plusieurs appareils. Et le mode "private server" qui permet d'héberger le backend chez vous, en totale autonomie.
Mais dans tous les cas, les requêtes restent les mêmes à savoir du bon vieux POST JSON avec basic auth.
Et côté fonctionnalités, y'a tout ce qu'il faut. Multi-SIM si votre téléphone est compatible, messages multipart automatiquement découpés pour les SMS longs, suivi de statut en temps réel (sent, delivered, failed), webhooks pour 8 événements différents (sms:received, sms:sent, sms:delivered, sms:data-received, mms:downloaded, system:ping...). Et puis du chiffrement bout-en-bout activé sur le mode cloud, comme ça personne ne peut lire vos messages en clair.
Maintenant vous vous demandez peut-être à quoi ça peut servir ??
Bah je pense à de l'envoi SMS 2FA pour vos applications, tout ce qui est messages transactionnels (confirmations de commande, rappels de RDV), des notifications push via SMS, et même du data SMS binaire pour piloter des périphériques IoT à distance. Pourquoi pas ? Y'a plus de limites après... Ah et y'a aussi une intégration n8n officielle (ici sur le repo example-webhooks-n8n ) pour brancher l'API à vos workflows, plus une bibliothèque PHP sur Packagist. Bref, y'a un petit écosystème qui commence à se développer autour.
Pour l'installer, oubliez le Play Store. capcom6 distribue uniquement des APK sur les GitHub Releases. Faut donc activer les sources inconnues, télécharger le .apk, et installer manuellement.
Après quand on fait le calcul côté pognon c'est vite vu. Twilio par exemple facture $0.0083 par SMS aux US, plus 1,15 $ / mois par numéro, plus les frais. Donc pour 1000 SMS par mois c'est vite entre 50 à 80 $. Avec SMS Gateway for Android et votre forfait perso, vous ne payez rien d'autre que votre forfait...
Après y'a quelques limites à connaître... Par exemple, si vous pensiez faire de l'envoi massif pour du marketing (comprenez du spam), votre opérateur va évidemment bloquer rapidement votre SIM. Et puis évidemment, faut que le téléphone soit allumé h24 avec sa connexion data activée. Donc pour du transactionnel léger c'est nickel mais pour du mass-mailing, oubliez ! De toute façon, n'oubliez pas, y'a une place pour vous en enfer, les spammeurs.
Voilà, donc si vous avez un vieux smartphone Android qui fait dodo dans un tiroir et que vous avez besoin d' une API SMS pour vos automations perso ou votre stack interne, c'est une alternative à Twilio très sympa !
Anthropic, la boîte derrière l'IA Claude, a racheté Stainless pour plus de 300 millions de dollars. Stainless, c'est un nom que le grand public ne connaît pas, mais l'outil est partout : il transforme automatiquement la spécification d'une API, l'interface par laquelle deux logiciels se parlent, en SDK.
Pour rappel, un SDK, c'est un ensemble de bibliothèques de code prêtes à l'emploi pour les développeurs, ici dans une dizaine de langages comme Python, TypeScript, Go ou Java.
En clair, quand un développeur veut brancher son application sur l'API de Claude, il utilise un SDK généré par Stainless. La boîte, fondée en 2022 par un ancien ingénieur de Stripe, a produit chaque SDK officiel d'Anthropic depuis les tout débuts de l'API Claude. Le rachat consolide donc une brique que l'entreprise utilisait déjà tous les jours.
Stainless ne s'arrête pas aux SDK. La société fournit aussi de l'outillage pour les serveurs MCP, le protocole poussé justement par Anthropic qui permet aux IA de se connecter à des outils et des données externes. Du coup le rachat fait sens à double titre : Anthropic met la main sur la génération de SDK et sur une partie de l'infrastructure MCP, deux briques où il veut clairement être central.
Sauf que voilà le détail un peu fou. Stainless ne servait pas qu'Anthropic, et sa liste de clients comprend OpenAI, Google DeepMind, Perplexity, Groq et Cloudflare, autrement dit la plupart des concurrents directs d'Anthropic sur le marché de l'IA.
La suite est sans pitié. Anthropic ferme tous les produits hébergés de Stainless, générateur de SDK compris. Les clients actuels gardent les SDK déjà générés et peuvent les modifier, mais le robinet, lui, est coupé. Tout le monde va devoir trouver une alternative ou rapatrier la génération de SDK en interne.
Pourquoi mettre 300 millions sur la table pour ça ? Parce que la vraie bataille n'est plus seulement sur les modèles d'IA, mais sur la couche d'outillage autour.
Celui qui contrôle la façon dont les développeurs branchent leurs applications et orchestrent leurs agents IA contrôle une partie de l'écosystème. OpenAI muscle son propre Agents SDK de son côté. Anthropic, lui, préfère racheter directement l'usine, et au passage priver ses concurrents d'un fournisseur bien pratique.
Source : TechCrunch
Hello les amis, voici ma petite trouvaille du jour, idéale pour ceux qui jouent en ce moment avec des adresses IP : ip66.dev . C'est une base de géolocalisation IP et entièrement libre, livrée au format MMDB (le même que celui de MaxMind) qui permet de remplacer direct un fichier GeoLite2 dans vos libs existantes (Python, Go, Node.js), sans toucher au code.
L'équipe de Cloud 66 maintient cette liste à jour sous licence CC BY 4.0 et tout est utilisable simplement en récupérant le fichier mmdb.
Pour le télécharger :
curl -LO https://downloads.ip66.dev/db/ip66.mmdb
Ensuite pour interroger une IP, l'outil mmdbinspect de MaxMind fera le job. Si vous l'avez pas déjà, une ligne suffit :
go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8
À l'intérieur de la réponse, vous trouverez le numéro et le nom de l'ASN, le pays avec son code ISO, le continent, en IPv4 et IPv6 :
Au lieu de moudre des heuristiques opaques, ip66 préfère tout simplement agréger des sources à partir des 5 registres régionaux (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) pour les allocations, le BGP via RouteViews et RIPE RIS pour les vues publiques d'annonces, le RFC 8805 geofeed quand les opérateurs déclarent eux-mêmes leurs localisations, sans oublier GeoNames pour tout ce qui concerne les libellés.
Du coup chaque enregistrement dispose de son propre niveau de confiance (Very High, High, Medium, Low) selon la qualité de la source. Y'a même des marqueurs pour identifier les IPs VPN / Tor et compagnie.
Notez par contre, que c'est du country-level, et pas du city-level comme GeoIP2 City ou IPinfo Core, mais pour enrichir des logs, sortir des stats par pays ou bloquer un continent entier, c'est largement suffisant !
Et si vous voulez l'exposer en API plutôt que la requêter en local, ça se branche nickel sur le
mmdb-server
, un petit serveur Python qui sert les fichiers MMDB en HTTP. Vous lui pointez ip66.mmdb dans son dossier db/ et hop, c'est plié !
Bref, un fichier mmdb à DL, et votre serveur sait maintenant que 8.8.8.8 c'est l'oncle Google.
Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'eteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.
La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.
Concrètement ça donne ça :
from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé
Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !
La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...
Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.
Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !
Sur le terrain anti-bot, ça se compare bien à
Botasaurus
dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.
Détail sympa pour les bidouilleurs : y'a également un serveur MCP est intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.
Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.
Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.
Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .
Et merci à Letsar pour le lien !
Si vous avez un site, vous savez déjà qu'il faut l'optimiser et le rendre lisible pour Google. Mais en ce moment, Cloudflare pousse vraiment une toute autre couche par-dessus : le rendre lisible pour les agents IA. Et pour vérifier si vous êtes dans les clous, l'équipe a sorti isitagentready.com , un scanner gratuit qui vérifie ça en quelques secondes.
Vous tapez tout simplement votre URL, et le scanner check une dizaine de standards émergents, puis pour chaque truc qui manque, il vous crache carrément un prompt prêt à coller dans Claude Code, Cursor ou Windsurf pour qu'il vous aide à l'implémenter. Vous pouvez aussi customiser le scan en cochant uniquement ce qui vous intéresse, selon que votre site est plutôt un blog de contenu ou une API.
L'interface annoncée par Cloudflare pour son nouveau scanner agent-ready
Les checks sont organisés en 5 catégories : la découvrabilité (robots.txt, sitemap, Link headers HTTP), l'accessibilité du contenu (markdown negotiation, llms.txt), le contrôle et la signalisation des bots (Content Signals, Web Bot Auth, règles IA dans robots.txt), la découverte de protocoles (MCP Server Card, Agent Skills, API Catalog, OAuth) et le commerce agentique (x402, MPP, UCP, ACP). Chaque catégorie pèse alors dans le score final, sauf le commerce qui est juste checké mais pas scoré.
J'ai testé sur korben.info et le résultat est franchement mitigé. Côté positif : robots.txt présent avec Content Signals (search=yes, ai-train=no, donc je dis oui à l'indexation et non à l'entraînement IA), llms.txt opérationnel avec 111 lignes en français, markdown negotiation qui répond bien sur Accept: text/markdown, sitemap.xml en place, et GPTBot, Google-Extended et Meta bloqués explicitement.
Côté manquant : pas de MCP Server Card, pas d'Agent Skills, pas d'API Catalog, pas de Link headers.
Score estimé : très moyen, et c'est plutôt cohérent avec un site qui n'a pas besoin d'OAuth ni de serveur MCP.
Cloudflare balance surtout des chiffres bien concrets dans son article de lancement . Sur les 200 000 domaines les plus visités du web, 78% ont un robots.txt, 4% déclarent leurs préférences via Content Signals, 3.9% font de la markdown negotiation, et moins de 15 (oui, quinze) ont un MCP Server Card ou un API Catalog combinés. Autant dire qu'on est très tôt dans la partie. Côté boite à outils, dans le panel d'agents testé par Cloudflare, seuls Claude Code, OpenCode et Cursor envoient un Accept: text/markdown par défaut quand ils browsent le web. Les autres récupèrent du HTML par défaut, comme un navigateur classique.
Cloudflare a aussi mesuré l'impact sur sa propre doc en activant tous ces standards : 31% de tokens en moins consommés et 66% de réponses plus rapides. Du coup c'est pas négligeable, surtout quand vous payez les agents au token. Et bonus, isitagentready.com lui-même est agent-ready (forcément), avec son propre serveur MCP exposé à /.well-known/mcp.json et un outil scan_site disponible pour les agents qui veulent l'appeler en autonomie.
Mais attention au piège ! Si on traite tout pour viser le "tout vert" comme objectif, beaucoup de sites finiront par prétendre être des fournisseurs OAuth ou des serveurs MCP juste pour cocher la case. Donc mieux vaut dire honnêtement "non, ça je ne fais pas" que de faire semblant. Pour un blog perso, vous n'avez probablement pas besoin de l'API Catalog ni du serveur MCP. Pour un site e-commerce par contre, x402 et l'Agentic Commerce Protocol vont commencer à compter le jour où les agents paieront vraiment pour leurs utilisateurs.
Petit détail historique amusant, le robots.txt date de 1994 (j'avais 12 ans, j'étais à fond sur le PC mais pas encore sur le net) et le code HTTP 402 Payment Required existe depuis 1997 mais n'a jamais été massivement utilisé. Jusqu'au jour où Cloudflare et Coinbase se sont associés pour le ressusciter avec x402, en l'imaginant comme la couche de paiement entre humains, agents et services. On verra bien si leur mayonnaise va prendre...
Aujourd'hui l'adoption de tout cela est embryonnaire, mais rappelez-vous qu'en 2004 peu de monde aurait parié sur l'industrie SEO qu'on connaît aujourd'hui. Donc ça vaut le coup d'y jeter un œil maintenant.
Merci à Camille Roux pour le lien !
John Decebal vient de sortir le RSVP Nano , une mini-liseuse open-source qui tient sur un ESP32-S3 et qui affiche votre bibliothèque... un mot à la fois. 92 mm sur 34, et sous licence MIT, je me suis dis que j'allais y jeter un oeil.
En fait, le concept tient en 4 mots : Rapid Serial Visual Presentation. Au lieu d'afficher une page entière, l'appareil fait défiler les mots un par un, à la cadence que vous voulez. Imaginez un téléprompteur de poche, sauf que c'est vous qui gérez le défilement. J'en parlais déjà avec Uniread en 2018 , sauf que là, la chose est matérialisée dans un boîtier qui tient dans la paume de la main, au lieu de tourner en CLI dans un terminal.
Côté hardware, c'est une carte Waveshare ESP32-S3-Touch-LCD-3.49 avec 16 Mo de flash incluant l'OPI PSRAM, plus un panel AXS15231B de 640 x 172 pixels en mode paysage. Par contre, comme c'est pas un écran e-ink, mais un LCD IPS classique tactile capacitif, exit l'autonomie d'une Kindle. On tape plutôt dans le rythme d'un téléphone.
Le firmware embarqué convertit alors les EPUB en format .rsvp directement sur la carte SD à la première ouverture, puis met le résultat en cache. Pour les autres formats type .txt ou .md ou .html, il existe un convertisseur desktop séparé à lancer sur PC avant copie. Voilà, c'est moins fluide mais ça reste carrément faisable.
Quelques bémols quand même. La lecture mot par mot, ça demande un peu d'entraînement (les premières minutes, le cerveau panique un peu !!), et si vous voulez relire un passage précédent, faudra piloter manuellement l'engin via avec l'écran tactile.
Le concept même de RSVP, ça reste quand même une affaire de goût personnel. Certains tiennent un roman entier comme ça, d'autres décrochent au bout de 30 minutes parce que le cerveau zappe la pause naturelle qu'on prend en bout de ligne. Après ça peut convenir aux lecteurs de métro qui dévorent par micro-sessions (entre 2 arrêts quoi...). Dans ce cas le format colle carrément à votre rythme.
Pour la petite histoire, j'avais déjà parlé en 2020 d'un cousin plus sérieux, The Open Book Feather , dans un genre plus orthodoxe avec un véritable écran e-ink complet et un microcontrôleur Adafruit Feather sous Linux embarqué.
Mais si ça vous chauffe, sachez que le hardware coûte une trentaine de dollars, le firmware est libre, et la communauté commence déjà à demander l'intégration Calibre.
Source : Hackster.io
L'histoire nous vient de Málaga, racontée par la Policía Nacional et reprise par The Register. Un magasin de paris local est pris en défaut par un bug logiciel qui affiche des gains doublés sur plusieurs tickets de la journée.
Les parieurs concernés voient leur jackpot apparaître deux fois à l'écran, et vont logiquement le réclamer au guichet. Sauf que la direction du groupe, une fois prévenue, refuse net d'honorer les paiements erronés. Les clients repartent avec leur mise normale, et bien bien remontés.
Parmi ces parieurs floués, visiblement, l'idée du recours en justice n'a pas séduit tout le monde. Un agent de sécurité du magasin lui-même, selon la police, s'associe à un complice non identifié pour monter une combine.
Les deux se présentent aux parieurs lésés comme des "intermédiaires" capables de récupérer l'argent dû, à condition que les clients leur fassent confiance pour la suite. Une petite économie parallèle de compensation, en somme.
Le problème, c'est la méthode choisie pour faire pression sur la direction. Les deux comparses traquent le gérant du magasin, obtiennent son adresse personnelle, lui envoient des SMS et des enregistrements audio d'intimidation, puis finissent par l'enlever.
La rançon demandée est de 50 000 euros, avec des exigences qui évoluent en cours de négociation, vers des acomptes plus petits et plus rapides. Clairement des kidnappeurs qui improvisent.
Heureusement pour le gérant, ça n dure pas. Après une info anonyme, la Policía Nacional localise le point de rendez-vous du premier versement, un fast-food dans un centre commercial de Málaga, et y interpelle les deux suspects en même temps qu'elle libère l'otage. Le tout 90 minutes après l'enlèvement, sans paiement effectué et sans blessé. Les deux hommes sont maintenant en détention pour kidnapping.
Moralité : un bug logiciel plus une mauvaise gestion de la communication client égale un agent de sécurité qui se reconvertit en pseudo-Robin des Bois. Le refus de la direction de payer les erreurs système est discutable commercialement, mais ce n'est clairement pas ce qui justifie d'enlever qui que ce soit.
Bref, un bon audit du logiciel de paris, et une réponse client un peu plus habile, auraient évité tout ce bordel.
Source : The Register
Google déteste que vous écoutiez YouTube gratuitement en arrière-plan. C'est comme ça depuis des années, et ça empire... Par exemple, vous verrouillez l'écran 2 secondes et pouf, plus de son.
YouTube Premium coûte dans les 13 balles par mois pour débloquer ça, ce qui fait quand même plus de 150 euros l'année juste pour écouter de la musique écran éteint. Heureusement, un dev français a trouvé une parade avec Allformusic , un site qui contourne le problème en utilisant l'API officielle de YouTube.
Le principe c'est que Allformusic est une sorte de jukebox géant qui tape directement dans le catalogue YouTube. Vous cherchez un artiste, un album, un genre... et ça lance la musique. Sans compte, sans pub et gratos ! Du coup, si vous voulez vous taper l'intégrale de Daft Punk un dimanche après-midi, vous tapez leur nom et c'est parti.
Et là où c'est malin, c'est que sur mobile, comme YouTube coupe le son dès que vous verrouillez l'écran (merci Google...), y'a une astuce simple à connaitre avec Alloformusic.
Vous lancez votre musique, vous verrouillez le téléphone, le son se coupe... normal. Sauf que le mini-lecteur natif du navigateur apparaît dans vos notifications. Appuyez alors sur Play depuis l'écran de verrouillage, et hop, la musique reprend en arrière-plan !
Par contre, attention si votre navigateur a un mode économie d'énergie agressif, ça peut couper au bout de 10-15 min. Dans ce cas, désactivez l'optimisation batterie pour Chrome dans les paramètres Android.
Le site fonctionne comme une PWA, une Progressive Web App, ce qui veut dire que vous pouvez l'ajouter sur votre smartphone comme une appli classique. Sur Android, direction le menu Chrome puis "Ajouter à l'écran d'accueil". Sur iPhone, c'est via Safari, le bouton partage, puis "Sur l'écran d'accueil".
Bruno, le créateur du site, confirme que ça tourne nickel sur Android. Côté iOS, c'est moins testé... perso, j'aurais tendance à dire que ça dépend de la version de Safari et de comment Apple gère la MediaSession API. À vérifier de votre côté.
D'ailleurs si vous aviez lu mon article sur le blocage de la lecture YouTube en arrière-plan , vous saviez que Google serre la vis sur les navigateurs tiers. Les méthodes à base de about:flags tombent les unes après les autres.
Allformusic a l'avantage de passer par l'API officielle, du coup en théorie c'est moins susceptible de se faire dégager du jour au lendemain... mais bon, avec Google, on n'est jamais à l'abri.
Après, la qualité audio dépend de ce que YouTube balance, et sur certains titres c'est du 128 kbps donc clairement pas du FLAC hi-fi. Si vous êtes du genre à entendre la différence entre un MP3 et un vinyl, passez donc votre chemin. Mais si vous êtes comme et que c'est juste pour se mettre un fond sonore en cuisinant ou dans les transports, ça fait largement le taf.
Y'a pas non plus de mode hors-ligne, donc sans connexion c'est mort. Et vu que ça streame du YouTube, comptez une cinquantaine de Mo par heure en audio seul... à garder en tête si vous avez un forfait serré.
Le site propose aussi des sélections thématiques... Top du moment, Top soirée, et même un "Top Johnny" pour les fans du Taulier ^^. C'est un projet perso fait par un lecteur du blog passionné de code et de musique, donc ça mérite bien un petit coup de projecteur !
Bref, merci à Bruno pour le partage et encore bravo ! Si vous cherchez un moyen d'écouter de la musique en streaming sans prise de tête, allformusic.fr ça vaut le détour.
60 Mo de source maps (ces fichiers qui permettent de remonter du code minifié à l'original) ont été oubliés dans un paquet npm. Et voilà comment Anthropic a involontairement balancé en public le code source complet de Claude Code, son outil à 2.5 milliards de dollars de revenus annuels.
Alors qu'est-ce qui s'est passé exactement ?
Hé bien hier, la version 2.1.88 du package @anthropic-ai/claude-code sur le registre npm embarquait un fichier .map de 59.8 Mo. Un truc normalement réservé au debug interne, sauf que ce fichier .map contenait les pointeurs vers les 1 900 fichiers TypeScript originaux, en clair. Chaofan Shou, un développeur chez Solayer Labs, a alors repéré la boulette et l'a partagée sur X. Le temps qu'Anthropic réagisse, le code était déjà mirroré partout sur GitHub, avec 41 500+ forks en quelques heures. Autant dire que le dentifrice ne rentrera pas dans le tube !
Pour ma part, j'avais un petit dépôt à moi assez ancien avec quelques trucs relatifs à Claude Code, qui n'avait rien à voir avec tout ça, qui s'est même retrouvé striké... Ils ratissent large avec leur DMCA donc.
Et là, c'est la fête pour les curieux comme moi parce que les entrailles de l'outil révèlent pas mal de surprises. Côté architecture, on découvre environ 40 outils internes avec gestion de permissions, un moteur de requêtes de 46 000 lignes de TypeScript, un système multi-agents capable de spawner des essaims de sous-tâches en parallèle, et un pont de communication entre le terminal et votre éditeur VS Code ou JetBrains. Le tout tourne sur Bun (pas Node.js ^^) avec Ink pour l'interface terminal. Par contre, pas de tests unitaires visibles dans le dump.
Côté mémoire, c'est plutôt bien pensé puisqu'au lieu de tout stocker bêtement dans la fenêtre de contexte du modèle, l'outil utilise un fichier texte MEMORY.md ultra-léger (genre 150 caractères par entrée) qui sert d'index de pointeurs. Les vraies données, elles, sont distribuées dans des fichiers thématiques chargés à la demande, et les transcripts bruts ne sont jamais relus entièrement, mais juste fouillés à la recherche d'identifiants précis. L'agent traite en fait sa propre mémoire comme un "hint" ce qui le force à vérifier toujours le vrai code avant d'agir. En gros, il a une mémoire sceptique, et pour moi c'est clairement le truc le plus intéressant du dump.
Y'a aussi un truc qui s'appelle KAIROS (mentionné 150 fois dans le code) qui est un genre de mode daemon autonome. En fait, pendant que vous allez chercher votre café, l'agent tourne en arrière-plan et fait ce qu'ils appellent autoDream : il consolide sa mémoire dans des fichiers JSON, vire les contradictions et transforme les observations vagues en données structurées. Comme ça, quand vous revenez devant votre écran, le contexte est nettoyé.
Et puis le code balance aussi la roadmap interne d'Anthropic (bon courage au service comm ^^). On y trouve les noms de code des modèles... Capybara pour un variant de Claude 4.6, Fennec pour Opus 4.6, et un mystérieux Numbat qui n'est pas encore sorti. D'ailleurs, les commentaires internes révèlent que Capybara v8 a un taux de fausses affirmations qui tourne autour de 30%, ce qui est une grosse régression par rapport aux 17% de la v4. Y'a même un "Undercover Mode" qui permet à l'agent de contribuer à des repos publics sans révéler d'infos internes (c'est sympa pour les projets open source).
Anthropic a confirmé la fuite : "C'était un problème de packaging lié à une erreur humaine, pas une faille de sécurité. Aucune donnée client n'a été exposée." Mouais, attention quand même, parce que le code est déjà partout et n'en repartira pas. Et même si aucun secret client n'a fuité, exposer l'architecture complète d'un agent IA à 2.5 milliards de revenus, c'est pas rien non plus.
Bon, et maintenant qu'est-ce qu'on peut en faire ? Bah pas mal de choses en fait.
Par exemple, le système de mémoire auto-correcteur est un pattern directement réutilisable pour vos propres agents IA. L'architecture "index léger + fichiers à la demande" résout élégamment le problème de la pollution de contexte qui fait halluciner les LLM sur les longues sessions. Les +40 outils internes permettent aussi de comprendre comment structurer un système de permissions granulaires dans un agent autonome . Et le concept KAIROS/autoDream, la consolidation mémoire pendant l'idle, c'est une idée qu'aucun outil open source n'implémente encore. Autant dire que les alternatives open source à Claude Code ou Codex vont monter en gamme dans les jours qui viennent. Et le code est déjà nettoyé, réécris en Rust et mis sur GitHub si vous voulez fouiller. Bon, pas sûr que le pattern autoDream soit simple à reimplémenter, mais le système de mémoire oui.
Je trouve ça assez marrant que le code proprio d'une boite qui a aspiré tout l'open source du monde voire plus, sans autorisation, pour le revendre sous la forme de temps machine / tokens, devienne lui aussi en quelque sorte "open source" sans qu'on leur demande leur avis ^^. La vie est bien faite.
Maintenant, pour les développeurs qui publient sur npm, la leçon est limpide : Vérifiez votre .npmignore et votre champ files dans package.json. Ou plutôt, lancez la commande npm pack --dry-run dans votre terminal avant chaque publish. Ça prend 2 secondes et ça vous montre exactement ce qui sera inclus dans le paquet. Ça aurait évité 60 Mo de secrets industriels qui partent en public.
Bref, un .npmignore bien configuré, ça coûte 0 euro. Alors qu'une fuite de propriété intellectuelle évaluée à 2.5 milliards... un peu plus !
