un simple agrégateur, lecteur de flux rss pour tout suivre .... par: fonds d'écran - Kriss Feed, version : 7 -
  • Thursday 09 July 2026 - 08:42
    from Korben

    On reçoit tous des mails un peu bizarres avec des liens qu'on n'ose pas ouvrir, et pourtant on est curieux, on est tenté parfois... C'est difficile de résister mais heureusement l'équipe de Linuxserver.io a pondu un truc super pour ça.

    Il s'agit tout simplement d'une instance de Firefox qui tourne dans un conteneur Docker et qui est totalement pilotable depuis votre navigateur habituel.

    Comme ça, quand vous recevez un lien louche que vous voulez ouvrir, vous le mettez là-dedans, dans une session jetable qui est totalement coupée de votre vraie machine. Et comme ça, si ça part en couille, vous butez le conteneur et on n'en parle plus.

    Voilà, ça se présente juste comme une page HTTPS avec un navigateur dedans. Et comme c'est LinuxServer qui maintient l'image, vous êtes tranquilles parce que c'est du sérieux.

    L'avantage d'avoir ce truc, c'est qu'un Firefox en conteneur ne voit ni votre répertoire personnel, ni vos cookies, ni vos sessions Google, ni vos extensions, absolument rien, il est totalement isolé. Donc si un site tente un drive-by download ou un exploit navigateur, eh bien en principe les dégâts resteront coincés dans le conteneur. Et le simple fait de le redémarrer remettra tout à 0.

    Attention quand même, un conteneur, ce n'est pas une machine virtuelle. Une vulnérabilité au niveau du noyau pourrait en théorie s'en échapper. Mais c'est pas le genre d'attaque qui se fait avec juste un clic douteux sur une page web.

    Les chercheurs en sécu s'en servent pour ouvrir des pièces jointes chelou, les marketeux pour jongler avec 12 comptes ad sans cookie cross-tracking , et les paranos dans mon genre pour cliquer sur les liens des mecs bizarres de Discord sans rien flinguer chez eux..

    Après y'a des petits inconvénients. Je pense aux perfs graphiques qui prennent une claque par rapport à un Firefox natif ou encore l'audio qui transite par le pipeline du navigateur, du coup ça crachote parfois sur les vidéos lourdes. Le copier-coller marche, mais en passant par la section presse-papiers de la barre latérale Selkies , pas en direct. Et la persistance ne tient que si vous mappez le volume /config comme il faut, sinon vos onglets et vos bookmarks gicleront dès que le conteneur sera recréé (à la première mise à jour d'image, typiquement).

    Côté vie privée c'est plutôt une qualité mais pour un usage quotidien, ça peut devenir relou.

    Installation en une commande

    L'image officielle, c'est lscr.io/linuxserver/firefox:latest. Elle tourne sur Selkies depuis juin 2025 (avant c'était KasmVNC) et démarre en Wayland par défaut depuis mars 2026. Maintenant, si un site part en vrille à cause de ça, vous ajoutez le paramètre PIXELFLUX_WAYLAND=false à la commande Docker et vous serez de retour en X11.

    La commande minimale ressemble à ça :

    docker run -d \
    --name=firefox \
    -e PUID=1000 \
    -e PGID=1000 \
    -e TZ=Europe/Paris \
    -e LC_ALL=fr_FR.UTF-8 \
    -p 3001:3001 \
    -v $HOME/firefox-config:/config \
    --shm-size=1gb \
    --restart unless-stopped \
    lscr.io/linuxserver/firefox:latest
    

    Le --shm-size=1gb, c'est la mémoire partagée de Docker et vous n'y couperez pas, désolé. Si vous le zappez, YouTube comme les sites un peu lourds vous planteront le navigateur. Le port 3001, c'est l'accès HTTPS, avec un certificat auto-signé qui fera râler votre Firefox principal (c'est normal, faut l'accepter). Y'a aussi un port 3000, mais lui c'est du HTTP en clair, à réserver derrière un reverse proxy genre SWAG et rien d'autre.

    Ensuite, direction https://localhost:3001/ et un joli Firefox vous attend. Notez que par défaut, il n'y a AUCUNE authentification. Personne ne vous demande rien, alors si vous voulez l'exposer sur votre réseau, définissez bien un CUSTOM_USER et PASSWORD pour activer le basic auth avant qu'un petit malin de votre réseau ne tombe dessus.

    La version docker-compose, plus propre

    Envie d'un setup versionnable, que vous pouvez reproduire ailleurs sans réfléchir ? Le compose fait ça mieux :

    ---
    services:
    firefox:
    image: lscr.io/linuxserver/firefox:latest
    container_name: firefox
    environment:
    - PUID=1000
    - PGID=1000
    - TZ=Europe/Paris
    - LC_ALL=fr_FR.UTF-8
    - CUSTOM_USER=korben
    - PASSWORD=changezmoi
    - HARDEN_DESKTOP=true
    - HARDEN_OPENBOX=true
    volumes:
    - ./firefox-config:/config
    ports:
    - 3001:3001
    shm_size: "1gb"
    restart: unless-stopped
    

    Ensuite, un docker compose up -d et roulez jeunesse. Le volume ./firefox-config conserve votre profil entre deux redémarrages avec bookmarks, extensions installées depuis le store Mozilla, tout reste en place.

    Et si vous avez envie de repartir de zéro, on met le dossier à la poubelle, on relance, et voilà. Et pour glisser des outils tiers dans le conteneur (filezilla, un éditeur, ce genre de bidule), [proot-apps install](https://github.com/linuxserver/proot-apps) les posera dans $HOME, où ils survivront aux mises à jour de l'image.

    Le hardening qu'il faut absolument activer

    Maintenant, le piège que la doc évoque du bout des lèvres et qui mérite d'être écrit en gros c'est que l'interface web embarque un terminal avec sudo passwordless . Traduction : quiconque accède à votre Firefox conteneurisé devient root dans le conteneur en deux clics. Exposez ça sur votre réseau, ou pire sur Internet, sans durcir le machin, et vous ouvrez un boulevard.

    La parade tient en une variable : **HARDEN_DESKTOP=true**, qui pose les principaux verrous d'un coup. Ça coupe sudo, ça vire les terminaux, et ça bloque xdg-open et exo-open, qui pourraient lancer des trucs hors conteneur. Vous pouvez empiler ça avec HARDEN_OPENBOX=true par-dessus, histoire de neutraliser les raccourcis clavier dangereux genre Alt+F4, de désactiver le clic droit et de masquer le bouton de fermeture. Firefox reste parfaitement utilisable, mais impossible de s'évader pour faire mumuse avec le système derrière.

    Et pour une exposition sur Internet, le basic auth CUSTOM_USER/PASSWORD ne suffira pas car c'est trop léger. Moi ce que je vous recommande, c'est de coller le tout derrière un reverse proxy SWAG avec une vraie couche OAuth2 ou Authelia. Le basic auth, gardez-le pour le LAN entre potes ou collègues de confiance, mais pas au-delà.

    SealSkin, le bonus qui change tout

    SealSkin , c'est la cerise sur le conteneur ^^. C'est une extension navigateur, dispo pour Chrome et Firefox, qui monte la garde sur votre navigateur principal et détourne ce qui sent mauvais vers le conteneur isolé. Un lien repéré comme suspect ? Hop, il s'ouvre direct dans le Firefox conteneurisé. Pareil pour les téléchargements, qui atterrissent dans le conteneur au lieu de finir sur votre machine.

    Du coup, l'isolation devient un réflexe permanent au lieu d'un machin que vous activez à la main quand vous y pensez (c'est-à-dire jamais). Seule contrainte par contre, faudra héberger le serveur SealSkin vous-même, et installer l'extension dans votre vrai Firefox. Mais vous verrez, après quelques jours à ce régime, vous aurez du mal à faire autrement.

    Et sur tablette ou mobile ?

    J'imagine que vous comptiez sur l'ancien tag kasm pour le tactile ? Eh bien c'est raté, puisque LinuxServer l'a déprécié début juillet. En échange, la barre latérale Selkies embarque désormais un trackpad virtuel et un clavier à l'écran, donc de quoi rendre l'interface utilisable depuis un iPad ou un smartphone sans bidouille en plus. On reste loin, c'est vrai, du confort d'un vrai desktop, et taper Ctrl+Tab au doigt c'est toujours la misère, mais pour dépanner ça fait le job.

    Et voilà, votre Firefox jetable vit désormais dans son petit conteneur, bien au chaud. Comme ça, le prochain lien douteux, vous l'ouvrirez sans trembler... pour tester des sites au calme, difficile de trouver mieux, je pense.

  • Thursday 09 July 2026 - 08:10
    from Korben

    Si vous lisez ça depuis Abidjan, Dakar, Douala ou Kinshasa, y'a une chance sur deux que votre téléphone soit un Tecno, un Infinix ou un itel. Trois marques, mais un seul patron : Transsion, qui trône sur près de la moitié des smartphones vendus en Afrique.

    Et si je vous parle de ça aujourd'hui, c'est parce qu'un chercheur en sécu, Buchodi, vient de décortiquer ce que ces appareils racontent dans votre dos et c'est pas joli, joli.

    Son terrain de jeu, c'est un Tecno Spark 40 tout ce qu'il y a de banal. En rétro-ingénierant le firmware, il tombe sur un framework maison signé Transsion, baptisé Athena pour la collecte et oneID pour le pistage entre applis. On n'est pas sur une appli lambda que vous auriez installée, mais un truc costaud câblé au niveau du système, avec les pleins pouvoirs.

    Et ce qu'il remonte, c'est du lourd ! Votre position GPS précise, les antennes-relais autour de vous, la consommation réseau appli par appli sur une soixantaine d'applis, quelle appli est affichée à l'écran en temps réel, et même quelle appli vient d'allumer la caméra (pas ce que filme la caméra, hein, juste le fait qu'une appli l'ait activée).

    Ensuite, tout ça part vers des domaines en shalltry.com et transsion-os.com. Shalltry, c'est la branche logicielle de Transsion, et les serveurs tournent sur du cloud loué en Europe.

    Donc c'est de la télémétrie++ qui part chez le fabricant, mais le gros souci, c'est qu'on ne peut rien désactiver ni désinstaller facilement. C'est vraiment une brique essentielle du téléphone reposant sur le SDK du constructeur. Ça prend racine dans l'application Réglages (pour les paramètres), l'interface système, et surtout dans un module assez discret nommé com.hoffnung qui est bardé de permissions flippantes comme lire le presse-papier en arrière-plan, connaître toutes les applis installées, forcer l'arrêt des autres.

    Alors oui, c'est chiffré avec un bon vieux AES, sauf que ça ne sert pas à grand chose parce que la clé de déchiffrement est planquée dans le code de l'application elle-même. Autrement dit, quiconque met la main sur le fichier récupère la clé avec, et peut tout ouvrir. Le chiffrement n'est là que pour faire un peu de camouflage afin que vous ne puissiez pas voir facilement ce qui sort de votre poche. Mais ce n'est absolument pas de la confidentialité.

    Et malheureusement, ça ne s'arrête pas à votre smartphone puisque ce même SDK se balade aussi dans des applications grand public très très populaires en Afrique comme Boomplay (100 millions de téléchargements et des poussières), StarTimes ou Orange Max it. Du coup, même avec un mobile d'un autre fabricant, vous pouvez trimballer ce mouchard sans le savoir.

    Alors oui, c'est vrai, tous les smartphones font de la télémétrie. Google, Apple, Samsung, Xiaomi, tout le monde collecte des trucs, et des centaines d'applis passées au crible violaient déjà le RGPD début 2026. C'est déjà pas normal, mais ça peut normalement se désactiver assez facilement. Mais dans le cas de Transsion, c'est fait au niveau système, c'est totalement invisible et la destination est très opaque...

    Puis surtout, ça concerne la moitié du continent !

    Notez que ce n'est pas la première fois que les constructeurs chinois low cost se font choper puisqu' en 2016 déjà, une backdoor chinoise se planquait dans le firmware de smartphones low-cost et balançait contacts et SMS toutes les 72 heures. Plus récemment, il y a eu aussi un malware qui s'appelle Triada et qui a été préinstallé sur environ 53 000 Tecno W2 vendus en Éthiopie, au Ghana ou encore au Cameroun avec, s'il vous plaît, des abonnements souscrits totalement à l'insu de leur propriétaire.

    C'était des composants différents à chaque fois, mais le motif se répète.

    Alors que faire les amis ? Eh bien la bonne nouvelle, c'est qu'on peut quand même bloquer 2-3 trucs pour les empêcher de remonter des infos. Vu que tout transite par ces fameux domaines, il suffit de bloquer *.shalltry.com (et *.transsion-os.com tant qu'à faire) au niveau DNS.

    Ça se fait facilement avec un NextDNS, un AdGuard ou un Pi-hole à la maison, ou directement sur le téléphone avec cette application qui s'appelle Personal DNS Filter , et comme ça, la télémétrie se retrouve isolée sans toucher au reste.

    Par contre, ça ne sert à rien d'aller trifouiller les réglages du téléphone parce que ce n'est pas désactivable à partir de là. Désolé.

    Source

  • Thursday 09 July 2026 - 06:09
    Aiko Konomi travaillant les chapelets de couleurs pour la tapisserie La sieste de Mei et Totoro - Cité internationale de la tapisserie ©Zoé ForgetPlongez dans la magie de Hayao Miyazaki tissée en laine à la Cité d'Aubusson. Un hommage exceptionnel à l'animation japonaise.
  • Wednesday 08 July 2026 - 22:17
    from Korben

    Snif, snif, macOS 28 ne lira plus vos disques chiffrés en Mac OS Étendu . C'est écrit dans un document de support Apple publié le 7 juillet, alors si vous stockiez là-dessus vos photos de 2014, vos factures, votre mémoire de fac ou une sauvegarde Time Machine chiffrée de l'ancienne époque, bah c'est grave le moment de vous en occuper.

    Pas de panique cela dit, seul le chiffrement dégage. Un volume HFS+ non chiffré restera donc lisible sous macOS 28 et après. Ce qui part à la benne, c'est surtout CoreStorage, la couche qui chiffre ces volumes... Et c'est aussi elle qui fait tourner les Fusion Drives avec lesquels j'aimais bien m'amuser à l'époque. Mais hormis ça, rien ne change.

    Et vu qu'APFS est le format par défaut depuis High Sierra en 2017, les disques concernés ont, pour la plupart, grosso modo 9 ans au compteur, donc ce sont des disques d'archives que vous ne branchez jamais j'imagine... jusqu'au jour où vous en avez vraiment besoin évidemment !

    Alors pour vérifier si vous êtes concerné, ouvrez l'Utilitaire de disque et regardez le libellé sous le nom de vos volumes externes. S'il affiche "CoreStorage Logical Volume" avec la mention "Encrypted", c'est lui. Et si vous êtes sous macOS 26, le système peut aussi vous envoyer une notification quand il détecte un disque qui ne passera pas le cap. Même si ça fait chier, c'est quand même assez réglo de la part d'Apple de prévenir 1 an à l'avance.

    Côté solutions, Apple vous laisse 2 portes de sortie. La douce d'abord... Vous faites un clic droit sur le volume dans le Finder pour le déchiffrer, et si le cœur vous en dit, vous le convertissez ensuite en APFS sans perdre le moindre fichier. Ou alors la radicale ensuite où vous reformatez le volume direct en APFS. Attention hein, ça efface tout, et définitivement donc on sauvegarde bien avant de jouer à ça, les amis ^^.

    Apple prévient aussi que le déchiffrement prend beaucoup de temps, spécialement si le volume est gros. Du coup lancez la machine avant d'aller vous coucher, et vous pourrez ensuite faire un petit diskutil cs list dans le Terminal pour savoir où ça en est !

    Malheureusement, la méthode douce, vous pouvez l'oublier pour les disques de sauvegarde Time Machine chiffrés. Howard Oakley en parlait déjà sur Eclectic Light Company 3 semaines avant que les gros sites américains ne captent le truc et il a expliqué pourquoi dans son article. En fait, ces vieilles sauvegardes s'appuient sur des liens en dur de répertoires, et c'est un mécanisme qu'APFS ne sait tout simplement pas reproduire.

    Du coup, ces sauvegardes-là, c'est impossible de les convertir, donc... il faudra repartir de zéro avec une sauvegarde toute neuve. Rassurez-vous, vos fichiers actuels ne craignent rien. Par contre, tout votre historique de versions restera coincé sur le vieux disque, que vous pourrez encore lire sous macOS 26 et 27, et après, ce sera terminé.

    Donc si vous êtes motivé (et avez-vous bien le choix ?), vous branchez vos vieux disques, vous faites des backups, vous checkez le format, vous déchiffrez ou reformatez ce qu'il faut puis vous relancez une sauvegarde propre, que vous pouvez d'ailleurs accélérer avec cette astuce . Allez, un petit week-end là-dessus à le laisser tourner et c'est plié !

    Bref, prenez 10 minutes maintenant, plutôt que de vous retrouver dans 1 an devant un disque qui refusera de répondre. Votre moi du futur vous dira merci !!

    Source

  • Wednesday 08 July 2026 - 17:59
    from Korben

    Comme je vous le disais tout à l'heure, en avril 2026, le FBI a coincé un membre présumé de Scattered Spider. Le mec planquait son trafic derrière un VPN, avec des IP dans trois pays différents. Et devinez quoi ? Ce n'est pas une fausse manip qui l'a balancé mais un identifiant que votre Windows se trimballe H24 et que Microsoft refile aux autorités quand elles le demandent : le GDID. Je vous en ai déjà causé dans cet article , et après avoir écrit l'article, je me suis demandé si on pouvait le virer.

    Du coup j'ai monté une petite VM Windows 11 Pro et j'ai mis les mains dedans en me faisant assister de mon LLM préféré et voilà ce que j'ai trouvé. Ce qui marche, et surtout ce qui ne marche pas du tout, vous allez voir.

    Déjà, faut comprendre ce qu'est ce GDID. C'est pas le numéro de série de votre carte mère, c'est pas un hash en lien avec votre matos. Non, c'est un PUID de 64 bits, c'est-à-dire un identifiant que les serveurs de Microsoft collent à votre compte dès que vous ouvrez une session Windows. Il est écrit en clair dans votre registre, votre machine l'enregistre dans un annuaire côté Microsoft, et un service le fait remonter peinard quand c'est nécessaire. Et si vous changez d'IP avec un VPN, bah lui il s'en fout. Le GDID ne bouge pas d'un poil.

    Regardez votre propre mouchard en face

    On commence par le voir de nos yeux. Ouvrez un PowerShell et collez ça :

    $lid=(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
    "g:$([Convert]::ToUInt64($lid,16))"
    

    Sur ma VM, ça m'a craché g:6755487812206045. C'est celui que Microsoft peut raccrocher à tout ce que je fais. (En théorie hein, parce que c'est le code qui est associé à ma VM, donc je m'en fous et c'est pour ça que je vous le montre).

    Vous venez de lire l'étiquette qu'on vous a collée dans le dos.

    Le supprimer ? Laissez tomber

    Réflexe de base, on efface la clé dans la base de registres HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties et hop, plus de mouchard. C'est ce que j'ai testé au début... J'ai shooté la valeur, redémarré le service qui s'en occupe, et là plus rien. Gagné ? Ben non. J'ai ouvert le Microsoft Store durant deux petites secondes, et le GDID est revenu. Et pas un nouveau, hein, LE MÊME !!

    C'est ça qui est fou. C'est que votre GDID n'est pas planqué sur votre disque, il est planqué chez Microsoft, bien accroché à votre compte comme une moule à son rocher. Votre PC ne fait que le retélécharger encore et encore. Après si vous réinstallez tout, Windows vous donne un nouveau numéro, d'accord, mais l'ancien et tout ce qui y était rattaché restent tout de même bien au chaud sur leurs serveurs. Le passé, on le récupère jamais...

    Couper la télémétrie ne change rien non plus

    Un autre conseil qu'on voit partout, c'est de désactiver la télémétrie de Windows. Sur ma VM, le service de télémétrie classique était déjà à l'arrêt. Et pourtant mon GDID était là, bien lisible, et les services qui le font remonter tournaient à plein régime. Le mouchard ne passe pas par la télémétrie que vous croyez couper. Il passe ailleurs, par les services de la plateforme d'appareils connectés et de l'optimisation de distribution.

    Vous pouvez donc cliquer sur tous les boutons vie privée des réglages, il s'en tape.

    Fermer le robinet pour de vrai

    Alors puisqu'on peut pas l'effacer, on va faire la seule chose qui est en notre pouvoir : L'empêcher de sortir. Et sans se déconnecter du compte Microsoft, histoire de garder un PC utilisable, hein.

    Et pour ça, on a 2 leviers. Le premier, c'est de désactiver les services qui enregistrent et remontent les infos de votre machine. Le second, c'est de renvoyer les serveurs de Microsoft dans le décor simplement via le fichier hosts, comme ça même si les services qui mouchardent tournent, et bien ils ne peuvent plus joindre personne... Et surtout, on ne touche pas à login.live.com, sinon adieu la connexion à votre compte.

    Toutefois, il y a un petit piège, vous vous en doutez... Le service qui fait remonter le GDID, DoSvc, refuse de se laisser désactiver par la voie normale. Même en admin, Windows vous balance "Accès refusé". La parade, c'est donc de le désactiver direct dans le registre, où l'admin a le droit d'écrire là où le gestionnaire de services vous bloque.

    Maintenant pour faire ça, plutôt que de vous mettre des tonnes de lignes de code à copier-coller, j'ai tout regroupé dans des scripts propres, que j'ai testés, avec une commande pour tout remettre comme avant.

    Le projet est là : no-gdid sur GitHub . Vous lancez d'abord l'audit en lecture seule pour voir où vous en êtes, puis les scripts de blocage en mode aperçu, et seulement après avec l'option qui applique vraiment. Testez dans une VM avec un snapshot avant de faire ça sur votre vraie bécane, parce qu'on désactive quand même des services système. Et si vous voulez juste couper le réseau d'un process précis sans tout ce cirque, ce bon vieux ProcNetBlocker fait déjà une partie du taf.

    Allez c'est parti mon canard !

    Ouvrez un PowerShell en administrateur, et la première fois faites-le dans une VM avec un snapshot histoire de tester et de vous familiariser avec les commandes. Étape 1, on clone le projet :

    winget install --id Git.Git
    git clone https://github.com/Korben00/no-gdid
    cd no-gdid
    

    D'abord on regarde sa propre situation. Cet audit est en lecture seule, il ne modifie rien, il vous affiche juste votre GDID et quels services de la chaîne tournent :

    powershell -ExecutionPolicy Bypass -File .\audit\Get-GDID-Audit.ps1
    

    Ensuite on regarde ce que la mitigation changerait, sans rien appliquer. Sans l'option -Apply, les deux scripts tournent en mode aperçu et se contentent de lister ce qu'ils feraient :

    powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1
    powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1
    

    Si ça vous va, on coupe pour de vrai. Cette fois on ajoute -Apply : les services qui enregistrent et remontent l'appareil sont désactivés, et les serveurs de Microsoft correspondants sont renvoyés dans le vide via le fichier hosts. Votre compte Microsoft, lui, reste connecté :

    powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1 -Apply
    powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1 -Apply
    

    Et pour tout remettre comme avant, une seule commande :

    powershell -ExecutionPolicy Bypass -File .\mitigate\Revert-GDID.ps1
    

    Une fois appliqué, tout redeviendra calme... les services d'enregistrement seront à l'arrêt, leurs serveurs injoignables, et votre compte Microsoft restera toujours connecté. Le GDID reste bien évidemment lisible sur le disque, mais il ne remontera plus chez Microsoft.

    La vérité qui pique

    Après, je ne vais pas faire un tuto qui vous vend du rêve. Ces manips réduisent ce que Microsoft pourra corréler à l'avenir mais elles n'effacent pas votre GDID, qui traîne sur leurs serveurs depuis votre toute première connexion, et elles ne vous rendent pas anonyme. Ensuite, passer en compte local comme j'ai pu le lire ailleurs supprime le chemin qu'on vient de bloquer, mais rien ne prouve encore qu'un identifiant anonyme ne prend pas le relais derrière.

    La seule vraie parade solide pour une activité sensible, est plus brutale : ne pas faire cette activité sous Windows. Un Linux live par exemple offre un contrôle total de ce qui sort de votre machine. Le reste, c'est que de la réduction des dégâts, rien de plus.

    Voilà, défendre sa vie privée, ça commence par savoir ce qu'on vous colle sur le dos et maintenant vous le savez. Pas merci Microsoft.

    Source : The Register et le reverse engineering de SmtimesIWndr .

  • Wednesday 08 July 2026 - 17:23
    from Korben

    Cet aprem, je bossais tranquillou quand j'ai reçu un mail de DoctoLib qui m'a bien énervé avec pour titre : "Doctolib s'engage dans la recherche pour améliorer la santé". Bon, si on s'arrête au titre, on se dit "Ah bravo, Doctolib", sauf qu'en le lisant en entier, j'ai vite compris qu'ils venaient de décider à ma place que mes données de santé allaient nourrir des trucs, des bidules et des machins pour de la recherche en intelligence artificielle.

    Et bien sûr que si ça ne me plaisait pas, bah fallait que je le dise.

    Alors ce qu'ils expliquent dans ce mail, c'est qu'à partir d'août 2026, Doctolib lance un projet de recherche mené par une équipe associée à Inria, l'Inserm et l'Université Paris Cité pour, je cite "améliorer les parcours de soins grâce à l'IA". Jusque-là, difficile de cracher dessus, ce sont des institutions publiques sérieuses et l'objectif est louable. Le truc, c'est ce qu'ils vont manger pour y arriver : nos données démographiques, nos données de santé, et même celles de vos proches rattachés à votre compte. Et cela que ces données aient été renseignées par nous ou par nos soignants.

    Et surtout, Doctolib ne nous demande pas notre accord. Ils s'appuient sur ce qu'on appelle l'intérêt légitime, une base légale du RGPD qui leur permet de piocher dans nos données sans passer par la case consentement. Hé ouais, en clair, on ne vous prend pas votre consentement, on vous l'enlève. Vous n'avez même pas à dire oui, c'est déjà oui par défaut, et vous êtes obligé de dire non si vous voulez sortir du dispositif.

    Ils présentent ça comme de l'intérêt légitime, sauf qu'en même temps on ne sait pas du tout sur quoi ils vont bosser, on ne sait pas avec qui ils vont bosser, on ne sait pas comment nos données seront sécurisées, bref, on ne sait rien du tout. Alors forcément, moi je m'inquiète surtout que leur mail annonce clairement que d'autres travaux suivront, "avec des hôpitaux ou des institutions privées ou publiques". Donc on accepte qu'ils signent à notre place un chèque en blanc avec nos données pour des projets futurs dont personne ne connaît le contenu et basta, tout ça sous couvert d'intérêt légitime. Ce n'est que mon avis mais je trouve ça vraiment léger.

    Alors oui, tout ça est parfaitement légal. Doctolib s'appuie sur la méthodologie MR-004 de la CNIL , qui encadre la recherche en santé et autorise justement ce fonctionnement par opposition plutôt que par consentement. Rien d'illégal là-dedans. Mais légal ne veut pas dire que je dois être d'accord.

    Et c'est bien ça le problème... Ce cadre légal permet à une entreprise privée comme Doctolib de considérer que nos données de santé lui appartiennent assez pour les offrir (ou les revendre, je n'en sais rien ??) à la recherche, tant que vous ne levez pas la main pour refuser.

    Doctolib tente de nous rassurer aussi en expliquant que les données sont pseudonymisées et "ne permettent pas de nous identifier directement". Notez bien le "directement", lol, ça ne se mouille pas trop. En réalité, pseudonymisé, ça ne veut pas dire anonyme... Ça veut seulement dire qu'on a remplacé votre nom par un code, mais que le lien existe toujours quelque part et reste réversible. Aux yeux de la loi, ça reste encore vos données personnelles . La vraie anonymisation, elle, est irréversible, et ce n'est pas ce dont on parle ici.

    Et puis il y a le contexte... Non, Doctolib n'a pas subi de grosse fuite de données, il faut être honnête là-dessus mais on nage actuellement dans un écosystème tech en France qui prend l'eau de partout : 33 millions de Français touchés par le piratage des mutuelles Viamedis et Almerys début 2024, une quinzaine de millions de plus avec la fuite Cegedim en 2026. Chaque base de données de santé qui se constitue quelque part, c'est une cible de plus.

    Et il y a un mois à peine, le Canard Enchaîné accusait Doctolib de transmettre des infos à Google, Microsoft et Anthropic pour de l'IA. Doctolib a répondu que ces boîtes n'étaient que des prestataires techniques qui n'entraînent pas leurs modèles avec vos données. Alors peut-être, hein, mais quand on nous demande de faire confiance sur parole pour des données aussi intimes que notre santé, l'inquiétude a le droit d'exister.

    Bref, moi je m'oppose, et si vous êtes sur Doctolib je vous invite au moins à décider en connaissance de cause. Le mail est probablement arrivé dans vos spams, donc pour refuser, sachez que ça se passe dans les paramètres de confidentialité de votre compte, via le formulaire d'exclusion de la recherche . Ça bloque toute utilisation future de vos données et de celles de vos proches, sans aucun impact sur vos rendez-vous ni sur vos soins. Faites-le avant août 2026, car c'est le moment où le premier projet démarre.

    Enfin bref, moi je pense qu'on devrait avoir à donner son accord, et pas à courir derrière ces boîtes pour retirer un accord qu'on n'a jamais donné en pleine conscience... C'est ça qui me dérange surtout.

  • Wednesday 08 July 2026 - 15:36
    Un ensemble d'outils pour protéger de manière défensive les données d'un serveur.
    - USB: Si vous retirez la clé USB de l'ordinateur, les clés LUKS sont écrasées et l'ordinateur rebooté (ce qui équivaut à reformater les disques puisque les données sont indéchiffrables sans les clés).
    - Dead man switch : Si vous n'envoyez pas un signal de vie à un service toutes les 24 heures, même effet: Écrasement des clés LUKS et redémarrage.

    C'est un peu comme dans les films d'espionnage quand vous ne voulez pas que vos données tombent entre de mauvaises mains.
    (Permalink)
  • Wednesday 08 July 2026 - 14:55
    from Korben

    Putain, c'est abusé, vous allez voir ! Peter Stokes, 19 ans, accusé d'appartenir au groupe Scattered Spider, enchaînait les VPN et changeait de pays pour brouiller les pistes mais le FBI l'a quand même coincé. Et vous savez grâce à quoi ?

    Hé bien grâce à un petit numéro planqué dans son Windows. C'est Microsoft qui l'a mouchardé aux enquêteurs et ça a suffi pour le relier à une intrusion malgré tous ses VPN.

    Et alors me direz-vous, vous aussi vous avez un numéro sur votre machine qui peut servir à vous identifier... Ce truc s'appelle le GDID, pour Global Device Identifier et c'est un identifiant unique qui est attribué lors de chaque installation de Windows. Il sert à la télémétrie, au rapport de plantage, à la vérification des licences et surtout il reste constant même après des mises à jour.

    Vous ne le voyez jamais, vous ne l'avez jamais choisi, et il ne bouge pas d'un poil quand vous changez d'adresse IP. Normal, un VPN protège la couche réseau, mais pas ce que laisse fuiter votre OS. Et ça on l'apprend dans la plainte de 39 pages qui a été rendue publique début juillet, où elle expliquait comment Microsoft a fourni au FBI l'historique des adresses IP rattachées à ce GDID précis.

    Les enquêteurs n'ont eu qu'à croiser ça avec les comptes perso de Stokes, de son compte Apple à ses comptes de gaming, en passant par Snapchat et Facebook, pour finalement découvrir des adresses IP à Tallinn, New York, ou encore la Thaïlande, ce qui correspond exactement à ses déplacements.

    Le mec pouvait empiler 10 VPN s'il le voulait, Microsoft le suivait à la trace quand même. Et c'est là que ça me hérisse le poil, parce que le problème, ce n'est pas que la justice ait serré un type accusé d'avoir extorqué des millions. Ça, c'est le boulot du FBI, et tant mieux s'ils l'ont arrêté.

    Non, le vrai problème, c'est que Microsoft dispose d'un identifiant permanent sur plus d'un milliard de machines, qu'ils ne communiquent pas dessus, qu'ils le partagent tranquille sur demande, et qu'on ne peut même pas le désactiver.

    Alors on fait quoi ? Bah déjà, on arrête de subir. Vous pouvez installer Windows 11 sans compte Microsoft pour couper une partie de la laisse, désactiver la télémétrie facultative pour limiter les autres fuites, ou carrément regarder du côté d'une stack privacy européenne . Aucune de ces astuces ne touchera au GDID par contre, car il n'y a aucun bouton pour ça, et c'est bien ça le fond du problème.

    Mais bon, j'imagine que des petits malins vont sortir des logiciels qui vont permettre soit de désactiver ce numéro ... Et là, vous pourrez compter sur moi pour que je vous le partage. Quoi qu'il en soit, quand vous utilisez Windows, gardez juste en tête que vous n'êtes jamais vraiment seul. Et que quelqu'un vous épie en permanence... Brrrr.

    Source

  • Wednesday 08 July 2026 - 14:42
    from Korben

    Je sais pas si vous avez vu mais Valve vient de sortir Proton 11, la nouvelle version stable de sa couche de compatibilité qui fait tourner les jeux Windows sur Linux via Steam Play. Et cette fois, c'est basé sur Wine 11, donc il y a pas mal de "nouveaux" vieux jeux qui sont maintenant jouables.

    Parmi ces nouveautés, on retrouve donc Resident Evil premier du nom, celui de 1996, Resident Evil 2, Dino Crisis et Dino Crisis 2, SHOGUN: Total War, Gothic 1 Classic, Breath of Fire IV, Deadly Premonition ou encore Metal Fatigue. Et à côté de ces reliques, il y avait aussi des trucs plus récents comme METAL GEAR SURVIVE, Warhammer: Vermintide 2 et X-Plane 12.

    Et pour les jeux qui étaient déjà jouables, Proton 11 affine encore le support de ces derniers pour les rendre encore plus jolis ou plus rapides ou avec moins de bugs etc. Je pense notamment à Cyberpunk 2077, The Witcher 3, Death Stranding 2, Helldivers 2, ARC Raiders, THE FINALS, Titanfall 2, Satisfactory, Metal Gear Solid 2, Oblivion GOTY ou Call of Duty 2.

    Donc autant dire que si vous jouez sous Linux ou sous Steam Deck, je pense que vous êtes concerné par cette mise à jour. Et puis il y a un truc dont je ne vous ai pas parlé encore, c'est les correctifs qui font zizir. Je pense notamment au hot plug des manettes qui a été amélioré, notamment pour la 8BitDo Ultimate 2C et toutes les manettes qui exposent plusieurs périphériques HID. Sur KDE, la maximisation des fenêtres a aussi été corrigée, sans oublier le rendu des pop-ups du Rockstar Launcher ou encore la détection du fuseau horaire qui devient plus fiable. Même le lecteur multimédia Kodi passe mieux sous cette version, ce qui est top !

    Ce passage sur Wine 11, c'est justement celui qui avait montré des gains de perf assez dingues au moment des premiers benchmarks NTSync et maintenant que c'est dans le Proton officiel, tout le monde y a droit sans bidouiller !! Pour l'installer, rien de sorcier, comme d'habitude, vous allez sur Steam, vous faites un clic droit sur un jeu, vous cliquez ensuite sur "Propriétés", et puis vous allez dans l'onglet "Compatibilité". Et là, vous sélectionnez la branche Proton 11.

    Et voilà ! En tout cas, je suis content de voir que jouer sur Linux n'est plus un parcours du combattant . Avec le Steam Deck et cette compatibilité qui grignote chaque jour un peu de terrain, Windows perd de plus en plus son statut de passage obligé pour le jeu PC....

    Source : 9to5Linux

  • Wednesday 08 July 2026 - 11:35
    Ouais je sais, je suis chiant avec DeltaChat.
    Mais vous avez quoi ? C'est un petit recoin d'internet qu'on s'approprie. Un petit coin à l'abris des bots débiles, des moteurs de recherche, de l'appétit de données des GAFAMs, des databrokers et des boîtes d'IA, loin des influenceurs et des accros aux "likes", loin des spammeurs et des arnaqueurs. Un endroit pour les humains, quoi. C'est serein et confortable.

    (On ne peut vous contacter sur DeltaChat que si vous avez donné votre URL de contact. Donc impossible de vous spammer, et les GAFAM sont dans l'incapacité d'accéder au contenu. On peut se faire des salons de discussion totalement hors de portée de tous ces nuisibles. C'est comme ça que devrait être internet.)
    (Permalink)