Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Archives janvier 2019

Hacker le débat

Rédigé par dada / 28 janvier 2019 / 2 commentaires


Quand on y réfléchit, nous sommes passablement lamentables, nous les libristes. Nous avons réussi à monter des logiciels plus efficaces, plus résilients et plus transparents pour nos petits besoins mais jamais nous n'avons réellement réussi à prendre de l'ampleur.

Les réseaux sociaux ne nous conviennent pas ? Un gus dans son garage sort Mastodon.
Passer du temps à engraisser Google via Youtube ? Peertube apparaît pour nous sortir de là.
Nous n'aimons pas rester dans un silo ? Finassons ActivityPub pour interconnecter nos modes de communications.

Avec le Grand Débat, nous avions une chance de mettre en branle nos communautés pour participer aux discussions autours de choix sociétaux. Et qu'est-ce qu'on arrive à faire ? Rien.

Nous n'arrivons plus à motiver les gens sur les questions logicielles. Je ne vais pas expliquer pourquoi, je vous laisse le soin de lire le billet de Cyrille BORNE sur le sujet. C'est mort, il faut passer à autre chose.

Ne devrions-nous pas nous lancer quand même dans la bataille d'idées qui va avoir lieu ? Bien sûr que si !

Notre transparence

Nos logiciels sont libres. Cette définition est maintenant reconnue comme gage de qualité dans le milieu professionnel via l'appellation Open Source. Nous avons gagné cette bataille. Le libre est caché partout derrière nos écrans. Pourtant, dans la vie de tous les jours, il n'existe plus. Nous aurions dû gagner sur ce terrain là aussi.
Quoi de mieux qu'une comparaison simple dont je m'étonne de ne pas la croiser plus souvent : en matière politique, le libre s'apparente à nos urnes électorales. Nos logiciels sont transparents et permettent à des assesseurs de tous bords de regarder ce qu'il se trame. C'est transparent, honnête et critiquable par tous. Nous respectons des principes moraux centenaires et pourtant la majorité s'en cogne.

Notre force technique

Rien qu'en se limitant à Mastodon ou Peertube, nous avons une armée de DevOps et d'administrateurs système et réseau capable de mettre en œuvre n'importe quelle idée folle. Et en quelques jours seulement. Des centaines d'admin Mastodon, c'est énorme. Je ne sais pas s'il existe une entreprise française avec une telle force de frappe ! Nous avons moins de développeurs mais qu'importe. Ils produisent déjà des logiciels incroyables en gérant efficacement leurs communautés à travers des forges logicielles !

Notre force financière

On n'a pas un rond ? Si, nous en avons. Le développeur de Mastodon vit de son travail pour la communauté. Framasoft emploie Chocobozz pour développer Peertube et j'en passe. Nous avons des outils pour gérer nos dons et pour les répartir. Ça marche alors pourquoi ne pas continuer à s'en servir ? Loin de moi l'idée de faire croire que nous pouvons réunir 10% du budget café de Google, mais nous pouvons quand même faire des choses. Nous avons quand même les moyens d'amorcer un projet jusqu'à un plan de financement plus traditionnel, s'il le faut.

Allons-y !

On me dira qu'il existe déjà des exemples d'impact du logiciel libre dans la vie politique : Mediamanif, par exemple. Son utilisation est à l'arrêt et je me demande si elle a vraiment servi ? Il doit y en avoir d'autres, mais ils m'échappent.

Nous semblons toujours arriver après guerre, quand tout est terminé, avec des alternatives. D'ailleurs, ce mot "alternative" commence sérieusement à me courir sur le haricot. Est-ce que pour une fois, il ne serait pas possible d'arriver avant les autres ?

Je me demandais comment hacker le Grand Débat, en lâchant un simple message sur Mastodon. Quelques minutes plus tard, j'apprends qu'une startup a déjà proposé ses services à quelques collectifs pour héberger et gérer une plateforme collaborative. Mais bordel, c'est dingue ! On se retrouve avec un début d'alternative au Grand Débat qui n'est pas basé sur un logiciel libre et qui est entre les mains d'une #CivilTech dont personne ne connaît le nom et dont les offres d'emploi se concentrent sur des juniors et des stagiaires ! Stop ! Comment est-ce possible ?!

