Le 20/03/2024 à 17h 05

Je réagissais par rapport à l'argent investi en R&D.

Le prix élevé du produit qui en résulte c'est autre chose et ne relève plus de la R&D (même s'il y a sans doute l'amortissement de la R&D inclus dedans).

Le 20/03/2024 à 13h 55

La réalisation de prototype et de petite série peut coûter extrêmement cher. Au delà de la masse salariale, il peut y avoir des besoins d'investissement en machines faites sur mesure. Et il peut y avoir besoin de plusieurs machines différentes selon les étapes (production, test, ...)

Du coup, vu le domaine extrêmement pointu, cela ne m'étonne pas vraiment.

Le 20/03/2024 à 13h 45

sans toucher la maquette. Juste mettre la balise span dans la zone réservé au sous-titre ;)

Le 19/03/2024 à 15h 51

Et mettre le sous-titre dans une balise span avec un attribut style="white-space: pre-wrap", c'est possible ou pas ? (pas de balise pre par contre, ça risque de casser complètement la mise en page !)

Le 19/03/2024 à 15h 35

Oui, je me suis fais avoir aussi. Sinon, il faut découper le texte tous les 41 caractères.

Pour les adeptes de la ligne de commande (sous Linux / Windows WSL):

fold -w 41 text.txt


[edit]
Bon ben ça marche pas. Impossible de faire une mise en forme qui respecte les espaces avec une police monospace, histoire d'avoir un rendu correct.

Le 19/03/2024 à 10h 09

Ah ? Il y a vraiment un message ? Je pensais pas ^^

Le 18/03/2024 à 20h 19

Ben c'est compliqué. Ca ne marche pas à cause d'une fonction javascript.

En gros, au moment de cliquer sur l'icône, un script vérifie la présence d'un lien dans le presse-papier pour le mettre directement là où il faut s'il y en a un. Sauf que la méthode javascript utilisée n'est disponible pour l'instant que dans les versions nightly de Firefox et pas sur Firefox Android. Sur le coup, Firefox est en retard.

Il faudrait juste vérifier la disponibilité de la fonction avant au pire, pour que le clic sur l'icône fonctionne, mais qui n'insérera pas le lien contenu dans le presse papier.

C'est difficile de toujours tout tester sur tous les navigateurs et sur toutes les plateformes. Ca va bien être corrigé. Il faut être patient. Il n'y a pas encore si longtemps, il n'y avait même pas l'icône. C'est un ajout récent ;)

Le 18/03/2024 à 18h 17

(edit : impossible de faire un lien cliquable, l'interface est buggée :/)

Firefox je suppose ? (non non, je ne troll pas, j'ai constaté que cela fonctionnait sous Chrome (et donc Edge, Chromium, ...) mais pas sous FIrefox)

Le 20/03/2024 à 09h 07

J'ai une piste pour savoir comment ils ont retrouver les suspects.

Ils ont pris la liste diffusée, ils ont demander une extraction complète à France Travail des données, ils ont fait la différence entre les 2 et trouvé qu'il manquait 3 noms !

Blague à part, chapeau les enquêteurs pour avoir pu avancer aussi si vite. Mais au delà tu piratages, cette affaire aura révélé la véritable problématique qui se cache derrière tout ça : je ne dis pas qu'il n'y a pas un sujet sur la durée de conservation, mais l'accès aux données étaient beaucoup beaucoup trop large.

Le 20/03/2024 à 08h 58

La solution "simple" que tu proposes est une folie d'un point de vue vie privée et suivi des flux.

La plateforme d'identification sera en mesure de savoir énormément de choses sur les personnes :
- ses caisses de retraites
- ses employeurs
- ses mutuelles
- les lieux où elle se fait soigner
- et j'en passe.

Cela en ferait pâlir de jalousie Facebook.

Sinon, même si théoriquement cela marcherait sur le papier, en pratique, c'est beaucoup plus compliqué. Dans le domaine de la santé (j'y travaille depuis plus de 10 ans), les questions d'identitovigilences sont primordiales, et c'est loin d'être aussi simple. Car il y a souvent des erreurs de saisie ou des données incomplètes. Les "JEAN-CHARLES" inscrits sous le nom de "JEAN" par exemple, les inversions entre le nom d'usage et le nom de naissance en passant par les fautes de frappes.

Les numéros de sécurité social sont aussi sujets à erreur, avec des inversions de carte, les erreurs de saisie (plus rare, car la clé est un mécanisme de vérification), la notion de NIR personne et NIR assuré, les numéros temporaires, les personnes qui changent de numéro au cours de leur vie (certaines personnes nées en Algérie par exemple durant la période coloniale, ou même les personnes transgenres).

Sans compter qu'il va falloir mettre en place des procédures pour détecter, et surtout corriger, les erreurs et la propagation d'informations erronées.

Je crois que tu ne te doutes pas de la complexité qu'il peut y avoir à mettre en oeuvre un mécanisme tel que celui que tu proposes. Et spoiler alert, cela a déjà été imaginé (au moins dans le domaine de la santé), tenté, avec plus ou moins de succès (souvent moins que plus d'ailleurs).

