Un compteur de visiteurs sur votre site, sans payer un centime

Vous avez peut-être remarqué un petit point rouge tout en bas de mon site, avec un nombre à côté. Il s'agit du nombre de personnes passées sur le site durant la dernière heure.

Je voulais remettre ce truc depuis un bail, bien à l'ancienne comme dans les années 2000 mais sur un site statique, qui plus est sans tracker de stats JS type Google Analytics ou Matomo, et sans cookies de tracking, c'était pas franchement une option... jusqu'à maintenant !

Le compteur, en vrai, tout en bas de korben.info.

La solution évidente sur des sites statiques, c'est souvent un petit Worker Cloudflare qui compte les visiteurs et servirait le chiffre, mais ça se facture à chaque requête. À 390 000 pages vues par jour, ça grimpe vite à des dizaines de millions d'invocations par mois, soit dans les 6 à 7 dollars. C'est pas super cher mais pour un compteur qui n'est utile qu'à satisfaire mon égo tout en sachant s'il y a du monde aujourd'hui, ça ne sert strictement à rien ! Donc le Worker, je l'ai écarté direct.

Du coup j'ai fait ça à l'ancienne. Un petit script Python tourne sur la machine qui héberge le site, une fois par minute. Il pose une seule question à Cloudflare, à savoir combien d'adresses IP distinctes ont chargé une page durant la dernière heure (ou demi-heure, ou quart d'heure ou 5 min, c'est vous qui paramétrez), il écrit la réponse dans un minuscule fichier live.json de quelques centaines d'octets, et c'est tout. Ce fichier, Cloudflare le sert ensuite depuis son cache comme il servirait une image, gratuitement. Zéro Worker, zéro base de données, zéro abonnement, j'ai exactement le même résultat sans dépenser une thune.

Maintenant, faut que je sois clair sur ce que ce chiffre raconte. C'est le nombre de navigateurs distincts ayant chargé une page durant la dernière heure, hors trafic interne de Cloudflare. C'est un "*combien de monde est passé récemment *", pas un "combien lisent là tout de suite".

Et les bots là-dedans ?

En fait, les bots pourris , ceux qui scrapent en boucle, se font bloquer en amont par le Super Bot Fight Mode de Cloudflare, donc ils n'arrivent même pas jusqu'à mon site. Restent les gentils bots, du genre de Googlebot et compagnie, que je laisse passer exprès, parce que les bloquer reviendrait à me flinguer mon référencement. Sur les 7 derniers jours, Cloudflare classe à peine 4% comme bots vérifiés. Donc c'est une goutte d'eau, surtout qu'ils tournent sur une poignée d'IP. Donc oui, mon compteur avale deux ou trois crawlers au passage, mais je ne voulais pas vous mentir en écrivant "zéro bot". Mais l'essentiel c'est que les nuisibles, eux, ne soient pas comptabilisés.

J'ai aussi dû gérer un petit piège car l'API de Cloudflare plafonne sa réponse à 10 000 lignes. Et comme sur une heure entière de trafic ça peut se remplir vite, si je crève ce plafond, la requête sous-compterait sans rien dire. Donc le script lève un flag et le compteur affiche "10 000 personnes ou plus" plutôt qu'un faux nombre. Quand j'y serai aux 10 000 et plus, je pense que je réduirai alors le delta temps en passant de 1h à 30 min...etc.

Côté vie privée, c'est carré également. Cloudflare renvoie à mon serveur une liste JSON des IP passées dans l'heure, mon script en compte le nombre de distinctes, et efface cette liste de sa mémoire dans la milliseconde qui suit. Aucune IP n'est stockée, aucune n'atterrit dans un log, aucun fichier avec les IPs n'est créé sur le disque... Il ne reste qu'un entier. Comme je vous le disais, pas de cookie , pas de traceur, et rien qui touche votre navigateur . Et comme le compteur ne s'affiche jamais en dessous de 10 personnes, impossible d'isoler qui que ce soit.

Maintenant, si vous voulez le même chez vous, sachez que j'ai tout balancé en open source sur GitHub , sous licence MIT, donc servez-vous. Voici les pré-requis :

1. votre site doit être derrière Cloudflare, le plan gratuit suffit largement.
2. vous générez un token API Cloudflare avec le droit de lecture sur les analytics.
3. vous posez le script live_count.py sur votre serveur et vous le lancez une fois par minute (ou toutes les 5 ou 10 min) via un cron.
4. vous ajoutez le bout de JavaScript et son span dans vos pages, tout se règle par des attributs, aucun script inline, donc ça passe même avec une politique de sécurité stricte.

Le seul truc sur lequel ne pas vous louper, c'est de mettre un temps de cache court à live.json. Si c'est trop long, tous vos visiteurs verraient un chiffre périmé.

Voilà. Un petit compteur maison simili-live sans tracking et qui ne me coûte rien, c'est le bonheur !

EmuDevz - Le jeu où vous codez votre émulateur NES

