Le 21/04/2024 à 09h 31

Le 20/04/2024 à 12h 21

Ben non, ce n'est pas une déclaration officielle. Ce n'est pas comme ça que ça marche. Et en plus c'est dans un contexte où il se défend de tweeter pour donner de l'importance à Twitter, il a tout intérêt à minimiser l'impact de ceux-ci.

Je n'ai pas dit que c'était une déclaration officielle, mais une information officielle. Information officielle = information qui émane d'une source officielle. E. Musk, en tant que CTO de X constitue une source officielle.

Je t'ai littéralement donné la source exacte de la citation tronquée du huff traduite par next...

Je n'avais pas pris le temps de comparer avec l'article du Huffpost. C'est maintenant chose faite. Et effectivement, je confirme donc mes dire : la traduction induit à surinterpréter les propos de Musk. Je vais le signaler à la rédaction ;)

Le 19/04/2024 à 11h 26

Ce n'est pas une information officielle, non.

Le PDG d'une boite ne constitue donc pas une information officielle concernant ladite boite ?

Il parle de ses tweets. Il explique que ses tweet ont probablement un impact négatif sur Twitter. Il ne parle pas de la gestion de l'entreprise et de la santé financière globale.

Comme dit dans la brève, "Il a par ailleurs déclaré « avoir potentiellement davantage contribué à affaiblir financièrement » le réseau social X, qu’il a racheté fin 2022, qu’à l’améliorer.". Est-ce le même passage ou pas, je ne sais pas. Il est vrai que si c'est le cas, la traduction induit un biais menant le lecteur en erreur, dans la mesure où l'usage de "contribuer à" signifie qu'il a joué un rôle dans l'affaiblissement financier, et donc que l'affaiblissement est confirmé.

Quoi qu'il en soit, et tu peux dire que j'y vois ce que j'ai envie de voir, couplé avec des observations extérieurs et certains chiffres données par X même (baisse de 30% du nombre d'utilisateurs actifs en 1 an), c'est un aveu (ou semi-aveu en fonction du possible biais de traduction dont j'ai parlé plus haut) de la part du CEO de X. C'est quand même loin d'être rien.

Le 16/04/2024 à 11h 13

A la fois d'accord et pas d'accord.

Sur le principe du ragot, je suis d'accord. Mais je trouve ici que la brève va plus loin que le simple ragot. On a une information officielle (et pas simplement celle d'un observateur extérieur aussi sérieux soit-il) qui annonce clairement que suite au rachat par E. Musk de Twitter, Twitter s'est affaibli financièrement.

Il y en a encore qui pense que X se porte pour le mieux depuis le rachat. Là, cela va être difficile de prétendre le contraire, dans la mesure où c'est E. Musk lui-même qui avoue cet état de fait.

Le 19/04/2024 à 09h 25

Et le mantra de Google à ses débuts étaient... "don't be evil" ;)

Je me souviens parfaitement de Facebook annonçant que Facebook resterait gratuit. Mais il ne faut pas se leurrer. C'est une entreprise, et s'il y a une chose que Meta a su prouver jusqu'à aujourd'hui, c'était qu'elle était loin d'être philanthropique. Le jour où cela coutera plus à Meta de rester en Europe que d'en partir, l'annonce du "gratuit pour toujours" tombera vite dans les oubliettes.

Ce genre de promesse n'engage que celles et ceux qui y croient ;) (à moins que ce soit dans leur CGU, marqué comme un article irrévocable, mais j'avoue que j'ai la flemme de lire les CGU les plus longues et les plus incompréhensible du monde pour trouver ça !).

Le 18/04/2024 à 14h 12

Max Schrems, son président, affirme que « dans l'ensemble, Meta n'a plus le choix dans l'UE. Elle doit maintenant donner aux utilisateurs une véritable option oui/non pour la publicité personnalisée. Elle peut toujours facturer les sites pour le reach, s'engager dans la publicité contextuelle et d'autres activités similaires, mais le suivi des personnes à des fins publicitaires nécessite un "oui" clair de la part des utilisateurs ».

Meta dispose encore d'autres choix, comme :
- fermer purement et simplement Facebook en Europe ;
- rendre Facebook totalement payant en Europe.

Irréaliste diront certains. Pourtant, à force de tout faire (à tort ou à raison, là n'est pas la question) pour remettre en cause le modèle de rémunération actuel, le jour où la balance entre ce que coûte un utilisateur non payant (les serveurs, la modération, les espaces de stockages, les tuyaux, etc. ce n'est pas gratuit) et ce qu'il rapporte sera en la défaveur de Facebook, c'est bien ce qui pourrait arriver, car il faut bien garder en tête que la publicité non ciblée paye beaucoup moins que la publicité ciblée.

Le 19/04/2024 à 09h 10

L'archivage ne suppose absolument pas une séparation des données dans des base de données différentes. L'archivage consiste à marquer des données qui ne sont plus utiles pour un objectif précis, afin d'en restreindre l'accès et l'utilisation. Mais absolument pas à retirer de la base des données pour les mettre dans une autre (même si cela reste une possibilité).

Classiquement, on distingue 3 états de la donnée :
- en base active : les données sont encore utiles pour l'objectif fixé (par exemple, l'état d'une commande)
- archivage temporaire : les données ne sont plus utiles pour l'objectif fixé (par exemple, la commande est livrée depuis 1 mois). Toutefois, les données peuvent devoir être conservé pour la gestion des litiges, répondre à des obligations légales, etc.
- archivage définitif : il s'agit de données qui ne répondent plus à des enjeux légaux, contentieux, ... mais qui conservent une valeur "stratégique" pour l'entreprise. Depuis le RGPD, la conservation définitif de données à caractère personnelle est généralement impossible (je ne connais aucun cas où cela serait justifié, mais cela doit bien pouvoir se trouver).

Ces 3 états se distinguent par une accessibilité décroissante, mais absolument pas par une séparation physique du stockage (même si, une fois encore, cette séparation peut être mise en oeuvre).

