Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un développeur du noyau Linux rappelle qu'à cause des failles matérielles qui affectent les CPU Intel
Il faut désactiver l'hyperthreading et s'attendre à une réduction des performances de 20 %

Le , par Christian Olivier

112PARTAGES

14  0 
Le développeur du noyau Linux Greg Kroah-Hartman estime que la technologie SMT (Simultaneous Multithreading) d’Intel - également connu sous le nom d’Hyperthreading - devrait être désactivée pour des raisons de sécurité à cause des failles de sécurité MDS (Microarchitectural Data Sampling) dévoilées plus tôt cette année. S’exprimant lors du sommet Open Source organisé récemment à Lyon, il n’a pas caché ses préoccupations vis-à-vis des lacunes en matière de sécurité des processeurs x86 Intel qui exploitent la technologie Hyperthreading. Kroah-Hartman précise que « Linux n’est ni moins sûr ni plus sûr » que les autres solutions, mais que tout le problème vient des failles matérielles qui affectent les puces.

À ce propos, il a déclaré : « J’ai donné une conférence l’année dernière sur Spectre et comment Linux y a réagi ; et puis cette année, le sujet porte sur les éléments trouvés depuis le dernier entretien ». Selon lui, ces problèmes sont devenus récurrents, sont là pour durer et ne disparaitront pas de sitôt. Kroah-Hartman assure par ailleurs que la base de données CVE des problèmes de sécurité n’est pas pertinente quand il s’agit du noyau Linux : « Les CVE ne signifient rien, pour le noyau. Très peu de CVEs sont assignés au noyau ».


Pour rappel, depuis 2018, plusieurs vulnérabilités affectant les processeurs d’Intel ont été dévoilées et il a été démontré que certaines d’entre elles existent depuis près de deux décennies. Ces exploits tirent parti de certains mécanismes d’optimisations implémentés dans les CPU x86, notamment celui dit de l’exécution spéculative. Les plus connues sont probablement : Meltdown/Spectre, PortSmash, BranchScope, TLBleed et Foreshadow. Ces vulnérabilités permettraient à un attaquant d’accéder et de détourner différents types de données (mot de passe, historique de navigation d’un navigateur Web, clé cryptographique…) sur un système sans être détecté par les outils de sécurité traditionnels. Les processeurs produits par Intel sont presque toujours les plus sensibles ou les seuls concernés par ces exploits.

En mai 2019, un ensemble de failles de sécurité critiques étroitement liées affectant les processeurs de la firme de Santa Clara a été publié. Il inclut RIDL (rogue in-flight data load), Fallout, ZombieLoad et Microarchitectural Data Sampling (MDS). Ces failles ont été découvertes de manière indépendante par Intel et diverses équipes de recherche. Pour désigner ce nouvel ensemble de failles, Intel préfère utiliser le terme « Microarchitect Data Sampling » (MDS).

Comprendre MDS

Chaque processeur a un comportement microarchitectural (le comportement d’une implémentation réelle de l’architecture) et un comportement architectural (le comportement documenté qui décrit le fonctionnement des instructions et sur lequel les programmeurs se basent pour écrire leurs codes). Celles-ci peuvent diverger de manière subtile. Par exemple, d’un point de vue architectural, une puce exécute chaque instruction séquentiellement, une à la fois, en attendant que toutes les opérations d’une instruction soient connues avant d’exécuter cette instruction. Ainsi, un programme qui charge une valeur d’une adresse particulière en mémoire attendra que l’adresse soit connue avant de tenter d’effectuer le chargement, puis attendra que le chargement se termine avant d’utiliser la valeur.

Au niveau microarchitectural, toutefois, le processeur peut tenter de deviner l’adresse de manière spéculative de sorte qu’il puisse commencer à charger la valeur à partir de la mémoire (ce qui est lent) ou qu’il puisse deviner que la charge récupérera une valeur particulière (plus rapide). Pour ce faire, il utilisera généralement une valeur du cache ou de la mémoire tampon. Si la prévision n’est pas bonne, le processeur ignorera la valeur estimée et effectuera à nouveau le chargement, avec cette fois l’adresse correcte. Le comportement défini par l’architecture est ainsi préservé, comme si le processeur attendait toujours les valeurs avant de les utiliser.