Je n'ai pas épluché le fonctionnement de Communecter (lien), mais ça me semble bien plus honnête qu'un truc non libre, non ?! Si cet outil n'est pas parfait, logiciel libre oblige, nous pouvons participer à son amélioration à travers leurs répo !

Bref, ceci est un billet d'humeur. Faites en ce que vous voulez.

Classé dans : Édito / Mots clés : aucun

Nextcloud, PHP-FPM, Nginx et Kubernetes

Rédigé par dada / 14 janvier 2019 / 7 commentaires




Ma première installation de Nextcloud dans Kubernetes était basée sur l'image Docker contenant Apache2. Aucun souci notable au niveau de la synchro des agendas, des fichiers ou encore des contacts. Par contre, la génération des miniatures des photos s'est révélée être un drame : Apache s'emballait et entraînait le nœud sur lequel il tournait avec lui, dans la tombe. Il me fallait une solution, j'ai donc décidé de changer de conteneur et de prendre celui basé sur PHP-FPM.

Un pod avec deux conteneurs

On entend souvent la rumeur racontant qu'un pod ne contient qu'un conteneur. C'est souvent vrai, mais c'est aussi faux. Dans l'exemple qui va suivre, le pod gérant Nextcloud contiendra le conteneur officiel de Nextcloud et un conteneur Nginx.

Contexte

Pour suivre, sachez que mon cluster, celui grâce auquel vous lisez ces quelques lignes, gère son système de fichier avec Rook, dont j'ai déjà parlé ici. Mes nœuds sont chez Hetzner, ce sont des CX21, du cloud public donc, et mes services sont exposés en NodePort derrière un Nginx configuré en LoadBalancer. Maintenant que vous savez ça, on peut y aller.

Le Deployment

On va commencer par balancer le Yaml qui marche :
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextcloud-deployment
spec:
  selector:
    matchLabels:
      app: nextcloud
  replicas: 1
  template:
    metadata:
      labels:
        app: nextcloud
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
      - name: nextcloud
        image: nextcloud:14.0-fpm
        ports:
        - containerPort: 9000
        volumeMounts:
        - name: pv-nextcloud
          mountPath: /var/www/html
        resources:
          limits:
            cpu: "1"
      volumes:
      - name : nginx-config
        configMap:
           name: nginx-config
      - name: pv-nextcloud
        flexVolume:
          driver: ceph.rook.io/rook
          fsType: ceph
          options:
            fsName: myfs
            clusterNamespace: rook-ceph
            path: /nextcloud2

Il n'y a pas le Service associé pour la simple et bonne raison que chacun fait comme il le veut. Si vous êtes chez DigitalOcean, OVH ou chez un des GAFAM qui propose du k8s, vous aurez un LoadBalancer qui va bien. Si vous êtes comme moi, vous êtes réduit à faire du NodePort.

Ce qu'il faut comprendre

Vous remarquerez qu'il y a deux conteneurs : Nginx et Nextcloud-FPM. Nginx écoute sur le port 80 et va router le trafic à travers vers le port 9000 du conteneur de Nextcloud.

Nginx

      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
On va faire gober à Nginx deux points de montage : sa configuration et les sources de Nextcloud. Sans les sources de l'application, Nginx ne pourra pas avoir accès aux fichiers PHP, et ne servira donc à rien. On va donc prendre le point de montage originalement dédié à Nextcloud pour le monter une deuxième fois dans un deuxième conteneur, celui de Nginx.

Lifecycle

Remarquez la présence de la section lifecycle, elle permet d’exécuter ce que vous voulez au démarrage du conteneur. Quand j'apprenais à me servir de ce couple, je ne comprenais pas pourquoi Nginx ne voulait pas correctement fonctionner. J'ai passé du temps à comprendre que le conteneur Nginx et le conteneur Nextcloud n'avaient pas le même docRoot :
  • Nginx : /srv/html
  • Nextcloud : /var/www/html