Le 18/04/2024 à 08h 33

Pour les factures, si ce n'est pas de l'archivage probatoire (en PDF par exemple), c'est stocké dans les entêtes de facture, pas besoin du compte client pour ressortir ce type de documents. Heureusement d'ailleurs, car une modification du compte client entre 2 éditions modifierait la facture

On est d'accord ;) Mais pour répondre aux demandes d'accès imposées par le RGPD, c'est beaucoup plus simple pour l'entreprise de conserver le compte client que de ne conserver que les factures ;)

Le 17/04/2024 à 16h 44

Concernant la présence de personnes désinscrites, ce n'est pas forcément complètement déconnant, même si cela semble aller à l'encontre du RGPD.

Déjà, désinscrites ne signifie pas compte clôturé. On peut avoir un compte "actif" mais être désinscrit de toutes communications.

Ensuite, en tant qu'entreprise, le Slip Français se doit de conserver certains éléments, notamment tout ce qui à trait à la facturation pendant au moins 10 ans (c'est la loi). Que des informations comme les nom, prénom, adresse soient encore stockées n'est donc pas forcément étonnant. De même que le mail peut être utilisé pour répondre aux demandes d'accès aux données personnelles sans forcément avoir besoin de demander de pièces justificatives.

Donc même si certaines personnes n'ont pas eu de contact depuis 2018, si ces personnes avaient commandé sur le Slip Français, il est normal que le Slip Français ait encore des informations les concernant.

On peut bien sur s'interroger sur d'autres aspects, comme la minimisation des données, ou le fait que certains désinscrit se sont soudainement mis à recevoir de nouveau des sollicitations publicitaires, mais cela n'a rien à voir avec la fuite de données à proprement parler.

Le 18/04/2024 à 10h 43

+100000

C'est un peu le côté que je déplore aujourd'hui. "Si tu n'es pas avec nous, tu es contre nous". Les positions intermédiaires (du genre, je m'en fiche royalement) sont complètement passées sous silence.

Le 17/04/2024 à 10h 36

Il existe plusieurs types de trou noir. Celui au centre de la voie lactée n'est pas un trou noir stellaire, mais un trou noir supermassif.

Il est bien précisé que Gaia BH3 est le trou noir stellaire le plus massif jamais découvert dans la Voie Lactée ;)

Le 17/04/2024 à 10h 15

Je me demande bien ce que tu as pu commander, car je constate l'extrême inverse.

