Allez, on va faire un jeu. Cherchez un disque dur externe sur Amazon et regardez où pointe le premier lien de la page. Bingo, ça part sur une adresse en /sspa/click, autrement dit un emplacement publicitaire. Et c'est pas le mieux noté, c'est pas le moins cher, non, c'est juste celui qui a payé le plus pour être là.

Et moi, ce qui me saoule vraiment, c'est que les filtres n'y peuvent rien.

Pour remédier à cela il faut sortir l'artillerie. J'ai d'abord pensé à faire un filtre uBlock Origin, puis à me coder une extension Firefox, avant de me rappeler que Tampermonkey tournait déjà dans mon navigateur.

Direction le repo Greasy Fork, donc, où traîne un script qui fait exactement ça . Une cinquantaine de règles CSS, qui dégagent du DOM les résultats sponsorisés de la recherche, les carrousels promo, les encarts publicitaires de la fiche produit, l'upsell Prime et les bannières de marque.

On passe ainsi de ça :

À ça :

Et ça fonctionne super sur toutes les versions d'Amazon, y compris Amazon.fr.

Trois réglages attendent dans le menu du gestionnaire de scripts. Un compteur qui affiche en bas de page ce qui a été retiré et pourquoi, une journalisation console pour les curieux, et une option qui redirige les pages de navigation vers la vraie liste de résultats.

Attention quand même à ce qui saute en plus des pubs. Le bloc "Les gens qui ont acheté ça, ont aussi acheté ça". Le script s'attaque aussi à Rufus, l'assistant d'achat maison et côté installation, il vous faut Tampermonkey, Violentmonkey ou Greasemonkey. Sur Firefox, ça s'arrête là. Par contre sur Chrome, depuis la version 138, il faut en plus activer un switch "Allow User Scripts" sur la fiche de l'extension, coupé par défaut sur toute extension fraîchement installée.

Voilà, j'espère que ça vous aidera à avoir un Amazon un peu plus propre. Maintenant, n'oubliez pas, Amazon, c'est le mal, donc si vous avez les moyens de payer 2x plus cher la même chose et que vous aimez passer votre vie dans les transports ou en bagnole à faire une espèce de chasse au trésor à travers toute la ville, pour trouver le produit qu'il vous faut, le mieux reste encore et toujours d'acheter dans des magasins physiques. Lol.

Voici une bonne nouvelle du côté de Chrome puisque ce dernier a commencé à enfermer la clé qui signe votre session dans la puce de sécurité de votre machine, c'est-à-dire le TPM sous Windows, ou la Secure Enclave sous macOS. Le serveur envoie un défi, le navigateur le signe, et la clé privée ne sort jamais du silicium. Ainsi, un cookie de session recopié ailleurs ne suffit donc plus à entrer dans votre compte.

Ça s'appelle DBSC, pour device-bound session credentials et comme le résume Scott Helme, qui vient de déployer le protocole chez Report URI : "*L'attaquant peut voler le cookie, mais il ne peut pas répondre à un défi DBSC en le signant avec la clé privée, qui reste en sécurité sur votre appareil *".

Depuis que la double authentification et les passkeys se généralisent, voler un mot de passe ne rapporte plus grand-chose et c'est pour cela que les attaquants sont passés au cookie de session, un bout de texte qui prouve au site que vous êtes déjà bien connecté.

Ils le récupèrent avec un infostealer, ou avec une page de phishing qui relaie votre vraie connexion, comme le faisait la plateforme Tycoon 2FA démantelée par Europol . Ensuite ils collent le cookie dans leur navigateur et héritent de votre session. Et votre bonne vieille 2FA n'y change rien, puisqu'elle est déjà passée.

Donc ce DBSC c'est une bénédiction, surtout que côté utilisateur, il n'y a rien à activer.

Google a basculé ses propres comptes dessus fin mai, sur Chrome pour Windows, et il n'existe ni réglage administrateur ni réglage utilisateur pour le couper. Pour le reste du web, il faut évidemment que le site ait implémenté le protocole de son côté, et Chrome ne l'ouvre encore qu'à une partie des utilisateurs (dispo à partir de la version 147 sous Windows et 150 sous macOS).

Pour vérifier si c'est en place chez vous, ouvrez les outils de développement (F12) sur un site où vous êtes connecté, votre compte Google par exemple, onglet Application, et cherchez "device bound sessions". Si la ligne apparaît, c'est que c'est actif. Sinon, c'est que le site, votre version de Chrome ou votre machine ne suivent pas encore, et Chrome retombe alors sur la session classique sans rien casser.