Toutefois, la génération de cette hypothèse erronée perturbe d’autres parties de la puce. L’approche principale consiste à modifier le cache en fonction de la valeur devinée, ce qui cause des différences de synchronisation subtiles (car il est plus facile de lire des données déjà en cache que des données qui ne le sont pas) qu’un attaquant peut mesurer. À partir de ces mesures, l’attaquant peut déduire la valeur estimée qui était en cache.

MDS est globalement basé sur un schéma de fonctionnement similaire. Mais au lieu d’exposer les valeurs devinées qui sont enregistrées au niveau du cache, il expose les valeurs des divers tampons au sein du processeur. Le processeur dispose d’un certain nombre de mémoires tampons spécialisées qu’il utilise pour déplacer les données en interne. Par exemple, les tampons de remplissage de ligne (LFB) sont utilisés pour charger des données dans le cache de niveau 1. Lorsque le processeur lit dans la mémoire principale, il vérifie d’abord le cache de données de niveau 1 pour voir s’il connaît déjà la valeur. Si ce n’est pas le cas, il envoie une requête à la mémoire principale pour récupérer la valeur. Cette valeur est placée dans un LFB avant d’être écrite dans le cache. De même, lors de l’écriture de valeurs dans la mémoire principale, elles sont enregistrées temporairement dans des mémoires tampons. Grâce à un processus baptisé « store-to-load forwarding », le tampon peut également être utilisé pour gérer les lectures en mémoire. Enfin, il existe des structures qui permettent de copier des données de la mémoire dans un registre, ce sont des ports de chargement. Les mémoires tampons peuvent contenir des données périmées et transmettre un mélange de données nouvelles et anciennes.

MDS et Hyperthreading

Comme d’autres attaques par canal latéral, les exploits récemment divulgués peuvent permettre aux pirates d’obtenir des informations qui seraient autrement considérées comme sécurisées, si elles n’avaient pas été traitées par le biais des processus d’exécution spéculatifs du CPU. Mais les attaques d’exécution spéculatives précédentes utilisaient une valeur périmée stockée dans le cache, alors que les nouvelles attaques MDS tirent parti des valeurs périmées stockées dans les différentes mémoires tampon du CPU. Les trois types de mémoires tampon peuvent être utilisés dans de telles attaques et l’utilisation de la technologie « Hyperthreading » augmente la facilité d’exploitation de MDS.

Pour rappel, le Simultaneous Multi Threading (ou SMT) est une technologie orientée multitâche qui permet d’exécuter plusieurs threads de calcul en parallèle sur le cœur physique d’un processeur. La technologie Hyperthreading développée par Intel n’est qu’une implémentation du SMT permettant d’activer deux cœurs logiques pour chaque cœur physique disponible sur un die. L’Hyperthreading est ainsi censé permettre l’exécution de deux instances simultanément d’un même programme ou de deux programmes différents en utilisant au mieux les ressources du processeur.

L’attaque peut être réalisée aussi bien sur un ordinateur que sur le cloud. Les chercheurs disent que cette faille peut être utilisée pour siphonner les données du processeur pratiquement en temps réel. Mais en règle générale, un attaquant a peu ou pas de contrôle sur ces tampons, car il n’existe pas de moyen simple d’obliger les mémoires tampon à contenir des informations sensibles. Les mémoires tampon peuvent contenir des données obsolètes issues de diverses opérations. Certaines d’entre elles peuvent intéresser un attaquant, mais elles peuvent être mixées à d’autres données non pertinentes. Par conséquent, rien ne garantit que les données divulguées seront utiles à l’attaquant et Intel estime que les nouvelles vulnérabilités présentent un risque faible ou moyen.

Open BSD avait raison

Tous ces éléments font dire à Kroah-Hartman qu’Open BSD avait raison : « Il y a un an, ils ont dit de désactiver l’Hyperthreading, il va y avoir beaucoup de problèmes ici. Ils ont choisi la sécurité plutôt que la performance à un stade plus précoce que n’importe qui d’autre. Désactivez l’Hyperthreading, C’est la seule façon de résoudre certains de ces problèmes ».