J'arrive à "user" certains de leur vêtement, mais :
- il me faut du temps
- je fais du sport avec (notamment de la course à pied, où il m'arrive de partir pendant 2h)

Chaussettes et boxer tiennent bien le choc. Il me fait plusieurs semaines d'utilisation intensive pour mettre à mal une paire de chaussette par exemple, alors que le premier prix chez Carrefour, c'était 3j. Les chaussettes ont tendances à se percer, et les boxer, ce sont les coutures qui ont tendance à lâcher.

T-shirt : en tondant, je me suis accroché à un barbelé de la clôture. Bilan : T-shirt intact, alors que ma première pensée était de gueuler car le T-shirt était neuf et je pensais qu'il était foutu.

Pantalon : rien à dire jusqu'à aujourd'hui. Cela fait plusieurs années que j'en ai certains, ils n'ont pas bougé d'un yota.

Le slip français, c'est peut être cher à l'achat, mais pour moi, c'est rentable sur le long terme tant j'achète moins de vêtements.

Le 15/04/2024 à 18h 17

Il est effectivement possible de faire de la double licence (comme Qt que tu cites fort judicieusement).

Sauf que le choix de la licence à utiliser ne revient pas à l'auteur, mais à l'utilisateur :
- s'il peut distribuer son programme en respectant les termes de la licence GPL, il peut prendre la GPL ou la licence alternative, et l'auteur n'a rien à redire là-dessus
- s'il ne peut pas distribuer son programme en respectant les termes de la GPL, il ne dispose alors que de la solution de secours via le double-licensing.

Pour Qt, cela se traduit grosso modo par :
- si tu utilises Qt, que tu as apportés des modifications à la bibliothèque, alors soit ces modifications doivent être disponible en LGPL, soit tu dois acquérir la licence alternative
- si tu utilises Qt, que tu as apportés des modifications à la bibliothèque mais, que pour des raisons diverses, tu ne peux pas les rendre disponible en LGPL (utilisation d'une bibliothèque avec une licence incompatible avec la LGPL, code métier spécifique présentant une plus-value et devant resté confidentiel, etc.) alors tu dois acquérir une licence.

Le 15/04/2024 à 18h 00

C'est une problématique similaire avec les nouvelles licences qui sont apparus pour les services utilisées massivement dans le cloud (MongoDB, Redis, Elastic Search, ...). Les nouvelles licences veulent dire (comme la SSPL), c'est du libre, sauf en cas d'utilisation en SAAS. Sauf qu'en réalité, ce n'est donc plus du libre.

Pour faire simple : une licence libre avec une clause "sauf si" dans le cadre de la jouissance d'une des 4 libertés fondamentales qui constitue le libre, n'est plus libre.

Le 15/04/2024 à 16h 59

Si le logiciel est libre, alors le fork doit fournir ses sources et mentionner le copyright de l'auteur original. Il semblerait ici que cela ne soit pas le cas.

Cela dépend des licences. Mais dans le cadre de la GPL v2 oui. Après, je n'ai pas d'iBidule pour aller vérifier (et de toute façon, l'application a été retirée).

Sinon l'affaire est juste un peu dégueulasse de la part du forker qui profite du travail d'autrui à peu de frais mais c'est effectivement la règle.

On est tout à fait d'accord. C'est d'ailleurs bien à cela que je réagissais quand je voyais que l'auteur n'en voulait pas au forkeur, mais à Apple.

C'est légal (si les conditions de la licence sont respectées comme la conservation du copyright), mais pas très moral...

Le 15/04/2024 à 16h 52

Cette restriction me semble inefficace. Elle l'aurait été s'il avait faite dans la même phrase et encore, je n'en suis pas sûr.

Même pas. La GPL interdit toute restriction, sous quelque forme que ce soit, dans la distribution. On a donc :
- soit le code est sous GPL, et il n'est pas possible de restreindre la diffusion (sa limitation ne tient donc pas)
- soit la diffusion est restreinte, mais son code ne sera pas sous GPL (ni même une quelconque licence libre).

Les deux sont purement et simplement incompatibles. Tout au mieux, on pourrait dire qu'il fait un dérivé non libre de la GPL (et encore, pas sur que cela plaise à la FSF de dire cela )

Le 15/04/2024 à 14h 53

Le développeur s’est fendu d’un message sur Threads : « Apparemment, Apple a approuvé une contrefaçon de GBA4iOS – le prédécesseur de Delta que j'ai créé au lycée – dans l'App Store. Je n'ai donné à personne la permission de le faire, et pourtant il est maintenant en tête des classements (bien qu'il soit rempli de publicités et de suivi) ».

Il a ajouté qu’il n’était pas en colère contre le développeur, mais bien contre Apple : « Je suis furieux qu'Apple ait pris le temps de modifier les règles de l'App Store pour autoriser les émulateurs, et qu'elle ait ensuite approuvé une copie de ma propre application, alors que j'étais prêt à la lancer ».

Plusieurs choses (punaise, voilà que je défends Apple maintenant...) :
- Apple a approuvé une contrefaçon de GBA4IOS : impossible de parler de contrefaçon. Le logiciel est libre (sous GPLv2) et le nom a été changé.
- Je n'ai donné à personne la permission de le faire : et si, en mettant le logiciel sous licence libre, chaque utilisateur peut le redistribuer comme il l'entend. Un utilisateur n'a AUCUNE permission à demander à l'auteur (sinon, le logiciel ne serait pas libre)
- est-ce à Apple de vérifier si, pour chaque application Open Source, le titulaire des droits (dans la limite de ce que cela peut bien signifier) a pour objectif ou non la publication d'un application pour vérifier si un fork soumis doit être accepté ou non ? Pour moi, non.

Je serai Riley Testut, je serai bien en colère contre l'auteur du fork, et pas contre Apple. Son projet est effectivement parasité, et la présence de publicités et de trackers dans la version distribuée plaide pour une action plutôt volontaire voire malsaine et non pas pour un acte de quelqu'un d'un peu trop passionné ne pensant pas à mal.


Voilà, sinon, un point de détail : le dépôt actif semble être celui sur bitbucket. Celui sur github est archivé.

Le 15/04/2024 à 11h 38

En fait, ce n'est pas un LLM à 1 bit, c'est une variante d'un LLM à 1 bit. La valeur ternaire se retrouve encodée sur 1,58 bits, d'où le nom. On peut retrouver l'article sur arxiv.org (en anglais).

Le 15/04/2024 à 09h 42

En quoi n'est-ce pas possible ? Un changement majeur niveau noyau n'implique pas forcément un changement des API exposés.

Le changement de noyau NT reflétait surtout une modification profonde de la manière de communiquer avec le matériel. De manière très simpliste (car c'est loin d'être le seul changement mais sans doute le plus significatif), avant NT, les drivers pouvaient accéder directement au matériel (en by-passant complètement le noyau donc), ce qui n'est plus le cas avec NT.

Winapi, première version, date du 20 novembre 1985 d'après Wikipédia et existait bien avant le noyau NT.

Il ne faut pas confondre le noyau (qui gère entre autre le matériel) des API exposés pour les programmes.

Le 13/04/2024 à 10h 08

On est d'accord sur un manque de documentation. Ce n'est pas pour rien que plusieurs équipes ont fait la même erreur.

Cela n'en constitue pas pour autant une faille dans l'API Windows.

Le 13/04/2024 à 00h 59

Parce que tu fournis une ligne de commande à analyser (parser) plutôt que de fournir le résultat de cette analyse ? Résultat que tu connais car au final, d'un point de vue programme tu connais les paramètres du programme que tu appelles.

Cela passe pour un shell, où l'utilisateur entre des commandes, mais pas pour des APIs bas niveau.

La question est de savoir si les paramètres du ligne de commande sont nécessaires au système d'exploitation ou pas. La réponse est non. L'OS à juste besoin de savoir le programme à lancer, et les paramètres à passer, mais n'a pas à connaitre la structure des paramètres (tableau ou ligne).

Sous Linux, le choix a été fait d'organiser les paramètres sous forme de tableau. Sous Windows, c'est une chaine de caractère. Les deux sont tout à fait viable et ont de subtiles différences.

Et je ne vois pas le souci d'espaces dans la façon Linux : tu passes juste un tableau de chaîne de caractères (terminées par le caractère NUL). Le fait de vérifier la taille max de l'ensemble n'est pas plus coûteux : vu la différence de temps de lancement entre Linux et Windows (plus lent), ce n'est certainement pas ça le plus coûteux !

Je ne parlais de la complexité en terme de temps de calcul, mais de la complexité d'avoir un algorithme correcte. Et j'avoue ne pas trop voir en quoi le temps de lancement vient jouer un rôle ici. On parle des paramètres des programmes. Cela n'a strictement rien à voir.

D'une part, la façon de faire de WIndows introduit des problèmes d'analyses vu que les règles sont difficiles à utiliser (je dis ça d'expérience de batch),

Jusqu'au jour où on va se rendre compte que linux a en fait potentiellement le même problème, car quand un script est exécuté, l'interpréteur est déterminé via le shell bang. Chaque interpréteur peut avoir des règles d'échappements différents. Du coup, là aussi, on accusera Windows ?

Or, il s'agit bien de ça : Rust a une faille critique à cause de cette façon de faire qui nécessite un travail compliqué, mal compris et pour rien

Pas pour rien non. Quand les systèmes sont différents, il faut bien palier les différences. C'est le rôle du pattern adapteur ou d'un wrapper en programmation. Mais parfois c'est compliqué oui. Comme ici.

Le 13/04/2024 à 00h 19

Oui Rust, Java & co doivent trouver une manière correcte pour contourner cette limitation de Windows. Mais pas seulement, c'est a peu près certain qu'on trouve dans le monde des dizaines de milliers de failles à cause de cette limitation problématique et difficilement compatible avec la manière dont la fonction main est spécifiée dans la plupart des langages (les argument sont une liste de string, pas une string)

Quitte à me répéter, les premières versions de l'API Windows sont sorties avant pas mal de standardisation, dont celle du C (dont le premier standard remonte à 89 rappelons le). Si les points d'entrées ont été mis à jour depuis et que Windows accepte aussi le point d'entrée actuellement répandue (autrement dit, la fonction main), beaucoup des choix techniques de l'époque ont perduré pour des raisons de compatibilité (car oui, Windows possède une API extrêmement stable, contrairement à ce que l'on trouve dans les environnements Linux). Mais pareil, il n'y a pas de solution quoi meilleure que l'autre Les deux ont des avantages et des inconvénients.

Et une fois encore, ce n'est pas une limitation de Windows. C'est une problématique entre un environnement POSIX et un non POSIX. C'est radicalement différent.

Si, il y a une approche correcte, qui maintient la sémantique de la liste d'arguments sur toute la ligne, de la commande ou du script jusqu'à la fonction main du programme, et une approche fondamentalement problématique et qui encourage les failles de sécurité, mais qui marchotte à peu près avec des hacks et des contournements.

Sérieusement ? Appeler ce qui relève d'un adapteur ou d'un wrapper un hack ? Sinon, certains langage n'avaient pas la notion de tableau d'arguments, mais bien d'une ligne : BASIC, Fortran à partir de 2003 (bon, qui propose les deux approchent :p), mais qui n'avait aucun mécanisme standard avant. Il me semble que COBOL permet les deux aussi. Et je suis loin de connaitre tous les langages.

Le problème est que tu considères la sémantique de la liste d'arguments comme allant de soi et étant une obligation aujourd'hui. Même si c'est très répandu, c'est loin d'être toujours le cas.

Le fait que les langages de programmation aient repris cette sémantique indique bien que tout le monde considère ça comme la manière correcte la plus pratique de faire.

Ma correction.

Sinon, cette faille est du même acabit qu'une injection SQL qui serait exploitable car le connecteur à la base de données, sensé protéger via l'utilisation de requêtes paramétrées, fait mal son boulot. Est-ce qu'on dit pour autant que ce sont les SGBD qui sont troués ? Ou les API qui sont mal utilisées ?

Le 12/04/2024 à 21h 46

Le standard sur lequel s'appuie Rust est celui de GNU C, pas "Linux" (qui est un noyau). Rien de bien nouveau, et qui à défaut d'être une norme, est un standard d'interopérabilité.

Qui plus, un vieux standard : on ne parle pas de dernière fraîcheur.

Pour être plus précis, le standard derrière s'appelle Posix (et pas GNU C). Sauf que l'API Windows existe 1985, POSIX depuis 1988. Windows ne respecte donc pas un standard qui n'existait tout simplement pas l'époque des premières versions du système d'exploitation.

Les langages doivent donc adopter un comportement particulier pour ce système d'exploitation particulier. D'aucuns dirait que c'est bien le système d'exploitation le problème.

C'est le principe de la bibliothèque standard de chaque langage. Quand tu as un langage dont l'API est proche de Posix, c'est plus simple à développer sur un système Posix que sur un système non Posix.

Le fait que plusieurs personnes se sont cassées les dents et qu'il y ait une faille à ce sujet aujourd'hui montre 2 choses :
- écrire une implémentation d'une API standard, ce n'est pas quelque chose de trivial
- un manque de documentation de l'API Windows.

Mais cela ne signifie pas que l'API présent une faille comme beaucoup le pense.

Le problème aujourd'hui touche uniquement Windows car :
- les systèmes à base de Linux (distribution classique, Android, etc.) respectent plus ou moins le standard POSIX
- les BSD respectent plus ou moins POSIX
- MacOS (basé sur BSD) respect plus ou moins POSIX

En fait, Windows est le seul système d'exploitation "grand publique" qui ne soit pas Posix de nos jours.

Une n-ème démonstration que l'habitude de M$ de produire du non-standard crée un/des risque(s) pour les utilisateurs de leurs produits

Comme dit plus haut, le standard n'existait pas à l'époque des premières versions de Windows.

Le 12/04/2024 à 21h 25

Et pour le coup, si Windows ne fournit pas l'API pour éviter (car il s'agit de ça au final) de prendre les paramètres et de recréer une ligne de commande, alors oui Windows est responsable de la situation.

Ben non, pas d'accord. En quoi c'est une situation à éviter ? Ce sont des choix, différents (ce que je souligne depuis le début), et c'est de cette différence que vient le problème.

Et les deux ont aussi des différences en dehors du caractère d'échappement. Il est beaucoup plus simple avec l'approche de Windows de vérifier la taille max des arguments de la ligne de commande (alors que sous linux, il faut la reconstituer, sans oublier de compter les espaces !). Car oui, il y a une taille max !

De même, l'approche utilisée par Windows préserve les espaces. S'il y a besoin de 3 espaces entre deux arguments, c'est possible de le faire sous Windows, pas sous Linux.

Encore une fois, il n'y a pas une approche qui soit meilleure qu'une autre. Ce sont juste 2 approches différentes.

Le 12/04/2024 à 17h 51

J'ai regardé l'article de blog cité pour plus de détails techniques.

Alors non, le problème ne vient pas de Windows. Le problème vient de la différence de comportement entre le monde Unix et le monde Windows (plus particulièrement, les caractères d'échappement à utiliser lors de la création d'un processus, où, sous Linux les spawn, popen, etc. utilise le backslash tandis que CreateProcess (l'API WIndows donc) utilise le caret (^).

Le fait que la même erreur ait été faite par plusieurs équipes distinctes dans plusieurs langages n'en fait pas un problème de Windows. Quand on appelle mal une API, il ne faut pas rejeter la faute sur l'API.

Des comportements Unix ont été calqués sur Windows, et après on vient dire que c'est de la faute de Windows. Le problème aurait tout aussi bien pu être dans l'autre sens, et là, personne n'aurait remis en cause Linux.

Comme expliqué dans l'article, on peut regretter que la communication soit axée sur Rust alors que la faille touche de nombreux langages. C'est juste que la faille a été découverte via Rust en premier.

Le 12/04/2024 à 09h 29

Aussi il faut se mettre a la place de l'utilisateur lambda : l'OS pas maintenu sur le téléphone ne donnera lieu à aucune notification donc pas d’inquiétude, par contre pour Windows en plus des notification il y aura surement un passage au JT et différents sites d'actualités donc inquiétude.

Justement, c'est bien ça qui me chiffone. Microsoft est transparent et averti longtemps avant, et se prend plein de skud sur le sujet.

Par contre, si on met tout sous le tapis, personne n'en parle, même si les pratiques sont encore pire

Le 12/04/2024 à 08h 57

Il te suffit d'aller dans les paramètres > Windows Update > et de cliquer sur "Obtenir un bilan de santé du PC".

Tu auras toutes les démarches nécessaires ;)

Cela va te permettre d'ouvrir (ou d'installer avant si besoin) l'application de contrôle d'intégrité du PC. Tu as un encart qui correspond à Windows 11. Si tu cliques sur "Vérifier maintenant", tu sauras si ton PC est compatible ou pas, si non, pourquoi.

Le 12/04/2024 à 08h 51

Ou sinon, on reste sous Windows 10 sans support. C'est sur, c'est pas top d'un point de vue sécurité, mais c'est déjà ce qui est fait aujourd'hui avec les smartphones et personne ne s'en plaint. Donc, à mon avis, beaucoup le feront.

Surtout que la fin du support de signifie pas que cela ne fonctionnera plus du jour au lendemain. Quand on voit la durée de vie de XP, il y en a encore pour des années. Ce qui a vraiment "motivé" les derniers récalcitrants à changer, c'est les applications qui ne supportaient plus XP, à commencer par les navigateurs.

Vu la part de marché de Windows 10 sur Windows 11 actuellement (pour les Windows installés, grosso modo 70% de Win10 contre 30% de Win11), je vois plusieurs possibilité :
- Microsoft fait comme XP : la durée de vie a été étendue à plusieurs reprises
- Microsoft a continué de réaliser des mises à jour de sécurité lorsqu'il s'agissait de failles critiques (jusqu'en 2019 je crois) alors que le support de XP SP3 date de 2014 (date de support étendu !).
- Microsoft autorise l'installation de Win11 sur des PC "non compatible", en désactivant certaines fonctionnalités (comme celles requérants la présence d'un TPM)
- Microsoft ne fait rien. La part de Windows 10 restera tout simplement importante.

Après, les gens peuvent aussi réfléchir 2s. Sur les portables, c'est un point plus compliqué (je le concède), mais sur les tours, rajouter un module TPM à la carte mère est souvent possible pour un coût dérisoire (quelques dizaines d'€). Donc quand je lis que les entreprises devront changer leur parc informatique, c'est surtout que ces entreprises devraient changer d'équipe informatique. Sans compter le nombre d'équipement en réalité matériellement compatible, dont une fonctionnalité est désactivée dans l'UEFI (coucou le TPM).

Microsoft n'a pas changé les prérequis matériels depuis au moins Windows Vista (oui oui, Vista !). La migration d'une version à l'autre est gratuite depuis Windows 7. Des versions successives de Windows auront donc eu comme prérequis la même configuration matériel pendant près de 20 ans ! 20 ans, c'est trèèèèès long en informatique.

Ca me tue aujourd'hui de lire que Microsoft fait de l'obsolescence programmée avec Windows 11, alors que justement, de ce point de vue, c'est un des acteurs privés qui fait le plus d'effort à ce sujet, bien loin devant ses confrères des GAFAM comme Apple.

Enfin, les gens auront le choix, c'est aussi à eux de prendre leur responsabilité :
- continuer d'utiliser Windows 10, sans support donc
- installer un OS alternatif
- changer de matos

Donc non, Microsoft n'oblige pas a changé son matériel. Les utilisateurs ont juste un choix à faire. Mais est-ce qu'ils se posent la question alors que leur téléphone n'a pas reçu de mise à jour depuis 2 ans ?

Le 11/04/2024 à 14h 03

D'autres ne sont pas de cet avis apparemment. En résumé : baisse du nombre d'utilisateurs de 30% en 1 an. Pas certains que l'on puisse dire que ce réseau social se porte bien du coup.

Le 11/04/2024 à 11h 30

Toutes les fortes variations sur unknown sont en fait des Windows non reconnus.

On distingue que ChromeOS est aussi impacté par ces pics. Une baisse de Chrome OS se traduit souvent par une hausse de Unknown. Il y a souvent un pic correspondant avec Windows presque au même instant, mais parfois un peu décalé (ce qui rend très difficile toutes interprétations).

Il faudrait analyser les données brutes pour aller plus loin...

Le 11/04/2024 à 11h 23

Oui, je suis plutôt d'accord avec ta conclusion.

Maintenant, Windows, même si pas parfait, à un mécanisme de mise à jour plutôt bien rodé, dans le sens où si ça foire, il arrive à revenir tout seul dans une situation stable dans la grande majorité des cas. Ca fait même des années que je n'ai pas eu à "réparer" un Windows manuellement après une mise à jour en erreur (depuis Windows 7).

Sous Linux, je ne comptais plus les kernel panic (parce qu'il manquait un argument au boot par rapport au modèle du portable ou que le nom du périphérique de boot avait changé par exemple), au DE qui ne démarrait plus, quand ce n'était pas purement et simplement X/Wayland après une mise à jour. Bref, sous Linux, j'avais toujours un live CD dans un coin pour réparer ma bécane en cas de problème

Le 11/04/2024 à 11h 14

Avec un graphique comme ça, j'ai tendance à me dire que les crêtes sont simplement des erreurs dans la détermination des OS (surtout que c'est avec Unknown).

Il y a tellement de chose qui peuvent influencer la détermination de l'OS, a commencer par le UserAgent. Il suffit donc qu'il y ait une mise à jour d'un navigateur ou de l'OS pour générer ce genre de pic.

Le 11/04/2024 à 10h 37

Comme quoi on a tous des ressentis différents. Je suis aussi un adapte du ça marche, c'est stable, c'est cool. Du coup, c'est à cause de ça que je suis repassé sous Windows, après une nième mise à jour de Linux qui avait flingué ma machine, et j'avais la flemme de passer encore des heures à résoudre le problème.

Et si au début, ça m'a fait un peu bizarre de repasser à windows, j'ai bien moins de soucis à gérer avec les mises à jour depuis.

On est d'accord que ça me fait chier aussi les mises à jour imposées. Mais dans un sens, c'est pas plus mal, car c'est bien le genre de truc que je suis capable de dire plus tard, plus tard, plus tard et de remettre cela beaucoup trop longtemps.

Windows n'est pas parfait (loin de là), mais ça m'a fait gagner du temps.

Le 11/04/2024 à 10h 11

Avant tout je suis néophyte. Pour mon regard naïf (de néophyte donc) ça me semble relativement simple :-)

Rien n'est simple en mécanique ondulatoire, et encore moins lorsqu'il s'agit d'électromagnétisme ;) Regarde le principe d'interférence des ondes électromagnétiques, comme l'expérience de Young par exemple.