Afska, le développeur derrière une flopée d'outils pour Game Boy Advance, a eu avec son studio [r]labs une idée géniale ! Ça s'appelle EmuDevz, et c'est un jeu vidéo dans lequel vous devez coder votre propre émulateur NES. Et pas en cliquant sur des boutons comme un loser, hein mais en pissant du vrai code pour le processeur, la puce graphique et la puce audio de la console de Nintendo.

Favicon - Un site web planqué dans 212 octets

Si vous ne connaissez pas, un favicon, c'est cette mini icône pixelisée que vous pouvez voir dans l'onglet de votre navigateur qui en général est le logo du site que vous visitez. Hé bien le dev Tim Wehrle a réussi à y faire tenir un site web entier en stockant tout son HTML dans les 212 octets de l'image.

L'astuce est toute con vous allez voir... Une image, c'est des pixels. Et chaque pixel a 3 valeurs : rouge, vert, bleu, soit 3 octets. Du coup il prend son HTML, le découpe octet par octet, et colle chaque octet dans une couleur. Premier octet dans le rouge, le suivant dans le vert, puis le bleu, et on continue ainsi de suite. Et voilà comment il arrive à stocker 208 octets de HTML dans un carré de 9 pixels sur 9. Et au final, le truc ressemble à des confettis random.

Pour relire tout ça ensuite, un peu de JavaScript suffit. Le navigateur charge l'image, la passe dans un canvas, relit chaque pixel, recolle les octets et réaffiche la page. Il n'y a donc rien à installer et pour tester ça par vous-même, il a même mis une démo ici où vous pouvez regarder l'encodage / décodage se faire sous vos yeux ébahis.

Maintenant, n'espérez pas faire tenir votre site e-commerce là dedans hein puisque la capacité plafonne à 239 octets. Et sans le bout de JavaScript qui décode, le favicon tout seul ne servira à rien. Et ce n'est pas de la stéganographie non plus puisqu'on ne planque rien dans une vraie image. La data c'est l'image...

Mais c'est le genre de hack inutile que j'adore ! Le code est sur GitHub si vous êtes curieux et il raconte toute sa démarche sur son blog .

Ableton Extensions SDK - Codez vos propres outils pour Live

Je suis trop content parce qu'avec son nouveau SDK pour extensions , Ableton nous permet enfin d'écrire nos propres outils pour son DAW Live en JavaScript. L'intérêt c'est que ces extensions peuvent lire et modifier vos Sets : pistes, clips, notes MIDI, paramètres, automations... et comme ça votre projet se transforme en un truc qu'on peut trafiquer avec du code (et donc avec de l'IA car ça repose sur des technos web standard ^^ niark niark).

En pratique, une extension peut renommer tous vos clips d'un coup, transformer une photo en mélodie MIDI, découper un beat tout seul, ou carrément faire tourner un petit jeu dans Live. Vous faites un clic droit dans le Set, ça s'exécute, et hop, c'est plié !

Par contre, ça ne remplace pas Max for Live puisque Max tourne en temps réel en agissant sur le son des synthés et des effets alors que les Extensions, elles, se lancent d'un clic droit, font leur boulot, puis s'arrêtent. Ce n'est donc pas du temps réel. C'est juste fait pour automatiser et bidouiller la structure d'un projet mais c'est ce qui fait que les deux se complètent bien.

Screenshot

Pour vous lancer, il faut Node.js, être à l'aise avec le terminal, et toute la doc est sur GitHub . Ableton a même sorti une vidéo qui montre comment créer sa première extension de bout en bout.

J'ai testé en le branchant avec Claude Code, et je lui ai demandé de me faire un morceau french electro du thème d'Indiana Jones et voilà ce que ça m'a sorti from scratch (j'ai juste mis un kit rock pour les drums car sinon, y'avait pas de son sur la piste) :

Maintenant, c'est réservé à Live 12 Suite (Beta), soit le haut de gamme du logiciel, donc sur Standard ou Intro, c'est mort. Ensuite c'est de la bêta, donc c'est pas encore 100% complet... Et n'oubliez pas que c'est du JavaScript tiers qui s'exécute dans Live avec un accès à votre projet, donc ça peut toujours faire des dégâts. Évitez donc d'installer un truc random trouvé sur Discord, car ce serait un peu comme quand vous lanciez des VBScript reçus par mail à la grande époque de Windows 98. Surtout que du code pondu par une IA peut aussi cacher quelques saloperies sans que ça se voie, donc vérifiez toujours d'où ça vient et lisez le code.

Quoi qu'il en soit, si vous êtes sur Live 12 Suite, foncez tester et surtout amusez-vous bien !

FROST - Quand un site web peut vous tracker grâce à votre SSD

FROST, c'est le nom d'une nouvelle attaque qui transforme votre SSD en mouchard. Des chercheurs de l'université de Graz, avec Daniel Gruss au générique (un des cerveaux derrière Spectre et Meltdown), ont montré qu'un simple site web peut deviner quels autres sites et applis vous avez ouverts et cela juste en mesurant les micro-ralentissements de votre disque. Oui, je sais c'est geudin !

Le principe ?

Quand vous ouvrez la page piégée, elle crée discrètement un gros fichier sur votre disque via une API du navigateur baptisée OPFS ( Origin Private File System ), présente aujourd'hui dans tous les navigateurs modernes. C'est ce fichier qui sert de sonde.