Selon lui, le déploiement de ces mesures d’atténuation à un impact négatif plus ou moins important sur les performances (qu’il estime à environ 20 %) et ralentit la machine des utilisateurs, l’ampleur du ralentissement dépendant de la charge de travail. « En tant que développeurs de noyau, nous nous battons pour une augmentation de 1 %, 2 % de la vitesse. Mettez ces trucs de sécurité et on revient en arrière d’un an en termes de performance. C’est triste », a-t-il confié à ce sujet.

Kroah-Hartman voit cette précaution comme un moindre mal. Il recommande d’ailleurs de toujours s’assurer que vous utilisez le patch de sécurité, la mise à jour ou la version du noyau Linux la plus récente sur votre système. Et il est catégorique : « Si vous n’utilisez pas une distribution supportée ou un noyau stable à long terme, vous avez un système non sécurisé. C’est aussi simple que ça. Tous ces appareils embarqués, qui ne sont pas mis à jour, sont faciles à pirater. Si vous travaillez dans un environnement sécurisé et que vous faites confiance à vos applications et à vos utilisateurs, vous récupérez la vitesse. Sinon, dans un environnement partagé, avec un code non fiable, vous avez besoin d’être sécurisé ».

Et vous ?

Que pensez-vous des propos de Kroah-Hartman ?

Voir aussi

L'architecture de tous les CPU Intel remise en question après la découverte de SPOILER, une nouvelle faille difficile à corriger par voie logicielle
AMD pourrait vendre plus de CPU serveur dédiés au cloud computing, après le scandale des vulnérabilités matérielles touchant surtout les CPU Intel
Les techniques de mitigation logicielles ciblant Spectre ne peuvent compenser les défauts de conception structurels des puces touchées, selon Google
Des chercheurs révèlent de nouveaux défauts de fabrication dans les CPU, une nouvelle génération de vulnérabilités Spectre et Meltdown ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de defZero
Membre averti https://www.developpez.com
Le 01/11/2019 à 22:38
@phil995511
Sauf que à ma connaissance pour mener ce type d'attaques il faut être physiquement présent sur une machine vulnérable dont les Bios / OS n'ont pas été patchés...
Tout le problème est là justement.
Les vulnérabilité découvertes dans les micro-archi Intel (et pour certaines même chez ARM/AMD) peuvent être exploités à "distances", puisqu'elles permettes de passer les barrières Mémoire/Processus mis en place par les OS pour empêcher les opérations d'écritures/lectures/exécutions sur une architecture à mémoire partagé.
Typiquement avec la bonne payload lancer sur un serveur cloud que ce soit dans un conteneur ou une VM, avec processeur Intel, il est possible de lire/écrire/exécuter des registres/buffers/instructions et leurs valeurs, sans que ce soit détectable.
De même une attaque par JS permettrait d'échapper à la sandbox mis en place par le navigateur est d'écouter en temps réelle tous ce qui passerait par le processeur.
Et ça, que la machine est été patché ou pas, puisque des dire même d'Intel, étant des bugs lié à la micro-architecture des processeurs, ce n'est pas "patchable".
La porté des attaques peut tout au plus être atténué, ce qui semble convenir à Intel ...moins à ses clients.

Intel de leur côté prétendent que la désactivation de l'Hyper Treading n'est pas nécessaire.
Tu m'étonne.
Tu voit une boite comme Intel venir expliquer à ses clients et leurs dires :
"Écouter, on s'est tromper il faudrait peut-être mieux désactiver l'HyperThreading sur nos processeurs en fin de compte.
Par contre vous allez perdre d'office 20% de performances et ne comptez pas sur un remboursement de notre part, même si c'est un vis cacher.
Parce qu'on à fait des erreurs OK, mais on ne va tout de même par rembourser tout le monde pour qu'ils aillent chez la concurrence".

Se mettraient-ils avec de telles affirmations potentiellement en porte à faux vis-à-vis de leurs clients au risque de les voir se retourner contre eux ?!
Là tu considère qu'Intel ne prend pas ses clients pour des pigeons, or ils démontrent tous les jours le contraire.
La preuve, ils continuent de vendre leurs processeurs/contrôleurs à des prix exorbitant, alors que ceux-ci sont toujours bugués et que les bios/UEFI des CM ne sont toujours pas systématiquement patchés en sortie d'usine (au bon vouloir des fabricants quoi ).
C'est un peu comme AMD qui demande à ses client de patcher une CM neuve pour pouvoir faire fonctionner leurs derniers Processeur "Compatible" .
Ça va 5 minute, mais ce n'est absolument pas normale.
Et quand une nouvelle faille apparait (ou qu'une fuite à lieu, parce que les Meltdown/Spectre c'est après 6 mois qu'on en a entendu parlé, alors qu'elles sont présentes dans tous les Processeurs Intel sortie depuis 95), leur premier réflexe a toujours été d'abord de le nier, puis d'en minimiser l'impact et enfin après un temps certain (pour ne pas dire un certain temps) de sortir des séries de patch bâclé qui font perdre X% de performances et qui finalement ne résolve rien puisque le problème est physique et ne peut être patché.