Sur Firefox, en revanche, il ne faudra pas l'attendre car Mozilla a acté début août une position officielle négative sur le sujet. Les deux reproches que fait Mozilla c'est que DBSC laisse une fenêtre ouverte pendant laquelle un cookie volé reste utilisable, et que son flux de réauthentification est un protocole ad hoc qui ne colle pas à la gestion normale des cookies.

Mozilla craint aussi qu'on finisse par exiger des sites une attestation matérielle, ce qui limiterait le choix du matos... Google répond que rien de tel n'est prévu, et que faire signer chaque requête s'est révélé infaisable à grande échelle. Mais bon, cette position négative n'interdit pas une implémentation future... On verra bien. Apple, elle, n'a jamais tranché, mais a prévenu que DBSC risquait de compliquer la restauration d'un appareil depuis une sauvegarde.

Bref, aujourd'hui, ça se joue donc sur Chrome, et seulement là où le site a implémenté DBSC, mais je pense que ça s'étendra de plus en plus à l'avenir.

Source

Aujourd'hui, je tiens à vous présenter cette extension navigateur qui colle le nom du propriétaire à côté des résultats Google dont le média est référencé, aussi bien dans la recherche Web que dans l'onglet Actualités. Ça s'appelle "Qui possède ?" et sa base de référence contient 584 médias français.

Une fois le propriétaire identifié, le badge reste affiché quand vous arrivez sur le site du média.

Au survol du badge, la chaîne de détention se déroule alors en entier, du média jusqu'au propriétaire final, avec la source de l'info. Les données viennent de l'open data d'Acrimed et du Monde diplomatique + les propres recherches de l'auteur de l'extension. Ensuite, les propriétaires sont répartis dans 7 catégories : milliardaire, famille ou propriétaire privé, groupe de presse, banque ou fonds, public, religieux, et indépendant.

Bien sûr, Korben.info est dedans, chez les indépendants, avec moi comme seul propriétaire ^^.

La base est embarquée dans l'extension, disponible sur Chrome, Firefox et Firefox Android et les permissions de celle-ci se limitent au stockage local, à 6 domaines Google et aux sites des médias référencés. Aucun serveur tiers n'est donc appelé et en plus c'est gratuit.

Et s'il manque un média, un bouton apparaîtra même dans les résultats pour le proposer. Bref, installez-la sur Chrome ou Firefox , et signalez les médias qui manquent.

Merci REDMAMBA l'auteur de l'extension pour le partage !

Si vous avez un Raspberry Pi et que Chromium commence à vous fatiguer, le VRAI Chrome, celui des chads que vous êtes, est enfin dispo en ARM64 !! Enfin, dispo... Si vous savez où chercher, parce que la page de téléchargement de Google vous propose toujours l'installeur amd64, qui ne tournera jamais sur votre machine. C'est Joey Sneddon, d'OMG! Ubuntu, qui a trouvé la combine en bidouillant l'URL depuis son Pi 5.

Avant toute chose, vérifiez que vous êtes bien en 64 bits, parce qu'un système 32 bits refusera le paquet :

dpkg --print-architecture

Si ça répond arm64, le fichier est là , 126 Mo. Il s'installe comme n'importe quel .deb local, en laissant apt gérer les dépendances :

wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb
sudo apt install ./google-chrome-stable_current_arm64.deb

Le RPM existe aussi pour les distributions qui préfèrent, en remplaçant la fin du nom par aarch64.rpm.

J'ai ouvert le paquet pour regarder ce qu'il y avait dedans. Son fichier de contrôle annonce google-chrome-stable en version 150.0.7871.186, architecture arm64, un peu plus de 400 Mo une fois installé. Soit exactement la même version que le paquet x86 poussé le même soir. Le même Chrome, à la même révision.

Et le canal stable n'est pas seul. Le dépôt de Google sert aussi la beta (151.0.7922.47), la dev (152.0.7967.2) et la canary (152.0.7974.0) pour les puces ARM, et son fichier Release déclare noir sur blanc les deux architectures. Les quatre canaux ont été publiés dans la même minute que leurs équivalents x86.

Est-ce qu'on se retrouve coincé sur cette version, à re-télécharger le .deb à la main tous les mois ? Non. Le script de post-installation contenu dans le paquet ajoute le dépôt Google en précisant l'architecture, et les cinq paquets y sont indexés en arm64 exactement comme en x86. Les mises à jour ont donc de quoi arriver par apt, comme d'habitude.