Comprenez que les requêtes Nginx allaient chercher des fichiers dans /srv/html/blabla.php quand Nextcloud annonçait la présence de ses sources dans /var/www/html/blabla.php. Le bordel.

C'est là que je n'ai trouvé pas idiot l'idée de créer le chemin manquant au démarrage du pod avec un postStart. Du coup, j'avais Nginx et Nextcloud au diapason. Il est sans doute possible de configurer Nginx pour surcharger son docRoot, mais c'était l'occasion de jouer avec des commandes en amont de la création d'un conteneur.

Les deux points de montage

On a donc un point de montage pour les sources de Nextcloud :
        - name: pv-nextcloud
          mountPath: /var/www/html
Et un point de montage pour la configuration de Nginx :
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf

Là aussi, j'ai perdu un peu de temps avant de comprendre qu'il fallait balancer toute la configuration de Nginx et pas seulement ce que j'ai l'habitude de mettre dans les sites-enabled. C'est du moins à faire quand on écrase le nginx.conf du pod. En y réfléchissant, c'est sans doute plus simple de modifier le point montage pour n'ajouter qu'un fichier dans le fameux sites-enabled.

Pour gérer la configuration de Nginx, je passe par une ConfigMap :
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  nginx.conf: |
    worker_processes  1;

    error_log  /var/log/nginx/error.log warn;
    pid        /var/run/nginx.pid;

    events {
        worker_connections  1024;
    }

    http {
        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;

        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';

        access_log  /var/log/nginx/access.log  main;

        sendfile        on;
        #tcp_nopush     on;

        keepalive_timeout  65;

        #gzip  on;

        server {
            listen 80;

            add_header X-Content-Type-Options nosniff;
            add_header X-XSS-Protection "1; mode=block";
            add_header X-Robots-Tag none;
            add_header X-Download-Options noopen;
            add_header X-Permitted-Cross-Domain-Policies none;
            add_header Referrer-Policy no-referrer;

            root /var/www/html;

            location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
            }

            location = /.well-known/carddav {
                return 301 $scheme://$host/remote.php/dav;
            }
            location = /.well-known/caldav {
                return 301 $scheme://$host/remote.php/dav;
            }

            # set max upload size
            client_max_body_size 10G;
            fastcgi_buffers 64 4K;

            # Enable gzip but do not remove ETag headers
            gzip on;
            gzip_vary on;
            gzip_comp_level 4;
            gzip_min_length 256;
            gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
            gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

            location / {
                rewrite ^ /index.php$request_uri;
            }

            location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
                deny all;
            }
            location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
                deny all;
            }

            location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
                fastcgi_split_path_info ^(.+\.php)(/.*)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                # fastcgi_param HTTPS on;
                #Avoid sending the security headers twice
                fastcgi_param modHeadersAvailable true;
                fastcgi_param front_controller_active true;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
            }

            location ~ ^/(?:updater|ocs-provider)(?:$|/) {
                try_files $uri/ =404;
                index index.php;
            }

            # Adding the cache control header for js and css files
            # Make sure it is BELOW the PHP block
            location ~ \.(?:css|js|woff|svg|gif)$ {
                try_files $uri /index.php$request_uri;
                add_header Cache-Control "public, max-age=15778463";
                add_header X-Content-Type-Options nosniff;
                add_header X-XSS-Protection "1; mode=block";
                add_header X-Robots-Tag none;
                add_header X-Download-Options noopen;
                add_header X-Permitted-Cross-Domain-Policies none;
                add_header Referrer-Policy no-referrer;

                # Optional: Don't log access to assets
                access_log off;
            }

            location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
                try_files $uri /index.php$request_uri;
                # Optional: Don't log access to other assets
                access_log off;
            }
        }

    }
Eh oui, il y a tout dedans. Ça déforme l'affichage de ce billet, m'enfin. C'est une configuration Nginx classique.

