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.
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 :
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".
Je viens de perdre de précieuses minutes sur un truc qui aurait dû me prendre trente secondes : Récupérer le numéro DUNS de mon entreprise.
Si vous ne savez pas ce que c'est, bienvenue au club ! En gros, c'est un identifiant que Dun & Bradstreet, une société américaine, a déjà collé à mon entreprise sans jamais me demander mon avis. C'est l'équivalent B2B de ce qu'Experian ou Equifax font sur les particuliers et leur job, depuis 1841 (oui, ils sont plus vieux que l'ampoule électrique), c'est de ficher les boîtes du monde entier et de revendre l'info.
C'est un peu le societe.com des américains quoi. Ils font le même taf que les mormons mais en maintenant une base de plus de 600 millions d'entreprises avec pour chacune, qui la dirige, son chiffre d'affaires, sa taille, si elle paie ses fournisseurs à temps, si elle a frôlé la faillite...etc. Bref, grâce à eux, sans le savoir, on a une note de solvabilité et une espèce de carte d'identité de notre entreprise.
Comme ça, avant qu'une banque ne vous prête de l'argent, ou qu'un gros client ne signe avec nous, ça permet de savoir si votre entreprise est solvable et réelle.
Sauf qu'à aucun moment, on ne nous demande notre avis. En France par exemple, leur partenaire exclusif c'est Altares qui crée automatiquement nos fiches à partir des registres publics (INSEE, RCS) dès que votre entreprise a un SIRET. On est donc enregistré par défaut et ensuite pour consulter SA PROPRE fiche ou la corriger, bah faut passer à la caisse.
Voilà, c'est juste un data broker de plus qui agrège des données en bonne partie publiques, pour y ajouter du comportement de paiement, et facturer l'accès aux pigeons qui passent.
Mais alors leur VRAI coup de génie, c'est ce code DUNS lui-même !!
Ce n'est qu'une numérotation privée, mais Apple, Google, l'administration américaine (les marchés publics US ont longtemps tourné au DUNS) l'ont adoptée comme standard. Cela veut dire que cet identifiant fait maison attribué par une société américaine est devenu un passage quasi obligé pour publier une app sur l'AppStore ou décrocher un contrat. Bref, c'est plus un numéro, c'est un péage mondial.
Et moi, tout ce que je voulais faire, c'était publier des applications sur l'App Store et sur Google Play. Sauf que voilà, pour le faire en tant qu'entreprise, eh bien, il faut ce numéro DUNS.
Le truc rigolo, c'est que ce numéro est censé être communicable gratuitement, mais j'ai eu beau chercher, que ce soit sur les sites officiels ou sur les sites alternatifs (qui sont parfois de grosses arnaques), tous exigent une "petite" contribution pour connaître le numéro.
Sympa la pression quand justement vous ne savez pas où les trouver.
Vous tapez le nom de votre entreprise sur verif.com, un service d'Altares-D&B. La fiche s'affiche, pas mal d'infos s'affichent SAUF la seule ligne que vous cherchez. À la place du DUNS, une zone de flou et un bouton pour acheter le rapport à 39 euros hors taxe.
Et d'autres sites vous vendent également une "recherche instantanée" à 3,90 euros... C'est un peu le même délire qu'avec notre KBIS nationale, car comme écrit dans la FAQ de Verif.com, ce numéro est gratuit !
Sauf que c'est tellement galère ou looong de l'obtenir que tout le monde finit par payer. Il y a bien, soi-disant, la possibilité de faire une demande directe chez Dun & Bradstreet ou chez verif.com / altares, mais j'ai retourné leur page contact, il y a tout sauf ça... Pire, le petit formulaire "Obtenir un DUNS", renvoie vers Verif.com qui veut nous facturer les 39 € HT dont je vous parlais ci-dessus.
Enfin ça, c'est ce que je croyais. Parce qu'il existe bien un service officiel, gratuit et instantané pour lire votre numéro, sauf que Dun & Bradstreet le planque bien : ça s'appelle UPIK (pour Unique Partner Identification Key). Vous allez sur
le portail UPIK
, vous tapez le nom de votre boîte, vous choisissez "France" dans la liste des pays, et là, magie, les neuf chiffres s'affichent en clair, sans compte à créer, sans un centime à sortir. J'ai testé, le numéro arrive en 3 secondes... celui-là même que verif.com me masquait derrière ses 46,80 €. Même base de données, même numéro, prix qui n'a plus rien à voir.
Le seul hic, c'est qu'UPIK sait juste lire, pas créer. Si votre entreprise est déjà fichée chez D&B (et une boîte française immatriculée l'est quasi toujours), vous avez vos chiffres direct. Mais si elle n'y figure pas encore, UPIK vous renvoie gentiment vers le partenaire du coin... Altares. Et rebelote, le péage. C'est là que la deuxième combine entre en jeu, celle qui fabrique le numéro gratos quand tout le monde veut vous le vendre, et elle vient d'où on ne l'attend pas du tout : Apple.
Étape 1 : ouvrez l'outil de recherche DUNS d'Apple
Direction
developer.apple.com/enroll/duns-lookup
. Oui, faut aller chez Apple, même si votre appli part sur le Play Store de Google parce que ces derniers proposent un service qui interroge la même base Dun & Bradstreet que tout le monde, et recrache le même numéro.
Il vous faut juste un identifiant Apple, gratuit, que vous avez sûrement déjà dans un tiroir et renseigner quelques infos.
Étape 2 : renseignez votre société
Apple vous réclame alors quelques infos telles que le nom légal exact de l'entreprise, l'adresse du siège, l'adresse postale et vos coordonnées professionnelles. Recopiez le nom légal au caractère près, tel qu'il figure sur votre extrait d'immatriculation KBIS et validez !
Étape 3 : récupérez vos neuf chiffres
Si votre boîte est déjà dans la base D&B, et une société française immatriculée y est quasi toujours, Apple renverra alors sur votre boite mail le précieux numéro DUNS gratuitement. Et si votre société n'apparaît pas, vous soumettez vos infos pour une création gratuite, et ça devrait prendre quelques jours max (ouais les mecs prennent leur temps). Après dans les deux cas, la facture sera identique à savoir que ça vous coutera zéro euro !!! Ouf !
Étape 4 : reportez le numéro dans Google Play
Une fois les neuf chiffres en poche, retour dans Play Console ou sur Apple Connect et voilà, vous allez pouvoir enregistrer votre entreprise chez eux. Attention à l'adresse car elle doit correspondre exactement à celle qu'a enregistrée D&B, pas à celle que vous croyez avoir.
Et voilà...
J'espère que vous aurez la chance de tomber sur mon article et que ça vous aura éviter bien des galères ! Le DUNS est gratuit mais ne pas connaître cette astuce peut vous coûter cher !
Google est allé raconter à la Commission européenne ce que les gens qui s'y connaissent un peu en réseau répètent depuis 15 ans : Bloquer les résolveurs DNS, les VPN et les adresses IP pour lutter contre le piratage, ça ne marche pas.
Dans
un document envoyé pour la consultation
sur la révision de la directive copyright, Mountain View écrit que "bloquer les résolveurs DNS, les IP ou les VPN est inefficace, car cela ne supprime pas du tout le contenu et se contourne facilement en utilisant des résolveurs DNS alternatifs".
Le plus marrant ??? Bah c'est que Google sait très exactement de quoi il parle, vu que
la justice française l'oblige déjà à filtrer son propre résolveur 8.8.8.8
pour protéger les matchs de foot de Canal+ (Fun fact : J'ai pas vu une seule image, ni score, ni entendu une seule histoire à propos de la Coupe du Monde cette année, tellement les algos savent que ça ne m'intéresse pas.... loool)
Pour ceux qui débarquent (oué oué), le blocage DNS, c'est demander aux annuaires du net (souvent ceux de votre FAI) de faire semblant de ne pas connaître l'adresse d'un site. Le site reste en ligne, ses serveurs tournent, et vous le retrouvez facilement en moins de 2 min, en changeant de résolveur ou en allumant un VPN.
Le blocage d'adresses IP, c'est encore pire, parce qu'une même adresse est souvent partagée par des milliers de sites sans aucun rapport entre eux... En bloquer une, ça revient donc souvent à couper l'électricité de tout l'immeuble pour punir un seul locataire.
Et des immeubles plongés dans le noir, la soumission de Google en aligne toute une collection. Je pense par exemple à ce document étiquetté "Privileged and Confidential" que la Commission a quand même publié (lol, des champions, je vous dis !) et qui cite le nom de clients de Google Cloud parfaitement en règle, qui pourtant ont été entièrement coupés à Internet fin 2019 au Portugal. Tout ça parce que des fournisseurs d'accès Internet locaux avaient bloqué des ASIP partagés pour viser certains sites pirates...
Ou encore un sous-domain de Google Drive ainsi que des IP Cloudflare sur lequel reposaient plus de 42 millions de domaines victimes du
Piracy Shield
italien. Ah et j'ai oublié l'Espagne qui vient compléter ce joli bingo parce que là-bas les blocages réclamés par LaLiga (la ligue de foot locale) durant les matchs, on fait carrément tomber +550 000 dont les sites d'Amnesty International, de l'UNICEF, du Sénat australien, de la Stanford Law Review et même des serveurs Amazon S3.
Et en France, je ne sais pas si vous vous souvenez, mais Cisco a carrément préféré débrancher son service OpenDNS plutôt que de se plier aux ordonnances de la justice. Quelle bonne ambiance dans ce terreau fertile à la dictature qui nous fonce dessus comme un train de la Deutsche Reichsbahn. (Point Godwin atteint, j'm'en fous, je fais ce que je veux, c'est mon site ^^).
Du coup, les ayants droit réclament maintenant de bloquer aussi les résolveurs alternatifs et les VPN eux-mêmes... et c'est exactement cette fuite en avant que Google demande d'arrêter. En tout cas dans son message, Google rappelle vivement ce que l'industrie du divertissement refuse d'entendre depuis l'époque de Napste : Quand vous avez un catalogue de merde émietté entre des dizaines de plateformes pour des prix exorbitants, avec de la pub, une qualité assez basse et des tas d'œuvres manquantes, eh bien, il ne faut pas s'étonner que le téléchargement illégal reparte de plus belle.
Maintenant, c'est vrai que Google ne joue pas les chevaliers blancs par pure bonté d'âme. En fait, ce qu'ils défendent, c'est leur résolveur maison, leur cloud et leurs clients. Elle reste par exemple très silencieuses sur tous les projets de loi de blocage qui avancent en ce moment même au Congrès américain.
Voilà, la consultation est close depuis le 25 juin dernier et la commission est actuellement en train d'éplucher toutes les contributions pour décider des futures conneries qu'elle va faire. On croise les doigts quand même.
Connexion