Alors pourquoi s'embêter, puisque Chromium tourne sur ARM depuis des années ? Pour deux trucs. D'abord ma synchro du compte Google, qui ramène favoris, mots de passe et extensions. Et ensuite, Widevine, le module DRM, qui est ici un vrai binaire aarch64 et pas une couche de compatibilité comme l'émulateur FEX financé par Valve . Netflix et les autres plateformes à DRM s'ouvriront enfin sur un SBC !!!

Mais avec une nuance à connaître avant de vous réjouir qui est que sous Linux, Widevine reste au niveau "Software Secure". Cela veut dire que sur Netflix, la qualité plafonnera entre 720p et 1080p. De la HD donc et pas de la 4K. Désoléééé !

Google avait promis tout ça en mars, pour le deuxième trimestre et son billet annonçait même une installation via chrome.com/download pour les autres distributions, ce qui est malheureusement le morceau qui manque aujourd'hui.

Cela veut dire aussi que rien ne garantit que ce paquet soit considéré comme étant prêt par ses auteurs donc si votre machine doit rester stable, laissez passer quelques semaines avant de vous y essayer.

Manque plus que quelqu'un chez Google ait le courage d'appuyer sur "publier".

Source

Vous le savez, j'adore mon Kindle ! Je manque effectivement de temps pour lire tout ce que je voudrais mais bon, on verra ça quand la retraite sera là ^^.

En attendant, ce que j'ignorais, c'est que sur les Kindle récents, il y a encore un petit navigateur web, plus exactement un vieux Chrome de 2019 bien planqué dans des menus qu'on n'ouvre jamais. Et c'est à ce module précisément que Tanguy Dubroca de Synacktiv s'est intéressé. Et en creusant, il a découvert qu'une faille s'y cachait et permettait de prendre le contrôle total de la liseuse avec votre compte Amazon en supplément salade tomate oignon.

Son objectif premier c'était de comprendre comment prendre la main sur un Kindle verrouillé sans le jailbreaker. Alors il a fouillé dans le firmware de son Paperwhite 5 et y a découvert ce vieux Chrome et son moteur Webkit d'une quinzaine d'années, prêt à céder à toutes ses demandes... niark niark.

Il n'a eu plus qu'à piocher dans les vieilles failles déjà bien connues de Chrome et en a choisi une présente dans le moteur Javascript V8 patchée par Google en 2022. Sauf que normalement, elle ne devait pas marcher sur un Kindle, parce qu'Amazon avait désactivé le composant vulnérable.

Enfin, avait essayé...

Parce que dans la commande censée le désactiver, il manquait deux petits tirets. Une faute de frappe qui faisait que l'option était ignorée en silence, et donc que le moteur JS d'époque restait allumé avec cette porte grande ouverte...

L'attaque n'a ensuite besoin que d'une seule chose qui est que vous ouvriez un site web piégé dans le navigateur de la liseuse. Pas de panique donc, car ça ne se déclenche pas tout seul quand vous recevez un livre, mais une fois la page web ouverte, elle peut trafiquer la mémoire de l'appareil, ce qui permet au chercheur de prendre la main sur le navigateur pour ensuite, via une seconde vulnérabilité dans le composant qui lance les applis, obtenir des droits administrateur et donc l'accès complet.

Une fois avec ça, il peut tout faire comme exécuter n'importe quel programme, vous espionner, détourner votre compte Amazon, et même rebondir vers les autres appareils présents sur votre réseau Wi-Fi. La totale !!

Dubroca a prévenu Amazon en décembre 2025, qui a classé le truc en critique, lâché 20 000 $ de prime, et poussé un correctif dans le firmware 5.19.2 en janvier. La mise à jour se fait toute seule une fois le Kindle branché et connecté au Wi-Fi alors si votre liseuse dort dans un tiroir depuis des mois, un petit coup de Wi-Fi et elle se mettra à jour, hop. D'ailleurs c'est la deuxième faille Kindle en 7 mois , après celle du livre audio piégé. Deux équipes françaises, deux fois le même appareil, ça commence à faire beaucoup pour de vieilles liseuses qu'Amazon laisse doucement vieillir .

Bref, une liseuse c'est comme un ordinateur, ça se pirate mais ça peut se mettre à jour ^^. Ouf !

Source