Finalement ils finissent par s'en sortir en promettant que la prochaine génération de processeurs sera exempt de failles, ce qui n'est pour l'instant toujours pas vrai.
Bref bel exemple de j'm'en bats les couillisme vis à vis de ses clients.

Au rythme auquel ils trouvent de nouvelles failles/vulnérabilités sur les CPU's ces derniers temps, si cela continue ainsi, on ne pourra bientôt plus rien faire de nos PC si ce n'est les recycler
C'est bien parce que l'on a pas vraiment le choix qu'ils ce permettent d'avoir ce comportement.
Si la masse de leurs clients avaient ne serait-ce qu'une architecture de replie, ils seraient plus avenant, or ce n'est pas le cas.
En l’état il n'existe aucunes architectures alternatives pour le grand publique.
L'industrie c'est orienté vers l'Intel x86 depuis l'IBM PC, finalement on va en subir les conséquences collectivement un jour ou l'autre.

En passant, j’attends encore les sanctions de l'Europe pour abus de position dominante d'Intel sur le x86 et divers autres IPs en leurs possessions.
9  0 
Avatar de eldran64
Membre éprouvé https://www.developpez.com
Le 05/11/2019 à 9:59
Juste pour la petite info, désactivé l'hyperthreading sur un core I3 de 10ème génération, c'est perdre un peu plus de 30% de performance et non 20%.
Ça a fait partie des arguments qui m'ont poussé à passer sur une plateforme AMD à la place d'Intel.
4  0 
Avatar de phil995511
Membre habitué https://www.developpez.com
Le 01/11/2019 à 18:21
Sauf que à ma connaissance pour mener ce type d'attaques il faut être physiquement présent sur une machine vulnérable dont les Bios / OS n'ont pas été patchés... Intel de leur côté prétendent que la désactivation de l'Hyper Treading n'est pas nécessaire. Se mettraient-ils avec de telles affirmations potentiellement en porte à faux vis-à-vis de leurs clients au risque de les voir se retourner contre eux ?!

Au rythme auquel ils trouvent de nouvelles failles/vulnérabilités sur les CPU's ces derniers temps, si cela continue ainsi, on ne pourra bientôt plus rien faire de nos PC si ce n'est les recycler
4  1 
Avatar de verdy_p
Futur Membre du Club https://www.developpez.com
Le 24/11/2019 à 1:23
Franchement @Jipété, je pense que tu n'as rien compris à la nature même de la vulnérabilité.
Ici ce n'est pas un bogue concernant les données qui peuvent être directement lues d'une adresse mémoire donnée avec une instruction de lecture normale, mais le fait qu'il est possible de déterminer alogithmiquement (par une simple mesure du temps pour lire une adresse, à laquelle on a légalement accès, pour en déduire ce que contient une **autre** adresse mémoire utilisée par un autre processus théoriquement protégé).
Ici le problème n'est même pas l'exécution spéculative: l'attaquant ne lira pas autre chose que ce qui était prévu, car son exécution spéculative aura été "annulée".