Wikipedia écrit exactement l'inverse :

Wikipédia parle des ondes en général. Ce qui est vrai à première vue pour les ondes mécaniques (avec support, comme le son par exemple) ne l'est pas forcément pour les ondes électromagnétiques et inversement.

Pour réaliser des interférences électromagnétiques, il faut que les deux sources soient en cohérence spatiale et temporelle.

Et cela ça nécessite des conditions très strictes. Les interférences, au sens ondulatoire du terme, on ne l'atteint à ce jour que par des lasers (à ma connaissance). Et encore, il faut que les 2 faisceaux qui interfèrent soient issus du même laser (sinon, il n'y a pas la cohérence temporelle, donc pas d'interférence).

On y arrive avec des constellations satellites de GPS en mouvements espacés de plusieurs milliers de km, pourquoi ne pourrait-t-on pas le faire pour des antennes séparées de quelques cm ?

Parce que ce ne sont pas les mêmes besoins. Pour que le GPS fonctionne, il faut effectivement une synchronisation avec les satellites. Mais les besoins de synchronisation pour pouvoir réaliser des interférences lumineuses sont beaucoup, beaucoup plus importants.

Quand tu parlais d'antennes, je pensais antenne distance, pas sur le même pylône. Mais cela ne change pas grand chose en pratique, tant les conditions pour avoir des interférences lumineuses sont drastiques.