Le JavaScript passe son temps à lire dedans et chronomètre chaque lecture au poil de cul et dès qu'une autre appli ou un autre onglet sollicite le SSD, ça crée un embouteillage minuscule sur le disque... que le code peut repérer sous forme de ralentissement.

Sauf que des variations de timing, ça reste du bruit illisible pour un humain. Du coup les chercheurs ont balancé toutes ces mesures dans un réseau de neurones (un CNN, le même genre de bidule qui reconnaît des choses sur des photos).

Entraîné sur des tonnes de traces, le modèle apprend alors la signature de chaque appli et de chaque site web et voilà comment à partir de ça, il devine ce que vous avez ouvert !

Sur un Mac, dans les tests présentés cette semaine, le truc retrouve le bon site parmi un top 50 dans près de 9 cas sur 10, et grimpe à plus de 95% pour reconnaître les applications ouvertes. Le tout sans la moindre action de votre part, à part avoir cliqué sur le lien. C'est totalement invisible.

Mais avant de débrancher votre PC, renvoyer votre box internet et vous lancer à temps complet dans la culture de chanvre, faut relativiser, car cette attaque a plusieurs limites... Le hic numéro un, c'est que le fichier-sonde doit être énorme, genre 1 Go ou plus, et un site qui se met à bouffer autant de place sur votre disque, ça se remarque vite. Le hic numéro deux, c'est que ce fichier doit être sur le même SSD que le navigateur sinon l'attaque est aveugle.

Les chercheurs ont fait tourner l'attaque complète sur un Mac M2, et démontré que la brique de base fonctionne aussi sous Linux (sans dérouler la classification complète), mais n'ont pas testé Windows. Et surtout, personne n'a encore vu FROST exploité dans la nature.

Perso, je trouve que cette attaque est trop bancale / incertaine pour faire du tracking de masse, en tout cas aujourd'hui...

Pensez donc à fermer les onglets dont vous ne vous servez plus comme ça, y'a moins d'activité à mesurer et pour les plus paranoïaques, vous pouvez toujours vous mettre à surveiller les fichiers OPFS créés par des sites web inconnus. Après comme tout repose sur du JavaScript, bloquer le JS sur les sites pas nets (avec un NoScript ou équivalent) ça coupe aussi l'attaque à la racine.

Les chercheurs proposent aussi aux éditeurs de navigateurs de plafonner la taille de ces fichiers OPFS. Ce serait dans la lignée de ce que fait par exemple Firefox avec le pistage, qui a récemment musclé son anti-fingerprinting .

Bref, pas de panique, personne ne fouille votre SSD en douce mais la technique reste intéressante. Les détails techniques complets sont dans le papier de recherche , qui sera présenté à la conférence DIMVA en juillet. Bonne lecture !

Source

tar-vfs-index - Monter du .tar.gz dans le browser sans l'extraire

Distribuer des paquets binaires en WebAssembly, c'est galère. Vous téléchargez le .tar.gz, vous le gunzippez, vous l'extrayez en mémoire... et ça rame sévèrement !! Mais youpi, Jeroen Ooms (qui contribue à webR et bosse chez ROpenSci) vient de publier tar-vfs-index , un petit npm package qui casse cette malédiction des enfers en sautant carrément l'étape extraction.

L'astuce est toute bête ! Au lieu d'extraire l'archive, on génère un fichier d'index qui liste la taille et l'offset de chaque fichier dans le tar. Du coup le navigateur n'a plus qu'à monter le blob du tar comme un système de fichiers virtuel, et chaque lecture devient alors un simple slice du blob à la bonne position. Pas d'extraction donc, mais juste du slicing à la demande !

Sous le capot, ça repose sur 3 propriétés alignées. 1/ le format tar est un layout plat : une suite de headers de 512 octets suivis des données du fichier, le tout contigu et adressable à l'octet près. 2/ Emscripten propose un backend filesystem appelé WORKERFS, prévu pour servir les lectures d'un Blob sans le copier dans le heap WASM. Et 3/ les navigateurs ont une API native, DecompressionStream , qui gunzippe efficacement pendant le téléchargement.

Concrètement, vous installez le truc avec npm install tar-vfs-index (y'a aucune dépendance externe) puis vous lancez npx tar-vfs-index archive.tar.gz. Et hop, le package vous sort un JSON dans ce genre :

{
 "files": [
 { "filename": "mypackage/DESCRIPTION", "start": 512, "end": 548 },
 { "filename": "mypackage/R/code.R", "start": 1536, "end": 1563 }
 ],
 "remote_package_size": 3072
}

const [metaRes, dataRes] = await Promise.all([
 fetch('archive.tar.gz.json'),
 fetch('archive.tar.gz'),
]);
const metadata = await metaRes.json();
const blob = await new Response(
 dataRes.body.pipeThrough(new DecompressionStream('gzip'))
).blob();
FS.mkdir('/pkg');
FS.mount(WORKERFS, { packages: [{ metadata, blob }] }, '/pkg');