Pour terminer, il ne faut pas croire que les gens qui pondent ce genre de système sont des imbéciles (bon, ok, il y en a) et qu'ils n'ont pas penser à cette solution. Mais la solution "simpliste" que tu proposes se heurte à de nombreuses barrières, à la fois technique, juridique et réglementaire.

Le 18/03/2024 à 14h 48

il faut probablement mettre à jour les systèmes de moins d'un millier d'organismes (probablement connus de la CNIL, donc avec une liste exhaustive simple à récupérer).

Ben, quand on voit la complexité de mettre à jour UN système, je n'ose imaginer avec des milliers ^^ Surtout lorsqu'il y a certains systèmes avec une forte inertie (pour ne pas dire résistance au changement ;) ).

Par contre, il n'y a rien d'insurmontable selon moi : on est plus là devant un manque de volonté qu'autre chose.

Insurmontable non. Mais un truc qui coute, qui va prendre du temps, et encore faut-il que le cap soit stable (dans le domaine de la santé, il était prévu de déployer l'INS-C d'abord, puis que l'INS-A prendrait le relais. Si l'INS-C a bien été déployé, l'INS-A a été remplacé par le matricule INS. On vient donc de perdre plusieurs années pour rien. Des logiciels compatibles INS-A ont une fonctionnalité qui ne servira à rien, et rien ne garantie que dans 5 ou 10 ans on ne remplacera pas matricule par autre chose encore).

Le 18/03/2024 à 08h 59

Il y a certainement une subtilité que je ne vois pas, mais j'aimerais bien comprendre...

Le problème de la diffusion n'est pas au niveau de la personne même (quoi que) mais surtout au niveau des différents organismes.

Ensuite, pour tous les organismes qui utilisent le NIR, il leur "suffit" de faire appel à un service qui fait la correspondance entre le NIR et le nouvel identifiant.

Déjà, il est bon de rappeler qu'il existe plusieurs type de NIR : le NIR assuré, et le NIR personne. Donc quand on a un NIR, il faut déjà savoir lequel on a. Très important, par exemple, lorsqu'il s'agit des enfants.

Ensuite, la difficulté vient n'ont pas du nouveau système en tant que tel, mais de la durée de la transition et de la coexistence nécessaire (ou du support comme tu veux) des deux systèmes :
- durée de la transition : sauf à pouvoir mettre à jour l'intégralité de tous les systèmes de tous les organismes en même temps (et je me limite aux organismes publics, mais les entreprises aussi utilise le NIR pour la gestion social de leur salariés) il y a forcément une période de transition durant laquelle il y aura une partie des organismes compatibles et d'autres non compatible
- coexistence : il est impératif qu'un système qui communique avec un autre système soit compatible avec les deux notions que sont le NIR et le nouvel identifiant. En effet, un système ne sait pas si le système avec lequel il communique est compatible, s'il le devient, etc.

Par exemple, il était hors de question de simplement prendre le champ qui contient normalement le NIR pour y mettre le nouvel identifiant. Car c'est un coup à ce que le nouvel identifiant se retrouve en tant que NIR dans le système cible si ce dernier n'a pas encore fait sa transition !

Il faut aussi parfois faire évoluer des normes ou des spécifications. Toujours dans le domaine de la santé que je connais bien, l'échange d'information de patient entre plusieurs systèmes repose souvent sur des protocoles comme le HPRIM (très franco-français) ou le HL7 (internationale avec des extensions plus locales). Avec l'apparition du matricule INS, il était impératif de les mettre à jour.


Je vais me hasarder à une analogie foireuse : c'est comme l'IPv6. L'IPv6 en tant que tel, c'est cool, c'est simple et efficace, existe depuis 1998. Pourtant, 25 ans après, l'IPv4 est encore extrêmement présent. Ce n'est pas du à la complexité de l'IPv6 (qui n'est pas plus complexe que l'IPv4, juste un peu différent sur certains points), mais au fait qu'il faille mettre à jour les systèmes et les matériels compatibles. Aujourd'hui, ça fait plus de 10 ans que la transition vers IPv6 a véritablement commencé, et elle est loin d'être terminée.

Pourtant, techniquement parlant, il n'y a rien de compliqué.


[edit]
Et c'est sans compter les coûts (€) et les risques (perte de fonctionnalité, erreur dans la transmission ou la gestion de l'identité) d'un tel changement à cette échelle.