Si tu prends l'expérience de Young, et qu'au lieu d'éclairer chaque fente avec le même faisceau, tu l'éclaires avec 2 sources différentes (2 lasers identiques), tu observeras... l'absence d'interférence !

Bref, le beamforming, est utilisé, selon moi, pour avoir une diffusion anisotropique du signal. Cela permet de diffusion plusieurs signaux sur la même fréquence et en même temps, mais dans des directions différentes. Mais absolument par pour faire interférer des signaux provenant de multiples antennes comme tu le sous-entends dans ton commentaire #5.3 ;)

Le 11/04/2024 à 08h 48

De mes cours lointain, notamment en électromagnétique, pour que deux signaux puissent interférer (au sens ondulatoire du terme), il faut qu'il soit totalement synchronisé. Le caractère constructif ou destructif provient alors de la différence de phase.

La méthode pour que les 2 signaux soient totalement synchronisés, c'est qu'ils proviennent de la même source (attention, c'est uniquement le cas pour les ondes électromagnétiques, pour les ondes mécaniques, pas besoin).

Donc l'effet beamforming dont tu parles, est utilisé au sein de chaque antenne, pour envoyer un même signal avec plus ou moins de force en fonction de l'angle vis-à-vis de l'antenne, pas pour faire interférer des signaux d'antenne entre eux.

Pour pouvoir réaliser une synchronisation parfaite de 2 antennes différentes (et si c'est possible !), il faudrait déployer des moyens colossaux, à commencer par une synchronisation parfaite des 2 antennes. Un décalage ne serait-ce que d'1 microseconde et la lumière parcours 300m de plus ou de moins par rapport à ce qui était prévu, et c'est donc raté pour la synchronisation des signaux.

Même en descendant à 1 nanoseconde, (30cm), c'est encore beaucoup trop pour pouvoir faire de l'interférence ondulatoire entre 2 sources différentes.

Donc en fait, de ce que je comprends, l'effet beamforming, c'est pour que chaque antenne émette une onde qui ne soit pas la même en fonction de la direction de la diffusion. Ce n'est pas pour faire interférer les ondes d'antennes différentes entre elles.

Le 10/04/2024 à 16h 01

Demandons à Arthur! Il a participé à une table ronde sur l'usage de l'IA dans le cinéma (véridique ^^)

Le 08/04/2024 à 20h 24

Simple : aie aie aie xD

Le 08/04/2024 à 09h 47

Quand à l'oral, c'est ce qui se fait en étude supérieures avec les colles. Mais c'est une pression énorme pour les élèves, il y a une proportion non négligeable qui craque avant/pendant/après une colle. Alors que dans les fait, une colle c'est juste une interro orale, mais le côté "personnel"/"intime" est un énorme poids.

J'ai fait classe prépa, et je n'ai pas vraiment vécu les khôlles comme une contrainte ou ajoutant une pression énorme. La pression vient du rythme effréné entre les heures de cours, les heures de khôlles, les DS, les DM et les devoirs à la maison. Mais ce n'est pas les khôlles en particulier qui ajoute de la pression.

J'ai envie de dire au contraire même. Cela permettait d'avoir un moment privilégié avec un professeur (qui n'est pas forcément le sien !) pour poser des questions s'il y a un truc qui est mal compris ou pas clair tout en s'assurant d'avoir compris d'autres notions. C'est un bon point de validation, mais je suppose qu'on n'aborde pas tous de la même manière ce genre d'exercice, et cela dépend aussi du prof qui fait passer la khôlle (j'ai eu la chance d'être dans un lycée où l'ambiance était plutôt bonne, les profs aussi)

Le 07/04/2024 à 10h 39

Cela ferait un excellent sous-titre.

Et avec un autre derrière : on en a gros xD

Le 04/04/2024 à 09h 01

Je me suis posé la même question, et j'ai donc décidé de compléter ma lecture en allant jeter un oeil au rapport (dont le lien est dans la brève).

Microsoft sait certaines choses, mais pas d'autres.

Ce qui est su : l'attaque c'est déroulé via une clé de chiffrement volée. Le laxisme reproché à Microsoft à ce sujet concerne plusieurs points :
- la clé devait initialement être retirée en mars 2021 => la clé a été prolongée
- la clé ne devait servir que pour générer des tokens OWA (Outlook Web Access) => la clé pouvait aussi générer des tokens pour MSA (Microsoft Account Service). Il y avait donc un problème de séparation et une réutilisation de la clé
- la clé, au moment des faits, n'était plus sensée être utilisée. Cela aurait donc pu être détecté.
- ce n'est pas Microsoft qui a détecté l'attaque, mais des clients.

Ce qui n'est pas su : comment l'attaquant à eu accès à la clé de chiffrement. Microsoft a pourtant fait de longues investigations à ce sujet, allant jusqu'à établir 46 hypothèses, chacune vérifiée par différentes équipes de Microsoft. Aucune des hypothèses envisagées n'a pu être validée à ce jour.

Il s'agit là d'un grossier résumé d'une lecture en diagonale, mais qui, je l'espère, permet de mieux comprendre un peu les tenants et aboutissants de cette histoire.

Le 03/04/2024 à 18h 29

Si par distribution web, on entend bien la distribution direct en dehors de tout store (que ce soit celui d'Apple ou un store alternatif), alors, chez Apple, se sont des génies pour s'assurer une rente :

- Autre condition identique et « sévère », avoir une application dont le nombre de premières installations dans l’Union européenne a dépassé le million.
- pour exploiter la distribution web, les développeurs et éditeurs devront obligatoirement passer par les nouvelles conditions tarifaires.
- Problème, en cas de passage aux nouvelles conditions (réservées à l’Europe),la Core Technology Fee entre en piste. Celle-ci prévoit un paiement supplémentaire à Apple de 0,5 euro pour chaque nouvelle installation de l’application au-delà du premier million et en fonction des gains générés par celle-ci.

Autrement dit, de ce que je comprends, Apple vient de s'assurer que tout éditeur qui pourraient utiliser la distribution web se retrouve dans des conditions telles qu'il devra obligatoirement payer la Core Technology Fee. J'aurais presque envie d'applaudir si cela n'était tout simplement pas abject.

[edit]
Je viens de trouver un bogue. Si on met de multiples citations, il n'y en a qu'une seule qui apparait. J'ai modifié le message en conséquence.

Le 03/04/2024 à 14h 54

Je ne peux malheureusement qu'être d'accord...

J'ai en tête un prestataire de messagerie sécurisée pour la santé, qui malgré plusieurs incidents ces dernières années, n'a pas fait de déclaration, ni de communication auprès de ses utilisateurs.

Pourtant, des mails qui sont bien marqués comme envoyés mais jamais reçus par les destinataires, dans le cadre de la prise en charge de patient (données de santé), c'est bien une violation de données...

C'est pourtant pas compliqué de dire aux utilisateurs que "de telle date à telle date, les emails que vous avez envoyés ne sont pas arrivés à destination. Merci de les renvoyer."

Mais bon, je suis aussi prestataire. J'ai informé mon propre client, mais ne peut pas faire beaucoup plus, n'étant pas RT...

Le 03/04/2024 à 11h 45

Je partage ton ressenti sur les impacts en terme d'image. Les organismes pensent d'abord à l'impact sur leur image avant de répondre à leurs obligations légales.

Par contre, attention aussi : un incident n'est pas forcément une violation de données. Exemple : des données sont écrasées (erreur humaine), mais restaurable via des sauvegardes. Il y a une perte de disponibilité, mais temporaire, et qui ne rentre donc pas vraiment dans la définition d'une violation au sens propre, d'autant plus qu'un tel cas ne présente généralement aucun risque pour les personnes physiques (cf. article 33 paragraphe 1 du RGPD).

Car il est bon de le rappeler : la déclaration de violation de données est obligatoire en cas de risque pour des personnes physiques. S'il n'y a aucun impact, il n'y a pas de déclaration obligatoire (on peut toujours la faire, mais c'est facultatif). Mais il faut qu'il n'y ait aucun impact (je le remets en gras volontairement). S'il y a un risque, même faible, alors oui, la déclaration est obligatoire. Ainsi, une fuite de données, même chiffrées, est toujours à déclarer à la CNIL, car présente toujours un risque, aussi faible soit-il.

En cas de doute sur l'impact (par exemple, on constate une violation, sans pouvoir en définir pour l'instant l'ampleur, ni les données concernées, etc.) alors, dans le doute, il faut faire une déclaration préalable à la CNIL, que l'on viendra ensuite compléter au fur et à mesure.

Il faut aussi dissocier la notification à la CNIL de la communication aux personnes concernées. La première est une obligation dès qu'il y a une violation avérée. La seconde uniquement si la violation présente un risque élevé pour les personnes concernées (article 34).

Un autre argument que j'ai entendu, pour ne pas déclarer à la CNIL une violation, c'était la peur que cela déclenche un contrôle. Il faut savoir qu'il ne sera jamais reprochés d'avoir fait une déclaration "inutile", mais qu'il nous sera toujours reproché de ne pas avoir fait de déclaration. Et pour ma part, je serai à la CNIL, si j'ai le choix entre 2 organismes à contrôler, un qui fait des déclarations de temps en temps, un autre qui n'en fait jamais, je choisirai celui qui n'en fait jamais !

Le 02/04/2024 à 20h 08

Ce n'est pas propre à WSL. C'est le choix d'Ubuntu.

Et ça se comprend : cela permet d'éviter de devoir downgrader des paquets qui auraient comme dépendance une des versions infectées.

Le 02/04/2024 à 19h 53

J'ai du mal à voir si ce commentaire est ironique ou non.

Le 31/03/2024 à 15h 11

J'avoue ne pas savoir ce qu'il en est aujourd'hui avec les derniers modèles. Mais à une époque pas si lointaine, ils avaient ce genre de pratique oui.

Pour installer un lineageOS c'est simplement 8 étapes, rien d'insurmontable tous les liens sont là, pas besoin de googler quoi que ce soit en parallèle.

Rectification : rien d'insurmontable pour toi. Dans mon entourage, j'ai des personnes qu'il faut assister pour l'installation et/ou la configuration d'applications via le store. C'est clairement le genre de personne à qui je ne donnerait pas la documentation pour changer l'OS de leur tel.

Les choses ont peut être changées aussi depuis, car cela fait un certains temps que je n'ai pas fait de changement de ROM, mais j'avais grosso modo 1/3 des cas où cela se passe mal, et il fallait des compétences plus avancées pour résoudre le soucis. J'ai depuis, décidé d'arrêter (trop d'emmerdes et de sueurs froides !).

Et non, le problème ne venait pas de la documentation qui n'était pas suivi à la lettre, mais d'une documentation parfois incomplète ou erronée, et c'est souvent en conjuguant plusieurs docs ou en consultant les forums que j'arrivais finalement à faire l'installation. A l'époque, ce n'était pas Linéage, mais Cynogenmod.

Le 30/03/2024 à 16h 15

La seule compétence nécessaire est de lire l'anglais, car la doc est quasi tout le temps en Anglais.

L'anglais ne suffit pas. Il faut connaitre suffisamment son téléphone, savoir déterminer avec précision son modèle, choisir les bonnes versions des ROMs, les logiciels, la ligne de commande. Non, ce n'est pas trivial

ll n'y a pas vraiment de risque, si un flashage plante (câble pourri plus de batterie ou t'as sauté une étape), bah tu recommences :)

Tu parles de soft brick. Oui, en général, on peut s'en sortir (mais là, il faut généralement un peu plus de connaissance que simplement l'anglais).

