• chevron_right

      Utiliser un certificat de signature électronique certinomis sur GNU/Linux Ubuntu (le retour...)

      news.movim.eu / LinuxFRJournaux · Yesterday - 15:39 · 3 minutes

    Ce journal fait suite au fort intéressant journal de dark_moule :
    https://linuxfr.org/users/dark_moule/journaux/utiliser-un-certificat-de-signature-electronique

    C'est lui qui m'a permis d'oser tenter d'acheter un certificat chez certinomis et l'installer sous mon xubuntu.

    Je vous partage les écueils que j'ai croisés. La documentation fournie par certinomis est plus que minimale, elle est indigente (autant que leur site web, qui date des années 1800. bref…)

    Installation initiale

    Premier écueil : que faut-il installer ? Là, c'est tout simple, le paquet qui est ici : https://www.certinomis.fr/drivers-gemalto comme le dit dark_moule.

    Une fois que c'est installé, une petite applet apparaît :
    logo applet
    Le S est rouge lorsque la clé USB a été insérée.
    Si en faisant clic droit > certificate information tu vois ton certificat (il y a 2 lignes, avec des numéros différents, je ne sais pas trop pourquoi), c'est que la 1ere étape est réussie :
    Certificate information

    Vérifions le code PIN : on sélectionne le certificat puis "Log On" en bas à gauche.
    Saisissons le code PIN dans "Token password".
    log-on
    Si le code est erroné, message d'erreur. Si le code est bon, aucun message ni changement visible. Seule différence : on ne peut plus cliquer sur "Log On" (puisqu'on est loggué) (Ça m'a pas mal troublé)

    Les autres options du menu de cette applet ne m'ont pas servi, en particulier le menu "unlock token" qui n'est PAS la saisie du code PIN

    Maintenant que l'on a une clé opérationnelle, comment on fait pour signer…

    Tunderbird

    C'est plutôt simple… jusqu'à THE écueil qui m'a tenu en haleine plusieurs heures. Je le mets en anglais (ça m'a beaucoup aidé de passer en anglais pour avoir des réponses de qwant quand je buttais)
    Thunderbird > Settings > Privacy and security > Security device > Load > new PKCS#11 module > Browse
    /usr/lib/libeTPkcs11.so

    Apparaît alors :
    thunderbird PKCS#11

    Et ensuite, je vous livre immédiatement LE truc qui a empêché que ça fonctionne pendant plusieurs heures. L'autorité certinomis n'était pas déclarée comme autorité de confiance pour signer des mails ! Pour l'activer, il suffit de :
    Thunderbird > Settings > Privacy and security > Manage Certificates >

    chercher certinomis dans la (longue) liste > cliquer sur
    "Certinomis Prime CA G2" puis sur "Edit Trust" :
    thunderbird certificate identify email

    À partir de là, ça roule ma poule :
    Thunderbird > Account Settings > choisir le compte > End-to-end encryption > dans la zone "S/MIME" cliquer sur "Select" et sélectionner son certificat

    Pour avoir le bouton qui permet de signer, personnaliser la barre d'outil de la rédaction d'un message (clic droit) et ajouter l'icône signature :
    signe ce mail

    Je n'ai pas réussi à faire comprendre à libreoffice comment signer.

    Par contre, pour Okular, ce qui est proposé dans le journal de dark_moule a fonctionné :
    On crée le lien vers le certificat dans la base NSS
    mkdir -p $HOME/.pki/nssdb
    certutil -N -d sql:$HOME/.pki/nssdb
    modutil -dbdir sql:$HOME/.pki/nssdb -add "OpenSC" -libfile /usr/lib/libeTPkcs11.so -mechanisms FRIENDLY

    Okular > Configuration > Configurer les moteurs de rendu > PDF > saisir son code PIN (et, auparavant, le mdp qui aura été choisi lors de la commande certutil ci-dessus)
    Pour signer un PDF, il suffit alors de l'ouvrir, puis
    Outils > Signature numérique en cours… > Tracer le carré de signature à la souris > sélectionner son certificat >
    On obtient un joli :
    PDF signé

    On peut alors aller vérifier, par exemple, sur https://www.marches-publics.gouv.fr/?page=Entreprise.VerifierSignature que tout est OK :
    Signature valide

    Et on peut enfin se détendre, fier du travail accompli (et, bientôt, signer des réponses à Appel d'Offre public !)

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/tipaul/journaux/utiliser-un-certificat-de-signature-electronique-certinomis-sur-gnu-linux-ubuntu-le-retour

    • chevron_right

      Téléphone sous Linux ?

      news.movim.eu / LinuxFRJournaux · Yesterday - 08:39 · 3 minutes

    Aujourd'hui, avoir un téléphone avec un Android libéré, c'est possible, on pense en particulier à Murena .

    Avoir un téléphone sous GNU/Linux, c'est aussi possible via des projets tels que Librem ou encore le Pinephone .

    On peut aussi utiliser PostmarketOS avec un Oneplus 6 par exemple.

    J'ai longtemps utilisé LineageOS (Oneplus one, Pixel 1, Oneplus 7 pro) tout en contribuant au projet mais j'avoue que le monde Android ne m'a jamais beaucoup passionné.

    J'ai aussi eu un Meizu/UbuntuPhone en 2015.

    L'année dernière, j'ai récupéré un Oneplus 6 que j'ai immédiatement passé sous PostmarketOS. C'est une expérience agréable modulo quelques déconvenues :
    - Pour l'instant, les appels téléphoniques se passent assez mal (problème de sélection des bonnes entrées/sorties audio)
    - La caméra ne fonctionne pas.
    - Le détecteur d'empreintes ne fonctionne pas

    C'est assez normal en soit, il y a un gros travail de portage des drivers Android (noyau ancien 4.14) vers le noyau actuel et pour la caméra par exemple, c'est très complexe.

    Je suis donc resté sous LineageOS sur mon Op7 pro en me servant du Op6 comme lecteur MP3.

    Et puis je suis allé en février au FOSDEM rencontrer la communauté GNOME (je contribue pas mal au projet) et j'ai découvert ce jour-là le projet Droidian

    Après réflexion, j'ai donc acheté un Redmi Note 9 pro et j'ai enfin pu avoir un téléphone sous GNU/Linux fonctionnel !

    Droidian c'est quoi ? C'est Mobian (Debian pour mobile) + Halium (ce qu'utilise UBports ). En gros, le téléphone boot sur le noyau Linux Android d'origine, lance un conteneur LXC pour avoir un Android minimal afin de communiquer avec le noyau puis lance les services Linux standards que l'on trouve sur un téléphone Linux: ofono, phosh, …

    Résultat, tout fonctionne (même la caméra)! On a donc un téléphone GNU/Android/Linux :) On peut même utiliser Waydroid pour lancer ses applications Android préférées.

    Pas de bol pour moi, le Redmi Note 9 pro a été supprimé des téléphones officiellement supportés et j'ai donc pris le relais (pas encore officiellement) pour la maintenance : https://github.com/gnumdk-miatoll

    Par défaut, Droidian utilise un service (batman) qui se charge de l'économie d'énergie avec des résultats plutôt intéressants. Ayant fait quelques modules kernel du temps où je bossais sur LineagesOS, je me suis inspiré de Batman pour développer un module chargé de gérer au mieux l'énergie quand l'écran est éteint .
    J'arrive à avoir des résultats impressionnants : https://floss.social/@gnumdk/112309304719804582 et https://floss.social/@gnumdk/112115901530845308 .

    Et pourtant ce module noyau fait une chose que l'on m'a toujours déconseillé de faire sous Android, baisser tous les curseurs de performances au minimum quand l'écran est éteint. En effet, un téléphone Android ne se met jamais en veille, il freeze les applications et compte sur le "CPU idle" pour économiser de l'énergie. Problème sous Android, si on force les performances au minimum, les tâches mettent plus de temps à s'exécuter, du coup les CPU ne sont jamais idle et donc on consomme plus d'énergie.

    Ben ce n'est pas vrai ici, j'ai clairement un téléphone qui tient beaucoup mieux que mes téléphones Android avec en usage une consommation d'énergie équivalente écran allumé, mais lorsque je laisse mon téléphone sur un coin de table, une consommation d'énergie vraiment minimale.

    Autre projet que j'ai dû développer pour avoir le même niveau de fonctionnalité que sur mon téléphone LineageOS: un gestionnaire de charge de batterie .

    Pour finir, concernant Waydroid, par défaut, il est livré soit avec un Android AOSP, soit avec le store Google. Cette dernière version fonctionne bien, mais l'appli de ma banque n'a pas voulu fonctionner à cause de SafetyNet . Je me suis donc rabattu sur AOSP + MicroG ce qui permet de "spoofer" SafetyNet.

    Voici les apps que j'utilise quotidiennement : SNCF, blablacar, Boursobank, Meteociel, Paypal et OrganicMap.

    Il y a bien Puremaps en natif sur Droidian mais sans la géolocalisation via 4G/Wifi, c'est un peu long d'où l'usage de OrganicMap + MicroG + Mozilla Location Services.

    Voilà, j'espère que j'ai donné envie aux plus geeks d'entre vous :)

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/gnumdk/journaux/telephone-sous-linux-3c82896e-f65c-4012-9c71-3e1fdd2b9558

    • chevron_right

      Traduction | Doit-on vérifier le pointeur pour NULL avant d'appeler la fonction free ?

      news.movim.eu / LinuxFRJournaux · 2 days ago - 10:15 · 13 minutes

    Sommaire

    La réponse brève est non. Cependant, cette question apparaît régulièrement sur Reddit, Stack Overflow et d'autres sites web, il est temps d'aborder le sujet. Il y a beaucoup de choses prenantes à réfléchir.

    Titre de l'image

    Remarque

    Bonjour! Cet article a été initialement publié sur le website PVS-Studio écrit par Andrey Karpov.
    J'ai traduit cet article théorique spécialement pour la communauté française. Bouquine bien !

    Fonction free

    La fonction free est déclarée dans le fichier d'en-tête <stdlib.h> comme suit :

    void free( void *ptr );

    La fonction libère la mémoire tampon avant alloué avec les fonctions malloc , calloc , realloc et aligned_alloc .

    Si ptr est un pointeur NULL , la fonction ne fait rien.

    Il n'est donc pas vérifier le pointeur avant d'appeler free .

    if (ptr)     // une vérification redondante
      free(ptr);

    Ce code est obsolète, car la vérification n'est d'aucune utilité. Si le pointeur est NULL , on peut le passer à la fonction free en toute sécurité. Les développeurs de la norme du C délibérément choisi cette solution :

    cppreference.com : free

    La fonction accepte (et ne fait rien avec) le pointeur null afin de réduire le nombre de cas particuliers.

    Si le pointeur est non NULL , mais toujours invalide, la vérification ne protège de rien. Un pointeur non NULL invalide est toujours passé à la fonction free , ce qui cause un comportement indéfini.

    cppreference.com : free

    Le comportement est indéfini si la valeur de ptr n'est pas égale à une valeur renvoyée précédemment par malloc() , calloc() , realloc() , ou aligned_alloc() (depuis C11).

    En outre, le comportement est indéfini si la zone de mémoire désigné par ptr a déjà été libérée, c'est-à-dire, free() , free_sized() , free_aligned_sized() , ou realloc() a déjà été appelée avec comme argument ptr et aucun appel à malloc() , calloc() , realloc() , ou aligned_alloc() abouti à un pointeur égal à ptr après.

    Par conséquent, on peut et on doit écrire simplement :

    free(ptr);

    D'où viennent les questions de la vérification préliminaire des pointeurs ?

    La documentation de la fonction free indique explicitement qu'on peut lui passer un pointeur NULL et qu'il ne pose aucun risque. Cependant, les discussions sur ce sujet continuent d'apparaître sur différents sites web. Les questions se divisent en deux catégories.

    Les questions des développeurs débutants. Ce type de questions est le plus courant. C'est simple : les gens commencent à apprendre la programmation, ne sont pas conscientes quand il faut vérifier un pointeur et quand il ne faut pas le faire. Pour les jeunes développeurs, une simple explication suffit. Lorsque vous allouez de la mémoire avec malloc, vérifiez le pointeur . (P.S. Commentaire du traducteur : malheureusement, je n'ai pas encore traduit cet article, mais une traduction est à venir :) )
    Sinon, le déréférencement d'un pointeur NULL peut causer un comportement indéfini. Avant de libérer la mémoire (en utilisant de free ), on n'a pas besoin de vérifier le pointeur, car la fonction le fera elle-même.

    Voilà, c'est tout. Un autre bon point pour un développeur débutant est d'utiliser un analyseur en ligne pour comprendre plus rapidement ce qui ne va pas dans le code.

    Les questions posées par des développeurs expérimentés et trop tatillons. C'est là que les choses deviennent intéressantes. Cette catégorie de personnes sait ce que la documentation contient. Cependant, ils posent toujours les questions parce qu'ils ne sont pas sûrs que l'appel à free(NULL) est toujours sûr. Ils s'inquiètent que leur code soit compilé sur de très vieux systèmes, où free ne garantit pas une gestion sûre des pointeurs NULL . Ou une bibliothèque tierce particulière qui implémente free d'une manière non standard (en ne vérifiant pas pour NULL ) peut être utilisée.

    On peut discuter de la théorie. En réalité, cela n'a pas de sens.

    Commençons par les anciens systèmes. Tout d'abord, il n'est pas facile de trouver un tel système. La première norme C89 montre que la fonction free doit bien gérer NULL .

    C89 : 4.10.3.2 The free function.
    La fonction free permet de désallouer l'espace pointé par ptr et le rendre disponible pour une nouvelle allocation. Si ptr est un pointeur NULL , aucune action n'a lieu.

    Deuxièmement, si vous voyez un système " pré-norm ", on ne pourra pas créer votre appli pour diverses raisons. Je doute également qu'on n'ait jamais besoin de le faire. Cette issue semble farfelue.

    Maintenant, imaginons que le système ne soit pas préhistorique, mais spécial. La bibliothèque tierce inhabituelle de fonctions système qui implémente la fonction free à sa manière : on ne peut pas passer NULL à la fonction.

    Dans ce cas, la fonction free brisée n'est pas votre plus grosse issue. Si l'une des fonctions de base du langage est brisée dans la bibliothèque, il y a beaucoup d'autres choses brisées que la dernière chose dont vous devez vous préoccuper est un appel sûr pour free .

    C'est comme être dans une voiture artisanale sans freins, sans rétroviseurs et avec un volant bloqué. Mais vous vous inquiétez de savoir si les bornes sont bien connectées à la batterie. Les bornes sont importantes, mais l'issue ne vient pas d'eux, mais de la situation dans son ensemble.

    La question de la vérification préliminaire des pointeurs est parfois abordée sous l'angle de la micro-optimisation du code : " Vous pouvez éviter d'appeler la fonction free si vous vérifiez le pointeur vous-même ". C'est là que le perfectionnisme se retourne contre vous. On examine cette idée plus en détail ci-dessous.

    Macro du malaise

    La chose la plus inutile et potentiellement dangereuse que vous puissiez faire est d'implémenter le contrôle des pointeurs à l'aide d'une telle macro :

    #define SAFE_FREE(ptr) if (ptr) free(ptr)

    Notre équipe a même une question d'entretien : " Qu'est-ce qui ne va pas avec cette macro ? " Tout y est mauvais . Il semble qu'une telle macro ne devrait pas exister dans la réalité, mais nous l'avons rencontrée dans des projets. Démontons-le un par un.

    Tout d'abord, cette macro est une entité redondante.

    Comme je vous disais, la fonction free gère bien les pointeurs NULL , et cette vérification ne fournit aucune sécurité supplémentaire lorsque l'on travaille avec des pointeurs.

    Deuxièmement, cette macro est également redondante en cas de micro-optimisation.

    J'ai lu dans les commentaires que la vérification supplémentaire optimise un peu le code, puisque le compilateur n'a pas à faire un appel coûteux à la fonction free . Je pense qu'il s'agit d'un non-sens et non d'une optimisation.

    Le coût de l'appel de fonction est exagéré. Dans tous les cas, ce n'est rien comparé à des opérations consommant des ressources telles que l'allocation et la désallocation de mémoires tampons. En termes d'optimisation, vous devriez vous efforcer de réduire le nombre d'opérations d'allocation de mémoire au lieu de vérifier avant d'appeler la fonction free .

    En programmation, le scénario standard est d'allouer la mémoire et de la libérer à nouveau. Les pointeurs NULL passés à free sont très probablement des cas spéciaux, rares et non standard. On n'a pas besoin de les " optimiser ". Une vérification supplémentaire serait très sûrement une pessimisation. En effet, deux vérifications sont effectuées au lieu d'un seul avant que la mémoire ne soit libérée. C'est possible que le compilateur l'optimise, mais ce cas, je ne comprends pas pourquoi on fait tant d'histoires. Au fait, puisque nous parlons d'optimisations, l'optimisation manuelle en utilisant de macros semble naïve et inutile. C'est mieux d'écrire un code simple et compréhensible plutôt que d'essayer de faire des micro-optimisations qu'un compilateur fait mieux qu'un humain.

    Je pense que cette volonté d'optimisation superflue confirme la célèbre déclaration de Donald Knuth :

    Il ne fait aucun doute que le Graal de l'efficacité conduit à des abus. Les programmeurs perdent énormément de temps à réfléchir ou à s'inquiéter de la vitesse des parties non critiques de leurs programmes, et ces tentatives d'efficacité ont en fait un impact négatif important lorsque l'on prend en compte la debugging et la maintenance. On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux.

    Troisièmement, la macro provoque des erreurs.

    Lorsqu'on utilise la macro, c'est très facile d'écrire un code incorrect.

    #define SAFE_FREE(ptr) if (ptr) free(ptr)
    ....
    if (A)
      SAFE_FREE(P);
    else
      foo();

    Le code ne se présente pas correctement. Étendrons la macro.

    if (A)
      if (P) free(P);
    else
      foo();

    L'instruction else fait référence à la deuxième instruction if et est exécutée lorsque le pointeur est NULL . Eh bien, ils ne se fonctionnent pas comme prévu. La macro SAFE_FREE s'est avérée ne pas être si " SAFE " que cela.

    Il y a d'autres façons de créer accidentellement un code incorrect. Examinons le code avec suppression d'un tableau deux dimensions.

    int **A = ....;
    ....
    int **P = A;
    
    for (....)
      SAFE_FREE(*P++);
    SAFE_FREE(A);

    Certes, le code est farfelu, mais il montre comment la macro est dangereuse lorsqu'il s'agit d'expressions complexes. Un pointeur est vérifié et le pointeur suivant est libéré :

    for (....)
      if (*P++) free(*P++);

    Il y a également un dépassement de tableau.

    En résumé, c'est mauvais.

    Peut-on fixer une macro ?

    On peut, mais on n'en a pas besoin. Examinons les solutions possibles pour y corriger — c'est à des fins éducatives uniquement. C'est aussi l'une des questions que nous posons lors des entretiens.

    Tout d'abord, on doit protéger la macro contre l'issue du else . La manière la plus simple, mais la plus inefficace, est d'ajouter des accolades :

    #define SAFE_FREE(ptr) { if (ptr) free(ptr); }

    Le code dont nous avons parlé plus haut ne sera plus compilé ( l'error: else without a previous if ) :

    if (A)
      SAFE_FREE(P);
    else
      foo();

    On peut utiliser le truc suivant :

    #define SAFE_FREE(ptr) do { if (ptr) free(ptr); } while(0)

    Le code se compile à nouveau. La première issue est résolue, mais qu'en est-il des nouveaux calculs ? Une solution standard recommandée n'existe pas. Toutefois, il y a des solutions de rechange si vous le souhaitez vraiment.

    Une issue similaire se pose lors de la mise en œuvre de macros telles que max . Voici un exemple :

    #define max(a, b) ((a) > (b) ? (a) : (b))
    ....
    int X = 10;
    int Y = 20;
    int Z = max(X++, Y++);

    21 au lieu de 20 seront écrites dans la variable Z parce que la variable Y aura été incrémentée au moment de la sélection :

    int X = 10;
    int Y = 20;
    int Z = ((X++) > (Y++) ? (X++) : (Y++));

    Pour éviter cela, on peut utiliser la magie : l'extension du compilateur GCC : referring to a Type with typeof .

    #define max(a,b) \
      ({ typeof (a) _a = (a); \
          typeof (b) _b = (b); \
        _a > _b ? _a : _b; })

    Il s'agit de copier des valeurs dans des variables temporaires et d'éliminer ainsi le calcul répété d'expressions. L'opérateur typeof est un analogue du decltype C++, mais pour C.

    Une fois encore, notez qu'il s'agit d'une extension non standard. Je ne recommande pas de l'utiliser à moins d'en avoir vraiment besoin.

    Appliquons cette méthode à SAFE_FREE :

    #define SAFE_FREE(ptr) do { \
      typeof(ptr) copy = (ptr); \
      if (copy) \
        free(copy); \
    } while(0)

    Cela fonctionne. Mais j'ai dû écrire un code terrible, insupportable et en fait inutile pour le faire.

    Une solution plus élégante consiste à convertir la macro en fonction. De cette manière, on peut éliminer les issues évoquées ci-dessus et simplifier le code :

    void SAFE_FREE(void *ptr)
    {
      if (ptr)
        free(ptr);
    }

    Attendez, attendez, attendez ! On revient à l'appel de fonction ! Sauf que maintenant, on a une couche de fonction supplémentaire. La fonction free effectue le même travail de vérification du pointeur.

    La meilleure façon de corriger la macro SAFE_FREE est donc de la supprimer !

    Remise à zéro du pointeur après free

    Il y a un sujet qui n'a presque rien à voir avec la vérification des pointeurs, mais discutons-en également. Certains programmeurs recommandent de remettre à zéro le pointeur après la libération de la mémoire. Au cas où.

    free(pfoo);
    pfoo = NULL;

    On pourrait dire que le code est écrit selon le paradigme de la programmation défensive. Je parle d'actions optionnelles extra qui permettent parfois de se prémunir contre les erreurs.

    Dans notre cas, si le pointeur pfoo n'est pas utilisé, il est inutile de le mettre à zéro. Toutefois, on peut le faire pour les raisons suivantes.

    L'accès aux pointeurs. Si des données sont écrites accidentellement dans le pointeur, il ne s'agit pas d'une corruption de la mémoire, mais d'un déréférencement du pointeur NULL . Une telle erreur est détectée et corrigée plus rapidement. La même chose se produit lors de la lecture de données à partir d'un pointeur.

    Double-free . La mise à zéro du pointeur protège contre les erreurs lorsque le tampon est à nouveau libéré. Cependant, les avantages ne sont pas aussi évidents au premier coup d'œil. Examinons le code qui contient l'erreur :

    float *ptr1;
    char *ptr2;
    ....
    free(ptr1);
    ptr1 = NULL;
    ....
    free(ptr1);  // la variable ptr2 doit être utilisée ici
    ptr2 = NULL;

    Un développeur a fait une erreur : au lieu d'écrire ptr2 , on a utilisé le pointeur ptr1 pour libérer à nouveau de la mémoire. En raison de la mise à zéro du pointeur ptr1 , rien ne se produit lorsque vous le libérez à nouveau. Le code est protégé contre l'erreur double- free . En revanche, la mise à zéro du pointeur cache l'erreur plus profondément. Il y a une fuite de mémoire qui peut être difficile à détecter.

    La programmation défensive est critiquée à cause de ces cas (masquer les erreurs, remplacer une erreur par une autre). C'est un vaste sujet, et je ne suis pas prêt à m'y plonger. Cependant, je pense qu'il est juste de vous mettre en garde contre les inconvénients de la programmation défensive.

    Quelle est la meilleure façon de procéder si vous décidez de remettre à zéro les pointeurs après avoir libéré la mémoire ?

    Commençons par la manière la plus dangereuse :

    #define FREE_AND_CLEAR(ptr) do { \
      free(ptr); \
      ptr = NULL; \
    } while(0)

    La macro n'est pas conçue pour être utilisée de cette manière :

    int **P = ....;
    for (....)
      FREE_AND_CLEAR(*P++);

    Un pointeur est libéré et le pointeur suivant est mis à zéro. Polissons la macro :

    #define FREE_AND_CLEAR(ptr)  do { \
      void **x = &(ptr); \
      free(*x); \
      *x = NULL; \
    } while(0)

    Il fait l'affaire, mais franchement, ce genre de macro n'est pas mon truc. Je préférerais que le pointeur soit explicitement mise à zéro :

    int **P = ....;
    for (....)
    {
      free(*P);
      *P = NULL;
      P++;
    }

    Le code ci-dessus est trop long, je ne l'aime pas. Il n'y a pas de magie macro. ! Je n'aime pas les macros . Le fait que le code soit long et laid est une bonne raison d'envisager sa réécriture. Est-il vraiment nécessaire d'itérer et de libérer des pointeurs d'une manière aussi maladroite ? Nous pourrions peut-être rendre le code plus élégant. C'est une bonne raison de procéder à un remaniement.

    Conclusion

    N'essayez pas de résoudre des issues inventées à l'avance et au cas où. Écrire un code simple et clair !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/mari-h/journaux/traduction-doit-on-verifier-le-pointeur-pour-null-avant-d-appeler-la-fonction-free-043c1be9-d442-49c8-bd07-a1e1a2cd5f02

    • chevron_right

      Traduction | Doit-on vérifier le pointeur pour NULL avant d'appeler la fonction free ?

      news.movim.eu / LinuxFRJournaux · 2 days ago - 10:13 · 13 minutes

    Sommaire

    La réponse brève est non. Cependant, cette question apparaît régulièrement sur Reddit, Stack Overflow et d'autres sites web, il est temps d'aborder le sujet. Il y a beaucoup de choses prenantes à réfléchir.

    Titre de l'image

    Remarque

    Bonjour! Cet article a été initialement publié sur le website PVS-Studio écrit par Andrey Karpov.
    J'ai traduit cet article théorique spécialement pour la communauté française. Bouquine bien !

    Fonction free

    La fonction free est déclarée dans le fichier d'en-tête <stdlib.h> comme suit :

    void free( void *ptr );

    La fonction libère la mémoire tampon avant alloué avec les fonctions malloc , calloc , realloc et aligned_alloc .

    Si ptr est un pointeur NULL , la fonction ne fait rien.

    Il n'est donc pas vérifier le pointeur avant d'appeler free .

    if (ptr)     // une vérification redondante
      free(ptr);

    Ce code est obsolète, car la vérification n'est d'aucune utilité. Si le pointeur est NULL , on peut le passer à la fonction free en toute sécurité. Les développeurs de la norme du C délibérément choisi cette solution :

    cppreference.com : free

    La fonction accepte (et ne fait rien avec) le pointeur null afin de réduire le nombre de cas particuliers.

    Si le pointeur est non NULL , mais toujours invalide, la vérification ne protège de rien. Un pointeur non NULL invalide est toujours passé à la fonction free , ce qui cause un comportement indéfini.

    cppreference.com : free

    Le comportement est indéfini si la valeur de ptr n'est pas égale à une valeur renvoyée précédemment par malloc() , calloc() , realloc() , ou aligned_alloc() (depuis C11).

    En outre, le comportement est indéfini si la zone de mémoire désigné par ptr a déjà été libérée, c'est-à-dire, free() , free_sized() , free_aligned_sized() , ou realloc() a déjà été appelée avec comme argument ptr et aucun appel à malloc() , calloc() , realloc() , ou aligned_alloc() abouti à un pointeur égal à ptr après.

    Par conséquent, on peut et on doit écrire simplement :

    free(ptr);

    D'où viennent les questions de la vérification préliminaire des pointeurs ?

    La documentation de la fonction free indique explicitement qu'on peut lui passer un pointeur NULL et qu'il ne pose aucun risque. Cependant, les discussions sur ce sujet continuent d'apparaître sur différents sites web. Les questions se divisent en deux catégories.

    Les questions des développeurs débutants. Ce type de questions est le plus courant. C'est simple : les gens commencent à apprendre la programmation, ne sont pas conscientes quand il faut vérifier un pointeur et quand il ne faut pas le faire. Pour les jeunes développeurs, une simple explication suffit. Lorsque vous allouez de la mémoire avec malloc, vérifiez le pointeur . (P.S. Commentaire du traducteur : malheureusement, je n'ai pas encore traduit cet article, mais une traduction est à venir :) )
    Sinon, le déréférencement d'un pointeur NULL peut causer un comportement indéfini. Avant de libérer la mémoire (en utilisant de free ), on n'a pas besoin de vérifier le pointeur, car la fonction le fera elle-même.

    Voilà, c'est tout. Un autre bon point pour un développeur débutant est d'utiliser un analyseur en ligne pour comprendre plus rapidement ce qui ne va pas dans le code.

    Les questions posées par des développeurs expérimentés et trop tatillons. C'est là que les choses deviennent intéressantes. Cette catégorie de personnes sait ce que la documentation contient. Cependant, ils posent toujours les questions parce qu'ils ne sont pas sûrs que l'appel à free(NULL) est toujours sûr. Ils s'inquiètent que leur code soit compilé sur de très vieux systèmes, où free ne garantit pas une gestion sûre des pointeurs NULL . Ou une bibliothèque tierce particulière qui implémente free d'une manière non standard (en ne vérifiant pas pour NULL ) peut être utilisée.

    On peut discuter de la théorie. En réalité, cela n'a pas de sens.

    Commençons par les anciens systèmes. Tout d'abord, il n'est pas facile de trouver un tel système. La première norme C89 montre que la fonction free doit bien gérer NULL .

    C89 : 4.10.3.2 The free function.
    La fonction free permet de désallouer l'espace pointé par ptr et le rendre disponible pour une nouvelle allocation. Si ptr est un pointeur NULL , aucune action n'a lieu.

    Deuxièmement, si vous voyez un système " pré-norm ", on ne pourra pas créer votre appli pour diverses raisons. Je doute également qu'on n'ait jamais besoin de le faire. Cette issue semble farfelue.

    Maintenant, imaginons que le système ne soit pas préhistorique, mais spécial. La bibliothèque tierce inhabituelle de fonctions système qui implémente la fonction free à sa manière : on ne peut pas passer NULL à la fonction.

    Dans ce cas, la fonction free brisée n'est pas votre plus grosse issue. Si l'une des fonctions de base du langage est brisée dans la bibliothèque, il y a beaucoup d'autres choses brisées que la dernière chose dont vous devez vous préoccuper est un appel sûr pour free .

    C'est comme être dans une voiture artisanale sans freins, sans rétroviseurs et avec un volant bloqué. Mais vous vous inquiétez de savoir si les bornes sont bien connectées à la batterie. Les bornes sont importantes, mais l'issue ne vient pas d'eux, mais de la situation dans son ensemble.

    La question de la vérification préliminaire des pointeurs est parfois abordée sous l'angle de la micro-optimisation du code : " Vous pouvez éviter d'appeler la fonction free si vous vérifiez le pointeur vous-même ". C'est là que le perfectionnisme se retourne contre vous. On examine cette idée plus en détail ci-dessous.

    Macro du malaise

    La chose la plus inutile et potentiellement dangereuse que vous puissiez faire est d'implémenter le contrôle des pointeurs à l'aide d'une telle macro :

    #define SAFE_FREE(ptr) if (ptr) free(ptr)

    Notre équipe a même une question d'entretien : " Qu'est-ce qui ne va pas avec cette macro ? " Tout y est mauvais . Il semble qu'une telle macro ne devrait pas exister dans la réalité, mais nous l'avons rencontrée dans des projets. Démontons-le un par un.

    Tout d'abord, cette macro est une entité redondante.

    Comme je vous disais, la fonction free gère bien les pointeurs NULL , et cette vérification ne fournit aucune sécurité supplémentaire lorsque l'on travaille avec des pointeurs.

    Deuxièmement, cette macro est également redondante en cas de micro-optimisation.

    J'ai lu dans les commentaires que la vérification supplémentaire optimise un peu le code, puisque le compilateur n'a pas à faire un appel coûteux à la fonction free . Je pense qu'il s'agit d'un non-sens et non d'une optimisation.

    Le coût de l'appel de fonction est exagéré. Dans tous les cas, ce n'est rien comparé à des opérations consommant des ressources telles que l'allocation et la désallocation de mémoires tampons. En termes d'optimisation, vous devriez vous efforcer de réduire le nombre d'opérations d'allocation de mémoire au lieu de vérifier avant d'appeler la fonction free .

    En programmation, le scénario standard est d'allouer la mémoire et de la libérer à nouveau. Les pointeurs NULL passés à free sont très probablement des cas spéciaux, rares et non standard. On n'a pas besoin de les " optimiser ". Une vérification supplémentaire serait très sûrement une pessimisation. En effet, deux vérifications sont effectuées au lieu d'un seul avant que la mémoire ne soit libérée. C'est possible que le compilateur l'optimise, mais ce cas, je ne comprends pas pourquoi on fait tant d'histoires. Au fait, puisque nous parlons d'optimisations, l'optimisation manuelle en utilisant de macros semble naïve et inutile. C'est mieux d'écrire un code simple et compréhensible plutôt que d'essayer de faire des micro-optimisations qu'un compilateur fait mieux qu'un humain.

    Je pense que cette volonté d'optimisation superflue confirme la célèbre déclaration de Donald Knuth :

    Il ne fait aucun doute que le Graal de l'efficacité conduit à des abus. Les programmeurs perdent énormément de temps à réfléchir ou à s'inquiéter de la vitesse des parties non critiques de leurs programmes, et ces tentatives d'efficacité ont en fait un impact négatif important lorsque l'on prend en compte la debugging et la maintenance. On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux.

    Troisièmement, la macro provoque des erreurs.

    Lorsqu'on utilise la macro, c'est très facile d'écrire un code incorrect.

    #define SAFE_FREE(ptr) if (ptr) free(ptr)
    ....
    if (A)
      SAFE_FREE(P);
    else
      foo();

    Le code ne se présente pas correctement. Étendrons la macro.

    if (A)
      if (P) free(P);
    else
      foo();

    L'instruction else fait référence à la deuxième instruction if et est exécutée lorsque le pointeur est NULL . Eh bien, ils ne se fonctionnent pas comme prévu. La macro SAFE_FREE s'est avérée ne pas être si " SAFE " que cela.

    Il y a d'autres façons de créer accidentellement un code incorrect. Examinons le code avec suppression d'un tableau deux dimensions.

    int **A = ....;
    ....
    int **P = A;
    
    for (....)
      SAFE_FREE(*P++);
    SAFE_FREE(A);

    Certes, le code est farfelu, mais il montre comment la macro est dangereuse lorsqu'il s'agit d'expressions complexes. Un pointeur est vérifié et le pointeur suivant est libéré :

    for (....)
      if (*P++) free(*P++);

    Il y a également un dépassement de tableau.

    En résumé, c'est mauvais.

    Peut-on fixer une macro ?

    On peut, mais on n'en a pas besoin. Examinons les solutions possibles pour y corriger — c'est à des fins éducatives uniquement. C'est aussi l'une des questions que nous posons lors des entretiens.

    Tout d'abord, on doit protéger la macro contre l'issue du else . La manière la plus simple, mais la plus inefficace, est d'ajouter des accolades :

    #define SAFE_FREE(ptr) { if (ptr) free(ptr); }

    Le code dont nous avons parlé plus haut ne sera plus compilé ( l'error: else without a previous if ) :

    if (A)
      SAFE_FREE(P);
    else
      foo();

    On peut utiliser le truc suivant :

    #define SAFE_FREE(ptr) do { if (ptr) free(ptr); } while(0)

    Le code se compile à nouveau. La première issue est résolue, mais qu'en est-il des nouveaux calculs ? Une solution standard recommandée n'existe pas. Toutefois, il y a des solutions de rechange si vous le souhaitez vraiment.

    Une issue similaire se pose lors de la mise en œuvre de macros telles que max . Voici un exemple :

    #define max(a, b) ((a) > (b) ? (a) : (b))
    ....
    int X = 10;
    int Y = 20;
    int Z = max(X++, Y++);

    21 au lieu de 20 seront écrites dans la variable Z parce que la variable Y aura été incrémentée au moment de la sélection :

    int X = 10;
    int Y = 20;
    int Z = ((X++) > (Y++) ? (X++) : (Y++));

    Pour éviter cela, on peut utiliser la magie : l'extension du compilateur GCC : referring to a Type with typeof .

    #define max(a,b) \
      ({ typeof (a) _a = (a); \
          typeof (b) _b = (b); \
        _a > _b ? _a : _b; })

    Il s'agit de copier des valeurs dans des variables temporaires et d'éliminer ainsi le calcul répété d'expressions. L'opérateur typeof est un analogue du decltype C++, mais pour C.

    Une fois encore, notez qu'il s'agit d'une extension non standard. Je ne recommande pas de l'utiliser à moins d'en avoir vraiment besoin.

    Appliquons cette méthode à SAFE_FREE :

    #define SAFE_FREE(ptr) do { \
      typeof(ptr) copy = (ptr); \
      if (copy) \
        free(copy); \
    } while(0)

    Cela fonctionne. Mais j'ai dû écrire un code terrible, insupportable et en fait inutile pour le faire.

    Une solution plus élégante consiste à convertir la macro en fonction. De cette manière, on peut éliminer les issues évoquées ci-dessus et simplifier le code :

    void SAFE_FREE(void *ptr)
    {
      if (ptr)
        free(ptr);
    }

    Attendez, attendez, attendez ! On revient à l'appel de fonction ! Sauf que maintenant, on a une couche de fonction supplémentaire. La fonction free effectue le même travail de vérification du pointeur.

    La meilleure façon de corriger la macro SAFE_FREE est donc de la supprimer !

    Remise à zéro du pointeur après free

    Il y a un sujet qui n'a presque rien à voir avec la vérification des pointeurs, mais discutons-en également. Certains programmeurs recommandent de remettre à zéro le pointeur après la libération de la mémoire. Au cas où.

    free(pfoo);
    pfoo = NULL;

    On pourrait dire que le code est écrit selon le paradigme de la programmation défensive. Je parle d'actions optionnelles extra qui permettent parfois de se prémunir contre les erreurs.

    Dans notre cas, si le pointeur pfoo n'est pas utilisé, il est inutile de le mettre à zéro. Toutefois, on peut le faire pour les raisons suivantes.

    L'accès aux pointeurs. Si des données sont écrites accidentellement dans le pointeur, il ne s'agit pas d'une corruption de la mémoire, mais d'un déréférencement du pointeur NULL . Une telle erreur est détectée et corrigée plus rapidement. La même chose se produit lors de la lecture de données à partir d'un pointeur.

    Double-free . La mise à zéro du pointeur protège contre les erreurs lorsque le tampon est à nouveau libéré. Cependant, les avantages ne sont pas aussi évidents au premier coup d'œil. Examinons le code qui contient l'erreur :

    float *ptr1;
    char *ptr2;
    ....
    free(ptr1);
    ptr1 = NULL;
    ....
    free(ptr1);  // la variable ptr2 doit être utilisée ici
    ptr2 = NULL;

    Un développeur a fait une erreur : au lieu d'écrire ptr2 , on a utilisé le pointeur ptr1 pour libérer à nouveau de la mémoire. En raison de la mise à zéro du pointeur ptr1 , rien ne se produit lorsque vous le libérez à nouveau. Le code est protégé contre l'erreur double- free . En revanche, la mise à zéro du pointeur cache l'erreur plus profondément. Il y a une fuite de mémoire qui peut être difficile à détecter.

    La programmation défensive est critiquée à cause de ces cas (masquer les erreurs, remplacer une erreur par une autre). C'est un vaste sujet, et je ne suis pas prêt à m'y plonger. Cependant, je pense qu'il est juste de vous mettre en garde contre les inconvénients de la programmation défensive.

    Quelle est la meilleure façon de procéder si vous décidez de remettre à zéro les pointeurs après avoir libéré la mémoire ?

    Commençons par la manière la plus dangereuse :

    #define FREE_AND_CLEAR(ptr) do { \
      free(ptr); \
      ptr = NULL; \
    } while(0)

    La macro n'est pas conçue pour être utilisée de cette manière :

    int **P = ....;
    for (....)
      FREE_AND_CLEAR(*P++);

    Un pointeur est libéré et le pointeur suivant est mis à zéro. Polissons la macro :

    #define FREE_AND_CLEAR(ptr)  do { \
      void **x = &(ptr); \
      free(*x); \
      *x = NULL; \
    } while(0)

    Il fait l'affaire, mais franchement, ce genre de macro n'est pas mon truc. Je préférerais que le pointeur soit explicitement mise à zéro :

    int **P = ....;
    for (....)
    {
      free(*P);
      *P = NULL;
      P++;
    }

    Le code ci-dessus est trop long, je ne l'aime pas. Il n'y a pas de magie macro. ! Je n'aime pas les macros . Le fait que le code soit long et laid est une bonne raison d'envisager sa réécriture. Est-il vraiment nécessaire d'itérer et de libérer des pointeurs d'une manière aussi maladroite ? Nous pourrions peut-être rendre le code plus élégant. C'est une bonne raison de procéder à un remaniement.

    Conclusion

    N'essayez pas de résoudre des issues inventées à l'avance et au cas où. Écrire un code simple et clair !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/mari-h/journaux/traduction-doit-on-verifier-le-pointeur-pour-null-avant-d-appeler-la-fonction-free

    • chevron_right

      Quand votre voiture vous espionne… et vous le fait payer

      news.movim.eu / LinuxFRJournaux · 3 days ago - 18:37 · 4 minutes

    Ceci se passe aux États-Unis, pour l’instant, aucune preuve qu’une telle fuite existe en Europe. Mais… si votre assurance augmente brutalement, méfiez-vous, les voitures ont des oreilles.

    Voici le lien du NYT, Automakers Are Sharing Consumers’ Driving Behavior With Insurance Companies du 11 mars qui a attiré mon attention sur ce sujet (c’est en loginwall, mais le mode « reader view » du brosseur permet la lecture de l’entrefilet). Developpez.com reprend en français cette information et la, euh…, développe. Également en français, un journal canadien, annuelauto.ca

    Pour résumer, c’est l’histoire arrivée à Kenn Dahl, un bon conducteur avec zéro accident. Mais voici que quelque temps après avoir acheté une Chevrolet en leasing, il voit sa prime d’assurance augmenter drastiquement (21 %, quand même). Il cherche alors à changer de boîte, mais toutes les assurances contactées lui donne un prix équivalent. Un agent lui lâche quand même le morceau, ils se basent sur l’évaluation de risques d’un « data brocker », LexisNexis.

    Il se fait alors remettre par cette boîte les informations le concernant, comme la loi lui en donne la possibilité, et découvre avec stupeur et horréfaction qu’il y a 130 pages détaillant ses déplacements, sa manière de conduire, de freiner, d’accélérer, de doubler, le nombre de freinages brutaux et d’accélérations vitaminées, la manière de se mettre en marche quand un feu passe au vert, enfin, une étude physio-psychologique du conducteur à laquelle ne manque que les destinations des trajets.

    Cette collecte est pour l’instant illégale, surtout que Dahl affirme qu’il n’a jamais signé d’agrément pour autoriser la collecte de ses données personnelles, contrairement à ce qu’affirme le constructeur, mais il est évident que sa légalisation nous pend au nez, à l’heure où plusieurs États ainsi qu’Europol font le forcing pour que le chiffrement des échanges entre particuliers soit muni d’une porte, non pas dérobée mais privée et réservée à la police (et aux black-hackers).

    De plus, l'insistance du constructeur à dire qu'un consentement a été signé à l'achat augure de ce qui peut facilement arriver : une petite croix dans une liasse de 20 pages au moment de signer le contrat de leasing ou de vente, et le tour est joué.

    Un lien posté par Volts en septembre 2023 pointait déjà vers un rapport de Mozilla dénonçant la situation actuelle.

    Certains, par exemple @marcel-les-bretelles sur le blog www .le-café-du-commerce .fr pourraient prétendre que ça ne serait que justice qu’un conducteur nerveux et donc plus “risky” paie son assurance plus cher pour que les conducteurs normaux normés soient taxés moins chers (un peu comme le coup des valoches payantes dans les avions auraient dû faire baisser les prix des billets, hum), mais ici, sur linuxfr, on est conscient du danger que représente l’espionnage touzazimuth. À commencer par « Un chat sur la route ! Ne pas freiner surtout, sinon ma prime augmente » pour finir par « Ce dangereux terroriste militant écologique a laissé sa voiture à la gare de *** à 20h43, juste à temps pour prendre le train qui pouvait l’amener à la manif (autorisée) de ***"

    De fait, il y a eu une inversion du principe de la présomption d’innocence après les attentats du 11 septembre, et cette inversion est appliquée de plus en plus généralement. Dans le cas présent, ça n’est plus la culpabilité (l’accident) qui provoque la sanction (l’augmentation), la situation s’est inversée et chaque conducteur est présumé coupable et doit prouver par sa manière de conduire qu’il est soupçonné à tort et ne mérite pas l’augmentation. Ou du moins ce raisonnement leur paraît tellement évident que les assurances l'appliquent au mépris de la loi (qui finira bien par s'adapter à ce nouveau paradigme, sur ce sujet comme elle le fait pour de nombreux autres).

    Bien entendu, la prolifération et l’interconnexion des fichiers de police procède du même principe, chaque citoyen doit être identifiable sur le champ et profilable : empreintes digitales stockées et consultables pour l’ensemble de la population, empreinte génétique se généralisant, scannage systématique des rézossocios, enregistrement par les FAI de tous les sites internet consultés, tout le monde est par définition susceptible d’être coupable un jour ou l’autre, tant mieux pour lui s’il ne l’est pas. Le forcing pour autoriser la reconnaissance faciale systématique dans les espaces publics est une tentative de passer à la vitesse supérieure.

    On parle de monde orwellien. Je n’aime pas cette expression, Orwell était un écrivain hautement respectable, et je préfère l’expression big-brotherien . Mais en fait, on en est bien au-delà. Orwell avait prévu de forme prémonitoire la fusion entre les capitalismes d’entreprises et bureaucratiques, mais il s’était trompé sur lequel des deux types prédominerait. Et comme l’inverse est arrivé, bien qu’une bonne partie de ses pré-visions se sont réalisées, la haute technicité de l’époque (pour lui) à venir lui a échappé, et il n’a pas su entrevoir les monstrueuses possibilités de contrôle, tant mentales que physiques, qui allaient advenir dans le monde pour lui futur mais pour nous bel et bien (ou plutôt moche et mal) présent.

    Enfin, pour revenir au sujet des assurances, voici un article du Presse-citron qui étudie les effets surprenants de la sur-technologie automobile sur les primes d’assurance.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/sebas22/journaux/quand-votre-voiture-vous-espionne-et-vous-le-fait-payer

    • chevron_right

      leboncoin : dysfonctionnements ou détournements ?

      news.movim.eu / LinuxFRJournaux · 3 days ago - 08:17 · 1 minute

    Depuis plusieurs mois, je constate des dysfonctionnements avec le porte-monnaie sur leboncoin.fr. Lorsqu'un achat est fait, le porte-monnaie est bien débité. Lorsque l'achat est annulé par le vendeur (pièce perdue etc.), la somme débitée n'est parfois pas re-créditée. Et si elle est re-créditée, le solde du porte-monnaie n'est lui pas toujours mis à jour. Du coup, quand je fais la somme de toutes les opérations affichées depuis la création du porte monnaie, elle diffère du solde du porte-monnaie, l'écart se creuse.

    Le souci avec le support client, c'est qu'on ne peut le joindre que depuis leur formulaire et que les réponses sont sans rapport avec les réclamations voire complètement fausses. On jurerait que c'est une IA qui répond. Depuis des mois, je me heurte à ce mur.
    J'ai écrit au médiateur, pas de réponse. J'ai fait un signalement sur https://signal.conso.gouv.fr/fr , fin de non recevoir.

    Exemple dernièrement :

    Achat avec débit de 6,01 € et aucun remboursement qui apparaît : https://ibb.co/tpP3N8z
    Demande au support : https://ibb.co/r7C0VQJ
    Réponse fausse, comme à chaque fois : https://ibb.co/N1fBmL5

    Ce sont de petites sommes mais si c'est le cas avec tous les utilisateurs, ça va vite faire des millions d'€.
    Si vous utilisez ce service, je vous conseille vivement de vérifier en détails vos opérations et votre solde. Je cherche d'autres témoignages.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/qui/journaux/leboncoin-dysfonctionnements-ou-detournements

    • chevron_right

      Traduction : Aux sources du complotisme

      news.movim.eu / LinuxFRJournaux · 4 days ago - 07:52 · 23 minutes

    Sommaire

    Contexte

    Dans cet article C. Doctorow se base sur son expérience personnelle parallèle à celle des anti-vax pour identifier une origine originale du phénomène complotiste et en proposer une analyse singulière. Les complotisme en tout genre produisant régulièrement des résurgences sur Linuxfr, il m'a semblé intéressant d'en proposer une traduction ici.

    Traduction

    Conspirationnisme et crise de la connaissance

    L’an passé, Ed Pierson devait prendre un vol Alaska Airlines de Seattle au New Jersey. Il embarqua, puis il s’est empressé de discuter avec le personnel de bord, expliquant qu’en tant qu’ancien ingénieur senior chez Boeing, il avait soigneusement sélectionné ce vol afin d’éviter de voler en 737 Max :

    https://www.cnn.com/travel/boeing-737-max-passenger-boycott/index.html

    Mais pour des raisons techniques, Alaska Airlines avait changé d’appareil, et il se trouvait justement à bord d’un 737 Max, sur le point de traverser un continent, et ne se sentant absolument en sécurité pour ce faire. Il demanda à débarquer. Ses bagages furent déchargés et il rebroussa chemin par le pont d’embarquement en déclarant à un personnel de bord effrayé, « impossible de vous expliquer précisément à l’instant, mais je ne prévoyais pas de voler à bord d’un Max, et je veux descendre de cet avion. »

    Le désastre volant qu’est Boeing ne s’est bien entendu pas construit en un jour. Leurs avions ont commencé à pleuvoir depuis 2019. Un tsunami de lanceurs d’alertes a déferlé pour dénoncer ces avions dangereux. Pierson est loin d’être l’unique employé à affirmer — tant ouvertement qu’en privé — qu’il ne volerait pas sur tel ou tel modèle, voire pour certains, sur aucun Boeing récent :

    https://pluralistic.net/2024/01/22/anything-that-cant-go-on-forever/#will-eventually-stop

    Et pourtant, des années durant, les autorités de régulation de Boeing ont autorisé cette compagnie à lancer des appareils qui s’avéraient des cailloux. Guère rassurant, à tout le moins. Je ne suis ni ingénieur aérospatial, ni inspecteur de la sécurité aérienne, mais chaque fois que je réserve un vol, je dois décider si je peux faire confiance à Boeing pour ne pas mourir d’avoir embarqué sur l’un de leurs engins.

    Dans un monde parfait, je n’aurais même pas à m’en préoccuper. Les agences de surveillance gouvernementale, responsables de la sécurité publiques s’en chargeraient, assurant que les avions soient fiables en vol. « Caveat emptor » (NdT : craint acquéreur, fameuse locution latine décrivant l’état d’esprit des acheteurs dans un marché anomique) n’est en aucun cas la bonne manière de gérer l’aviation civile.

    Quoique n’ayant nullement l’expertise pour décider de la fiabilité des boeings, je possède celle bien plus générique qui permet de se prononcer sur la fiabilité de la régulation de l’aviation civile. La FAA (administration de l’aviation fédérale) n’est qu’obséquieuses courbettes devant Boeing depuis belle lurette, au point de les autoriser à auto-certifier que leurs avions sont sûrs. Et elle persévéra dans cette pratique de laisser Boeing évaluer ses propres productions, quand bien même les assertions de Boeing eurent-elles coûté des centaines de vies.

    https://www.youtube.com/watch?v=Q8oCilY4szc

    De surcroît, le patron de la FAA qui a présidé à ces centaines de décès est un ancien lobbyiste de Boeing, nommé par Trump pour les superviser. Ce n’est pas le seul ancien de la maison à finir en régulateur, et inversement nombre d’anciens officiels sont désormais des employés de la maison :

    https://therevolvingdoorproject.org/boeing-debacle-shows-need-to-investigate-trump-era-corruption/

    Inutile d’être un expert en aviation pour comprendre qu’une compagnie est face à un conflit d’intérêt quand il s’agit de certifier ses propres produits. Les « forces du marché » n’empêcheront pas Boeing de fourguer des produits défectueux, car les huiles de la compagnie sont bien plus préoccupées de profiter des rachats massifs d’actions saisonniers qu’elles ne s’intéressent à la capacité de leurs successeurs à gérer les tempêtes médiatiques ou les audiences au Congrès qui découleront des centaines et centaines de morts provoquées par leur cupidité.

    Pareillement inutile d’être un expert pour comprendre que ces conflits persistent quand un employé de Boeing quitte la compagnie pour travailler à sa supervision ou inversement. Un superviseur qui anticipe un mega bonus de la part de Boeing une fois son service achevé, ou un ancien directeur de Boeing qui détient des millions en actions font face à un insoluble conflit d’intérêt qui leur rendra extrêmement délicat — voire impossible — de tenir la compagnie responsable de ces bénéfices réalisés aux détriments de la sécurité.

    De manière tout à fait justifiée, les clients de Boeing ne sont pas les seuls à devoir s’inquiéter d’un système avec de tels conflits d’intérêt : Les propres cadres, lobbyistes, et avocats de Boeing refuseraient également de participer à un système de résolution des conflits du même acabit, c’est-à-dire complètement biaisé par les conflits d’intérêts. Si Boeing était poursuivi par ses actionnaires et que le juge soit l’un d’eux, ils demanderaient sa récusation. Si Boeing recherchait un avocat pour une audience de responsabilité dans des poursuites portées par la famille de l’une de leurs victimes assassinées, ils ne recruteraient assurément pas le cabinet qui les poursuit — même si ce dernier promet d’être équitable. Si l’épouse d’un dirigeant de Boeing demande le divorce devant la justice, ce dirigeant choisira-t-il le même avocat que sa future ex-épouse ?

    Évidemment qu’il faut des connaissances et une formation appropriée pour être avocat, juge, ou inspecteur de la sécurité aérienne. En revanche, n’importe qui peut se rendre compte des plus criants défauts d’organisation du système dans lequel travaillent ces gens. Autrement dit, alors qu’acquérir de l’expertise est difficile, il est bien plus aisé de remarquer les déficiences des systèmes par lesquels ces expertises affectent le monde qui nous entoure.

    Et c’est là que se trouve le problème : l’aérien est loin d’être l’unique secteur, techniquement complexe, potentiellement fatal, profondément et évidemment indigne de confiance qu’il nous faille pratiquer. Qu’en est-il des codes et règlements de la construction qui régissent le bâtiment dans lequel vous vous trouvez ? Beaucoup ont présumé allègrement que des ingénieurs en génie civil avaient soigneusement conçu ces standards, et que ces derniers ont été rigoureusement mis en œuvre, pour découvrir tragiquement et de la manière la plus atroce qu’il n’en était rien.

    https://www.bbc.com/news/64568826

    Quotidiennement, il faut résoudre des douzaines — des centaines mêmes ! — de questions de vie ou de mort hautement techniques. Devez-vous faire confiance au logiciel de l’ABS (système antiblocage lors du freinage) de votre voiture ? Qu’en est-il des règlementations sanitaires dans les usines qui produisent l’alimentation dans votre chariot de supermarché ? ou dans la pizzeria qui vient de vous livrer ? L’école de vos enfants leur enseigne-t-elle correctement, ou grandiront-ils ignorant pour devenir des laissés pour compte ?

    Bon sang, même si je ne devais plus jamais prendre un Boeing, j’habite sous le couloir d’approche de l’aéroport de Burbank, où Southwest fait atterrir plus de 50 Boeing quotidiennement. Comment être certain que le prochain 737 Max qui décrochera n’atterrira pas sur mon toit ?

    C’est la crise épistémologique de notre temps. L’épistémologie est au fondement de notre connaissance. (NdT : « [ …C]’est […] l’épistémologie qui est seule compétente pour décider si les cadres de référence du vrai correspondent, oui ou non, aux cadres du réel… » (TILF)) Le but ultime de processus transparents et démocratiques pour les délibérations techniques est de résoudre ce défi épistémologique qui conduit à faire les bons choix pour toutes ces questions quotidiennes de vie ou de mort. Même les plus brillants parmi nous ne peuvent acquérir l’expertise pour l’ensemble de ces questions ; mais nous sommes tous à même de comprendre les processus qui les traitent ces et d’en juger la pertinence.

    Le processus est-il public ? Les responsables en sont-ils honnêtes ? Ont-ils des conflits d’intérêts, et si oui participent-ils à quelque décision d’une manière qui semble inappropriée ? Si de nouveaux éléments apparaissent — disons un drame horrible — y a-t-il moyen de réviser le processus et d’adapter les règles ?

    Le détail précis peut parfaitement être opaque et indéchiffrable, une boîte noire pour nous tous. Mais la boîte noire elle-même peut être observée : est-elle résistante ? a-t-elle des sommets pointus ? des arêtes nettes ? où est-elle bancale, irrégulière, et bordée de bavures ? Inutile de connaître le contenu de la boîte pour décider de la confiance à lui accorder.

    Par exemple, nous ne sommes pas tous experts en chimie et potabilité, mais nous sommes à même de savoir si une agence de régulation est sur de bon railles ou non en la matière. En 2019, la direction de la protection environnementale de l’ouest viriginien (WV) a lancé une consultation publique. Dow Chemical — la plus grosse compagnie de l’industrie la plus massive de l’état — a répondu, argumentant que la WV devrait abaisser ses standards quant à la contamination des eaux potables.

    Soit, je suis parfaitement prêt à croire qu’un certain niveau de résidus chimiques est acceptable dans l’eau courante. Il y a beaucoup d’eau, et « c’est la dose qui fait le poison. » Comme en plus, je me trouve être l’un des usagers des produits dont la production aboutit à ces déchets… Je souhaite qu’ils soient produits, de manière sûre certe, mais je tiens surtout à ce qu’ils le soient — juste un exemple, la prochaine fois que je passe sur le billard, rien qu’au tout début, je préfère vraiment que l’anesthésiste travail avec une perfusion neuve aux tubulures stériles.

    Et je ne suis pas un chimiste, encore moins un spécialiste de la chimie de l’eau ; pas plus qu’un toxicologue. Certains aspects du débat me sont parfaitement étrangers. Nonobstant, je ne peux m’empêcher de penser que la méthodologie employer par la WV est bancale, en voici la raison.

    https://www.wvma.com/press/wvma-news/4244-wvma-statement-on-human-health-criteria-development

    Il s’agit du mémoire de Dow adressé à son agence de régulation (tel que proféré par sa marionnette, l’association des industriels de WV). Dans ce commentaire, Dow argumente que les citoyens de l’Ouest de la Virginie peuvent absorber en toute sécurité plus de poison que les autres Américains, parce qu’ils sont plus gras que les autres, qu’ils ont donc plus de tissus corporels, et qu’ils supportent donc de plus grandes doses de poison par personne que l’Américain moyen. Mais Dow ne s’arrête pas là. Ils affirment aussi que les habitants de l’ouest de la Virginie boivent moins d’eau que leurs voisins des autres états, lui préférant de la bière, et qu’ainsi, même si leur eau est plus toxique, comme ils en boivent moins…

    https://washingtonmonthly.com/2019/03/14/the-real-elitists-looking-down-on-trump-voters/

    Même sans aucune expertise en toxicologie ou en chimie des solutions, je peux affirmer que cette argumentation est de la bouse. Le seul fait que les autorités de WV acceptent un tel memorandum démontre qu’elles ne font pas correctement leur travail.

    Même sans aucune expertise, il est parfaitement raisonnable de rejeter les conclusions des experts si le processus d’expertise est parfaitement corrompu et biaisé au-delà de toute possibilité de rédemption. Mais certains rejets coûtent cher — aussi bien pour celui qui refuse que pour son entourage — plus que de choisir de l’eau de bouteille à Charleston.

    Prenez les antivax (ou les « hésitants » à se faire vacciner). De nombreuses personnes ont accueillie l’avènement extrêmement rapide d’un vaccin anti-covid ultra moderne avec crainte et défiance. Ils affirmaient que l’industrie pharmaceutique était dominée par des corrompus, composée de corporations avides privilégiant usuellement leur profit au bien public, et que les autorités de supervision étaient dans leur poche au point de les blanchir d’éventuels meurtres de masse.

    En fait… tout ça est on ne peut plus véridique. Pourtant j’ai reçu cinq doses de vaccin anti-covid, mais en aucun cas parce que je ferais confiance aux industries pharmaceutiques. J’ai personnellement expérimenté leur manière d’immoler la sécurité sur l’autel de la cupidité, et échappé d’un cheveu à des dégâts pour ma santé. Toute ma vie j’ai souffert de douleurs chroniques empirant d’année en année. Quand mon épouse était enceinte de notre fille, il m’a semblé que ces douleurs m’empêcheraient d’être un bon père — je souhaitais pouvoir la porter longtemps ! — j’ai donc repris activement la quête, longuement délaissée, d’un traitement.

    Ça m’a mené chez une foule de spécialistes — physiologistes, diététiciens, addictologues, neurologues, chirurgiens — et j’ai essayé des tas et des tas de traitements. Heureusement, mon épouse avait une mutuelle personnelle — nous étions alors au Royaume-Uni — et je pouvais essayer n’importe quel traitement d’apparence prometteuse. C’est ainsi que je me suis retrouvé dans les bureaux d’un charlatan d’Harley Street (NdT : fameuse rue des médecins à Londres), un f[au]meux spécialiste de la douleur, qui avait de grandes nouvelles pour moi : il s’avérait que les opioïdes étaient bien plus sains qu’on ne l’avait cru jusque-là, et il m’était recommandé d’en prendre jours et nuits jusqu’à la fin de mes jours ; aucun risque d’addiction ; tout planerait !

    Ces sornettes ne sonnaient pas honnêtes à mes oreilles. Plusieurs de mes amis sont morts d’overdoses, et j’en ai vu d’autres déchoir dans la spirale de la misère au fur de leur lutte contre l’addiction. J’ai donc fait mes propres recherches. N’ayant aucune formation en biologie, chimie, neurologie, ou pharmacologie, je me suis battu avec des monceaux d’articles et autres commentaires pour arriver à la conclusion que les opioïdes étaient tout sauf sûres. Tout au contraire, des milliardaires corrompues comme la famille Sackler avaient fait collusion avec les autorités pour risquer les vies de millions de gens en promouvant des recherches falsifiées dans les meilleures revues scientifiques à comité de lecture.

    Voici comment je suis devenu un anti-opioïde.

    J’ai décidé, en me basant sur mes propres recherches, que les experts avaient torts, et ce pour cause de corruption, et que je ne pouvais leur faire confiance.

    Quand les anti-vax ont décrié les vaccins contre le covid, ils disaient des choses qui — au moins sur la forme — étaient indistinguables de mes propres propos quinze ans plus tôt lorsque je décidais d’ignorer les recommandations de mon médecin et de balancer mes médocs en pensant que ça me ferait probablement du mal.

    Pour moi, la foi dans les vaccins ne provient pas de la découverte d’une immense et nouvelle confiance dans l’industrie pharmaceutique. Plutôt, j’ai considéré que la focalisation du public sur le sujet était telle qu’elle terrasserait jusqu’à la corruption bien ancrée de dealers des produits qu’en secret les industrielles savent néfastes :

    https://www.npr.org/2007/11/10/5470430/timeline-the-rise-and-fall-of-vioxx

    Mais nombres de mes pairs avaient une appréciation fort différente des anti-vax. Pour ces amis et collègues, ils étaient juste insensés. Étrangement, ces gens avec qui je me sentais largement en accord ont commencé à défendre le système pharmaceutique et ses autorités. Dès qu’ils ont vu les anti-vax comme l’avant-garde des lobotomisés anti-culture de droite, ils ont basculé de pro-vax à pro-pharma !

    Ce phénomène a un nom : la schizogenèse (NdT : dans ce sens, il s’agit d’un néologisme emprunté à l’Anglais, j’ai conservé la graphie française dans cette traduction.). Ce terme décrit la manière de choisir son camp par rapport à un problème en considérant les parties prenantes. Pensez par exemple aux progressistes américains auto-proclamés qui sont devenus les fervents supporters de l’impitoyable, sans foi ni loi, police spéciale quand elle collait aux basques de Trump :

    https://pluralistic.net/2021/12/18/schizmogenesis/

    Le fait que le FBI n’aime pas Trump n’en fait aucunement un allié des causes progressistes. C’était, et ça reste l’entité qui (parmi d’autres choses) à tentée de pousser au suicide Martin Luther King :

    https://en.wikipedia.org/wiki/FBI%E2%80%93King_suicide_letter

    Mais la schizogenèse ne peut être considérée uniquement comme une manière très hasardeuse de choisir son camp en se basant sur des inimitées communes. Bien plutôt il s’agit d’une tactique épistémologiquement raisonnable : Dans un monde où vous vous trouvez cernés par bien plus de problèmes à résoudre que vous ne le pouvez réellement, des raccourcis de raisonnement sont indispensables. L’un d’eux — un de ceux qui vous conduisent invariablement dans une impasse — serait de dire, « je prêterais foi à tout ce que les experts officiels affirmeront. » Un autre raccourcit serait « désormais je ne croirais plus rien de ce qu’affirment les gens dont je sais qu’ils agissent de mauvaise foi. » Voilà ce qu’est la schizogenèse.

    La schizogenèse n’est pas une tactique optimale. Il serait infiniment préférable de disposer d’institutions de confiance ; soit, que les boîtes noires des débats d’experts soient parfaitement fiables.

    Mais elles sont loin de l’être. Nos autorités déconnent. La concentration du capital est telle qu’il est trivial pour les cartels de piéger les institutions, de les orienter vers des conclusions qui bénéficient aux actionnaires même si cela doit coûter énormément — même des masses de décès — au public.

    https://pluralistic.net/2022/06/05/regulatory-capture/

    Personne n’exècre les géants de la tech plus que moi, mais nombre de mes cobelligérants dans la guerre contre ces puissances croient que la montée du conspirationnisme est de leur ressort. Ils notent les fanfaronnades de la tech quant à sa capacité à manipuler nos opinions, et attribuent la multiplication des qanons, platistes, et autres zinzins adeptes de quelque conspirationnisme au mésusage de ces algorithmes.

    « Nous disposons du rayon qui contrôle les esprits » est l’une de ces affirmations extraordinaires qui nécessitent des preuves extraordinaires. Mais les indices de la capacité des géants de la tech à manipuler les esprits sont on ne peut plus légers : essentiellement, il ne s’agit que de leurs propres prétentions à destination de leurs investisseurs et de leurs clients pour fourguer leurs produits. « Nous pouvons orienter les esprits, » vieille rengaine de publicitaire. Et clairement ils le peuvent en ce qui concerne l’avis des consommateurs sur la publicité.

    Considérez le magnat de la grande distribution John Wanamaker, resté dans les mémoires pour avoir déclaré « la moitié de l’argent que je dépense en publicité est perdu ; le problème est que j’ignore laquelle. » Aujourd’hui, grâce à la surveillance commerciale, nous savons que la vraie proportion du gâchis publicitaire est plutôt proche de 99,9%. On peut probablement argumenter que grâce à d’intense et prolongées campagnes personnalisées, les agences de publicités sont effectivement capables de toucher John Wannamaker et ses successeurs ; mais cela ne signifie nullement qu’elles arrivent à atteindre le reste d’entre nous avec leur bombardement de bannières publicitaires et de spam :

    http://pluralistic.net/HowToDestroySurveillanceCapitalism

    Autrement dit, ce n’est pas parce que Facebook se prétend très convaincant qu’il l’est. À l’instar des compagnies d’intelligence artificielle qui prétendent que leurs modèles de langages peuvent faire votre travail : elles sont bien meilleures à convaincre votre patron (obsédé par l’idée de virer des travailleurs) qu’elles ne sont réellement capables de produire un algorithme qui puisse vous remplacer. Ce qui est logique car leur rentabilité dépend infiniment plus de leur capacité à convaincre des nababs crédules dotés d’un fort pouvoir décisionnaire que de la mise au point d’une technologie productive.

    Pour en revenir à notre sujet, je crois que Facebook et consorts jouent un rôle crucial dans la montée des conspirationnismes. Nonobstant, ce rôle n’implique pas d’algorithmes à persuader les gens de se défier des institutions. Plutôt, les géants de la tech — comme tout cartel — corrompent tant les institutions qu’il en devient irrationnel d’accorder de la confiance à ces dernières !

    Prenons l’exemple des lois sur la vie privée. Le dernier texte fédéral aux USA sur ce sujet remonte à 1988, lorsque le Congrès a passé le Video Privacy Protection Act, une loi interdisant aux vidéostores de déballer l’historique de vos locations :

    https://www.eff.org/deeplinks/2008/07/why-vppa-protects-youtube-and-viacom-employees

    C’était très ponctuel. En lien avec les géants de la tech, d’évidents soucis pour la vie privée hantent les Américains ; et malgré tout le mieux que pourrait faire le Congrès en la matière serait de tenter de forcer la vente du seul géant Chinois ayant une emprise aux USA à une entreprise nationale, afin de s’assurer que ses violations systémiques de la vie privée soient dirigées par nos concitoyens, et de forcer les espions chinois à acheter leurs données de surveillance concernant des millions d’Américains, dans la gabegie anomique et nauséabonde des grossistes en données Américains.

    https://www.npr.org/2024/03/14/1238435508/tiktok-ban-bill-congress-china

    Pour des millions d’Américains — particulièrement les jeunes — l’échec à voter (et même à seulement proposer !) une réglementation fédérale sur la vie privée démontre la versatilité de nos institutions. Ils ne se trompent pas :

    https://www.tiktok.com/@pearlmania500/video/7345961470548512043

    Le principe du rasoir d’Ocam nous enjoint de chercher l’explication la plus simple pour les événements de notre environnement. Il y a justement une explication bien plus simple des raisons qui poussent les gens à croire dans des théories du complot qu’ils trouvent en ligne que d’inférer que l’unique occurrence où Facebook dirait la vérité serait justement quand ils fanfaronnent sur l’efficacité de leurs produits.

    Peut-être que si les gens croient dans les théories complotistes c’est parce qu’ils ont au quotidien des centaines de questions de vie ou de mort à trancher, et que les institutions censées rendre cela possible persiste à se démontrer versatiles. Ces décisions doivent néanmoins être prises, quelque chose doit donc venir remplir le vide épistémologique créé par la boîte noire manifestement bancale où les décisions devraient être prises.

    Pour beaucoup — des millions — ce qui rempli ce vide, ce sont des fantasmes complotistes. La technologie les rend plus faciles à fréquenter que jamais, et facilite également les contacts entre crédules. Mais la vulnérabilité aux conspirationnismes que les algorithmes identifient et sur la base de laquelle ils ciblent les gens n’est pas produite par le Big Data. C’est le produit de la corruption — de la vie dans un monde dans lequel les véritables conspirations (pour détourner vos salaires, ou laisser les riches échapper aux conséquences de leurs crimes, ou sacrifier votre sécurité pour protéger les profits de grandes firmes) sont omniprésentes.

    Les progressistes — soit la coalition des libéraux et des gauchistes (NdT en termes français les socialistes et l’extrême gauche), dans laquelle les gauchistes font figures de perpétuels mineurs quand leurs partenaires contrôlent la fenêtre du discours — étaient coutumiers d’identifier et de dénoncer ces conspirations. Mais quand les trumpistes, soi-disant populistes, s’y sont déclarés opposés — quand Trump a maudit le marché libre et les médias grands publics en tant qu’outils de domination de l’élite — les progressistes ont glissé dans la schizogenèse et déclaré bruyamment leur soutien à ces vieux ennemis du progrès.

    C’est le point crucial du brillant roman de Naomi Klein Doppelganger : comme la coalition progressiste commence à soutenir ces institutions indignes et défaillantes, la droite retourne leur critique en miroir, en formant une image déformée qui s’évertue à transformer en boucs émissaires les groupes les plus vulnérables au lieu de combattre les institutions dépravées :

    https://pluralistic.net/2023/09/05/not-that-naomi/#if-the-naomi-be-klein-youre-doing-just-fine

    C’est un schéma récurrent en politique. Aux siècles derniers, des gauchistes ont étiqueté l’antisémitisme comme un « socialisme des nigauds. » Au lieu de condamner l’emprise des milieux financiers sur le système et ceux qui en profitaient, les antisémites blâment un groupe défavorisé — des gens tout aussi susceptibles que les autres de souffrir du système :

    https://en.wikipedia.org/wiki/Antisemitism_is_the_socialism_of_fools

    Il s’agit d’une version puérile, ignoble et superficielle, de l’analyse complète et mesurée proposée par le socialisme des relations de classes et de leurs dérives si néfastes pour tous sauf une élite mesquine. Puérile et caricaturale, voici vraiment ce qu’est cette image déformée du socialisme qui entérine une iconographie simpliste de la lutte des classes. Et la schizogenèse — « si la droite l’apprécie, pas moi » — envoi alors les progressistes houspiller quiconque critique le rôle crucial de la finance dans les problèmes de notre monde en les traitant « d’antisémites ridicules. »

    C’est le problème de la « théorie du fer à cheval » — l’idée que les extrêmes politiques se rejoignent :

    https://pluralistic.net/2024/02/26/horsehoe-crab/#substantive-disagreement

    Quand la droite critique l’industrie pharmaceutique, ils nous disent « faites vos propres recherches » (autrement dit, ignorez les problèmes systémiques, comme ceux de gens forcés à travailler dans les conditions dangereuses d’une pandémie tout en dénouant le vrai du faux sur la sécurité vaccinale, idéalement en concluant qu’il leur faut les compléments alimentaires d’un escroc). Quand la gauche critique les mêmes, c’est pour l’accès universel aux soins, et une surveillance publique efficace des industriels du secteur. Ça diffère un brin :

    https://pluralistic.net/2021/05/25/the-other-shoe-drops/#quid-pro-quo

    Bien avant que des politiciens de droite réalisent qu’ils pourraient faire carrière en décriant l’effroyable crise épistémologique de devoir faire de bons choix à l’ère des institutions versatiles, la gauche sonnait le tocsin. Le conspirationnisme — une fracture de notre réalité commune — est un problème sérieux, obérant notre capacité à réagir à la litanie des désastres d’une crise multifactorielle.

    Mais en blâmant la crédulité des conspirationnistes (plutôt que la perte de crédibilité méritée des institutions auxquelles ils ne prêtent plus foi) nous adoptons la logique de la droite : une insistance schizogène que les institutions sont saines et fiables et l’affirmation que « le conspirationnisme est un problème individuel de gens crédules » alors qu’il procède « d’un système qui rend crédible des explications ridicules. »

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/pmanglade/journaux/traduction-aux-sources-du-complotisme

    • chevron_right

      RGPD et parti politique

      news.movim.eu / LinuxFRJournaux · 4 days ago - 07:32 · 1 minute

    Bonjour cher journal,

    Aujourd'hui je reçois du spam comme tous les jours, mais je décide d'en regarder un en particulier provenant d'un parti politique français pour les élections européennes.

    Je constate qu'il provient d'un mailing liste hébergée en suisse par mailpro saleté de com. Entreprise donc Suisse …

    Je clique pour me désinscrire et je vois un petit onglet MY DATA.

    Et je vois tranquillement mon :

    • Email
    • Nom
    • Prénom
    • Date de naissance
    • Lieu de naissance
    • Adresse personnelle à l'étranger

    Donc la fuite de donnée provient vraisemblablement de l'ambassade ou de l'école de mes enfants.

    Je n'ai jamais donné mon autorisation pour la diffusion de mes données personnelles.

    Le site web suisse me propose gentiment d'écrire un courriel à fedeffe@parti-socialiste.fr pour que je puisse modifier ou effacer mes données personnelles. Ce que j'ai fait.

    Mais la question du jour, cher Moules, est-ce que vous avez une idée de comment faire pour effacer toutes les données aux parties politique français ?

    J'ai essayé de trouver une liste exhaustive de tous les e-mails de rgpd, mais impossible d'en trouver une.
    Déjà il faudrait savoir le nombre de partie et micropartie politique qui existe ?

    Demander a l'ambassade, aux grands dieux, ils ne font rien de tel, et ne communique rien aux partis bien sûr …

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/regis/journaux/rgpd-et-parti-politique

    • chevron_right

      Douze ans après

      news.movim.eu / LinuxFRJournaux · 5 days ago - 18:51

    Il y a 12 ans, LinuxFr publiait un article « Les Variations Goldberg dans le domaine public » qui annonçait que l'œuvre de Bach était, non seulement dans le domaine public (depuis longtemps, quand même), mais qu'il en existait désormais une interprétation gratuitement téléchargeable (et redistribuable puisque sous licence CC0)

    Depuis, les choses ont changé, et pas en bien :

    • le lien dans l'article de LinuxFr fait désormais un 404,
    • le site du projet existe toujours mais le téléchargement est désormais plus complexe (il faut cliquer sur Buy, oui, pour l'avoir gratuitement, et indiquer zéro comme prix) et même assez pénible (on ne peut pas télécharger directement, il faut donner son adresse de courrier électronique, qui sera inscrite d'autorité à une newsletter).

    En soi, que l'auteur ou l'interprète change la licence n'est pas scandaleux. Mais, ici, le projet avait été financé par crowdfunding, sous la promesse que le résultat serait librement téléchargeable :-(

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • wifi_tethering open_in_new

      This post is public

      linuxfr.org /users/bortzmeyer/journaux/douze-ans-apres