Le 17/03/2024 à 22h 18

Le problème n'était pas tant d'avoir un identifiant unique, mais de pouvoir diffuser l'identifiant.

L'INS-A n'a pas vraiment été diffusé, car d'un point de vue pratique, il fallait qu'il soit généré puis diffuser. Cette diffusion posait justement problème. D'où le passage par un INS-C dans un premier temps : sa diffusion était en théorie facilité, car il pouvait être calculé à partir des informations de la carte vitale.

Pour l'INS-A, il aurait fallu un organisme qui soit en charge de permettre de le récupérer. La grande question, c'était sur la base de quoi ? Un nom + prénom + date de naissance, ce n'est pas suffisant (identitovigilence) à l'échelle de la nation.

On pourrait se dire qu'il faudrait que ce numéro soit disponible sur la carte d'identité par exemple. Mais cela prendrait donc des années pour faire la transition (si on prend en compte la durée de vie d'une carte d'identité) sans compter que cette dernière n'est pas obligatoire.

Aujourd'hui, la difficulté technique aussi, c'est d'avoir une base qui serait exhaustive et contiendrait l'ensemble de toutes les personnes en France, et définir le périmètre (tous les habitants ? tous les citoyens ? Quid des citoyens français expatrié ? des étrangers sur le territoire français ? des mineurs ? ...).

Donc, je pense qu'on est d'accord pour dire que techniquement, c'est faisable. C'est simplement la mise en oeuvre qui demande des moyens colossaux et une collaboration de tous les acteurs. Bref, hyper compliqué en pratique.

Le 17/03/2024 à 17h 21

Ce n'est pas auprès du registrar qu'il faut le faire, mais en fonction de la "menace" :
- escroquerie et contenu illicite : auprès de la plateforme Pharos.
- SMS phishing : le transférer au 33700

Et quand on ne sait pas, on peut utiliser le diagnostique de la plateforme cybermalveillance

Au passage, le registrar précise bien qu'en dehors d'une décision de justice, il ne peut rien faire si ce n'est pas de la pédopornographie.

[edit]
J'ai oublié de préciser : le signalement a déjà été fait ^^ J'ai pour habitude le faire, surtout quand cela provient d'un 06 ou d'un 07, histoire que le numéro soit bloqué le plus rapidement possible.

Le 17/03/2024 à 10h 45

Certainement oui. Après, il y a une microtransaction pour les frais d'envois. Donc il n'est pas impossible non plus qu'ils effectuent cette microtransaction (tout est bon à prendre ^^) pour vérifier complètement les données.

Le 15/03/2024 à 21h 55

Et ces données liées à la retraite ne doivent pas être accessibles à n'importe qui surtout si c'est un partenaire comme Cap Travail Emploi.

