GitHub commit spoofing - Quand n'importe qui peut être Linus
Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?
Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.
Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".
Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...
Pourquoi Git laisse passer ça
Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.
Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.
Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.
Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)
Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :
# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3
# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "torvalds@linux-foundation.org"
# 3. Vérifier la config
git config --global --list | grep user
# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"
# 5. Pousser sur votre repo
git push origin main
Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.
Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.
Étape 2 : Repérer un commit douteux
Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.
Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...
Étape 3 : Signer vos commits avec SSH
Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :
ssh-keygen -t ed25519 -C "votre@email.com"
Configurez Git pour signer automatiquement avec cette clé :
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true
Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.
Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans
le tuto sur Thunderbird et GPG
.
Étape 4 : Activer Vigilant Mode
Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.
Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.
La position de GitHub (et pourquoi je trouve ça discutable)
GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.
Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.
Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.
Google Workspace CLI - Pour piloter tous les services Google avec votre IA
Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !
Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.
Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.
Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.
Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension
Gemini CLI
qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.
En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?
Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !
Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...
Hash MD5 - 60% des mots de passe craqués en moins d'une heure
60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure... C'est ce que dit en tout cas une étude de Kaspersky publiée cette semaine qui se base sur +231 millions de mots de passe qu'on peut trouver sur le dark web et tirés de fuites ayant eu lieu entre 2023 et 2026. D'après leurs tests, 48% sont craqués en moins d'une minute et 60% en moins d'une heure. C'est pas très rassurant, surtout si votre base tourne encore au MD5.
Ce qui a changé ces dernières années, c'est surtout la puissance des GPU modernes qui n'a cessé d'augmenter. Par exemple, une RTX 5090 monte à 220 milliards de hash MD5 par seconde ce qui représente une augmentation de +34% par rapport à la RTX 4090 ! Du coup, louer un GPU cloud pour lancer une attaque par dictionnaire revient à quelques dizaines de centimes à quelques dollars de l'heure. C'est rentable hein ?
L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres. Et là, du point de vue des règles hashcat, c'est du pain bénit car les crackers adorent la prévisibilité. Alors attention si vous administrez un service web avec une gestion de comptes utilisateur car les attaques modernes (dictionnaire + règles hashcat) règlent aujourd'hui son compte à une bonne partie du corpus et cela en moins d'une minute. Par contre, les mots de passe longs avec symboles variés résistent encore puisque c'est exponentiel ! Vaut mieux une phrase de passe avec plein de mots et facile à retenir du genre running-douche-afford-laborer-art-amber-deftly-acetone-lego-reoccupy qu'un mot de passe court et complexe comme 3d2^vO$RZ1.
Bref, MD5 pour les mots de passe c'est mort donc si vous avez encore ça dans vos bases, migrez moi tout ce bordel rapidement ! La migration maintenant, ça se fait vers Argon2id en priorité... Je balance pas ça au pif, hein, c'est le standard recommandé par OWASP et le NIST, et c'est memory-hard, donc les GPU ne peuvent pas juste brute-forcer des milliards de hashs par seconde comme avec MD5.
Après si votre stack est ancienne et qu'Argon2id n'est pas dispo, bcrypt reste une option solide. Dans tous les cas, évitez SHA-1, SHA-256 ou SHA-512 sans algorithme adaptatif car ils sont rapides par conception, donc tout aussi crackables que MD5.
Dirty Frag - L'exploit kernel Linux qui donne un accès root sur toutes les distros
Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.
L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.
Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!
La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.
Alors comment ça marche ?
Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.
Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.
Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.
Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.
Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.
Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via linux-distros@vs.openwall.org. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.
Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.
En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.
Tester avec Lima sur macOS
Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :
# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :
Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :
echo 3 > /proc/sys/vm/drop_caches
Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.
Alors que faire ?
Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.
Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...
En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.
Source : https://github.com/V4bel/dirtyfrag
Google Discover - L'algorithme qui choisit vos actus à votre place
Vous le savez, il y a un algorithme dans votre téléphone qui décide ce que vous allez lire aujourd'hui et il s'appelle Google Discover.
Google Discover, c'est le flux d'articles qui apparaît quand vous ouvrez l'appli Google sur Android ou iOS, ou que vous swippez à gauche depuis la home de votre smartphone Android et Chrome mobile aussi. Et pas besoin d'avoir cherché quoi que ce soit puisque Google analyse votre historique, connaît vos centres d'intérêt, et vous sert ainsi des articles « adaptés » en continu.
Sauf que l'algo confond souvent « ce que vous voulez lire » avec « ce qui génère le plus de clics ». Et là, ça part en couille sévère...
Du coup vous vous retrouvez avec des articles qui expliquent que le cash va être interdit dans deux mois, que les conducteurs avec une moustache vont devoir repasser le permis, ou que l'Union Européenne s'apprête à requalifier la pizza comme « sandwich plat » pour l'assujettir à une nouvelle taxe.
Et pendant ce temps, les vraies actus tech que vous aimez tant, elles, se noient quelque part entre deux horoscopes et une pub déguisée en article. Et c'est d'ailleurs ça le gros défaut de tous les flux algorithmiques : ils optimisent l'engagement mais pas l'exactitude. On est tous humain, alors forcément un titre alarmiste battra toujours un article de qualité sobre et bien sourcé. L'algo se contrefout royalement de respecter les 3 neurones qui vous restent... ^^
Mais Discover a quand même un truc pas con ! En fait depuis fin de l'année dernière, Google permet de suivre directement des éditeurs sur le réseau, un peu comme un flux RSS mais sans lecteur à installer ni boîte mail à gérer. Suffit de cliquer sur un bouton et hop, les articles de vos sources préférées remontent en priorité dans votre feed Google Discover !
Par exemple, si vous voulez voir les articles de Korben.info apparaître dans votre flux (de la vraie tech, sourcée, sans moustaches ni taxes pizza), c'est par là, il suffit d'aller sur mon profil Google Discover et de cliquer sur le bouton "Suivre sur Google".
Et comme ça, une fois abonné, mes publications remonteront directement dans votre Discover. Perso, je trouve ça pas mal du tout comme système.
Bref, si vous ne voulez pas que votre téléphone vous apprenne demain que les chats seront bientôt recensés comme « animaux de surveillance passive » par un nouveau décret gouvernemental, pensez à bien choisir vos sources !
Et pour trouver les liens de vos médias préférés, vous pouvez passer par cet outil de Julien .
LibreSpeed - Le test de vitesse à auto-héberger
Speedtest.net c'est pratique, sauf que ça a été racheté par Accenture en 2026 et chaque test envoie votre IP, le nom de votre FAI et votre localisation à leurs serveurs...
Alors pourquoi ne pas adopter LibreSpeed , l'alternative open source que vous hébergez chez vous, et qui ne contient aucun tracker ??? L'outil est signé Federico Dossena, ça a été lancé en 2016 et c'est sous licence LGPL v3. Et ce que ça mesure c'est la vitesse du download, de l'upload, le ping, le jitter , et ça relève aussi l'adresse IP et le nom de votre FAI.
Côté déploiement, c'est du classique. Vous déposez les fichiers sur votre serveur, dont speedtest.js et speedtest_worker.js pour le frontend, vous configurez le backend via config.json, et hop c'est lancé. Un simple VPS ou n'importe quelle autre machine sur votre LAN fera l'affaire.
Et comme vous choisissez le serveur de test, y'a pas de saturation par d'autres utilisateurs, pas de route réseau bizarre vers un data center à l'autre bout de l'Europe et surtout, les résultats sont parfaitement reproductibles donc pour les "homelabers" (c'est comme ça qu'on dit ?) ou les équipes réseau, c'est assez chouette.
Il y a aussi le mode multi-serveur pour comparer des endpoints, le partage de résultats via lien unique, et un CLI librespeed avec ses flags --server et --host pour les fans du terminal. Des backends officiels en Go et Rust existent aussi sur le github de
librespeed
, signe que le projet est sérieux.
Et surtout, les résultats sont fiables, sauf si votre serveur plafonne à 20 Mbit/s et dans ce cas, vous mesurerez sa liaison et pas la vôtre. Ça coule de source, mais je tenais à le préciser quand même...
Voilà, l'interface est moche, en tout cas beaucoup plus que celle de Speed.cloudflare.com , par contre l'essentiel est là. Et surtout, les mesures restent chez vous plutôt que de partir ailleurs.
Un hamster qui court dans une roue peut-il charger un téléphone ? Apparemment oui
Le YouTubeur « Flamethrower » a documenté un projet aussi inutile que satisfaisant : utiliser un hamster comme source d'énergie pour charger son smartphone.
Le principe est simple sur le papier. Vous prenez un hamster, vous le mettez dans une roue, vous reliez la roue à un générateur, et au bout d'une nuit complète d'activité rongeuse, vous obtenez assez de jus pour démarrer la charge d'un téléphone. Pas pour finir la charge, hein. Juste pour la commencer.
Le maker a utilisé un module CJMCU-2557, basé sur la puce TI BQ25770. C'est un composant fait pour récupérer de très petites quantités d'énergie : il accepte des tensions entre 0,1 et 5,1 V (avec un minimum de 0,6 V pour démarrer), un courant max de 0,1 A, et il intègre un supercondensateur pour stocker ce qui rentre.
La roue du hamster fait tourner un petit générateur à courant continu, qui alimente le BQ25770, qui charge le supercondensateur, qui charge ensuite des cellules Li-ion 18650 récupérées sur des batteries usagées. Avec ce relais, l'énergie hamster finit par se stocker dans des batteries qui peuvent ensuite charger un téléphone via un câble USB classique. Bricolage propre.
Maintenant la vraie question : combien d'énergie produit réellement un hamster ? Eh bien très peu en fait.
La chaîne complète de conversion (mécanique vers électrique, supercondensateur vers cellule 18650, cellule vers téléphone) génère des pertes à chaque étage. Du coup, après une nuit, vous avez juste assez pour commencer la charge, pas pour la terminer. C'est très loin du panneau solaire, et encore plus loin d'une simple prise murale.
Mais bon, ce n'est évidemment pas le but. Le projet existe pour démontrer qu'on peut techniquement le faire, pas pour révolutionner la production d'énergie domestique. Le hamster a fait sa petite course, le maker a sa vidéo YouTube avec une vraie puce dedans, et tout le monde apprend quelque chose sur la récupération d'énergie à très basse puissance. Les commentaires de Hackaday ironisent d'ailleurs déjà sur le potentiel du hamster pour la "domination mondiale", ce qui résume assez bien le ton du projet.
Bref… un hamster qui charge votre téléphone, c'est mignon, c'est inutile, et c'est exactement pour ça que c'est génial.
Source : Hackaday
Au Royaume-Uni, les enfants contournent la vérification d'âge avec des fausses moustaches dessinées
Le Royaume-Uni a mis en place via l'Online Safety Act un système de vérification d'âge obligatoire sur les plateformes accessibles aux mineurs, avec contrôles biométriques à la clé pour estimer l'âge à partir d'un selfie.
Sur le papier, c'était la grande solution pour empêcher les ados d'accéder à TikTok, Instagram ou aux sites pour adultes. En pratique, c'est l'inverse : les enfants britanniques se passent les méthodes pour passer outre, et les méthodes en question sont parfois franchement drôles.
En fait, selon une étude d'Internet Matters, près de la moitié des enfants britanniques (46 %) considèrent les systèmes de vérification d'âge comme faciles à contourner, et un tiers reconnaissent l'avoir déjà fait.
Les méthodes documentées vont de la classique fausse date de naissance au VPN, mais aussi à des techniques plus créatives : envoyer une vidéo du visage de quelqu'un d'autre, voire d'un personnage de jeu vidéo, et le meilleur : se dessiner une moustache au feutre pour tromper l'estimation d'âge faciale. J'adore.
Côté plateformes, c'est du coup difficile à gérer. L'Online Safety Act prévoit des amendes importantes contre les services qui laisseraient passer ces contournements, mais le régulateur Ofcom rame pour qualifier la responsabilité quand le gosse a triché lui-même avec une astuce que la plateforme n'a pas su détecter.
Internet Matters relève d'ailleurs que les adultes profitent aussi de ces failles, ce qui complique encore le tableau quand un majeur peut piquer la session d'un mineur, ou inversement.
L'autre limite, c'est la captation des données biométriques. Pour vérifier qu'un gosse est bien un gosse, il faut analyser son visage, ce qui veut dire stocker (ou au moins traiter) une image biométrique d'un mineur.
Plusieurs experts ont déjà soulevé le paradoxe : pour protéger les enfants, on les oblige à transmettre leur visage à une plateforme étrangère. Et si la plateforme se fait pirater (spoiler : ça arrive régulièrement), on a une fuite de données très sensibles dans la nature.
Vous l'avez compris, une régulation qui se fait contourner par un coup de feutre sous le nez, c'est probablement le signe qu'il faut revoir la copie.
Source : Independent
GridTV, le guide TV open source pour votre setup IPTV
Bon, maintenant que vous avez vos chaînes IPTV qui tournent via Tunarr ou xTeVe, votre flux XMLTV est super propre. Mais il vous manque un seul truc : Un guide de programme potable.
Hé bien GridTV développé par l'ami JohnnyBeGood est là pour ça !
GridTV c'est une interface web en PHP/JS/CSS qui transforme toute source XMLTV compatible en guide TV façon grille horizontale, avec l'indicateur "maintenant" visible en permanence, une barre de progression du programme en cours, et les émissions passées qui se retrouvent automatiquement grisées. C'est exactement ce à quoi ressemble le guide TV de votre box opérateur, mais en mieux, et pour votre propre contenu !
Pour le déploiement, Docker est le chemin recommandé plutôt que de tout configurer à la main : git clone, cd GridTV, docker compose up -d, et hop, vous ouvrez localhost:8080.
Un assistant de setup vous demandera alors votre source EPG obligatoire et une playlist M3U si notamment vous voulez utiliser le player intégré, et une fois validé, vous retombez directement sur la grille.
Ça se met en place en moins de 5 min mais si vous préférez installer sans Docker, ou plutôt sans la couche conteneur, il y a également sur le Github des exemples de config pour Apache et Nginx dans la doc. Caddy fonctionnera aussi et la doc concernant Traefik, c'est pour le cas où GridTV tourne en Docker mais derrière un reverse proxy.
Côté fonctionnalités, le player HLS s'ouvre en PiP (Picture in Picture) dans un coin en cliquant sur une chaîne et le multi-EPG vous permettra de configurer plusieurs sources avec un petit switch. GridTV propose aussi des rappels de programme via notifications navigateur, 15 minutes avant la diffusion. Mais pour en profiter, l'onglet du browser doit rester ouvert et les notifs autorisées.
Et il y a aussi possibilité de générer un export PDF/PNG du guide sur 24h. C'est pas indispensable mais ça permet pour ceux qui veulent d'imprimer le programme de la soirée.
Chaque visiteur de l'instance peut aussi utiliser / paramétrer ses propres URLs XMLTV/M3U, car rien n'est stocké côté serveur. Hé oui, tout passe par le localStorage du navigateur donc vous pouvez partager votre instance avec autant de monde que vous voulez, ça n'a pas d'impact.
La version Steampunk
Et il y a même des thèmes genre cyberpunk, steampunk, magazine ou le thème par défaut. Et la page de monitoring admin expose également une sonde accessible via un endpoint compatible Uptime Kuma qui renvoie le code HTTP 200 si tout va bien. Sinon, ce sera du code 503. Bref, ça vous connaissez...
Bref, l'outil est jeune mais bien construit et une démo live tourne ici guide.demo.johnnybegood.fr . À suivre donc....
Et si vous cherchez juste des listes de chaînes IPTV gratuites , c'est par là !