Bien que plus rare de nos jours, il y a également le hardbrick. Et là, rien à faire, à part le jeter à la poubelle

Le flashage ne désactive rien du tout, tu peux à tout moment retourner sur l'image Stock et retrouver ton téléphone comme à l'origine.

Certains téléphones ont un compteur indiquant le nombre de flashage. S'il est supérieur à 0, certaines fonctionnalités (comme le NFC) peuvent être irrémédiablement désactivé, car même la réinstallation de la ROM d'origine ne remettra pas en route la fonctionnalité.

Il existe sur certains modèles de téléphone la possibilité de réinitialiser le compteur. Mais là encore, c'est une opération non triviale, qui, si mal faite, peut briquer le téléphone.

L'option "installe un Android vierge" n'est pas une option grand public. C'est une opération qui nécessite un minimum de compétence et qui présente toujours un risque.

Le 29/03/2024 à 20h 40

Le FLNJ approuve. Ils en ont marre de ces prédateurs

Le 29/03/2024 à 15h 13

Il me semblait justement que ce n'était pas aléatoire mais fixe. Pour que toutes les personnes utilisant Tor renvoi, grosso modo, les mêmes info dans les entêtes, limitant ainsi les risques de pistage.

Le 29/03/2024 à 11h 46

Attention, il a aussi été critiqué, mais je ne retrouve pas où, mais il permet de comprendre le principe.