(le smiley est d'autant plus de circonstance, que son raccourci est... cap !)

Le 15/03/2024 à 21h 30

Tu rigoles, mais j'ai testé avec des numéro bidons. Le numéro a été rejeté

Le 15/03/2024 à 21h 29

Je pense que ce n'est pas prêt d'arriver. Dans le domaine de la santé, il y a fort fort longtemps, c'était le numéro de sécurité social. On a voulu le remplacer. Une des raisons, c'est que le numéro de sécurité sociale est signifiant. On peut en déduire la commune de naissance, le mois et l'année et le sexe de la personne notamment.

On a donc eu l'INS, avec deux variantes :
- l'INS-C (C = Calculé), qui était déterminé à partir des informations de la carte vital (pour être précis, Prénom, Numéro de Sécu et date de naissance, mais pas le nom (car il peut changer)). Cela devait être un numéro temporaire
- l'INS-A (A = Aléatoire), qui devait être assigné à chaque personne (qui potentiellement pouvaient aussi en avoir plusieurs au cours de sa vie)

Pendant des années (depuis au moins 2012, date où j'ai commencé à m'intéresser au sujet professionnellement), on (=les éditeurs) devaient mettre ça en place. Puis comme c'était trop compliqué (je crois que l'INS-A n'a jamais vraiment vu le jour, et l'INS-C nécessitait d'avoir un accès à la carte vital), on est passé récemment sur le Matricule INS ! Le matricule INS, c'est quoi ?
- le numéro de sécurité social (oh, le revoilà !)
- l'identité de la personne (nom de naissance, prénom de naissance)
- date de naissance
- sexe
- code INSEE du lieu de naissance en vigueur le jour de la naissance de la personne (car le code INSEE d'une commune peut évoluer dans le temps)

Donc voilà, je crois que le numéro de sécurité social à encore de beaux jours devant lui... L'INS-C et l'INS-A ? Abandonné.

Le plus cocasse dans tout ça ? C'est que c'est la CNIL en 2007 qui s'était opposé à l'utilisation du NIR dans le domaine de la santé pour le restreindre à la sphère sociale. Mais cela a été cassé par le Ministère de la Santé en 2016. Du coup, il revient en force...

Le NIR est déjà utilisé, déjà répandue. Quand je vois le bazar que c'est pour un seul domaine (celui de la santé), changer d'identifiant tout domaine confondu me parait utopique, sauf à avoir des contraintes/volonté extrêmement forte (au hasard, un piratage massif rendant trop risqué de continuer sur ce système).

Le 15/03/2024 à 20h 02

Sinon, hasard ou pas, pas plus tard qu'aujourd'hui, j'ai reçu un SMS de phishing au sujet de la carte Vitale :

AMELI : Votre cartve vitale arrive à expiration. Effectuez son renouvellement sur le formulaire avant le 16/03/24. Via: formulaire-assure.com

Je n'ai pas mis le lien, tant il s'agit d'une arnaque, donc attention à vous !!

Je les ai trollé un peu : j'ai rempli le formulaire avec les informations suivantes :
- Nom : Allez
- Prénom : vous
- Adresse e-mail : [email protected]
- adresse postale : 3 rue du Blaireau
- Ville : MONTCUQ
- Numero de téléphone : 3615696969


Je me suis arrêté lorsqu'il fallait procéder au paiement.

Le 15/03/2024 à 19h 58

J'y pensais justement pas plus tard qu'aujourd'hui. Il faut juste que je bouge mon popotin sur La Rochelle ;)

Le 19/03/2024 à 09h 47

Tout à fait. Il n'y a qu'à s'intéressé au cas Clearview AI, condamné à plusieurs reprise pour violation du RGPD.

Mais je ne réagissais pas sur les éventuels poursuites en cas d'infraction, mais sur ce qu'impose le RGPD. On lit encore trop souvent que le RGPD impose le consentement. C'est faux. C'est une possibilité, mais pas une obligation. L'obligation qui s'y réfère, c'est d'avoir une base légale.

Le 19/03/2024 à 08h 22

Il impose que tu donne ton consentement à la récolte de données (de conduite d'une voiture connectée par exemple), et s'ils le font sans ton consentement, c'est attaquable. Et ce n'est pas le cas aux US visiblement.

C'est terrible de toujours lire ceci, 6 après l'entrée en vigueur du RGPD. Le RGPD impose une base légale, dont le consentement fait parti. Une autre base largement utilisable dans ce cas, c'est la base contractuelle.

Ici, on pourrait même pousser le vice jusqu'à utiliser la clause pour la sauvegarde des intérêts vitaux des personnes, en détectant les chauffards.

Il n'a jamais été question « d'être à l'abri » avec le RGPD, juste de limiter la casse au niveau de la collecte, du stockage et de l’utilisation des données.

Exactement. Hormis pour les données dites sensibles, un responsable de traitement peut faire ce qu'il veut, tant qu'il décrit le traitement et dispose d'une base légale pour le faire (et dans un sens, c'est même plus laxiste qu'avant, car avant, un certain nombre de traitements nécessitait au moins une déclaration à la CNIL, ce qui n'est plus le cas aujourd'hui).

Le 18/03/2024 à 09h 02

Dommage que ce ne soit pas la Direction Territoriale et Centrale , autrement connue sous l'acronyme DTC.

Le 18/03/2024 à 08h 12

Les 6 morts, sont côtés des victimes, pas des escrocs. Des victimes qui se seraient suicidées suite à la réception de cet e-mail.

Après, ce n'est pas 19 arrestations, mais 19 interpellations. Cela reste très différent :
- interpellation : vient là, faut qu'on te cause et qu'on te pose des questions
- arrestation : on t'enferme jusqu'au procès.

Une interpellation peut être suivi d'une arrestation.

Le 18/03/2024 à 08h 37

Ou alors il faudrait faire comme l'API de I have been pwned, où cela se passe en 2 temps :
- une requête avec un hash partiel (et le serveur répond avec l'ensemble des hash correspondants)
- une vérification en local par rapport à la liste retournée par le serveur.

Ainsi, le hash complet d'un mot de passe testé n'est jamais envoyé complètement. Pour I have been pwned, 5 caractères suffisent.

[edit]
Je viens de regarder le post de Google, et c'est bien ce qu'ils font ! Donc j'ai rien dit :)

Le 17/03/2024 à 11h 22

Vous êtes un dev, vous ne savez pas quoi faire ce dimanche ? Alors participez, en retard, au One Billion Row Challenge. C’est ce que vient de faire Ben Hoyt. Alors que la compétition initiale était en Java, il a opté pour le langage Go et propose neuf solutions pour passer de plus de 100 secondes à 3,4 secondes seulement pour traiter un fichier avec un milliard de lignes.

Il faut quand même pas mal de RAM pour pouvoir atteindre ce genre de performance. En allant jeter un oeil aux conditions & règles du challenge, on se rend compte qu'ils font tourner les tests sur une machine disposant de 128Go RAM. Donc suffisamment pour que le fichier de test puisse tenir dans le cache disque de l'OS.

Dès lors que le cache est trop petit, les performances seront forcément plombées par le matériel, car même avec bon bon débit de 2Go/s, il faudrait 6,5s rien que pour lire les données. Pour le vainqueur, le programme tourne en 1.535s. Cela n'enlève rien à la performance, mais il faut commencer à avoir un sacré config pour espérer faire tenir le fichier en entier dans le cache. Minimum 32Go, car bien que 16 soit en théorie possible, il resterait moins de 3 Go pour tout le reste... (os, application, service, autres fichiers mis en cache, ...)

Du coup, je propose sur Next le OBRC, mais avec 50 000 000 enregistrements, au lieu de d'1 milliard. Le fichier ainsi généré ne fait plus que 658Mo, qui pourra être mis en cache beaucoup plus facilement pour des tests.

Quitte à faire tourner ensuite sur une bonne grosse config, et pour le fun (le challenge étant terminé), sur 1 milliard d'enregistrement comme prévu initialement.

Le 15/03/2024 à 14h 41

Oui, on a le choix entre Y. Noah.

Pour ma part, comme un grand gagnant de cette histoire pourrait être Musk, j'ai pensé à Starlinklight (version de muse, version de The Supermen Lovers) ^^

Le 15/03/2024 à 11h 57

Plutôt d'accord dans l'ensemble avec ce que tu dis. Sauf ce passage

Sur la durée, le RGPD étant plus important dans la hiérarchie des normes qu'un décret parce qu'il est un texte résultant d'un traité, il n'y a aucune raison de considérer un maximum prévu dans le décret comme une durée qui permettrait de ne pas respecter le RGPD qui dit explicitement qu'il faut minimiser la durée de conservation choisie doit être nécessaire au traitement.

Alors oui, on est d'accord que le RGPD est plus important dans la hiérarchie des normes. Maintenant, le RGPD ne dit pas qu'il faut minimiser la durée de conservation. Le RGPD impose d'en définir une (soit directement, soit en pouvant la calculer) et ne va pas plus loin. Le reste, ce sont des dispositions réglementaires, légales, les délibérations de la CNIL, etc. qui permettent de donner une durée (mais pas le RGPD).

En l'absence de toute référence, c'est au RT de définir la durée de conservation. Mais si le RGPD n'impose pas de durée, il ne faut pas qu'elle soit disproportionnée vis-à-vis du traitement. Ce qui est hautement subjectif et largement soumis à interprétation. Et quand on a un texte (comme ici) donnant une limite maximum (20 ans), il me parait difficile de dire avec une certitude absolue que c'est disproportionnée, puisqu'un cadre réglementaire donne une échelle de temps.

Quant au caractère "supérieur" du RGPD, c'est toujours compliqué. Il suffit de regarder l'exemple de la conservation des logs de connexion. L'Europe et la France n'ont pas du tout la même interprétation, mettant dans une position largement inconfortable les entreprises qui pourront, quoi qu'elles fassent, se faire attaquer soit devant la justice française, soit la justice européenne (avec les frais et l'énergie que cela demande, bien évidement).

Et si le RGPD imposait vraiment la minimisation de la durée de conservation, alors je pourrais dès aujourd'hui supprimer toutes les données relatives à mes ex-employés (je n'ai plus de traitement en cours avec eux, le solde de tout compte étant fait depuis belle lurette). Pourtant, si je le fais, je risque de me prendre une amende plutôt salée.

Par contre, sur l'accessibilité des données, oui, il semblerait dans le cas présent qu'elle soit beaucoup trop large (si les données ont bien été récupérées via Cap Emploi). Et là, oui, tu as raison de le souligner, le RGPD est explicite.

Le 15/03/2024 à 08h 30

Pardon, je n'étais pas allé voir le décret. C'est bien une durée maximum qui est précisée.

Autant je suis d'accord avec ton interprétation sur le fait que la question de la durée de la conservation aurait du se poser. Toutefois, je ne suis pas certains pour autant que cela soit opposable dans le cadre d'une procédure de sanction, la réglementation définissant explicitement une durée (même si elle n'est que maximum) car derrière un pas plus de 20 ans, se cache implicitement une "autorisation" de les conserver jusqu'à 20 ans...

Et après, il ne faut pas se leurrer non plus. Même en cas de sanction de la CNIL, cela reste un établissement public. Donc une sanction pécuniaire prononcé par la CNIL... revient à l'Etat !

Le 14/03/2024 à 21h 01

Par contre une durée de ce type n'est pas conforme au RGPD article 25 qui dispose que :

C'est plus compliqué que ça. Le RGPD ne vient pas remplacer la réglementation, elle vient en plus de la réglementation. Le RGPD impose juste de définir une durée de conservation (ou au moins le moyen de la déterminer) qui soit en corrélation à la réalisation du traitement, avec des exceptions pour à des fins archivistiques dans l'intérêt publique, la recherche publique, etc.

Si une durée est fixée par la réglementation, le responsable de traitement se doit de respecter cette durée (et la CNIL le rappelle sur son site), qu'importe si la durée semble disproportionnée.

Ici, la durée est fixée par le législateur. Le problème est donc au niveau du législateur, pas au niveau du responsable de traitement.

Le 14/03/2024 à 11h 57

- OpenAI dit que ca s'apparente à du hacking car il a fallu plusieurs dizaines de milliers de tentatives pour y arriver.

Si le NYT a payé pour ces requêtes, est-ce vraiment du hacking ?

Mon avis: les deux ont raison => les deux sont coupables.

Je propose donc qu'on leur coupe un doigt chacun

Le 14/03/2024 à 11h 55

Il me semble oui. Sur la question des clés de chiffrement. HADOPI avait botté en touche...

Le 14/03/2024 à 09h 23

L’interdiction de TikTok passe à la Chambre des représentants des États-Unis

Pauvre Kesha

(inutile de me chercher, je suis déjà dehors )

Le 13/03/2024 à 19h 57

Je t'invite à lire (ou relire) l'édito de Next sur l'importance de bien vérifier ses sources.

Nous avons ici :
- une quasi-absence sur le net de ce cas
- les 2 seuls cas que j'ai trouvé, c'est ton lien, et un autre site, dont l'article est là copie conforme de celui de boulveard voltaire
- aucun travail d'investigation n'a pu être fait
- il s'agit du témoignage d'un auditeur tout ce qu'il y a de plus anonyme (non, rien ne dit que Mickaël est son vrai prénom)
- les faits sont présentés de manière très biaisées (uniquement un seul point de vue)
- le replay de l'émission est disponible ici à 1h01min40s. Un policier intervient juste après pour dire qu'il est étonné et ne comprend pas très bien cette décision et parle de l'interprétation des faits pour pouvoir expliquer cette décision.

Le 13/03/2024 à 11h 38

Ca servirait a ce que le gentil admin se fasse une liste de bonnes poires qu'il pourra revendre à d'autres encore

Ou les refaire chanter 3 mois après la fin de l'ultimatum ^^

Le 13/03/2024 à 08h 27

- les vendeurs vont-ils déclarer aux CNILs la violation de données dont ils sont victimes ?
- les vendeurs vont-ils porter plainte ?
- les vendeurs vont-ils contacter leurs clients pour les avertir de la violation de données ?

vive le darkoueb xD

Le 13/03/2024 à 14h 22

Je n'ai pas vu le lien vers le test. Je me permets de l'ajouter ici : https://browserbench.org/Speedometer3.0/

Et moi, je ne dépasse pas le 8 avec Chrome ^^

Le 13/03/2024 à 10h 31

Oui, j'ai vu ça aussi. J'ai noté la différence de couleur entre les articles consultés et non consultés ;)

Merci pour ces petites améliorations !

[edit]
Du coup, j'en profite :
- la recherche génère une page 404
- la page 404 est simplement l'accueil de Next, sans utilisateur connecté (on perd le thème, le login en haut à droite, etc.)

Le 13/03/2024 à 10h 13

Je l'ai constaté aussi. De ce que j'ai vu, c'est les commentaires d'ouvertures de sujet qui sont inaccessibles. Pour les commentaires "de réponse", je n'ai pas constaté de souci.

Le 12/03/2024 à 15h 53

Il faudra évidemment respecter plusieurs règles, notamment être membre de « l’Apple Developer Program depuis au moins deux années consécutives et disposer d’une app avec plus d’un million de premières installations en un an sur iOS, dans l’UE et au cours de l’année civile précédente ». Des frais peuvent également s’appliquer.

Autant dire que ce n'est que pour les plus gros. Bye bye 99,9% des applications....

Le 12/03/2024 à 08h 54

La blockhain est effectivement une belle idée, qui répond à un besoin particulier.

Malheureusement, comme beaucoup d'innovations numériques avant elle, elle a été surutilisée (surtout là où on n'en avait pas besoin).

Mais voilà, il n'y a pas si longtemps "une entreprise qui n'utilisait pas la blockchain, c'était une entreprise qui avait raté sa vie". Mais on a eu la même chose par le passé avec le cloud, le NoSQL, l'IA, etc.

Quand les technologies sont utilisées par des décideurs et des marketeurs, cela conduit en général à une catastrophe, car la solution technique n'est pas en adéquation avec le besoin réel.

Alors quand les technologies sont utilisées par des spéculateurs, promues par des influenceurs et sont mises en avant dans des publicités (j'en ai eu pas mal à une époque pas si lointaine sur les pubs dans mes applications sur mobile)... je n'ose imaginer les dégâts le jour où cela s'écroulera.

Le 11/03/2024 à 18h 24

Ah mais non scacrebleu ! Si j'ai des warnings, il est totalement inenvisageable que cela vienne du code. C'est à cause de la version obsolète de GCC, que je suis allé volontairement chercher pour accréditer mes dires

Plus sérieusement, tant qu'il y aura des dev avec ce genre de mentalité, les CVE ont de beaux jours devant eux

Le 11/03/2024 à 08h 02

Cela aurait été mesquin de ma part de ne pas prendre un vrai linux...

Le 10/03/2024 à 23h 09

Dans le "t'es content ?" ... il fallait comprendre que je salue tes efforts pour prouver ton point de vue. Je salue également tes capacités de recherche d'un environnement suffisamment vétuste te permettant de prouver tes dires : la version 9.4 de GCC a été mise à jour pour la dernière fois en juin 2021. Pour te dire, même la vieille LTS Ubuntu 22.04 installe de base GCC 11 et propose GCC 12.

Au quotidien, je tourne en GCC 13.

Si tu crois que j'ai "recherché" un environnement vétuste... ben non. J'ai juste pris la première VM que j'avais sous la main (car oui, ma machine principale est sous Windows )

Je reste dans le ton des commentaires qui ont été faits. L'arrogance dont tu me crédites n'est ni plus ni moins que celle avec laquelle tu as entamé les débats.

On pourra se la jouer court de récré, car bizarrement, en relisant nos premiers échanges, je n'ai pas du tout la même interprétation que toi. Je t'avoue qu'après un "script kiddy" et "une médaille en chocolat dans le paramétrage Java", j'ai commencé sans doute à être un peu moins sympa, sans pour autant tomber dans des attaques ad hominem. Je préfère toutefois laisser aux lecteurs se faire leur propre opinion à ce sujet.

Pour ma part, je pense que l'on peut clore la discussion, le tour ayant été fait sur le sujet.

Le 10/03/2024 à 22h 14

Il faut que tu comprennes une chose : que ton programme fonctionne ou pas, je m'en fiche totalement (et ceci le plus sincèrement du monde et sans vouloir te manquer de respect).

Ce que j'essaie de te dire (et d'autres aussi), c'est que ton comportement arrogant vis-à-vis de ton programme est une des plaies quant à la sécurité des programmes d'aujourd'hui. Rust (que je n'apprécie pas vraiment, je trouve sa syntaxe illisible) empêche, de par sa conception, les principaux pièges qui constituent la majorité des failles (une étude révélait, par exemple, que la majorité des failles de sécurité dans des programmes C étaient dues à des buffer overflow).