Le problème vient du processus d'annulation: l'état du processus (ou du thread) reste le même, mais la faille est ailleurs: il est possible de mesurer le temps mis par la code valide, même corrigé par l'annulation de la spéculation. En effet le processeur ne PEUT PAS tout annuler: il n'annule que l'état superficiel, mais il ne peut pas restaurer l'état du cache qui a été impacté par l'exécution spéculative, l'exécution reprend d'un côte ou de l'autre (celui de l'attaquant ou celui du code protégé) mais avec des temps différents.

Et il est démontré maintenant que l'attaquant peut contrôler sans sortir de sa "bulle" d'isolation, l'état des caches partagés.

Dans le cas de VMs: l'hyperviseur isole bien la VM attaquée de la VM dans laquelle tourne l'attaquant. Mais les deux se partagent des ressources communes et notamment divers niveaux de caches. Dans le cas de "l'hyperthreading Intel" l'attaque ne touche pas les caches L1D ou LI1 puisque deux threads concurrents ne partagent pas les caches L1, mais ils se partagent le même cache L2 et le même cache L3 dans le processeur, et parfois un cache L4 dans les processeurs Xeon ou sur la carte mère. Ils se partagent aussi les bus mémoire, les bus de communication (PCIexpress, notamment de la carte réseau où les processus protégés et les processus attaquants arrivent par le même canal et se partagent la bande passante.

Désactiver l'hyperthreading pourtant n'a aucun effet ! le cache L2 est réservé à un seul thread car l'autre est désactivé et ne tourne plus, les autres processus devront s'exécuter sur un autre coeur sur des caches L2 différents. Mais ils se partagent encore le cache L3 et tous les autres bus avec la mémoire ou le réseau. Au passage c'est drastique sur les perfs, mais ça ne résoud rien.

Tous les systèmes qui sont amenés à traiter des données venant de différents clients ayant des droits d'accès différents, et notamment les serveurs Internet y compris les serveur de VPN sont obligés de se partager une ressource.

Spectre est là pour durer et on n'a pas fini de trouver d'autres caches exploitables avec TOUTES les architectures modernes. Désactiver tous les caches et interdire le partage de ressource veut dire simplement l'extinction TOTALE de l'Internet et de tous les réseaux. Autrement dit toute l'informatique d'aujourd'hui.

La réflexion doit avoir lieu sur d'autre points: et ça commence par revoir les "politiques d'éviction de cache" en mettant des quotas d'utilisation sur chaque usage et empêcher les différents clients de provoquer la "famine" de ressources partagés chez les autres. Hors on a basé une très grande partie des optimisations qui ont permis d'epxloser les performances, en utilisant des politiques d'éviction de cache simple (de type LRU sans identifier réellement les usages de chacun).

Ce qui a été fait dans les OS pour isoler la mémoire (mémoire virtuelle) n'est pas suffisant. On commence à voir des isolations entre processus, puis entre VMs, par logiciel mais là on est sur des parties inaccessibles même au logiciel normal (code ISA), car ça ce situe dans la microarchitecture. Et rien n'a été fait sur les caches externes et on n'en verra pas le bout sur les caches du coeur de réseau Internet : on se partage les backbones, et il y a de larges totlérances d'usage permettant de mettre en "famine" facilement un lien pendant une durée assez longue pour écouter des secrets pendant un temps pourtant assez court pour que ça passe sans être bloqué (les backbones Internet commence à perine à s'en préoccuper en renforçant les politiques d'usage et d'équilibrage avec du "trafic shaping" de plus en plus aggressif : sur des liens gigabits et au sein même des hébergeurs de services clouds sur les routeurs internes, il y a un sévère problème! Les solutions d'isolation vont couter très cher !)

En fait c'est la politique LRU simpliste qu'il faut revoir et utiliser à la place des temps de réponse aléatoires (avec assez de variabilité pour ne rien pouvoir en déduire, et donc une précision de l'aléa suffisante d'au moins 128 bits, mais aussi avec l'utilisation de vrais générateurs aléatoires et pas algorithmiques, disposant d'une très grande entropie: Google est là en avance avec son processeur quantique, il peut protéger efficacement son réseau et je pense que ce sera la première utilisation de son système pour protéger ses secrets: utiliser l'aléa n'a pas autant d'impact en performance que la désactivation des caches partagés; ce plus on peut utiliser la ségrégation des usages par domaine et renforcer les quotas pour limiter la famine sur un des flux ou su un grand nombre de flux parallèles, et garantir qu'aucun ne pourra controler comme il veut le flux disponible aux autres pour parvenir à savoir à quoi ils accèdent).

Les mitigation actuelles de Spectre sont cependant limitées! On a dans le logiciel une mitigation des attaques de type 1 (les plus simples en fait à corriger, même si ça coête un peu de performance: "Retpoline" et "Lfence"), il y a 3 autres types d'attaques, l'attaque du L1 décrit ci-dessus concerne surtout les serveurs d'application et serveur web ou VPN où un mêm processuis ou thread traite en boucle les demandes venant de différents clients pour leur concéder une tranche de temps, même limitée mais permettant à un autre client de savoir ce qui s'est passé juste avant lui et de modifier le comportement/les performances du client suivant. Pour prevenir ça il n'y a pas d'autre solution que d'utiliser un "scheduler" non totalement prédictif basé sur des règles strictes, mais sur l'aléa le plus total, et une mesure effective des quotas et un équilibrage suffisant mais pas strict mais avec aussi un aléa suffisant des ressources allouées à chacun.

L'attaque de type 4 en revanche touche TOUS les systèmes, toutes les architectures, tous les langages, tous les réseaux. Spectre est là pour longtemps et va hanter l'internet pendant des décennies. Elle durera tant qu'un utilisera des "machines de Turing" à algorithmes impératifs, et qu'on ne sera pas passé à l'informatique quantique (totalement basée sur l'aléa le plus fort). Et là tout est à développer. On comprend pourquoi Google investit massivement dans l'informatique quantique.

