L’intelligence artificielle, le machine learning, la blockchain… le paysage numérique est riche en « solutions » consommatrices de ressources, bien que cela dépende des usages. Le LINC de la CNIL détaille cette problématique et propose quelques pistes de réflexion, notamment autour de la sobriété et de la frugalité.
Dans son 9e cahier IP (Innovation et Prospective), le Laboratoire d’innovation numérique de la CNIL (alias LINC) revient sur un sujet d’actualité, avec « une exploration des intersections entre protection des données, des libertés, et de l’environnement ». Dans un premier article, nous sommes revenus sur les paradoxes et controverses de la consommation bien réelle d’un monde virtuel. Ce n’était qu’une partie du cahier de 70 pages (pdf).
Intelligence artificielle : docteur Jekyll et M. Hyde
Dans ce même cahier, il est aussi question d’intelligence artificielle, avec un constat : « Ces systèmes et outils présentent de grands enjeux en termes de protection des données. S’ils présentent d’ores et déjà des succès notables, ils sont encore sujets à des défaillances, des attaques, et peuvent avoir dans certains cas des impacts insoupçonnés sur les individus et la société ».
Pour ne citer qu’un exemple, certains ont tendance à renforcer les biais humains, justement, car ils sont entrainés sur des données provenant d’humains. En cas d’attaque, la paralysie des systèmes vitaux dans les hôpitaux, la fuite de données personnelles (y compris médicales) ou la perte de fichiers clients peuvent avoir des conséquences catastrophiques.
Ce n’est pas la seule fois où l’intelligence artificielle a un double visage : « Les IA, comme tout système informatique, pouvant être vues à la fois comme un moyen d’améliorer ou optimiser des consommations, et comme une source de consommation importante, sans que l’on soit toujours en capacité d’en mesurer réellement la balance ».
La CNIL donne quelques exemples : l’entrainement de BERT (Google) « a nécessité l’apprentissage de quelque 340 millions de paramètres pour un coût en électricité équivalent à la consommation d’un ménage américain pendant 50 jours ». Du côté de GPT-3 (OpenAI, utilisé pour ChatGPT), on compte 175 milliards de paramètres, et même jusqu’à 540 milliards de paramètres Pathways (Google). Reste qu’il est bien difficile pour les chercheurs de mesurer les effets indirects du développement et de l’utilisation des IA.
Le Laboratoire reprend une étude sur les émissions carbone de l’entrainement des algorithmes : « des régions à faible émission comme la France ou la Norvège pourraient permettre d’économiser 70 % des émissions par rapport à des régions comme le centre des États-Unis et l’Allemagne. L’heure de la journée à laquelle les calculs sont effectués à également un impact significatif ».
Parfois (souvent ?), il est difficile d’obtenir des données fiables et comparables, sans compter les contraintes locales en matière de gestion des données privées, avec le RGPD en Europe par exemple.
- Empreinte environnementale du numérique : entre certitudes, inconnues et recommandations
- Mesurer l'empreinte environnementale du numérique, un vrai casse-tête
- L’Europe face à la consommation croissante des datacenters et l’explosion des services cloud
La question de l’usage est primordiale
Le cahier revient aussi sur le choix des priorités : « la recherche d’avancées dans la détection de la mort subite du nourrisson semble par exemple plus prioritaire que la production de nouveaux filtres pour des images postées sur les réseaux sociaux ».
C’est l’occasion d’évoquer un autre sujet, tout aussi déterminant : l’usage des algorithmes. Le machine learning peut ainsi servir à optimiser la performance énergétique des centres de données (et d’autres infrastructures) – et donc « être considérés directement utiles à la lutte contre le réchauffement » –, à l’inverse par exemple de l’optimisation de la publicité. Pour résumer, « l’impact environnemental de l’IA dépendra largement de son usage ».
La publicité « a un poids bien réel »
Une partie de l’étude se penche justement sur le cas de la publicité en ligne, notamment celle qui est ciblée. Après l’entrée du RGPD, un développeur s’est amusé à comparer les versions américaines et européennes du site USA Today, qui proposait une version sans traceurs ni publicités sur le vieux continent.
Le verdict est sans appel (et sans grande surprise) : « La version européenne du site chargeait 500 kb de données, quand la version états-unienne, ses cookies et ses publicités nécessitait le chargement de 5,2 Mb de données », soit 10 fois plus ! Autre résultat intéressant, venant d’une équipe de l’INSA Lyon : « les publicités ont un fort impact sur la batterie, qui s’épuisent jusqu’à trois fois plus vite sur certains sites entre des versions avec ou sans publicité ».
Bref, « La publicité ne pèse pas seulement sur l’attention, elle a un poids bien réel. Quand le trafic ne l’est pas toujours ». La CNIL met en avant plusieurs pistes pour agir : « refus[er] les cookies et install[er] des logiciels bloqueurs de publicité, autant de petits gestes qui par des effets de masse peuvent bénéficier aux individus, et à la planète ».
La blockchain et les cryptomonnaies… « c’est compliqué »
C’est un autre sujet qui revient souvent sur le tapis lorsque l’on parle de consommation électrique. Le Cahier de la CNIL reprend à son compte une citation de Bitcoin Magazine : « La [forte] consommation électrique de Bitcoin n’est pas un bug, mais une caractéristique ».
Une piste est de bannir la preuve de travail (proof of work) et la remplacer par la preuve d’enjeu (proof of stake) qui est bien moins énergivore. Une option promue par Erik Thedéen, vice-président de l’Autorité européenne des marchés financiers (AEMF) :
« Dans cette méthode, le mineur doit pouvoir prouver la possession d’une certaine quantité de crypto-monnaie pour prétendre valider des blocs supplémentaires et toucher la récompense. La probabilité d’être choisi comme validateur d’un bloc est proportionnelle à la quantité de cryptomonnaie possédée, et à la durée de cette possession, et non plus à la quantité de travail fourni », explique la CNIL.
Les gains sont-ils importants ? Oui, selon le cahier qui annonce une consommation en baisse « entre 4 et 6 ordres de grandeur » par rapport au Bitcoin. « Le gain par transaction peut même atteindre 8 ordres de grandeur pour devenir négligeable, de l’ordre de la consommation du chargement d’une page web ou de l’envoi d’un mail ».
Le chiffrement à double tranchant
La CNIL recommande régulièrement de chiffrer les données – afin de les protéger –, mais reconnait que cette opération n’est pas sans coût sur l’environnement : « le chiffrement augmente automatiquement la consommation énergétique, d’abord par le calcul nécessaire à cette opération, mais également pour le déchiffrement et le stockage », car les données chiffrées prennent souvent plus de place.
Mais la CNIL met aussi en parallèle la compression, qui permet a contrario de réduire le stockage et donc la consommation de ressources. Elle rappelle aussi que « des méthodes cryptographiques permettent de générer des preuves sans pour autant conserver le fichier en lui-même ».
Le Laboratoire met en avant une autre dichotomie entre « défenseurs des libertés, hostiles aux systèmes de surveillance pour des fins de "sécurité", et défenseurs de l’environnement, favorables à ces systèmes, voire aux dénonciations lorsqu’il s’agit de protection de l’environnement ». Un dossier sur lequel la gardienne des libertés individuelles est en première ligne.
L’occasion pour la CNIL de mettre en avant son site Climatopie avec six récits décrivant un quotidien futuriste « dans lequel notre relation à la technologie a évolué en fonction des contraintes de la crise climatique ». Il est notamment question d’une vie rythmée par les quotas énergétique et/ou de pollution, de l’impact environnemental comme donnée publique et de l’écroulement des ressources.
Des exemples d’actions actuellement mises en place sont décrites dans le Cahier. On y retrouve des bacs à ordure individuels avec des capteurs de poids, ou encore le rationnement du carbone pour les déplacements des personnes. De manière plus large, on peut citer « la surveillance des comportements sur les réseaux sociaux telle qu’expérimentée par l’administration fiscale pourrait être utilisée pour traquer des comportements déviants, ou demain illégaux, du point de vue de la protection de l’environnement, au-delà du flight tracking ou des opérations de vigilantisme ».
Quelques pistes de réflexion
En guise de conclusion, le LINC propose des « pistes pour rapprocher protection des données et de l’environnement ». On y retrouve pêle-mêle la promotion d’une informatique sobre – avec « des systèmes justement dimensionnés » – et frugale sur les données, par « la minimisation, et des systèmes robustes, afin de limiter notamment les failles et les fuites de données ». La frugalité est aussi mise en avant pour l’intelligence artificielle.
Le laboratoire souhaite aussi « documenter les bonnes pratiques pour la réparation et le reconditionnement », et proposer des solutions pour « un partage vertueux des données environnementales ». Il veut également « engager un débat autour des libertés en période de crise climatique » :
« Cette question de la balance des droits et des libertés pourrait être amenée à évoluer avec la crise climatique, les gouvernements amenés à proposer la mise en œuvre de textes de loi et/ou de solutions visant à encadrer les comportements des personnes, sur la base de leurs données personnelles, voire limiter leur capacité à aller et venir, comme cela a déjà été fait à l’occasion de la pandémie de COVID.
L’acteur public pourrait alors invoquer un principe de responsabilité pour le développement d’outils de surveillance ou de bridage des comportements et consommations. »
Enfin, le LINC revient sur le cas du Collège de la CNIL, qui « pourrait ajouter une composante environnementale à ses décisions, en complément de l’analyse juridique et de conformité des projets numériques ».
Commentaires (31)
#1
Et c’est eux qui protègent notre vie privée ?
La crypto moderne ça ne consomme presque rien. La consommation liée au chiffrement est complétement marginale en comparaison du reste. Charger la donnée depuis un NVMe consomme des ordres de grandeur en plus que le chiffrement AES ou ChaCha20.
Le chiffrement de données utilise presque toujours une clé symétrique. Dans ce cas, les données chiffrées ne prennent pas plus de place. La clé fait quelques octets en général.
Rendu là ça n’est plus drôle du tout, leur discours n’est pas juste ridicule mais aussi dangereux en donnant l’impression d’une tension entre les deux alors que ce n’est pas du tout le cas.
Leur incompétence donne des excuses bidons à ceux qui voudront limiter le chiffrement.
#2
C’est intéressant les récits du site Climatopie. Les sources d’inspirations rajoutent de la crédibilité.
#3
Texte hello word! non chiffré, ascii:
hello word!Texte hello word!, chiffré AES-128 (secret:1234567890123456), base64, ascii:
M8M7de1Wq7n3Zdb5I8wSjA==#4
Après une lecture rapide du chapitre “des libertés en transition ?” j’ai l’impression d’une dépolitisation du sujet.
L’accent est mis sur la responsabilité individuelle de toutes les classes sociales. Il manque par exemple la responsabilité des industries, des entreprises.
La surveillance est celle entre individus ou celle venant de l’Etat pour surveiller par exemple la présence d’une piscine non déclarée. Elle sert à modifier nos comportements individuels.
Or la surveillance entre individus (publier la conso du jet privé d’Elon Musk) disparaît avec une régulation. Et la liberté qui disparaîtrait, interdire les jets privés, n’est accessible qu’aux plus riches.
Que de nombreux foyers deviennent autonomes concernant l’énergie électrique leur semble impossible.
Je cite page 46 : les nouveaux moyens de production d’électricité, comme les éoliennes ou surtout les panneaux solaires, ont constitué une nouvelle opportunité pour les individus de contribuer
et gérer eux-mêmes leur consommation et leur production. Il n’est toutefois pas évident de l’autoriser compte tenu des contraintes de gestion d’un réseau électrique fortement
centralisé et dont l’équilibre est sensible et stratégique.
Si la centralisation ne peut être remise en cause, au moins en partie, il s’agit d’un statu quo.
Cette partie ne risque de froisser ni le pouvoir en place ni les lobbies les plus polluants. Et elle manque de pertinence. Et comme le dit Wagaf elle n’empêchera pas de trouver normal de punir (interdire le chiffrement) au lieu d’agir au niveau politique.
#5
Question “poids de la pub”, cela fait des années que c’est mubloc au minimum sur mes navigateurs (smartphone, linux ou windows), ne serait-ce pour mon confort personnel et par conviction, étant hostile à toute forme de publicité/tracking, parce que je les considère comme de la pollution visuelle, auditive, et anti-écologiques (consommation sur nos PC/smartphones mais aussi sur le transport des données et leur stockage). J’avais déjà dénoncé le poids exagéré des pubs sur mon site perso il y a quelques années, avec des pages 8x trop lourdes à cause de la pub.
Désormais, c’est carrément un DNS menteur que j’ai installé chez moi. Adieu la pub même dans mes (rares) applications (qui en ont) sous android et vive Adguard.
#6
Rigolo, la CNIL ne parle bien du chiffrement (et visiblement ne semble plus le défendre sous pretexte d’une pollution qu’elle ne peut même pas quantifier), mais en plus elle omet de mentionner l’une des pollutions majeures du secteur avec le fait de devoir renouveler le matériel régulièrement (en raison d’offres commerciales douteuses ou d’OS qui s’engraissent aussi rapidement que les artères d’un américain moyen dopés aux protéines de synthèses et au poulet à l’eau de javel).
Je passerai sur le paragraphe (que @wagaf) a cité et juste après le “oui mais la compression peut résoudre ce problème” Et la conso en énergie ?!
Franchement, c’est vraiment la CNIL (je sais c’est LINC, mais la CNIL a bien du autorisé la publication) qui a pondu cette immondice ? Ou bien c’est du McKensy qui a demandé à ChatGPT de lui faire un rapport ?
Concernant le chiffrement, nos politiques français si fan des US feraient mieux de se souvenir qu’interdir quelque chose c’est au contraire en faciliter son accès. (coucou la prohibition US).
Ce qui me rassure, c’est que le jour où la France interdit le chiffrement, ça va être un tel bordel législatif qui soit ça va être interdiction totale (et on va bien se marrer [même si on va prendre chère)) soit avec tellement d’exception que les décrets d’applications seront confiés à l’ANFR et qu’au final, ça va être de l’argent public dépensé à payer des brasseurs d’airs.
#7
A mon sens, l’augmentation de la consommation à cause du chiffrement n’est ni dans le chiffrement/déchiffrement, ni dans le stockage, mais dans les transmissions par les réseaux, et c’est la seule qui n’est pas citée. Déjà en effet la taille de la donnée peut-être augmentée par le chiffrement, mais ce sont surtout les protocoles qui augmentent la consommation. Utiliser un VPN chiffré par exemple augmente les échanges de 3 à 10% mais c’est finalement peu impactant.
Charger quelque chose en HTTPS l’est bien plus car il nécessite 2 échanges avec le serveur pour générer la clé privée, un échange avec le serveur ayant émis le certificat pour s’assurer de sa validité (échange qui, s’il est chiffré, nécessitera 2 échanges de plus), plus parfois des vérifications supplémentaires auprès d’autres serveurs (qui peuvent être chiffrés pareil), et au final l’échange pour récupérer la donnée. Soit facilement 6 échanges contre un seul en HTTP. Et ce, pour chaque serveur différent qui fournit les données de la page que l’on charge, et il peut y en avoir beaucoup, surtout quand il y a de la pub.
Tous ces échanges qui, même s’ils sont de petites taille, génèrent autant de paquets qu’il faut router et transmettre de multiples fois.
Cette différence n’existe pas sur du stockage. Une fois la donnée stockée dans un fichiers, c’est la taille minimale du bloc du système de fichiers qui définit l’espace occupé et non le système de chiffrement qui n’a plus d’influence là-dessus, il vaut mieux changer la taille du bloc si on sait qu’on va stocker beaucoup de petits fichiers.
De plus du stockage plus grand ne consomme pas plus d’énergie ni de ressources de fabrication, on se trompe de cible là.
#8
La pub est clairement plus significative en impact énergétique (et surtout démontré) que 12 tours d’AES. Commençons par éliminer les plus grosses sources de pollutions avant de s’attaquer à des micro-détails.
Stockage plus grand veut dire plus de cellules, donc plus de transitor et de matières, non ? Sinon je n’ai pas compris ton propos.
#9
La pub augmente effectivement nettement le nombre et le volume d’échanges.
Mais il y a aussi un concept qui consomme beaucoup: les pages dynamiques.
Dans la majorité des cas, les pages affichées sont calculées par le serveur avant d’être envoyées. Mais dans énormément de cas aussi, elle pourraient être statiques.
Par ailleurs, par fainéantise souvent, des mécanismes sont inclus pour empêcher que la page reste en cache côté client, nécessitant un retransfert des données.
Mais somme toute, c’est toute la techno HTML/CSS/Javascipt qui est à revoir. Le ratio entre la données utile et le volume transféré est souvent de mins de 1⁄100 (et je suis gentil 1⁄1000 serait plus juste).
Entre le temps CPU, la RAM non gérée, le volume des transferts, l’utilisation du GPU pur afficher du texte, l’informatique d’aujourd’hui est un gâchis de ressources de tous les jours (et ce sans demander à revenir à l’âge de pierre). Les technos type Java étaient infiniment plus légère que ce qu’on a actuellement.
Vivement des pages compilées type WASM et des informaticiens formés.
#9.1
Je suis d’accord avec tes dires. Mais il y a point que je ne saisis pas bien ? Pourquoi vouloir ne pas stocker la page coté client ? Perso, je préfère que ma page web soit stockée chez le client car ça évite à mon serveur de tourner pour rien, et donc de lui libérer du temps pour autres choses (idle, nouvelles connexions…).
#10
Surtout la pub en HTTPS… 50 sessions HTTPS à ouvrir pour charger tous les petits trackers
Sur la durée, la taille physique du stockage ne change pas avec le temps, pourtant la quantité stockée augmente sans cesse car le stockage devient plus dense, que ce soit sur des plateaux de taille standard pour les disques durs où les particules magnétiques sont de plus en plus proches, ou sur la même surface de silicium pour les SSD où les transistors sont de plus en plus proches et empilés.
En effet, à un instant donné, un périphérique neuf de stockage d’une taille donné utilise plus de matière que son collègue de même gamme moitié plus petit (pour les disques durs on enlève des plateaux par exemple). Mais ce même périphérique n’utilise pas plus de matière qu’un modèle moitié plus petit mais d’il y a 2 ou 3 ans car la densité a évolué entretemps.
Mais on peut toujours le voir dans l’autre sens et dire que si le besoin n’avait pas évolué avec la densité, on utiliserait de moins en moins de matière au lieu de rester stable. Après peut-être que si le besoin n’évoluait pas, il y aurait moins de motivation à rechercher une meilleure densité, donc c’est pas forcément si évident.
#10.1
N’en déplaise à la CNIL, être écolo c’est chiffrer ses données et tout faire pour bloquer les trackers de pub (Adblocker et/ou DNS menteur local). D’ailleurs quand est-ce que la CNIL va faire des tutos pour configurer un DNS local menteur
? Histoire de remonter très sérieusement son niveau.
Je suis d’accord pour dire qu’un support de stockage de 2To gravé en 5 nm (sous l’hypothèse que la densité est la même pour tout l’ensemble des transistors) et un autre de 2To à 12 nm font la même capacité, mais que le premier nécessite moins de matière.
En pratique, tu fabriques toujours le support de stockage de la génération d’après, qui certes va consommer - à capacité de stockage identique avec la gen. d’avant- moins de matières mais qui va en consommer toujours.
La question devenant : Est-ce que le gain obtenu par une gravure plus fine compense la quantité de matière provenant de la production de masse sous l’hypothèse qu’en raison de facteurs extérieurs je n’ai pas produits la même quantité de support entre les deux générations ?
Le besoin d’évolution est, en dehors de l’aspect économique, une conséquence de toujours vouloir faire mieux car on a trouvé une nouvelle façon de faire par l’innovation technique/scientifique. Mais ça, c’est inhérent à l’humanité et très présent dans les domaines techniques/scientifiques.
#11
Je ne sais pas ce que vous avez tous sur la remarque de la CNIL sur le chiffrement.
Elle ne fait noter que c’est plus coûteux (énergétiquement parlant) de chiffrer que de ne pas chiffrer.
Rien de plus, si ?
(Je n’ai pas été lire le rapport non plus mais juste l’article au dessus).
#11.1
Relis le premier commentaire de ce thread (@wagaf, déso je ne sais pas comment le lier).
Physiquement parlant, oui le chiffrement va consommer plus d’énergie (et encore je parie que les instructions AES-NI sont économes).
Sauf que le rapport ne donne pas de valeurs et ne fait pas de mise en perspective à côté du reste des composants d’un PC.
A ce titre, @wagaf rappelle que l’accès à des données sur SSD NVMe est bien plus coûteuse (et pour le coup on peut le quantifier) qu’un simple chiffrement AES. Surtout qu’en pratique, ton processeur passe plus son temps à se toucher les transistors qu’à chiffrer continuement des données. Sauf cas particuliers (serveurs, transfert de données importants) le chiffrement AES n’est pas significatif devant les autres sources de consommation.
Vérifions les dires avec un wattmètre. Proc intel i7-9750H @ 2.6 GHz (oui je coupe le turbo sauf quand je fais des calculs et du jeux. En temps normal, la fréquence de base est suffisante et m’évite du “sifflement de bobine” et une chauffe inutile du CPU. ). Actuellement je consomme (avec Thunderbird, Firefox et vim d’ouvert) 19 W à la prise (avec le GPU integré Intel) et l’écran à 10% de luminosité.
Je génère 4Go de données aléatoires dans le /tmp monté en tmpfs.
Le chiffrement de ces données via openssl avec de l’AES-256-CBC et la réecriture des nouvelles données dans le /tmp entraine + 4W.
Le transfert sur mon SSD (non chiffré pour le test) entraîne + 7W.
Dès lors, on peut déduire comme ordre de grandeur que le chiffrement consomme 1W/Go (et là encore je le fais en flux continue donc le proc est monté à 2.6GHz alors qu’en temps normal il reste à 0.8 GHz) tandis que le transfert sur SSD est de l’ordre 1.75 W/Go, soit 75% plus consommateur que le chiffrement. Sous réserve d’un flux continu.
Sur un simple fichier pdf (article scientifique) de 6Mo, le chiffrement est imperceptible avec le wattmère. Tandis que je vois +2W pour le SSD.
Conclusion : Pour des cas de transfert, on peut constater l’impact du chiffrement mais il reste en deça des autres élements comme les supports de stockage. Dans le cas d’un fichier réel, celui-ci est imperceptible au contraire du SSD.
#12
Dans le web 1.0, surement. Et avec le succès de markdown (merci github), il y a pas mal de petits blogs qui ont redécouvert les avantages du générateur de site statique. On peut aussi concevoir une page maitre pour mixer le contenu statique et les encarts dynamiques (pubs, bloc spécifique utilisateur, recherche…)
Par contre, le web 2.0+ vise à fournir du contenu qui cible en permanence l’utilisateur. Parfois même dynamiquement sur la page (genre le scroll infini qui ajoute les nouveaux blocs en fonction de vos actions sur les blocs précédents)
#13
Beaucoup de dev ont “peur” du cache côté client, et ajoute de faux arguments dans les pages pour forcer les refresh complets.
Le cache côté client c’est de la magie noire pour beaucoup.
Après, il y a eu des problèmes. Je me rappelle de meteofrance qui affichait la météo de 2 semaines avant et un mal de chien pour lui faire afficher la météo du jour.
#13.1
Ok. Merci. ça revient à ton commentaire sur la compétence des gens formés.
#14
Je ne vois pas pourquoi le chiffrement augmenterait le volume de données. Que le protocole effectivement nécessite un handshake (très léger, part le problème de latence), ok, mais les donnée ne changent pas de taille.
Belle démo.
Le chiffrement est surtout un problème en entreprise quand on a proxy qui déchiffre/rechiffre. De mon point de vue, le déchiffrement est actuellement efficace (jusqu’à ce qu’on change d’algo pour un plus sûr…), et l’interprétation du message est peut être bien plus consommatrice.
#15
Dans le cas de l’AES, en fonction du mode de chiffrement (CTR, CBC, GCM…) tu peux avoir un padding ajoutant quelques octets sur l’ensemble des données. Mais ça reste très marginal au regard d’une requête HTML.
Pour le cas des algorithmes asymétriques, je sais que cette notion de padding existe aussi et, de mémoire, c’est également marginal.
Au final, oui il peut avoir une augmentation de données mais ça reste très marginal dans plus de 99% des usages réels.
#16
c’est marginal si on regarde seulement les data transférées lors d’un échange chiffré.
Mais si on regarde tout l’écosystème de la crypto, c’est moins marginal.
Par exemple, développer un micro serveur http qui répond “hello world!”: tu peux le faire facile en moins de 10 lignes avec l’API socket. Mais développer un micro serveur https qui répond “hello world!”… là c’est pas la même histoire ! idem pour le dev des clients et l’infrastructure/config réseau (certificats, …).
Y a une bonne raison pour laquelle la diversité de l’ecosystème du web “gratuit” disparait au profit de chromium + let’sencrypt + Nginx/Apache. Construire/maintenir une alternative “gratuite” est devenu extrêmement couteux. Trop couteux pour que cela subsiste.
On peut aussi ajouter les DRM; “widevine” commence a accaparer le marché, au point que bientôt personne ne construira/maintiendra des alternatives.
Au final, mon browser web qui prenait au total quelques Mo sur mon disque-dur occupe aujourd’hui 615Mo pour l’appli et +2Go pour les data (profile). Cet embonpoint n’est pas directement causé par la crypto. Mais la crypto participe à l’absence d’alternatives qui seraient moins gourmandes.
#17
Bof, pas vraiment.
Par ailleurs avec les dernières évolutions de TLS, l’établissement de la connexion sécurisée se fait en zéro round trip (le premier paquet inclus des donnés chiffrées) ou 1 round trip si le serveur n’avait pas été visité auparavant.
Mais c’est surtout que le chiffrement sur le Web ce n’est plus un débat, c’est le standard depuis plus de 15 ans, et il n’est simplement pas envisageable aujourd’hui de revenir là dessus.
Ça me choque que la CNIL remette ça sur le tapis en le présentant comme un truc à contre-balancer avec d’autres choses comme l’écologie, autant pour la conso que pour pouvoir surveiller la consommation des gens..
C’est un peu comme dire que la serrure de ta porte a consommé du CO2 a fabriquer, et que ça ne permet pas à une éventuelle police écolo du futur de surveiller ta consommation, donc une autorité publique indépendante lancerait une réflexion sur les portes verrouillées, avec des fonctionnaires qui s’amuseraient à écrire des histoires de science fiction ridicules sur le sujet.
On créé dans la tête du grand public l’idée que “le chiffrement, ça pollue”, ce qui est faux et dangereux.
Honnêtement, c’est plutôt trivial en fait.
#18
Je parlais d’alternatives moins gourmandes en espace occupé sur mon disque-dur !
Personne ne va plus sérieusement penser à implémenter from scratch du code pour gérer TLS 1.3, HTTP/2, et un render HTML5+CSS3.
Même google qui a pourtant les moyens a préféré forker webkit et openssl plutot que d’implémenter from scratch son code.
La crypto c’est complexe et tout le monde préfère reprendre des libs existantes (openssl) ou même des applis existantes (chromium) pour construire son projet.
Je ne suis donc pas près d’avoir un browser web qui prenne moins de place sur mon disque-dur… sauf si la brique de base (chromium) diminue en taille.
#19
Heu, tu es sérieux là ? La place d’un browser web sur un disque de nos jours, c’est vraiment pas un problème. Le prix d’un support de stockage est abordable de nos jours en occassion. Et les systèmes de fichiers font de la compression efficacement.
Alors je suis d’accord pour dire que le Web moderne souffre de l’obésité d’un américain moyen, mais là tu exagères de dire que 2 ou 3 Go sont critiques pour ton support de stockage.
Et si la taille est un problème de ton navigateur, tu en as des alternatifs open-source qui vise justement à être économe sur ce point.
#20
D’un autre côté, en 2001, webkit était dispo et propre.
1- En 1h ou 2 tu te fais un browser minimal avec Qt. Je pense que 50-80Mo suffiront pour l’exécutable.
2- le problème n’est pas tant la taille du browser, que le fait que chacun y va de sa couche. 10Go pour l’OS, le browser (qui est quasiment un OS) par dessus, le tout mâtiné de GPU, chiffrement, Javascript et technos “dynamiques”, et tu as un gâchis de ressource pour chaque page.
J’ai dernièrement allumé un Atari ST, puis un Palm. Ce qui sidère: l’efficacité des engins. Droit au but. Et de l’utile dès le début.
Autre constat: émuler Win95+Word 97 en Javascript est plus réactif à l’utilisation qu’utiliser Word 2016 en natif sur un Core i5. On me rétorquera qu’il y a plus de fonctionnalités dans le 2016. Mais lesquelles vous utilisez?
Et vous savez ce qu’un CPU fait le plus et pour lequel peut de CPU on progressé en efficacité? Transformer et comparer des chaînes de caractères (opération très dépendante de la mémoire)…
Tu charges un HTML: il faut l’interpréter, elle ne sont pas forcément en majuscule/minuscule. Ensuite il y a le CSS. Les identifiants sont en texte -> comparaison. Le javascript est en texte. Le Json aussi. Tout ces traitements de texte sont lourds et long. Sans parler du fait que l’ASCII n’est plus le seul standard de codage: nicode, UTF-8, ISO8859, … Cela demande des conversions permanentes des chaînes (et souvent, leur présence en double dans la RAM)
Ensuite le calcul de position des éléments, de taille. Là on a de la virgule flottante pour les polices.
Mais en gros, sur le Web, sur Excel, dans la plupart des softs, la vitesse de calcul n’est pas importante. Ce qui est important, c’est la vitesse de comparaison des chaînes et l’accès à la RAM.
Et vous pensez que le sordis sont plus efficaces? Oui, sur le papier, à la prise, un atari, un 286 ça consommait au max moins que nos ordis en Idle (ordis fixes): 20W.
Pour gagner en efficacité, être capable de faire des choses à peu près semblables avec des CPU plus économiques, il faudrait prétokenizer les pages, “compiler” le HTML/CSS, … A partir de là, n’importe quel CPU de 800MHz serait convenable et on aurait besoin de moins de RAM et moins rapide.
#21
Rien n’est un problème de nos jours car on augmente la capacité du HDD, on augmente la capacité de la RAM, on augmente la puissance du CPU, on augmente les débits, on augmente la résolution, on augmente la puissance du GPU, on augmente la puissance des alimentations.
bref, on augmente l’empreinte écologique.
D’où cet article sur NXI qui se focalise sur le chiffrement, mais on peut étendre la réflexion à tout le secteur du numérique.
#21.1
Je te rétorque qu’il y a probablement moins d’espionnage dans le premier que le second. Ou que espionnage il y a, il est déporté chez l’hébergeur et non sur ta machine.
Les CPUs ont progressé sur ces points. Tu trouves facilement des libraries optimisés pour faire ce genre de choses et qui exploite proprement les unités vectorielles (mettons de coté SSE4 .2 pour la manipulation des strings). Celle qui me vient immédiatement en tête concerne JSON.
Le problème provient parfois des effets de ramp-up concernant l’activation des unités vectorielles.
+1. Mais faudrait déjà que ce cancer de Windows comprennent que l’UTF-8 (et 16 et 32) sont la norme et qu’il n’est qu’une métastase dans un monde ou Linux (donc les serveurs) et OSX l’ont déjà par défaut.
Vu les perfs des processeurs en calculs flottants de nos jours (évidemment il faut bien coder le truc. A noter que les polices vectorielles s’appuient sur des B-splines dont il existe des algos très efficaces, je suis pas sur que ce soit si visible en dehors de pages pathologiques).
Ce qui encore plus important, c’est les optimisations des structures de données pour justement optimiser ses accès. Et là, tout les softs sont rarement bons sur ce point.
Il serait plus pertinent de comparer la puissance électrique / flops pour avoir une idée. Parce que tu ne fais pas la même chose avec 286 et un i7.
Idem, ton atari n’a pas de NVMe, ni d’USB 3.0.
J’approuve !
Je suis d’accord avec toi, en particulier sur le dernier point.
#21.2
Pluzun.
#22
Oui, ça serait bien plus simple …
Ce n’est pas visible normalement sur nos ordis. C’est juste pour souligner pourquoi nous avons besoin de cette puissance de calcul actuellement - et le côté très avancé de ce qui se passe quand on regarde u page web, ce que certains considèrent comme une fonctionnalité “basique” mais qui demande plus de calcul que d’anciennes bases de données…
+1
Les boucles qui recherchent dans un résultat SQL la valeur d’une colonne en indexant par le nom de la colonne. ou comment faire 500 cycles CPU à chaque ligne là où deux indirections et 10/2à cycles suffiraient.
Tout dépend de ce qu’on appelle “la même chose”. Pour taper une lettre, c’est pas kif/kif, mais au final la lettre sera tapée.
Je parle de l’efficacité “métier”. Et dans ce domaine, les interfaces graphiques puis le web ont fait énormément de mal.
Mais mon PC n’a pas de disquettes :)
Dernier point, et pas des moindres: quand on parle de PC “inutilisable” (exemple: les PC donnés au lycée), je ne suis pas d’accord. Ces PC sont utilisables MAIS ils sont soumis à l’environnement sécuritaire actuel: faire une tâche sur ces PC (consulter les manuels, internet, faire un document ou du python) n’est pas désagréable. Par contre, la faire quand l’antivirus se lance, c’est dur.
Nos PC passent beaucoup de temps à:
Et là la perf peut faire très mal: un celeron qui doit revérifier 80Go de documents compressés avec les nouvelles définitions de virus y passe quelques petites heures…
Il n’y a qu’à voir le problème en début d’année: téléchargement d’un manuel de 1Go en PDF: à chaque écriture sur le fichier en téléchargement, l’antivirus se redéclenche et revérifie le fichier (le bloquant au passage), et ça prend 10h pour télécharger. Couper l’antivirus le temps du téléchargement et TADA! c’est fini en quelques minutes…
C’est la même chose sous Android: démarrez une vieille tablette de 7 ans (ma shield K1): elle va mettre 5 bonnes minutes à être utilisable, le temps que Android recompile les apps et que le playstore revalide via play protect tout ça (et il y a 48 apps en tout…)
Bref, incriminer le chiffrement, c’est un peu comme dire qu’il y a une ampoule cassée sur un véhicule qui s’est encastré dans un mur je trouve.
La dépense d’énergie est lié à notre utilisation qui a amené risques sécuritaires, surcouches, implémentations douteuses et “besoins” farfelus poussez par un marketing aggressif.
#23
Je ne suis pas experte en SQL donc je m’avancerai pas sur ce point. Par contre, les indirectons je m’en méfie. J’ai connu des codes de calculs (le code qui a besoin de 34 000 cores) qui souffraient justement des indirections car ça pétait les caches CPUs en permanence. Sur le papier, l’idée était très bonne mais en pratique, l’approche plus “naïve” était finalement la plus rapide.
Autant pour moi, j’ai mal évalué le critère.
C’est un énorme sujet. Mais entre marketeux, politiciens et crétins de consommateurs nous n’y sommes pas rendu. Les 3 cavaliers de la conneries pour lutter contre le réchauffement climatique… Autant demander à Trump d’avoir le prix Nobel de physique.
#24
Je croyais qu’une des inquiétudes sur les blockchains était qu’une entité puisse en prendre le contrôle en alignant suffisamment de puissance de calcul (si une entité détient >50% de la puissance, elle contrôle le réseau), la preuve d’enjeu ne facilite-t-elle pas cela ?
Si je comprends bien l’intérêt en efficacité du réseau, c’est également la sacralisation du “les riches deviennent plus riches” inscrite dans le fonctionnement même du système ou j’ai mal compris ? On pourra bien sûr arguer que monter une ferme de GPU demande en soi un capital de départ, mais ça me paraissait moins ostentatoire.
#25
Je me souviens de mon cours de cryptographie, 1ère heure, le formateur nous expliquait que la maitrise de la crypto c’est la maitrise du (pseudo)aléatoire. Que la première chose à faire pour estimer la qualité d’un chiffrement était d’essayer de compresser le résultat. S’il est compressible, alors c’est le (pseudo)aléatoire est mal fait et donc le chiffrement faible.
Donc pour être efficace, la compression doit être faite avant le chiffrement, mais ça, c’est un point à prendre en compte dès les premières phases de conception.