Je relais rarement des pétition, car je suis convaincu que les signer revient généralement à se soulager dans un instrument de musique à corde frottées aussi onéreux que difficile à apprendre à utiliser.

Cependant, je fais une exception pour celle-ci : le gouvernement français semble décidé à faire passer une loi qui pourrait obliger les navigateurs à inclure dans leur code un système de blocage de sites illégaux sans passer par l'inefficace blocage DNS.

Dans les mains d'un régime totalitaire, un tel dispositif pourrait permettre une censure semblable à celle du "Grand Firewall" chinois, sans toutes les contraintes techniques derrière (il est bien plus simple de maintenir une simple liste de sites à bloquer et à laisser le sale boulot aux navigateurs, que d'installer toute une infrastructure réseau).

Autre problème qui n'est pas soulevé ici : le Web est un ensemble de technologies ouvertes, ce qui signifie que n'importe qui (ayant beaucoup de courage, je vous l'accorde) devrait être en capacité de créer son propre navigateur. Un tel projet n'implémentant pas la fonctionnalité réclamée par le gouvernement français deviendrait-il alors illégal ? Si oui, c'est alors la nature ouverte elle-même du Web qui est en danger.

La petite trouvaille du jour : si vous voulez envoyer indiquer aux algos de OpenAI que vous ne voulez pas qu'ils crawlent votre site, vous pouvez l'indiquer dans votre fichier robots.txt :

User-agent: GPTBot
Disallow: /

Edit : cette autre page indique qu'il existe un autre user-agent dédié à ChatGPT, on pourra donc également ajouter :

User-agent: ChatGPT-User
Disallow: /

Merci à @Troll sur Mastodon pour le partage !

Une très bonne nouvelle pour la vie privée sur le Web.

Notons également l'existence de l'extension Remove FBclid and UTM, avec laquelle cette fonctionnalité semble complémentaire.

— C'est qui Deuchnord ?
— C'est moi.

Un début de discussion tout à fait normal chez Les-Tilleuls.coop

Hier soir, j'indiquais brièvement et en 280 caractères que ce site avait subi une indisponibilité dans certaines situations. Pour être plus précis, cela arrivait notamment quand on tentait de venir sur tech.deuchnord.fr avec Safari et qu'on utilisait le réseau mobile d'Orange.

Autant vous dire que quand j'ai découvert ça, je ne comprenais pas tout. C'est avec l'aide d'un collègue que j'ai fini par trouver le coupable : la configuration du serveur Nginx !

Quand on installe Nginx pour la première fois sur son serveur, il crée un fichier par défaut qui ressemble à ceci :

server {
     # ...
     listen 80;
     # ...
}

Tel quel, on pourrait comprendre qu'une fois chargé, Nginx écoutera sur le port 80 (port standard dédié au protocole HTTP à la base du Web), et puis c'est marre. Spoiler : non, c'est pas le cas.

Ou pour être plus précis, Nginx ouvre bien le port 80 pour écouter ce qu'il se passe dessus, mais il le fait sur l'adresse IPv4 uniquement.
Si votre serveur possède aussi une adresse IPv6, vous devrez aussi indiquer à Nginx d'ouvrir le port sur ce protocole, autrement, il n'écoutera pas dessus !

Pour faire cela, rien de plus simple, il suffit d'éditer votre fichier et d'ajouter la directive suivante dans la section server :

listen [::]:80;

Notez bien les deux signes : entre crochets, suivis d'un nouveau signe :.
Une fois cette modification faite, rechargez la configuration (service nginx reload sous Debian), et votre site sera désormais bien disponible sur les adresses IPv6 !

Il est très facile de créer de jolies failles de sécurité, et c'est souvent le résultat d'un oubli ou d'une paresse.
Ici un cas pratique avec la Caisse d'Épargne qui avait oublié de supprimer un sous-domaine qui pointait à une époque vers un serveur légitime, depuis supprimé et dont l'adresse IP a été récupéré par un particulier… qui aurait pu effectuer des attaques assez violentes auprès des clients de la banque (s'il en avait eu conscience et l'avait voulu).

Je passe exceptionnellement par Archive.org pour partager ceci, étant donné que le ticket a été fortement altéré par le mainteneur de la librairie.

Apparemment, la librairie JavaScript node-ipc (utilisée par plus de 300 paquets, elles-même certainement en dépendance de beaucoup d'autres, vu que la plupart sont des librairies) a ajouté récemment un morceau de code offusqué qui s'active dans le cas où il est exécuté depuis une adresse IP russe ou biélorusse, et écrase tous les fichiers (au moins de l'application, peut-être du système entier) avec un message de protestation contre la guerre en Ukraine.

Faites donc très attention si cette librairie se trouve dans vos dépendances (directes ou non), car elle pourrait provoquer des dommages irréversibles pour vos utilisateurs.

Édit : un article ici qui explique la situation de façon un peu plus claire.

Vous vous souvenez quand Microsoft a sauté Windows 9 en disant que Windows 10 était « le renouveau du système d'exploitation », et que quelques mois plus tard on s'est rendus compte que la vraie raison était que ça aurait cassé plein d'applis qui recherchaient la chaîne Windows 9 dans le nom de l'OS pour détecter Windows 95 et 98 ?

Eh bah surprise (non) : Firefox et Chrome vont bientôt arriver à la version 100.0… et ça va casser des sites qui vont se croire sur Firefox/Chrome 10.0 ! 🙃

Les noms de domaine en .xyz, popularisés par Google lors de la création de leur holding Alphabet en 2015, semblent avoir acquis une réputation suffisamment mauvaise pour que le simple fait d'envoyer un e-mail à partir d'un tel nom de domaine suffit à le voir partir immédiatement en spam. Pire, il semblerait que le fait d'envoyer un lien avec un nom de domaine en .xyz par SMS provoque un échec d'envoi sans notification de l'émetteur. Dit autrement, le destinataire de votre SMS a de bonnes chances de ne jamais le recevoir.

Cette situation me fait beaucoup penser aux domaines gratuits en .tk qui ont reçu une mauvaise réputation après avoir été massivement utilisés pour réaliser des campagnes de phishing…

• Les cookies n'ont jamais été conçus au départ pour traquer les internautes. Ils ont été détournés de leur usage premier : stocker une information utile au site sur le navigateur.
• Un outil qui « permettrait […] de diffuser des messages ciblés, tout en évitant aux gens d'être suivis par ces cookies », c'est un outil qui traque par définition. Sauf que là, il est conçu pour cela.

Reste à savoir si l'élimination progressive de ces traceurs donnera à Google plus de contrôle sur sa publicité en ligne, un secteur qu'il domine pour l'instant aux côtés de Facebook.

Exactement la raison pour laquelle il ne faut pas laisser ce projet à Google, donc.

Cela signifie que si les propriétaires de sites Web ne modifient pas ces paramètres par défaut en modifiant le code source du CMS, la plupart des sites Web construits sur ces CMS mettent les mots de passe de l'utilisateur en danger si un pirate informatique volait la base de données du site.

Et comme la plupart des sites basés sur un CMS sont tenus par des personnes n'ayant aucun bagage technique, cela veut dire qu'une très large majorité d'entre eux stocke ses mots de passe de manière non sécurisé. C'est tout de même très problématique compte tenu qu'une très grande proportion de sites sont construits sur WordPress…

Par défaut, Nginx et PHP sont un peu bavard et signalent au client Web leurs versions exactes. Le problème est qu'il suffit ensuite d'une petite recherche pour visualiser les failles de sécurité existantes dessus.

Cette astuce permet de demander à Nginx et à PHP de ne pas envoyer leurs numéros de version respectifs.

Un outil sympa pour les développeurs Web. Il permet de générer des favicons pour toutes les plateformes, et fournit un outil permettant de vérifier que ces derniers sont bien en place.

Mine de rien, on penserait pas comme ça, que c'est aussi compliqué à gérer…

Utiliser un peu de ressource du visiteur pour miner de la cryptomonnaie me semble une idée intéressante en tant qu'alternative intéressante aux publicités, à partir du moment où cela est fait dans la limite du raisonnable.

Je pense pour ma part que cela ne devrait se faire que sous deux conditions :

• si l'utilisateur a donné son consentement (ou bien s'il ne s'est pas opposé à cette pratique, à voir) ;
• si le terminal est suffisamment puissant pour ce genre de chose.

À noter que nous sommes arrivés dans une ère où la plupart des visites sur le Web se font désormais sur un smartphone, donc gare à l'utilisation de la batterie…

C'est assez cocasse, comme faille !

Pas considéré comme une faille critique en soi, mais peut permettre de mener des attaques dans le but de piquer des données personnelles de l'internaute, ou même intercepter ses frappes au clavier sur une page Web.

Réponse des éditeurs des navigateurs principaux :

• Google : corrigée
• Apple : corrigée
• Mozilla : pas concerné par la faille
• Microsoft : osef, c'est pas un bug mais une fonctionnalité

Histoire de voir un peu autre chose que du Font Awesome sur le Web :)

Je suis un peu sceptique concernant cette décision : tous les sites n'ont pas forcément besoin d'être protégés par HTTPS. Je pense notamment aux petits sites perso qui ne contiennent que quelques pages Web contenant du texte et quelques images…

Dans un monde où 60% des internautes utilisent Chrome comme navigateur par défaut, c'est un choix qui me semble judicieux pour lutter contre les abus sur les publicités.
Bonus : vu que la fonction sera implémentée directement dans le navigateur, on sera peut-être débarrassés des boîtes de dialogues "Aidez-nous à survivre, désactivez AdBlock !".

Hmmm, intéressant… Si ce nouveau format est implémenté dans les lecteurs de flux, je proposerai probablement un système de flux dans ce format (tout en conservant le flux RSS classique, bien sûr, au moins le temps que la transition se fasse ^^)