Il faut rester dans l'optique du projet et ne pas lui prêter des intentions qui ne sont les leurs ;)

L'objectif du site, rappelé dès la page d'accueil, est le suivant :

Ce site web a pour but d'étudier la diversité des empreintes de navigateur et de fournir à des développeurs des pointeurs pour créer des contre-mesures efficaces aux techniques de suivi. Vous pouvez nous aider en permettant de récolter votre empreinte. Vous aurez une présentation de celle-ci ainsi que des statistiques présentant son unicité pour chaque attribut.

Que la détermination de quelques critères soit un peu biaisé n'a pas forcément d'impact réel sur les objectifs suivis, qui sont plutôt d'ordre pédagogique. L'idée est de montrer comment, rien qu'avec les entête HTTP, ou via le javascript, il est possible de faire une empreinte plus ou moins fiable. Si tu couples cela avec une adresse IP (très discriminant) tu peux vite avoir une empreinte unique quasi à coup sur à un instant T (pour la plus grande joie de Facebook, Google, X, etc. bref ceux qui ont des trackeurs sur n'importe quel site et qui peuvent donc suivre quelqu'un, même sans cookie).

Je me souviens du logiciel Tor, quand je l'avais essayé, qui conseillait de garder la taille de la fenêtre par défaut, et non pas de la mettre en plein écran (critère supplémentaire)

Mais sinon, je suis d'accord que l'affichage par défaut devrait être 90 jours (ou en tout cas, pas tout le temps !)