Le pire, c'est que non seulement tu n'arrêtes pas de dire que ton programme est bien pensé, mais qu'en plus, tu te montres plutôt méprisant (pour ne pas dire insultant) envers celles et ceux qui ne seraient pas d'accord avec toi.

Du coup, je ne peux qu'abonder dans le sens du commentaire 14 de Stephane Bortzmeyer (sauf le côté virilisme que je n'ai pas trop compris dans son propos), où, désolé de te le dire, ton comportement est l'archétype même de ceux qu'il dénonce.

Le 10/03/2024 à 21h 55

Je me suis amusé à le compiler et à le lancer, histoire de voir. Toi qui est si fier de ton programme, sache qu'il génère 8 warnings avec gcc 9.4 (je croyais qu'il fallait les éviter ? C'est en tout cas ce que tu demandais commentaire 6.31 (je ne l'invente pas).

Et le comble, c'est que ton programme se termine par un beau segmentation fault à l'exécution.


Current Minimum Maximum
Core 0 : Khz Khz Khz
Core 1 : Khz Khz Khz
Core 2 : Khz Khz Khz
Core 3 : Khz Khz Khz
Core 4 : Khz Khz Khz
Core 5 : Khz Khz Khz
Core 6 : Khz Khz Khz
Core 7 : Khz Khz Khz