On peut quand même s'arrêter sur la configuration du fastcgi_pass : il tape sur le 127.0.0.1 et le port 9000 du conteneur Nextcloud. Je n'ai pas encore gratté pour comprendre le pourquoi du comment mais je suppose que les deux conteneurs tournant dans le réseau du pod, ils se comportent comme deux services dans une seule et même machine. À confirmer.

On apply tout ça

Attention ! Avant de balancer le Deployment, balancez le yaml de la ConfigMap. Sans ça, Nginx ne chargera pas votre configuration !
dada@k8smaster1:~$ kubectl apply -f configmap.yaml
dada@k8smaster1:~$ kubectl apply -f nextcloud.yaml
Si tout se passe bien, vous devriez pouvoir voir ça :
dada@k8smaster1:~$ kubectl get pods
nextcloud-deployment-d6cbb8446-87ckf   2/2     Running   0          15h
Remarquez que Kubernetes vous montre bien qu'il y a deux conteneurs dans ce pod : 2/2.

Pour aller plus loin

Je ne parle pas des vérifications de l'état des conteneurs. Il faudrait placer des sondes liveness et readness pour parfaitement vérifier l'état des conteneurs. Sans ça, si l'un des services tombe, Kubernetes ne sera pas forcément en mesure de le détecter et de relancer le pod.
Il est aussi possible, pour respecter le concept de micro-service, de ne pas concaténer deux conteneurs dans un seul pod mais de faire un pod par conteneur et des services associés. Ça demande plus de travail pour un résultat qui, dans mon cas, n'apporte pas grand chose.

Wireguard sur Debian 9

Rédigé par dada / 07 janvier 2019 / 2 commentaires



Heztner, c'est vraiment un hébergeur qui propose un cloud peu cher et performant. Vraiment. Par contre, il n'y a que ça. Jusqu'à peu, nous n'avions pas la possibilité d'ajouter des volumes pour gonfler l'espace disque des machines et pas de réseau privé. Maintenant, les volumes sont là, mais toujours pas de réseau privé. Tant pis, on va le faire à la main.

On m'a parlé de Wireguard : un outil simple, puissant et sécurisé pour monter des VPN entre nos serveurs. J'ai testé, j'approuve. Je n'aime pas le réseau, c'est pas mon truc mais avec Wireguard et mes balades sous Kubernetes, je commence à presque apprécier cette chose.

Voici donc comment mettre en place des connexions privées entre vos machines pour y faire transiter ce que vous voulez sans que ça se balade sur l'Internet mondial.

Installation de Wireguard

Au moment où j'écris ces lignes, l'outil n'est disponible que dans les dépôts unstable. C'est chiant, mais rien de grave.

Ajouter les dépôts installables

# echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable-wireguard.list

Faire un peu de pinning

Pourquoi ? Parce qu'avec le dépôt que vous venez d'ajouter, si vous n'y faites pas attention, vous allez massacrer la stabilité de votre machine.
# printf 'Package: *\nPin: release a=unstable\nPin-Priority: 150\n' > /etc/apt/preferences.d/limit-unstable

Installer les paquets

On va d'abord installer les headers pour permettre à Wireguard de bien s'installer :
apt install linux-headers-$(uname -r)
On peut maintenant installer la bête :
# apt update && apt install wireguard
C'est installé !

Configuration

Exemple simple

On va prendre deux serveurs et on va s'amuser à les interconnecter. Sur les deux machines, nous allons générer les clés privées et publiques :
wg genkey | tee privatekey | wg pubkey > publickey

Configuration de l'interface réseau

Tout va se passer dans le fichier wg0.conf, qui sera placé dans /etc/wireguard/. Sur la première machine, son contenu va ressembler à ça :
# Votre premier serveur
[Interface]
Address = 10.0.42.1
PrivateKey = kEQpUJDtur3yHqtoto42Y0+FXNK5lyJoUhh2g21BFWo= 
ListenPort = 1190