La solution simpliste proposée par les promoteurs de Linux ne sert à rien, elle ne résout rien. Intel n'est pas seul en faute, mais tous les fabricants du monde et tous les producteurs de code (Linux compris) : il faudra changer de langage de de façon d'utiliser un ordinateur et aussi changer tout ce qu'on attend d'un ordinateur: une réponse oui/non absolue sans aucune erreur et le plus rapidement possible alors qu'on s'orientera plutôt vers des réponses heuristiques tendant vers une simple optimisation progressive (et on, rédoudra plus de problèmes avec ça). L'avenir est aux probabilités et non plus aux statistiques: dehors les statisticiens, on ira voir les physiciens, les biologistes, les architectures ne seront plus "distribuées" mais "réparties", avec des pannes inhérentes au système et des variations dans les réponses, elle ne sera plus "localisée" et on ferra avec.

Les fondeurs s'y préparent parce qu'ils n'ont plus le choix et ont quasiment atteint les barrières quantiques avec les technos de gravure actuelles qui sont bridées par la température, la puissance d'énergie consommée (et à dissiper), les fréquences, et la taille des transistors. On atteind les 7 nanomètres en gravure, mais au delà on n'a plus beaucoup de solution, la gravure 2D est à bout de souffle, on passera aux réseaux cristallins 3D, et il n'y aura plus de transistor localisé avec des jonctions NP, on utilisera à la place des réseaux de diffractions, l'holographie, la superposition d'états quantiques, on ne cherchera plus à éviter les interférences entre circuits voisins mais on les utilisera à grande échelle.
0  0 
Avatar de verdy_p
Futur Membre du Club https://www.developpez.com
Le 24/11/2019 à 1:35
Nul besoin de présence physique. Spectre est exploitable à distance sur tout système proposant un accès par Internet dès son point d'accès: la page de login, même protégée par du multifacteur: c'est une ressource partagée qui permet d'écouter aussi les accès concurrents. Et tout service utilisant en interne des données soumises par leurs utilisateurs (beaucoup mêm sans le savoir concernant la collecte des données de profilage: tout service qui collecte ces données est INCAPABLE d'empêcher que ces données soient écoutées, même si l'envoi est crypté/sécurisé: il suffit d'envoyer d'autres données de collecte spécialement conçues pour modifier les performances de ce système d'écoute et donc savoir ce que contiennent ou comment sont traitées les données collectées venant d'autres clients.

Si on veut mon avis: c'est la mort de la "télémétrie", les publicitaires (et leurs diffuseurs dont Google qui en vit) seront les premiers à devoir se passer de ces données (et la loi va devoir se renforcer, le simple "consentement" ne suffit pas, même le site "développez.com" oblige à accepter cette collecte sinon son service est inutilisable et devra se passer des utilisateurs et de ce forum, ils ne pourront plus que diffuser leurs propres contenus, c'est la fin de l'interactivité, des réseaux sociaux et de la possibilité donnée à chacun de communiquer même par des canaux "privés" puisque Spectre démontre que c'est en fait impossible de protéger la confidentialité avec l'informatique impérative actuelle).

Vivement l'arrivée de l'informatique quantique et des réseaux quantiques pour tous !
0  0