Total : Khz Khz Khz
Average : Khz Khz Khz

Nb Mini :
Nb Maxi :

Extr. Min: Khz Khz Khz
Extr. Max: Khz Khz Khz
Segmentation fault


(tu m'excuseras, je me suis contenté d'un copier/coller de la console, je n'ai pas envie de m'amuser à héberger une image pour ensuite la coller ici).

Alors, tu peux dire tout ce que tu veux de ton programme, tu ne peux pas lutter contre les faits.

Le plus drôle dans tout ça, c'est que j'ai trouvé un buffer overflow exploitable, et que je voulais justement le compiler/tester pour vérifier, mais que je n'ai même pas eu à le faire, car ton programme plante de lui-même.

J'applaudie, à 2 mains, les 20 ans d'expérience mis avec tant de valeur dans ton commentaire précédent

Le 10/03/2024 à 21h 18

Cette approche plus dépouillée sert la maintenabilité.

Désolé de te le dire, mais toi qui défend la maintenabilité à tout va (ça fait plusieurs fois que tu parles de maintenabilité), il y a encore beaucoup de boulot pour que ton programme soit maintenable :
- avoir des conventions cohérentes : un coup de PascalCase, un coup du camelCase, un coup du snake_case
- nommage qui laisse sérieusement à désirer ;
- utilisation de constantes en dure, au lieu de les définir via un #define ou une variable const ;
- utilisation de la virgule au lieu du point virgule pour séparer des instructions (oui, c'est valable en C, je sais, mais cela n'en est pas moins une très mauvaise pratique, surtout pour éviter de définir un bloc d'instructions dans un if ou else par exemple)

Mon code fonctionne car les procédures appelées forment un ensemble.

Comme je te l'ai déjà dit dans un précédent commentaire : ton code fonctionne pour toi, dans ton cas d'utilisation. Mais il est public (tu l'as publié sur github) et tu ne sais pas dans quelles conditions il sera utilisé.

Ton code est du pain béni pour n'importe quel hacker, mais ça, tu n'en as que faire. Pire, tu refuses ne serait-ce que de le concevoir.

PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego universitaire.

Argument d'autorité + attaque ad hominem (encore). Peux-tu rajouter la victimisation la prochaine fois stp, histoire de varier les procédés rhétoriques ?

Ou plus simplement, avoir de vrais arguments pour défendre ton point de vue. Merci d'avance ;)

Le 11/03/2024 à 17h 56

Ne t'inquiète pas, ça arrive à tout le monde. Même à des gens très bien

Le 10/03/2024 à 22h 56

J'ai déplacé le lien. Il souffre du bogue qui affecte les commentaires : la première ligne n'est pas sélectionnable (et donc les liens... cliquables !)

Le 10/03/2024 à 08h 56

J'avoue que je n'y ai pas pensé sur le coup, sans doute en grande partie à cause de mon ignorance sur le sujet ! Mais c'est une idée :)

[edit] : il suffisait de demander :)