# Votre deuxième serveur
[Peer]
PublicKey = MnL98kIZYrHgopn1U3kptoto42L/8MqgyqKh2g2Hixo=
Endpoint = IP.DE.MON.PEER:1190
AllowedIPs = 10.0.42.2/32
Sur la deuxième machine :
# Votre deuxième serveur
[Interface]
Address = 10.0.42.2
PrivateKey = kEQpUJDtur3yHqtoto42Y0+FXNK5lyJoUhh2g21BFWo= 
ListenPort = 1190

# Votre premier serveur
[Peer]
PublicKey = MnL98kIZYrHgopn1U3kptoto42L/8MqgyqKh2g2Hixo=
Endpoint = IP.DE.MON.PEER:1190
AllowedIPs = 10.0.42.1/32
Non, je n'ai pas changé les clés, la flemme. Pensez quand même à vérifier que vous n'avez pas fait de coquille en copiant/collant tout ça. C'est souvent en se trompant entre les clés qu'on perd un temps fou à déboguer.

Interface

La partie [Interface] porte bien son nom : c'est là que vous allez définir l'IP de la machine sur laquelle vous bossez, configurer sa clé privée et le port qui sera utilisé par Wireguard. Allez récupérer la clé privée générée quelques secondes auparavant et remplacez ma valeur de test.

Peer

La partie [Peer], qui porte aussi bien son nom si on speak l'english, permet de configurer un pair, c'est à dire un serveur distant qui va pouvoir passer par le VPN pour faire des coucous à votre première machine.
Endpoint est à remplir avec la véritable IP de la machine et AllowedIPs doit contenir les IP (ou range) VPN de vos machines clientes. Pas la véritable IP publique.

Tester la connexion

On va activer la connexion en tapant ça sur les deux machines :
root@master:/etc/wireguard# wg-quick up wg0
Vous devriez avoir une réponse, pour le premier serveur, dans le genre :
root@test1:/home/dada# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.42.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.42.2/32 dev wg0
Et pour le deuxième :
root@test2:/home/dada# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.42.2 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.42.1/32 dev wg0
Maintenant, si tout s'est bien passé, vous devriez pouvoir faire des pings sur les IPs VPN des machines !

Démarrer Wireguard avec la machine

Avec systemd :
systemctl enable wg-quick@wg0.service
Ça fait quelques semaines que mon infra tourne avec Wireguard sans le moindre souci de latence, de déconnexion ou de bogue. C'est du bon !

Astuces du dimanche #6

Rédigé par dada / 06 janvier 2019 / Aucun commentaire


Ça faisait longtemps que je n'avais pas fait de ADD. En voici une très orienté Kubernetes.

Grafana

Vous avez installé le Prometheus Operator et vous ne savez pas où est passé le traditionnel couple utilisateur/mot de passe admin/admin ? L'info est ici : l'utilisateur est bien admin, mais le mot de passe est prom-operator.

Rook

Impossible de mettre la main sur le Dashboard ? La configuration a changé avec la version 0.9 : tout est ici.
Votre cluster hurle à coup de HEALTH_ERR ? Toujours à cause de la 0.9, deux modules sont en erreur : l'issue est ici. Rien de grave, le cluster tourne bien malgré les alertes. Les manipulations pour corriger le tir sont décrites par là.

Version de Docker

Les versions de docker se suivent et ne sont pas toujours compatibles avec ce que demande Kubernetes, pour installer une version précise :
export VERSION=18.03 && curl -sSL get.docker.com | sh
Prenez le temps de bien supprimer/purger l'ancienne version de docker avant de lancer la commande et d'installer Git. Notez aussi que ça vous empêchera d'utiliser le bon vieux couple "apt update && apt upgrade".

Init d'un Cluster k8s

Si vous installez un master sur un serveur n'ayant qu'un seul CPU, ignorez l'erreur avec :
--ignore-preflight-errors=NumCPU
Si vous voulez forcer l'API à utiliser un réseau spécifique, genre un réseau privé basé sur, disons, WireGuard :
--apiserver-advertise-address="10.0.42.1"
Où 10.0.42.1 est l'IP de l'interface VPN de votre Master.

Méfiez-vous des Resources

Utiliser Kubernetes sur des petits serveurs comme ceux que j'utilise chez Hetzner peut vous pousser à mettre en place des limitations de ressources sur vos conteneurs. Dans mon cas très particulier, où je suis quasiment le seul utilisateur, il est plus efficace de ne pas limiter les conteneurs, quitte à les voir éclater le CPU pendant quelques secondes. Avec des limitations, j'ai réussi à monter à plus de 200 de load pour 2 CPU. Voilà.

Mozilla encore sous le feu des critiques

Rédigé par dada / 02 janvier 2019 / 4 commentaires


On prend les mêmes et on recommence. Ça devient lassant de lire toutes ces critiques envers la maison mère de Firefox. Vraiment. Les dernières nouvelles ont permis aux trolls de service de se lâcher :

Un autre thème que je voulais aborder : les contenus. Le Web en regorge, mais de nos jours, il est difficile de distinguer le vrai du faux. Nous avons au sein de Mozilla des experts qui doivent prendre part aux discussions sur le sujet et peuvent travailler sur des solutions expérimentales pour résoudre ce problème.

Ce paragraphe est extrait des derniers mots de Mitchell Baker, la cofondatrice de Mozilla. Qu'est-ce qu'on y lit ? Les plus tordus s'amuseront à le traduire en : "Nous allons configurer Firefox pour que les actualités qui ne nous plaisent pas mais qui pourraient vous intéresser n'apparaissent plus dans Firefox".

Dingue.

Ça me fait penser à l'intégration de Safe Browsing, l'outil de Google qui permet de recenser les sites crapuleux et de les bloquer. Qui continue à en parler ? Qui s'amuse à le désactiver lorsqu'il installe Firefox ? Sans doute personne, ou si peu. On se souvient pourtant du scandale : Google s'arrogeait le droit de couper l'accès à des sites dont le but était visiblement la malveillance. Mais de quel droit osent-ils ? Comment peut-on ?

Depuis, plus rien.

L'année 2018 a fait sortir l'influence des trolls, des crapuleux, des malhonnêtes, etc, du bois. Internet, le web, est partout et tout le monde ou presque y traîne ses gros doigts. Et les gens vont se battre pour l'orienter dans leurs intérêts.

On pourrait reprendre les mots de Baker sous cet éclairage : Mozilla va mettre sa charte et ses moyens aux services des internautes en plaçant des gens compétents au cœur des réunions qui vont certainement avoir lieu autour des notions de fakenews/désinformations/manipulations. Pour quoi faire ? Pour taper autant que possible du poing sur la table quand des mesures farfelues seront proposées.

Personnellement, quand je vois passer des liens qui redirigent les gens vers des blogs ou des torchons qui débitent des conneries dingues sur des décisions politiques entre deux billets traitant de l'existence, la vraie, d'agroglyphes : je veux bien que Firefox ouvre une popup pour m'avertir de la folie des rédacteurs.
Et moi, je m'en rends compte. Les Michus n'auront pas toujours le reflexe de s'intéresser aux contextes.

Mozilla peut se servir de ce qui lui reste de ses compétences et de sa notoriété pour nous aider. S'ils ne le font pas, nous quitterons tous le navire Firefox pour aller voir ailleurs. Pas chez Vivaldi, pas chez Brave, encore moins chez Chrome, mais pourquoi pas chez Librefox.

C'est facile de s'énerver quand la neutralité d'un navigateur ne semble plus garantie. Il ne faut cependant jamais oublier que 99% des gens ne comprennent pas ce qu'est un navigateur. Le laisser neutre serait l'idéal, c'est certain, mais peut-on vraiment se le permettre alors que les sociétés se transforment en somme d'individualisme et plus en multitude réunie par les mêmes envies, règles, droits et devoirs ?

Pour finir : les choix techniques qui seront peut-être pris par les grands navigateurs ne seront que des rustines posées sur une jambe de bois. L'éducation devrait faire son travail mais dans un monde bouffé par l'optimisation et la rentabilité de l'humain, on fait avec ce qu'on a.

Classé dans : Édito / Mots clés : aucun