Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

🏆 Meilleures contributions LinuxFr.org : les primées d'octobre 2024

14 novembre 2024 à 01:25

Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles, ENI et D-Booker. Voici les gagnants du mois d'octobre 2024 :

Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Les livres 📚 sélectionnés

Bandeau LinuxFr.org

Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions Eyrolles, ENI et D-Booker.

Logo éditions ENI Logo éditions Eyrolles Logo éditions B-BookeR
     

Commentaires : voir le flux Atom ouvrir dans le navigateur

The U.S. National Security State is Here to Make AI Even Less Transparent and Accountable

19 novembre 2024 à 14:37

The Biden White House has released a memorandum on “Advancing United States’ Leadership in Artificial Intelligence” which includes, among other things, a directive for the National Security apparatus to become a world leader in the use of AI. Under direction from the White House, the national security state is expected to take up this leadership position by poaching great minds from academia and the private sector and, most disturbingly, leveraging already functioning private AI models for national security objectives.

Private AI systems like those operated by tech companies are incredibly opaque. People are uncomfortable—and rightly so—with companies that use AI to decide all sorts of things about their lives–from how likely they are to commit a crime, to their eligibility for a job, to issues involving immigration, insurance, and housing. Right now, as you read this, for-profit companies are leasing their automated decision-making services to all manner of companies and employers and most of those affected will never know that a computer made a choice about them and will never be able to appeal that decision or understand how it was made.

But it can get worse; combining both private AI with national security secrecy threatens to make an already secretive system even more unaccountable and untransparent. The constellation of organizations and agencies that make up the national security apparatus are notoriously secretive. EFF has had to fight in court a number of times in an attempt to make public even the most basic frameworks of global dragnet surveillance and the rules that govern it. Combining these two will create a Frankenstein’s Monster of secrecy, unaccountability, and decision-making power.

While the Executive Branch pushes agencies to leverage private AI expertise, our concern is that more and more information on how those AI models work will be cloaked in the nigh-impenetrable veil of government secrecy. Because AI operates by collecting and processing a tremendous amount of data, understanding what information it retains and how it arrives at conclusions will all become incredibly central to how the national security state thinks about issues. This means not only will the state likely make the argument that the AI’s training data may need to be classified, but they may also argue that companies need to, under penalty of law, keep the governing algorithms secret as well.

As the memo says, “AI has emerged as an era-defining technology and has demonstrated significant and growing relevance to national security.  The United States must lead the world in the responsible application of AI to appropriate national security functions.” As the US national security state attempts to leverage powerful commercial AI to give it an edge, there are a number of questions that remain unanswered about how much that ever-tightening relationship will impact much needed transparency and accountability for private AI and for-profit automated decision making systems. 

epub, le convertisseur EPUB3 à la volée de LinuxFr.org

4 novembre 2024 à 03:57

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à epub, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le convertisseur EPUB3 à la volée de LinuxFr.org, et elle vient accompagner la précédente sur img, le cache d’images sur LinuxFr.org.

    Sommaire

    Des EPUB de vos contenus et commentaires

    LinuxFr.org vous permet de lire les contenus et commentaires du site, au format EPUB3, par exemple dans votre liseuse préférée. Il y a une exception à cela, les liens, parce que certes ça ferait des EPUB tout mignons, mais surtout petits voire un poil inutiles. Le lien EPUB est présent automatiquement sur chaque contenu (hormis les liens donc).

    Le principe est simple : on donne un lien vers un contenu HTML à epub, il le demande à la partie Ruby on Rails du site, ainsi que les images associées, convertit le tout au format EPUB3 et le renvoie à la personne qui l’a demandé. Techniquement epub n'est pas exposé frontalement mais se trouve derrière un nginx.

    Côté code Ruby on Rails

    C’est assez basique : on ajoute juste sur chaque contenu un lien pour télécharger au format EPUB. Ainsi, y compris sur cette dépêche, vous allez trouver un lien à la fin pour récupérer le tout au format EPUB (et un autre pour récupérer le source en Markdown mais c’est un autre sujet).

    app/views/news/_news.atom.builder:    epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/polls/_poll.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/posts/_post.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/nodes/_actions.html.haml:    = link_to "EPUB", "#{path_for_content node.content}.epub", title: "Télécharger ce contenu au format EPUB", class: "action download"
    app/views/diaries/_diary.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/wiki_pages/_wiki_page.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))

    Côté epub

    Le service est plutôt simple, par rapport à img, car il n’a pas de dépendance sur redis par exemple, et qu’il a, au final, peu de paramétrage (un couple adresse+port d’écoute, un fichier de trace et un hôte pour aller chercher les contenus).

    Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

    Sinon on lui demande une dépêche, un journal, une entrée de forum, un sondage, une entrée de suivi ou une page wiki en prenant le chemin sur LinuxFr.org et ajoutant un petit .epub à la fin, et il va renvoyer un fichier EPUB. Ou bien il va répondre un contenu non trouvé HTTP 404 s’il y a un souci. Et vu son fonctionnement, si on a un souci de HTML non valide ou si img a un problème avec une image, alors derrière epub pourrait avoir le même souci.

    epub est un binaire dynamique en Go. Il impose le https pour l’hôte (du coup on aura tous les liens en HTTPS en interne normalement). Il ne peut pas vraiment être compilé statiquement (on a besoin de libxml2, libonig2 et de la même version de la libc au déploiement). Il ne gère pas les images in-line.

    Dans les logs on va trouver des infos comme :

    2024/11/03 16:34:02 Status code of http:/example.invalid/exemple.png is: 404
    (…)
    2024/11/03 16:38:23 Fetch https://linuxfr.org/news/capitole-du-libre-2024-au-programme-du-16-et-17-novembre
    2024/11/03 16:38:24 Fetch https://linuxfr.org/users/liberf0rce/journaux/libreast-2006-is-out-of-order
    

    Historique

    epub a été créé par Bruno Michel en 2013 et Bruno est le seul à travailler dessus (48 commits) jusqu’en 2018. Comme img, on peut considérer que epub a fait le job pendant ce temps-là, sans besoin de retouche.

    Mon premier commit de 2021 concerne la gestion d’un cas de collision de nommages des images.

    En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et epub fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

    Bref je décide de me plonger dans epub (2022-2024), dans la foulée de img, car a priori ce n’est pas un composant compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer - divulgâchage en fait non pas seulement).

    Le choix est le même que pour img (cf la dépêche précédente) : ajouter un Dockerfile permettant de recompiler epub dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant. Et de découvrir qu’une version statique n’est pas facilement envisageable.

    Puis je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose, et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types de contenus, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Et surtout de vérifier avec epubcheck que le fichier epub produit est correct. Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

    Les différents travaux effectués vont permettre de détecter et corriger quelques soucis :

    Et à la fin, j’écris une dépêche pour parler de tout cela.

    Évolutions récentes

    Dockerfile

    Le fichier Dockerfile du projet permet :

    • de partir d’une image officielle Go d’une version donnée, basée sur une distribution Debian (en raison des dépendances)
    • de l’utiliser pendant la construction en prenant la liste des dépendances de compilation, en les téléchargeant, en prenant l’unique fichier source epub.go et en le compilant dynamiquement avec l’option pour retirer les chemins de compilation
    • de rechercher les éventuelles vulnérabilités avec govulncheck
    • de tester avec golangci/golangci-lint le code (fait à la construction de l’image, car on dispose de toutes les dépendances à ce moment-là)
    • de repartir d’une base Debian en y mettant les autorités de certification, les dépendances de fonctionnement et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

    La suite de tests

    Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant epub, et démarrer le nginx-cert qui fournit les certificats et le nginx préconfiguré pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

    linuxfr.org-epub-test_1  | All tests look good!
    tests_linuxfr.org-epub-test_1 exited with code 0
    

    Rentrons un peu dans les détails.

    D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image nginx-cert qui sera utilisée pour créer une autorité de certification et un certificat serveur de test, l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image epub et son paramétrage (dont l’accès au nginx) ainsi que le répertoire de l’autorité de certification de tests et enfin l’image de la suite de tests qui est construit avec son Dockerfile et son répertoire de dépôt des fichiers EPUB.

    Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), curl, openjdk17 (pour epubcheck), openssl, unzip (transitoirement), bind-tools et shellcheck. On installe epubcheck. Et on lance les tests par défaut.

    La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

    Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, des contenus dans divers formats, une image très grande et des images qui ne seront pas accessibles.

    Sont aussi présents deux fichiers de tests avec une extension en .hurl :

    • le test de vie et les chemins hors des contenus autorisés
    • les tests sur les contenus

    Vient enfin le script shell qui pilote le tout :

    • on définit les variables pour les cibles IPv4/IPv6 que l’on veut utiliser dans les autres conteneurs Docker
    • on purge le stockage des EPUB sur disque
    • on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
    • sur chaque EPUB produit, on lance epubcheck et on regarde si la validation donne le résultat attendu (succès ou échec)
    • si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

    Les problématiques restantes

    Il y a quelques entrées encore ouvertes dans le suivi :

    • les images trop grandes (en octet), non récupérables, de format inconnu, etc. : la suite de tests actuelle « couvre » le cas des images de plus de 5 MiB ou non récupérables, avec des tests qui échouent, comme prévu, vu que c’est img qui est censé faire le job de les éviter. Cependant il pourrait être sympa de remplacer toute image non disponible/invalide par une image de remplacement « Image indisponible » du bon Content-Type et du bon nom (vu qu’elle est déclarée dans le MANIFEST).
    • les images trop grandes (en pixel) : globalement on revient à la question des images que laisse passer img
    • les epub non fonctionnels en rédaction et modération : pour des questions de droits, la génération EPUB ne marche pas dans les espaces de rédaction et de modération, à voir si on trouve un contournement ou si on évite de proposer le lien.

    Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails). Et des questions à se poser sur l’avenir de nginx ?. Les dépendances pendant le fonctionnement amènent aussi leur lot de contraintes.

    Conclusion ?

    Encore une fois, sans surprise et me répétant, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

    epub rend la fonction que l’on attend de lui, même si on pourrait faire un peu mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du nginx, du hurl, de l’HTTP et de gérer des problématiques statique/dynamique et des dépendances. Il s’agissait encore de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    "Is My Phone Listening To Me?"

    31 octobre 2024 à 13:32

    The short answer is no, probably not! But, with EFF’s new site, Digital Rights Bytes, we go in-depth on this question—and many others.

    Whether you’re just starting to question some of the effects of technology in your life or you’re the designated tech wizard of your family looking for resources to share, Digital Rights Bytes is here to help answer some common questions that may be bugging you about the devices you use.  

    We often hear the question, “Is my phone listening to me?” Generally, the answer is no, but the reason you may think that your phone is listening to you is actually quite complicated. Data brokers and advertisers have some sneaky tactics at their disposal to serve you ads that feel creepy in the moment and may make you think that your device is secretly taking notes on everything you say. 

    Watch the short videofeaturing a cute little penguin discovering how advertisers collect and track their personal dataand share it with your family and friends who have asked similar questions! Curious to learn more? We also have information about how to mitigate this tracking and what EFF is doing to stop these data brokers from collecting your information. 

    Digital Rights Bytes also has answers to other common questions about device repair, ownership of your digital media, and more. Got any additional questions you’d like us to answer in the future? Let us know on your favorite social platform using the hashtag #DigitalRightsBytes so we can find it!

    img, le cache d’images sur LinuxFr.org

    Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à img, un code sous AGPLv3.

    Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le cache d’images de LinuxFr.org, complétée d’une demande d’un « article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… ».

      Sommaire

      Des images sur le site

      LinuxFr.org vous permet d’utiliser des images externes dans les contenus et commentaires du site. Ces images sont incluses en syntaxe markdown avec ![description textuelle](adresse "titre optionnel") (soit en saisissant directement du Markdown, soit en cliquant sur l’icône d’ajout d’image dans l’éditeur). Profitons-en pour rappeler que pour utiliser une image sur LinuxFr.org, vous devez vous assurer de respecter sa licence.

      Nous vous encourageons donc à utiliser des images sous licence libre et à citer les auteurs (c’est même obligatoire pour les licences CC-by et CC-by-sa). Cette citation est tirée de la dépêche d’annonce Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org de 2012.

      Il est aussi recommandé de mettre une vraie description textuelle, qui finira dans l’attribut alt de la balise img utilisée pour l’accessibilité ou si l’image ne peut être chargée. Il peut être utile de lui donner un titre qui apparaîtra l’autre du survol de l’image à la souris par exemple.

      Exemple :

      ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png "L’actualité du logiciel libre et des sujets voisins (DIY, Open Hardware, Open Data, les Communs, etc.), sur un site francophone contributif géré par une équipe bénévole par et pour des libristes enthousiastes.")

      Logo LinuxFr.org

      Buts du cache d’images

      Les raisons évoquées à la mise en place de img (sans ordre particulier) :

      • la sécurité : si une image externe n’est servie qu’en HTTP (en clair donc) et est appelée au milieu d’une page LinuxFr.org elle-même servie en HTTPS, alors le navigateur va râler sur le mélange des genres. img permet de servir toutes les images identiquement (par exemple en HTTPS, et avec le certificat de LinuxFr.org, via le serveur frontal devant img). À noter que ces images ne sont pas servies directement depuis le domaine principal linuxfr.org mais depuis un sous-domaine img.linuxfr.org pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d’attaque contre le site.
      • la protection de la vie privée des personnes visitant LinuxFr.org : seul LinuxFr.org voit les informations en provenance de leur navigateur (dont l’adresse IP). Les équipes d’administration des différents sites ne les voient plus (elles voient l’adresse IP du serveur LinuxFr.org).
      • une meilleure gestion du trafic : au lieu d’envoyer tout notre public chercher individuellement chaque image, LinuxFr.org la récupère une fois et la rend disponible. Si le site externe fournissant l’image est un serveur à faibles ressources (liaison ADSL avec faible débit montant par exemple), la mise en cache permet de garantir qu’il ne recevra qu’un faible volume de requêtes (la récupération se faisant initialement toutes les 10 min tant que des demandes arrivent, le cache expirant après 10 min).
      • la conservation des images : les images incluses depuis des sites externes peuvent ne plus être disponibles (l’entité a disparu, le serveur a été arrêté, le domaine a été perdu, l’adresse a changé, etc.). Nous avons donc un mécanisme de cache pour que nous puissions continuer à servir une image même si elle devient indisponible.

      Parmi les conséquences de cette implémentation initiale, on peut citer :

      • si le fichier est changé sur le serveur distant (modifié, converti dans un autre format), l’ancien fichier est servi jusqu’à la prochaine récupération et le nouveau fichier ne sera servi qu’à la prochaine récupération ;
      • si le fichier est supprimé sur le serveur distant, l’image ne sera plus servie après la prochaine récupération (car le serveur a répondu que l’image n’existe plus) ;
      • il est possible de modifier l’image au passage : les images d’avatar sont retaillées pour une hauteur de 64 pixels par exemple ;
      • il est possible de bloquer des images : les images problématiques (pub/spam, contenus pour adultes, images injurieuses, etc.) peuvent être bloquées et ne plus être servies ;
      • par ailleurs img n’accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 MiB.

      À l’utilisation

      Lors de l’écriture d’un commentaire ou d’un contenu sur LinuxFr.org, une personne va ajouter une image externe via la syntaxe Markdown, par exemple ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png)

      Ce qui donne à l’affichage :

      Logo LinuxFr.org

      Et côté code HTML :

      <img src="https://linuxfr.org/images/logos/linuxfr2_classic_back.png" alt="Logo LinuxFr.org">

      OK, mauvais exemple ce n’est pas une image externe, puisqu’elle est hébergée sur LinuxFr.org justement. Prenons un autre exemple ![April - Campagne d’adhésion](https://april.org/campagne-2024/relais/banniereCampagneApril.svg).

      Ce qui donne à l’affichage :

      April - Campagne d’adhésion

      Et côté code :

      <img src="//img.linuxfr.org/img/68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667/banniereCampagneApril.svg" alt="April - Campagne d’adhésion" title="Source : https://april.org/campagne-2024/relais/banniereCampagneApril.svg">

      Donc on sert l’image via le sous-domaine img.linuxfr.org. On peut aussi noter le titre rempli automatiquement avec la source. Expliquons la nouvelle adresse :

      • // on sert en https si la page est en https et en http si la page est en http (c’est plutôt un oubli qu’autre chose, vu que le site est uniquement en https)
      • img.linuxfr.org on sert depuis un sous-domaine du site
      • 68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667 est la version en texte-vers-hexadécimal de l’adresse d’origine (68 pour h, 74 pour t (deux fois), 70 pour p, etc.). Il existe des sites et des outils en local pour faire cette conversion, mais cela ne concerne pas la simple utilisation du site.
      • banniereCampagneApril.svg on met à la fin le nom du fichier pour être sympa si vous voulez sauver l’image en local avec un nom plus explicite

      Ceci était le cas où tout se passe bien, comme prévu, comme le voulait la personne qui voulait utiliser une image externe.

      Voyons maintenant ce qui se passe dans le cas pas si rare où la personne a donné une adresse d’image invalide, une adresse ne pointant pas vers une image vers autre chose (cas extrêmement fréquent), une image trop grosse (plus de 5 MiB), etc. Il se passe la même chose côté code, mais côté affichage, pas d’image, et on voit seulement le texte alternatif dans son navigateur. Dans les coulisses, img a répondu 404, cette adresse n’est pas disponible.

      On note donc qu’une même image servie en http:// ou en https:// aura une adresse convertie en hexadécimal différente, donc sera vue comme une autre image par img. Même chose si le serveur externe accepte des adresses sans tenir compte de la casse, ou si on rajoute des paramètres dans l’adresse comme « ?mot_magique=merci ».

      Côté code Ruby on Rails

      Un contenu ou commentaire est en cours de création et une image externe a été mentionnée. Le code de gestion des images va vérifier que l’image est déclarée dans redis (créer l’entrée img/<adresse> avec adresse l’adresse de l’image en clair, ajouter un champ created_at avec l’horodatage, ajouter l’adresse dans la liste des dernières images img/latest) et renvoyer l’adresse via img.

      Le code peut aussi modifier le champ status d’une image dans redis pour mettre ou enlever un blocage (valeur Blocked) par l’équipe du site, et l’ajouter/enlever de la liste des images bloquées img/blocked.

      Côté img

      Les schémas dans la documentation du service img explicitent les possibilités et les comportements.

      Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

      Sinon, on peut envoyer des requêtes GET /img/<adresse_en_hexa> or GET /img/<adresse_en_hexa>/<nom_de_fichier> pour les images, et GET /avatars/<adresse_en_hexa> ou GET /avatars/<adresse_en_hexa>/<nom_de_fichier> pour les avatars.

      En se limitant aux requêtes légitimes, le comportement de img est le suivant :

      • l’adresse demandée a été précédemment déclarée (dans redis par la partie code Ruby On Rails) sinon il répond 404 ;
      • l’adresse demandée n’est pas bloquée par l’équipe du site sinon il répond 404 ;
      • l’adresse est déjà dans le cache disque, alors il renvoie l’image ;
      • l’adresse n’est pas dans le cache disque et la récupération échoue, il renvoie 404 (et va noter temporairement l’échec dans img/err/<uri>) ;
      • l’adresse n’est pas dans le cache disque et la récupération a lieu (noté temporairement dans img/update/<uri>): si le serveur répond positivement à la demande, avec une image comme attendue, pas trop volumineuse, alors on la met en cache disque. Si c’est un avatar, on peut retailler l’image. On aura des champs supplémentaires stockés type avec la nature de l’image (en-tête Content-Type), checksum avec un hachage SHA1 et etag avec la valeur ETag (entête ETag).

      Le cache est rafraîchi régulièrement.

      img est un binaire statique en Go. Il offre des options pour définir le couple adresse:port d’écoute, pour définir où envoyer les logs, pour se connecter à une base redis, pour définir le répertoire du cache disque, pour choisir le User-Agent qui sera utilisé pour les requêtes externes, pour définir l’avatar qui sera renvoyé par défaut, et la possibilité de le lancer uniquement en mode audit interne pour vérifier la cohérence et l’état des données et des fichiers.

      Dans les logs on va trouver des infos comme :

      2024/10/20 20:39:24 Status code of http://example.invalid/exemple1.png is: 404
      2024/10/20 20:39:24 Fail to fetch http://example.invalid/exemple1.png (serve from disk cache anyway)
      2024/10/20 20:44:12 Fetch http://example.invalid/exemple2.png (image/png) (ETag: "be5e-4dba836030980")
      2024/10/20 20:44:12 http://example.invalid/exemple3.png has an invalid content-type: text/html;charset=UTF-8
      2024/10/20 20:44:12 Fail to fetch http://example.invalid/exemple3.png (serve from disk cache anyway)
      

      Ici l’exemple 1 est déjà en cache et peut être servi même si on échoue à le récupérer à ce moment-là. L’exemple 2 vient d’être récupéré. L’exemple 3 a désormais une adresse invalide (qui renvoie une page HTML au lieu d’une image) mais il existe en cache une image précédemment récupérée.

      Historique

      img a été créé par Bruno Michel en 2012. Adrien Kunysz amène 5 commits en novembre 2013, mais globalement Bruno est le seul à travailler dessus (43 commits) jusqu’en 2018. img fait le job et il n’est pas besoin d’y retoucher trop souvent.

      En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et img fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

      Bref je décide de me plonger dans img (2022-2024), car a priori ce n’est pas le composant le plus compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer).

      Étape 1 : je vais commencer par ajouter un Dockerfile permettant de recompiler img dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant.

      Étape 2 : je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose (avec des images redis et nginx), et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types d’images, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

      Étape 2,5 : l’avatar par défaut renvoie sur le site de production, y compris sur les tests en développement en local et sur le serveur de test du site. J’en profite pour ajouter un paramètre pour cela (et cela permettra de passer du PNG au SVG par défaut).

      Étape 3 : encore une fois essayons de simplifier la vie d’hypothétiques personnes contributrices. Une petite modification pour que hurl et redis soient fournis via docker-compose et ne soient plus nécessaires sur le poste de développement.

      Étape 4 : il est temps de documenter plus le fonctionnement. J’avais déjà décrit les infos stockées dans redis, mais pour comprendre le système de cache, autant fournir des diagrammes pour illustrer ce qui se passe lors d’une requête et comment on passe d’un état à un autre. C’est aussi l’occasion de compléter la suite de tests en ajoutant des tests avant et après expiration du cache, histoire de pouvoir documenter ces cas précis.

      Étape 5 : en cas d’échec de récupération, une image était indisponible jusqu’à la prochaine récupération (donc potentiellement pendant 10 min). Autant servir l’ancienne version en cache lorsque cela se produit : je modifie le code et les tests en conséquence.

      Étape 6 : je sais que certaines images ont été perdues, que des adresses d’images ont toujours été erronées, que des contenus et commentaires ont été supprimés et qu’il n’y a donc plus lieu de garder les images associées. Je décide d’implémenter dans img un audit interne qui indiquera si des anomalies sont présentes dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image. Et j’ajoute cet audit dans la suite de tests.

      Étape 7 : j’écris une dépêche pour parler de tout cela.

      Évolutions récentes

      Dockerfile

      Le fichier Dockerfile du projet permet :

      • de partir d’une image officielle Go d’une version donnée, basée sur une distribution minimale Alpine
      • de l’utiliser pendant la construction en prenant la liste des dépendances, en les téléchargeant, en prenant l’unique fichier source img.go et en le compilant statiquement avec l’option pour retirer les chemins de compilation
      • de rechercher les éventuelles vulnérabilités avec govulncheck
      • d’ajouter le paquet tzdata pour avoir les définitions fuseaux horaires (nécessaire pour les conversions de/vers GMT pour les entêtes type Last-Modified).
      • de repartir d’une base Alpine en y mettant les définitions de fuseaux horaires et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

      La suite de tests

      Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant img, et démarrer le redis et le nginx préconfigurés pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

      linuxfr.org-img-test_1  | All tests look good!
      tests_linuxfr.org-img-test_1 exited with code 0
      

      Rentrons un peu dans les détails.

      D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image redis qui sera utilisée (stockage géré par docker), l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image img et son paramétrage (dont l’accès au redis et au nginx) ainsi que le répertoire du cache et enfin l’image de la suite de tests qui est construit avec son Dockerfile, prévue pour faire du Docker-in-Docker et avoir accès au cache img et aux fichiers nginx.

      Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), coreutils, docker et xxd (pour les conversions texte vers hexadécimal). Et on lance les tests par défaut.

      La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

      Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, une image destinée à être bloquée, des images dans divers formats, une image très grande en pixels mais pas trop en octets, une image trop grande en octets, et un avatar à servir par défaut.

      Sont aussi présents cinq fichiers de tests avec une extension en .hurl :

      • le test de vie et les chemins hors img/ et avatars/
      • les tests sur les avatars : adresse valide ou invalide, image inexistante, bon et mauvais types, comportements sur les différents codes HTTP et sur une boucle de redirection infinie
      • les tests sur les images (découpés en trois parties, la partie initiale, la partie entre la récupération initiale et l’expiration du cache et enfin la partie après la récupération et l’expiration du cache.

      Vient enfin le script shell qui pilote le tout :

      • on définit les variables pour les cibles IPv4/IPv6 et les binaires redis et img que l’on veut utiliser dans les autres conteneurs Docker
      • on liste les images dans différentes catégories :
        • celles qui vont échouer et ne comporteront donc qu’une entrée dans redis sans rien dans le cache disque (avec sous-catégories possibles bloquées/non-bloquées)
        • les images devant être en erreur
        • les images qui iront normalement dans le cache
      • on prépare des images qui seront altérées plus tard
      • on purge le cache sur disque, on nettoie redis et on déclare toutes nos images comme le faire le code Ruby on Rails. Certaines sont déclarées bloquées pour les tests.
      • on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
      • on modifie certaines images pour simuler un changement sur le serveur externe, une suppression sur le serveur externe ou un blocage par l’équipe de site
      • on lance les tests post-récupération initiale mais avant l’expiration du cache (toujours avec toutes les variantes)
      • on force l’expiration du cache
      • on lance les tests post-expiration du cache (toujours avec toutes les variantes)
      • si on est arrivé jusqu’ici, c’est qu’on a passé tous les tests Hurl, alors maintenant on recompte ce que l’on a dans redis et sur disque et on vérifie si ça correspond à nos attentes
      • on nettoie les images mises volontairement en échec
      • on lance le test d’audit interne qui doit nous dire que tout va bien
      • si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

      L’audit interne

      L’objectif est de vérifier la cohérence des données dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image.

      Le binaire d’img peut donc être appelé en mode audit et lancer des contrôles internes.

      D’abord il collecte la liste des fichiers dans le cache disque.

      Ensuite il vérifie que toutes les images listées dans les dernières images (img/latest) existent comme entrées individuelles.

      Puis il vérifie s’il existe des images bloquées (il râlera s’il y en a) et si chacune existe comme entrée individuelle le cas échéant.

      Ensuite on parcourt tous les entrées individuelles d’images :

      • on râle si on tombe sur une entrée img/updated/ ou img/err/ sans date d’expiration
      • on râle si on tombe sur une entrée img/ sans champ created_at, sans type ou d’un type inconnu, sans checksum, avec un statut inconnu, une image bloquée non présente dans les images bloquées, un champ inconnu, une présence inattendue dans le cache disque, etc. Et on marque les images que l’on a vu passer comme attendu dans le cache.
      • on râle sur tous les fichiers du cache restants (ne correspondant à aucune image)
      • si on a râlé, on renvoie 1, sinon 0

      Le grand nettoyage

      img a fonctionné pendant 12 ans en production : il a rencontré des bugs, des comportements inattendus, des contenus et commentaires ont été supprimés ou réédités, etc. Il est donc probable qu’il y ait besoin d’aller dépoussiérer un peu tout cela et de retirer ce qui est inutile.

      Les traces du grand nettoyage sont d’abord visibles dans la rétrospective de la première quinzaine de septembre 2024 :

      • une « image » sur sept présente un souci (n’est pas une image, adresse invalide, trop grosse, etc.) et n’est donc pas dans le cache sur disque (ce qui a conduit à pas mal de taf sur la partie gestion des images)
      • les types de contenu (Content-Type) en provenance de sites variés et divers, c’est quelque chose… entre les « image/JPEG » ou « image/PNG » en majuscules parce que, les charset=utf-8 ou UTF-8 ou… sur du binaire, les name= qui ne sont pas dans la norme… Wikimedia renvoie aussi du profile="https://www.mediawiki.org/wiki/Specs/SVG/1.0.0" (pareil ça semble en dehors de tout standard).

      D’abord j’attaque le sujet la fleur au fusil en me disant que ça va passer crème, je fais un joli tableau qui résume l’état initial :

                                    img/<uri>   img/updated/<uri>   img/err/<uri>   blocked
      total                           25565 -21       634               160            5
      
      no created_at                      23 -23         0                 0            0
      created_at                       2857 -3          0                 5            1
      created_at+type                   222             0                 0            0
      total not in cache               3104 -26         0                 0            0
      
      created_at+type+checksum(+etag) 22463 +5        634               155            4
      
      files in cache                  22778 +5
      

      Donc on a officiellement 25 565 images, mais 23 sont mal créées (état théoriquement impossible hors race condition), 222 sont incomplètes (état théoriquement impossible race condition), 22 463 sont attendues en cache et on a 22 778 fichiers dans le cache. Ça part mal. Je nettoie en premier le plus facile (on voit le delta +/- de mes corrections). Et on arrive à une situation où une image sur sept présente alors un souci et il faut gérer un grand volume de corrections à faire.

      Parmi les soucis on trouve des types de contenus inattendus (image/PNG ou image/JPEG avec majuscules, image, des images binaires annoncées avec un charset, des types invalides comme image/jpg au lieu de image/jpeg, etc), des erreurs de notre lectorat (mauvais lien, mauvais copier-coller, lien vers une page web au lieu d’une image), mais aussi des espaces insécables et autres blancs inopportuns, des guillemets convertis, des doubles scheme (http://https:// ou http://file://).

      Après cela se cache une autre catégorie encore plus pénible : les images que l’on a en cache, mais qui ne sont plus utiles au site : par exemple celles qui étaient dans des contenus ou commentaires supprimés (notamment le spam), celles qui étaient dans des commentaires ou contenus réédités depuis, etc.

      Un problème connu est devenu vite pénible : on n’a pas d’association entre les images externes et les contenus/commentaires concernés. Donc il faut d’abord extraire la liste de toutes les déclarations d’images externes des 12 tables SQL où l’on peut trouver des images et des avatars, sous forme HTML ou Markdown.

      Ensuite il faut sortir toutes les entrées dans redis et regarder si on les retrouve en clair ou converties en hexadécimal dans l’extraction SQL.

      Et par sécurité on fera une double vérification pour celles détectées en erreur, en relançant une recherche en base (attention à la casse dans la recherche texte).

      Au final, on peut supprimer des milliers d’entrées redis et de fichiers dans le cache.

      Et un jour l’audit dit :

      Connection 127.0.0.1:6379 0
      2024/10/19 12:11:21 Sanity check mode only
      2024/10/19 12:11:37 Files in cache: 17926
      2024/10/19 12:11:39 Total img keys in redis: 18374
      OK
      

      Ça aura pris un mois et demi (l’audit a été fusionné le 8 septembre 2024), certes pas en continu, mais ça a été long et guère palpitant de faire ce grand ménage. Et j’ai refait une seconde passe du traitement complet la semaine d’après pour vérifier que tout se passait correctement et que les soucis résiduels après tout ça étaient minimes ou nuls.

      Parmi les anecdotes, Web Archive / archive.org a eu sa fuite de comptes utilisateurs et a été indisponible sur la fin (ce qui rendait compliqué la récupération d’images perdues ou leur remplacement par un lien valide par exemple). Et, mentionné dans la rétrospective de la seconde quinzaine de septembre 2024, un compte de spammeur de 2015 supprimé… mieux vaut tard que jamais : détecté parce que comme beaucoup de visiteurs, le spammeur ne fait pas la différence entre un lien vers un document et l’ajout d’une image.

      Les problématiques restantes

      Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails) et du remplacement des composants devenus non-libres (migrer vers valkey plutôt que redis ? Questions à se poser sur l’avenir de nginx ?).

      On pourrait aussi ajouter la prise en charge du TLS et d’un certificat X.509 directement dans img plutôt que dans un frontal. Mais ce n’est utile que si on les sépare sur deux serveurs distants, ce qui n’est pas le cas actuellement. Donc même si ça ne paraît pas compliqué à faire, ce n’est pas urgent.

      Ensuite une entrée de suivi existe pour séparer le cache des avatars du cache des autres images : les contraintes pour le cache des avatars étant différentes de celui des autres images, le stockage en cache devrait être différent. Cela reste un problème mineur. Le changement doit d’abord être fait côté Ruby on Rails pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier img pour séparer le traitement des requêtes HTTP /img/<adresse_hexa> vers les clés redis img/<adresse> et le cache disque des images par rapport aux requêtes /avatars/<adresse_hexa> vers les clés avatars/<adresse> et le cache des avatars. Il faudra aussi déplacer les avatars stockés dans l’actuel cache des images dans leur propre cache. Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.

      Un autre problème concerne la non-association des contenus ou commentaires avec les images externes qu’ils contiennent, ce qui rend l’administration des anciennes images un peu pénible. Le fait que les contenus et commentaires peuvent être réédités ou simplement prévisualisés (donc que des images peuvent être supprimées et d’autres ajoutées) vient compliquer un peu la tâche. Actuellement un ensemble de scripts permettent d’obtenir ces infos et fournissent un contournement, mais ça reste un peu laborieux.

      Un cache rafraîchi périodiquement conserve les images pour éviter de surcharger le site d’origine, pas si le site a changé, déplacé ou perdu l’image. La modification pour servir depuis le cache disque en cas d’échec de récupération couvre le cas de la disparition d’une image avec une erreur sur l’adresse, pas celui où le serveur répond une mauvaise image. Il y a donc une autre entrée de suivi images et disparition du web évoquant l’augmentation des soucis sur les images externes avec un cache rafraîchi, en raison des domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing (imageshack.us, après framapic, pix.toilelibre, etc.). Diverses problématiques sont mentionnées comme la perte d’information et donc la diminution de l’intérêt des contenus anciens, la prime aux pénibles du référencement SEO qui pourrissent le net en récupérant les vieux domaines, la modification possible des images publiées. Pour résoudre cela techniquement, ça nécessite de suivre les images et les domaines perdus, et d’intervenir de façon régulière. Ou bien de ne plus rafraîchir le cache (que cela soit jamais, après la publication ou au bout d’un certain temps après la publication). Pour juste éviter la perte d’info, il est possible de remplacer par une image locale récupérée d’une archive du net type archive.org, avec le côté « pénible à faire » et sans garantie que ça soit toujours possible (merci waybackpy).

      Enfin une troisième entrée de suivi suggère l'hébergement des images des dépêches (et éventuellement des journaux), idéalement en permettant d’avoir une version modifiée d’une image en changeant sa taille. On peut citer en vrac comme problématiques la responsabilité légale, l’éventuelle volumétrie, l’impossibilité de corriger une image publiée facilement par la personne qui l’a soumise, la centralisation et la perte de référencement pour des tiers, l’éventuelle rétroactivité et le traitement de l’historique, le fait qu’il faut traiter tous les autres contenus/commentaires pouvant accueillir des images, etc. Autre question, faut-il différencier les images passées en modération a priori de celles en modération a posteriori ?

      Conclusion ?

      Bref sans surprise, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

      img apporte les fonctionnalités que l’on attendait de lui même si on pourrait faire mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du redis et du nginx, du hurl et de l’HTTP. Et de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche. Reste à savoir si j’ai répondu à l’attente d’un article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… et la réponse est à trouver dans les commentaires.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      Triumphs, Trials, and Tangles From California's 2024 Legislative Session

      California’s 2024 legislative session has officially adjourned, and it’s time to reflect on the wins and losses that have shaped Californians’ digital rights landscape this year.

      EFF monitored nearly 100 bills in the state this session alone, addressing a broad range of issues related to privacy, free speech, and innovation. These include proposed standards for Artificial Intelligence (AI) systems used by state agencies, the intersection of AI and copyright, police surveillance practices, and various privacy concerns. While we have seen some significant victories, there are also alarming developments that raise concerns about the future of privacy protection in the state.

      Celebrating Our Victories

      This legislative session brought some wins for privacy advocates—most notably the defeat of four dangerous bills: A.B. 3080, A.B. 1814, S.B. 1076, and S.B. 1047. These bills posed serious threats to consumer privacy and would have undermined the progress we’ve made in previous years.

      First, we commend the California Legislature for not advancing A.B. 3080, “The Parent’s Accountability and Child Protection Act” authored by Assemblymember Juan Alanis (Modesto). The bill would have created powerful incentives for “pornographic internet websites” to use age-verification mechanisms. The bill was not clear on what counts as “sexually explicit content.” Without clear guidelines, this bill will further harm the ability of all youth—particularly LGBTQ+ youth—to access legitimate content online. Different versions of bills requiring age verification have appeared in more than a dozen states. We understand Asm. Alanis' concerns, but A.B. 3080 would have required broad, privacy-invasive data collection from internet users of all ages. We are grateful that it did not make it to the finish line.

      Second, EFF worked with dozens of organizations to defeat A.B. 1814, a facial recognition bill authored by Assemblymember Phil Ting (San Francisco). The bill attempted to expand the use of facial recognition software by police to “match” images from surveillance databases to possible suspects. Those images could then be used to issue arrest warrants or search warrants. The bill merely said that these matches can't be the sole reason for a warrant to be issued—a standard that has already failed to stop false arrests in other states.  Police departments and facial recognition companies alike both currently maintain that police cannot justify an arrest using only algorithmic matches–so what would this bill really change? The bill only gave the appearance of doing something to address face recognition technology's harms, while allowing the practice to continue. California should not give law enforcement the green light to mine databases, particularly those where people contributed information without knowledge that it would be accessed by law enforcement. You can read more about this bill here, and we are glad to see the California legislature reject this dangerous bill.

      EFF also worked to oppose and defeat S.B. 1076, by Senator Scott Wilk (Lancaster). This bill would have weakened the California Delete Act (S.B. 362). Enacted last year, the Delete Act provides consumers with an easy “one-click” button to request the removal of their personal information held by data brokers registered in California. By January 1, 2026. S.B. 1076 would have opened loopholes for data brokers to duck compliance. This would have hurt consumer rights and undone oversight on an opaque ecosystem of entities that collect then sell personal information they’ve amassed on individuals. S.B. 1076 would have likely created significant confusion with the development, implementation, and long-term usability of the delete mechanism established in the California Delete Act, particularly as the California Privacy Protection Agency works on regulations for it. 

      Lastly, EFF opposed S.B. 1047, the “Safe and Secure Innovation for Frontier Artificial Intelligence Models Act authored by Senator Scott Wiener (San Francisco). This bill aimed to regulate AI models that might have "catastrophic" effects, such as attacks on critical infrastructure. Ultimately, we believe focusing on speculative, long-term, catastrophic outcomes from AI (like machines going rogue and taking over the world) pulls attention away from AI-enabled harms that are directly before us. EFF supported parts of the bill, like the creation of a public cloud-computing cluster (CalCompute). However, we also had concerns from the beginning that the bill set an abstract and confusing set of regulations for those developing AI systems and was built on a shaky self-certification mechanism. Those concerns remained about the final version of the bill, as it passed the legislature.

      Governor Newsom vetoed S.B. 1047; we encourage lawmakers concerned about the threats unchecked AI may pose to instead consider regulation that focuses on real-world harms.  

      Of course, this session wasn’t all sunshine and rainbows, and we had some big setbacks. Here are a few:

      The Lost Promise of A.B. 3048

      Throughout this session, EFF and our partners supported A.B. 3048, common-sense legislation that would have required browsers to let consumers exercise their protections under the California Consumer Privacy Act (CCPA). California is currently one of approximately a dozen states requiring businesses to honor consumer privacy requests made through opt–out preference signals in their browsers and devices. Yet large companies have often made it difficult for consumers to exercise those rights on their own. The bill would have properly balanced providing consumers with ways to exercise their privacy rights without creating burdensome requirements for developers or hindering innovation.

      Unfortunately, Governor Newsom chose to veto A.B. 3048. His veto letter cited the lack of support from mobile operators, arguing that because “No major mobile OS incorporates an option for an opt-out signal,” it is “best if design questions are first addressed by developers, rather than by regulators.” EFF believes technologists should be involved in the regulatory process and hopes to assist in that process. But Governor Newsom is wrong: we cannot wait for industry players to voluntarily support regulations that protect consumers. Proactive measures are essential to safeguard privacy rights.

      This bill would have moved California in the right direction, making California the first state to require browsers to offer consumers the ability to exercise their rights. 

      Wrong Solutions to Real Problems

      A big theme we saw this legislative session were proposals that claimed to address real problems but would have been ineffective or failed to respect privacy. These included bills intended to address young people’s safety online and deepfakes in elections.

      While we defeated many misguided bills that were introduced to address young people’s access to the internet, S.B. 976, authored by Senator Nancy Skinner (Oakland), received Governor Newsom’s signature and takes effect on January 1, 2027. This proposal aims to regulate the "addictive" features of social media companies, but instead compromises the privacy of consumers in the state. The bill is also likely preempted by federal law and raises considerable First Amendment and privacy concerns. S.B. 976 is unlikely to protect children online, and will instead harm all online speakers by burdening free speech and diminishing online privacy by incentivizing companies to collect more personal information.

      It is no secret that deepfakes can be incredibly convincing, and that can have scary consequences, especially during an election year. Two bills that attempted to address this issue are A.B. 2655 and A.B. 2839. Authored by Assemblymember Marc Berman (Palo Alto), A.B. 2655 requires online platforms to develop and implement procedures to block and take down, as well as separately label, digitally manipulated content about candidates and other elections-related subjects that creates a false portrayal about those subjects. We believe A.B. 2655 likely violates the First Amendment and will lead to over-censorship of online speech. The bill is also preempted by Section 230, a federal law that provides partial immunity to online intermediaries for causes of action based on the user-generated content published on their platforms. 

      Similarly, A.B. 2839, authored by Assemblymember Gail Pellerin (Santa Cruz), not only bans the distribution of materially deceptive or altered election-related content, but also burdens mere distributors (internet websites, newspapers, etc.) who are unconnected to the creation of the content—regardless of whether they know of the prohibited manipulation. By extending beyond the direct publishers and toward republishers, A.B. 2839 burdens and holds liable republishers of content in a manner that has been found unconstitutional.

      There are ways to address the harms of deepfakes without stifling innovation and free speech. We recognize the complex issues raised by potentially harmful, artificially generated election content. But A.B. 2655 and A.B. 2839, as written and passed, likely violate the First Amendment and run afoul of federal law. In fact, less than a month after they were signed, a federal judge put A.B. 2839’s enforcement on pause (via a preliminary injunction) on First Amendment grounds.

      Privacy Risks in State Databases

      We also saw a troubling trend in the legislature this year that we will be making a priority as we look to 2025. Several bills emerged this session that, in different ways, threatened to weaken privacy protections within state databases. Specifically,  A.B. 518 and A.B. 2723, which received Governor Newsom’s signature, are a step backward for data privacy.

      A.B. 518 authorizes numerous agencies in California to share, without restriction or consent, personal information with the state Department of Social Services (DSS), exempting this sharing from all state privacy laws. This includes county-level agencies, and people whose information is shared would have no way of knowing or opting out. A. B. 518 is incredibly broad, allowing the sharing of health information, immigration status, education records, employment records, tax records, utility information, children’s information, and even sealed juvenile records—with no requirement that DSS keep this personal information confidential, and no restrictions on what DSS can do with the information.

      On the other hand, A.B. 2723 assigns a governing board to the new “Cradle to Career (CTC)” longitudinal education database intended to synthesize student information collected from across the state to enable comprehensive research and analysis. Parents and children provide this information to their schools, but this project means that their information will be used in ways they never expected or consented to. Even worse, as written, this project would be exempt from the following privacy safeguards of the Information Practices Act of 1977 (IPA), which, with respect to state agencies, would otherwise guarantee California parents and students:

      1.     the right for subjects whose information is kept in the data system to receive notice their data is in the system;
      2.     the right to consent or, more meaningfully, to withhold consent;
      3.     and the right to request correction of erroneous information.

      By signing A.B. 2723, Gov. Newsom stripped California parents and students of the rights to even know that this is happening, or agree to this data processing in the first place. 

      Moreover, while both of these bills allowed state agencies to trample on Californians’ IPA rights, those IPA rights do not even apply to the county-level agencies affected by A.B. 518 or the local public schools and school districts affected by A.B. 2723—pointing to the need for more guardrails around unfettered data sharing on the local level.

      A Call for Comprehensive Local Protections

      A.B. 2723 and A.B. 518 reveal a crucial missing piece in Californians' privacy rights: that the privacy rights guaranteed to individuals through California's IPA do not protect them from the ways local agencies collect, share, and process data. The absence of robust privacy protections at the local government level is an ongoing issue that must be addressed.

      Now is the time to push for stronger privacy protections, hold our lawmakers accountable, and ensure that California remains a leader in the fight for digital privacy. As always, we want to acknowledge how much your support has helped our advocacy in California this year. Your voices are invaluable, and they truly make a difference.

      Let’s not settle for half-measures or weak solutions. Our privacy is worth the fight.

      EU to Apple: “Let Users Choose Their Software”; Apple: “Nah”

      28 octobre 2024 à 10:48

      This year, a far-reaching, complex new piece of legislation comes into effect in EU: the Digital Markets Act (DMA), which represents some of the most ambitious tech policy in European history. We don’t love everything in the DMA, but some of its provisions are great, because they center the rights of users of technology, and they do that by taking away some of the control platforms exercise over users, and handing that control back to the public who rely on those platforms.

      Our favorite parts of the DMA are the interoperability provisions. IP laws in the EU (and the US) have all but killed the longstanding and honorable tradition of adversarial interoperability: that’s when you can alter a service, program or device you use, without permission from the company that made it. Whether that’s getting your car fixed by a third-party mechanic, using third-party ink in your printer, or choosing which apps run on your phone, you should have the final word. If a company wants you to use its official services, it should make the best services, at the best price – not use the law to force you to respect its business-model.

      It seems the EU agrees with us, at least on this issue. The DMA includes several provisions that force the giant tech companies that control so much of our online lives (AKA “gatekeeper platforms”) to provide official channels for interoperators. This is a great idea, though, frankly, lawmakers should also restore the right of tinkerers and hackers to reverse-engineer your stuff and let you make it work the way you want.

      One of these interop provisions is aimed at app stores for mobile devices. Right now, the only (legal) way to install software on your iPhone is through Apple’s App Store. That’s fine, so long as you trust Apple and you think they’re doing a great job, but pobody’s nerfect, and even if you love Apple, they won’t always get it right – like when they tell you you’re not allowed to have an app that records civilian deaths from US drone strikes, or a game that simulates life in a sweatshop, or a dictionary (because it has swear words!). The final word on which apps you use on your device should be yours.

      Which is why the EU ordered Apple to open up iOS devices to rival app stores, something Apple categorically refuses to do. Apple’s “plan” for complying with the DMA is, shall we say, sorely lacking (this is part of a grand tradition of American tech giants wiping their butts with EU laws that protect Europeans from predatory activity, like the years Facebook spent ignoring European privacy laws, manufacturing stupid legal theories to defend the indefensible).

      Apple’s plan for opening the App Store is effectively impossible for any competitor to use, but this goes double for anyone hoping to offer free and open source software to iOS users. Without free software – operating systems like GNU/Linux, website tools like WordPress, programming languages like Rust and Python, and so on – the internet would grind to a halt.

      Our dear friends at Free Software Foundation Europe (FSFE) have filed an important brief with the European Commission, formally objecting to Apple’s ridiculous plan on the grounds that it effectively bars iOS users from choosing free software for their devices.

      FSFE’s brief makes a series of legal arguments, rebutting Apple’s self-serving theories about what the DMA really means. FSFE shoots down Apple’s tired argument that copyrights and patents override any interoperability requirements. U.S. courts have been inconsistent on this issue, but we’re hopeful that the Court of Justice of the E.U. will reject the “intellectual property trump card.” Even more importantly, FSFE makes moral and technical arguments about the importance of safeguarding the technological self-determination of users by letting them choose free software, and about why this is as safe – or safer – than giving Apple a veto over its customers’ software choices.

      Apple claims that because you might choose bad software, you shouldn’t be able to choose software, period. They say that if competing app stores are allowed to exist, users won’t be safe or private. We disagree – and so do some of the most respected security experts in the world.

      It’s true that Apple can use its power wisely to ensure that you only choose good software. But it’s also used that power to attack its users, like in China, where Apple blocked all working privacy tools from iPhones and then neutered a tool used to organize pro-democracy protests.

      It’s not just in China, either. Apple has blanketed the world with billboards celebrating its commitment to its users’ privacy, and they made good on that promise, blocking third-party surveillance (to the $10 billion dollar chagrin of Facebook). But right in the middle of all that, Apple also started secretly spying on iOS users to fuel its own surveillance advertising network, and then lied about it.

      Pobody’s nerfect. If you trust Apple with your privacy and security, that’s great. But for people who don’t trust Apple to have the final word – for people who value software freedom, or privacy (from Apple), or democracy (in China), users should have the final say.

      We’re so pleased to see the EU making tech policy we can get behind – and we’re grateful to our friends at FSFE for holding Apple’s feet to the fire when they flout that law.

      L’IA Open Source existe-t-elle vraiment ?

      Par : Framalang
      31 octobre 2024 à 05:10

      À l’heure où tous les mastodontes du numérique, GAFAM comme instituts de recherche comme nouveaux entrants financés par le capital risque se mettent à publier des modèles en masse (la plateforme Hugging Face a ainsi dépassé le million de modèles déposés le mois dernier), la question du caractère « open-source » de l’IA se pose de plus en plus.

      Ainsi, l’Open Source Initiative (OSI) vient de publier une première définition de l’IA Open-Source, et la Linux Foundation (dont le nom peut prêter à confusion, mais qui ne représente surtout qu’une oligarchie d’entreprises du secteur) s’interroge également sur le terme.

      Au milieu de tout cela, OpenAI devient de manière assez prévisible de moins en moins « open », et si Zuckerberg et Meta s’efforcent de jouer la carte de la transparence en devenant des hérauts de l’« IA Open-Source », c’est justement l’OSI qui leur met des bâtons dans les roues en ayant une vision différente de ce que devrait être une IA Open-Source, avec en particulier un pré-requis plus élevé sur la transparence des données d’entraînement.

      Néanmoins, la définition de l’OSI, si elle embête un peu certaines entreprises, manque selon la personne ayant écrit ce billet (dont le pseudo est « tante ») d’un élément assez essentiel, au point qu’elle se demande si « l’IA open source existe-t-elle vraiment ? ».

      Note : L’article originel a été publié avant la sortie du texte final de l’OSI, mais celui-ci n’a semble t-il pas changé entre la version RC1 et la version finale.

      L’IA Open Source existe-t-elle vraiment ?

      Par tante, sous licence CC BY-SA (article originel).
      Une traduction Framalang par tcit et deux contributeur·ices anonymes.
      Photo de la bannière par Robert Couse-Baker.

       

       

      L’Open Source Initiative (OSI) a publié la RC1 (« Release Candidate 1 » signifiant : cet écrit est pratiquement terminé et sera publié en tant que tel à moins que quelque chose de catastrophique ne se produise) de la « Définition de l’IA Open Source ».

      D’aucuns pourraient se demander en quoi cela est important. Plein de personnes écrivent sur l’IA, qu’est-ce que cela apporte de plus ? C’est la principale activité sur LinkedIn à l’heure actuelle. Mais l’OSI joue un rôle très particulier dans l’écosystème des logiciels libres. En effet, l’open source n’est pas seulement basé sur le fait que l’on peut voir le code, mais aussi sur la licence sous laquelle le code est distribué : Vous pouvez obtenir du code que vous pouvez voir mais que vous n’êtes pas autorisé à modifier (pensez au débat sur la publication récente de celui de WinAMP). L’OSI s’est essentiellement chargée de définir parmi les différentes licences utilisées partout lesquelles sont réellement « open source » et lesquelles sont assorties de restrictions qui sapent cette idée.

      C’est très important : le choix d’une licence est un acte politique lourd de conséquences. Elle peut autoriser ou interdire différents modes d’interaction avec un objet ou imposer certaines conditions d’utilisation. La célèbre GPL, par exemple, vous permet de prendre le code mais vous oblige à publier vos propres modifications. D’autres licences n’imposent pas cette exigence. Le choix d’une licence a des effets tangibles.

      Petit aparté : « open source » est déjà un terme un peu problématique, c’est (à mon avis) une façon de dépolitiser l’idée de « Logiciel libre ». Les deux partagent certaines idées, mais là où « open source » encadre les choses d’une manière plus pragmatique « les entreprises veulent savoir quel code elles peuvent utiliser », le logiciel libre a toujours été un mouvement plus politique qui défend les droits et la liberté de l’utilisateur. C’est une idée qui a probablement été le plus abimée par les figures les plus visibles de cet espace et qui devraient aujourd’hui s’effacer.

      Qu’est-ce qui fait qu’une chose est « open source » ? L’OSI en dresse une courte liste. Vous pouvez la lire rapidement, mais concentrons-nous sur le point 2 : le code source :

      Le programme doit inclure le code source et doit permettre la distribution du code source et de la version compilée. Lorsqu’une quelconque forme d’un produit n’est pas distribuée avec le code source, il doit exister un moyen bien connu d’obtenir le code source pour un coût de reproduction raisonnable, de préférence en le téléchargeant gratuitement sur Internet. Le code source doit être la forme préférée sous laquelle un programmeur modifierait le programme. Le code source délibérément obscurci n’est pas autorisé. Les formes intermédiaires telles que la sortie d’un préprocesseur ou d’un traducteur ne sont pas autorisées.
      Open Source Initiative

      Pour être open source, un logiciel doit donc être accompagné de ses sources. D’accord, ce n’est pas surprenant. Mais les rédacteurs ont vu pas mal de conneries et ont donc ajouté que le code obfusqué (c’est-à-dire le code qui a été manipulé pour être illisible) ou les formes intermédiaires (c’est-à-dire que vous n’obtenez pas les sources réelles mais quelque chose qui a déjà été traité) ne sont pas autorisés. Très bien. C’est logique. Mais pourquoi les gens s’intéressent-ils aux sources ?

      Les sources de la vérité

      L’open source est un phénomène de masse relativement récent. Nous avions déjà des logiciels, et même certains pour lesquels nous ne devions pas payer. À l’époque, on les appelait des « Freeware », des « logiciels gratuits ». Les freewares sont des logiciels que vous pouvez utiliser gratuitement mais dont vous n’obtenez pas le code source. Vous ne pouvez pas modifier le programme (légalement), vous ne pouvez pas l’auditer, vous ne pouvez pas le compléter. Mais il est gratuit. Et il y avait beaucoup de cela dans ma jeunesse. WinAMP, le lecteur audio dont j’ai parlé plus haut, était un freeware et tout le monde l’utilisait. Alors pourquoi se préoccuper des sources ?

      Pour certains, il s’agissait de pouvoir modifier les outils plus facilement, surtout si le responsable du logiciel ne travaillait plus vraiment dessus ou commençait à ajouter toutes sortes de choses avec lesquelles ils n’étaient pas d’accord (pensez à tous ces logiciels propriétaires que vous devez utiliser aujourd’hui pour le travail et qui contiennent de l’IA derrière tous les autres boutons). Mais il n’y a pas que les demandes de fonctionnalités. Il y a aussi la confiance.

      Lorsque j’utilise un logiciel, je dois faire confiance aux personnes qui l’ont écrit. Leur faire confiance pour qu’ils fassent du bon travail, pour qu’ils créent des logiciels fiables et robustes. Qu’ils n’ajoutent que les fonctionnalités décrites dans la documentation et rien de caché, de potentiellement nuisible.

      Les questions de confiance sont de plus en plus importantes, d’autant plus qu’une grande partie de notre vie réelle repose sur des infrastructures numériques. Nous savons tous que nos infrastructures doivent comporter des algorithmes de chiffrement entièrement ouverts, évalués par des pairs et testés sur le terrain, afin que nos communications soient à l’abri de tout danger.

      L’open source est – en particulier pour les systèmes et infrastructures critiques – un élément clé de l’établissement de cette confiance : Parce que vous voulez que (quelqu’un) soit en mesure de vérifier ce qui se passe. On assiste depuis longtemps à une poussée en faveur d’une plus grande reproductibilité des processus de construction. Ces processus de compilation garantissent essentiellement qu’avec le même code d’entrée, on obtient le même résultat compilé. Cela signifie que si vous voulez savoir si quelqu’un vous a vraiment livré exactement ce qu’il a dit, vous pouvez le vérifier. Parce que votre processus de construction créerait un artefact identique.

      Logo du projet Reproducible builds

      Le projet Reproducible builds cherche à promouvoir la reproductibilité des systèmes libres, pour plus de transparence.
      Le projet est notamment financé par le Sovereign Tech Fund.

       

      Bien entendu, tout le monde n’effectue pas ce niveau d’analyse. Et encore moins de personnes n’utilisent que des logiciels issus de processus de construction reproductibles – surtout si l’on considère que de nombreux logiciels ne sont pas compilés aujourd’hui. Mais les relations sont plus nuancées que le code et la confiance est une relation : si vous me parlez ouvertement de votre code et de la manière dont la version binaire a été construite, il me sera beaucoup plus facile de vous faire confiance. Savoir ce que contient le logiciel que j’exécute sur la machine qui contient également mes relevés bancaires ou mes clés de chiffrement.

      Mais quel est le rapport avec l’IA ?

      Les systèmes d’IA et les 4 libertés

      Les systèmes d’IA sont un peu particuliers. En effet, les systèmes d’IA – en particulier les grands systèmes qui fascinent tout le monde – ne contiennent pas beaucoup de code par rapport à leur taille. La mise en œuvre d’un réseau neuronal se résume à quelques centaines de lignes de Python, par exemple. Un « système d’IA » ne consiste pas seulement en du code, mais en un grand nombre de paramètres et de données.

      Un LLM moderne (ou un générateur d’images) se compose d’un peu de code. Vous avez également besoin d’une architecture de réseau, c’est-à-dire de la configuration des neurones numériques utilisés et de la manière dont ils sont connectés. Cette architecture est ensuite paramétrée avec ce que l’on appelle les « poids » (weights), qui sont les milliards de chiffres dont vous avez besoin pour que le système fasse quelque chose. Mais ce n’est pas tout.

      Pour traduire des syllabes ou des mots en nombres qu’une « IA » peut consommer, vous avez besoin d’une intégration, une sorte de table de recherche qui vous indique à quel « jeton » (token) correspond le nombre « 227 ». Si vous prenez le même réseau neuronal mais que vous lui appliquez une intégration différente de celle avec laquelle il a été formé, tout tomberait à l’eau. Les structures ne correspondraient pas.

      Représentation d'une puce informatique sous la forme d'un cerveau.

      Image sous CC BY par Mike MacKenzie & Liam Huang

      Ensuite, il y a le processus de formation, c’est-à-dire le processus qui a créé tous les « poids ». Pour entraîner une « IA », vous lui fournissez toutes les données que vous pouvez trouver et, après des millions et des milliards d’itérations, les poids commencent à émerger et à se cristalliser. Le processus de formation, les données utilisées et la manière dont elles le sont sont essentiels pour comprendre les capacités et les problèmes d’un système d’apprentissage automatique : si vous voulez réduire les dommages dans un réseau, vous devez savoir s’il a été formé sur Valeurs Actuelles ou non, pour donner un exemple.

      Et c’est là qu’est le problème.

      L’OSI « The Open Source AI Definition – 1.0-RC1 » exige d’une IA open source qu’elle offre quatre libertés à ses utilisateurs :

      1. Utiliser le système à n’importe quelle fin et sans avoir à demander la permission.
      2. Étudier le fonctionnement du système et inspecter ses composants.
      3. Modifier le système dans n’importe quel but, y compris pour changer ses résultats.
      4. Partager le système pour que d’autres puissent l’utiliser, avec ou sans modifications, dans n’importe quel but.

      Jusqu’ici tout va bien. Cela semble raisonnable, n’est-ce pas ? Vous pouvez inspecter, modifier, utiliser et tout ça. Génial. Tout est couvert dans les moindre détails, n’est-ce pas ? Voyons rapidement ce qu’un système d’IA doit offrir. Le code : Check. Les paramètres du modèle (poids, configurations) : Check ! Nous sommes sur la bonne voie. Qu’en est-il des données ?

      Informations sur les données : Informations suffisamment détaillées sur les données utilisées pour entraîner le système, de manière à ce qu’une personne compétente puisse construire un système substantiellement équivalent. Les informations sur les données sont mises à disposition dans des conditions approuvées par l’OSI.

      En particulier, cela doit inclure (1) une description détaillée de toutes les données utilisées pour la formation, y compris (le cas échéant) des données non partageables, indiquant la provenance des données, leur portée et leurs caractéristiques, la manière dont les données ont été obtenues et sélectionnées, les procédures d’étiquetage et les méthodes de nettoyage des données ; (2) une liste de toutes les données de formation accessibles au public et l’endroit où les obtenir ; et (3) une liste de toutes les données de formation pouvant être obtenues auprès de tiers et l’endroit où les obtenir, y compris à titre onéreux.
      Open Source Initiative

      Que signifie « informations suffisamment détaillées » ? La définition de l’open source ne parle jamais de « code source suffisamment détaillé ». Vous devez obtenir le code source. Tout le code source. Et pas sous une forme obscurcie ou déformée. Le vrai code. Sinon, cela ne veut pas dire grand-chose et ne permet pas d’instaurer la confiance.

      La définition de l’« IA Open Source » donnée par l’OSI porte un grand coup à l’idée d’open source : en rendant une partie essentielle du modèle (les données d’entraînement) particulière de cette manière étrange et bancale, ils qualifient d’« open source » toutes sortes de choses qui ne le sont pas vraiment, sur la base de leur propre définition de ce qu’est l’open source et de ce à quoi elle sert.

      Les données d’apprentissage d’un système d’IA font à toutes fins utiles partie de son « code ». Elles sont aussi pertinentes pour le fonctionnement du modèle que le code littéral. Pour les systèmes d’IA, elles le sont probablement encore plus, car le code n’est qu’une opération matricielle générique avec des illusions de grandeur.

      L’OSI met une autre cerise sur le gâteau : les utilisateurs méritent une description des « données non partageables » qui ont été utilisées pour entraîner un modèle. Qu’est-ce que c’est ? Appliquons cela au code à nouveau : si un produit logiciel nous donne une partie essentielle de ses fonctionnalités simplement sous la forme d’un artefact compilé et nous jure ensuite que tout est totalement franc et honnête, mais que le code n’est pas « partageable », nous n’appellerions pas ce logiciel « open source ». Parce qu’il n’ouvre pas toutes les sources.

      Une « description » de données partiellement « non partageables » vous aide-t-elle à reproduire le modèle ? Non. Vous pouvez essayer de reconstruire le modèle et il peut sembler un peu similaire, mais il est significativement différent. Cela vous aide-t-il d’« étudier le système et d’inspecter ses composants » ? Seulement à un niveau superficiel. Mais si vous voulez vraiment analyser ce qu’il y a dans la boîte de statistiques magiques, vous devez savoir ce qu’il y a dedans. Qu’est-ce qui a été filtré exactement, qu’est-ce qui est entré ?

      Cette définition semble très étrange venant de l’OSI, n’est-ce pas ? De toute évidence, cela va à l’encontre des idées fondamentales de ce que les gens pensent que l’open source est et devrait être. Alors pourquoi le faire ?

      L’IA (non) open source

      Voici le truc. À l’échelle où nous parlons aujourd’hui de ces systèmes statistiques en tant qu’« IA », l’IA open source ne peut pas exister.

      De nombreux modèles plus petits ont été entraînés sur des ensembles de données publics explicitement sélectionnés et organisés. Ceux-ci peuvent fournir toutes les données, tout le code, tous les processus et peuvent être appelés IA open-source. Mais ce ne sont pas ces systèmes qui font s’envoler l’action de NVIDIA.

      Ces grands systèmes que l’on appelle « IA » – qu’ils soient destinés à la génération d’images, de texte ou multimodaux – sont tous basés sur du matériel acquis et utilisé illégalement. Parce que les ensembles de données sont trop volumineux pour effectuer un filtrage réel et garantir leur légalité. C’est tout simplement trop.

      Maintenant, les plus naïfs d’entre vous pourraient se demander : « D’accord, mais si vous ne pouvez pas le faire légalement, comment pouvez-vous prétendre qu’il s’agit d’une entreprise légitime ? » et vous auriez raison, mais nous vivons aussi dans un monde étrange où l’espoir qu’une innovation magique et / ou de l’argent viendront de la reproduction de messages Reddit, sauvant notre économie et notre progrès.

      L’« IA open source » est une tentative de « blanchir » les systèmes propriétaires. Dans leur article « Repenser l’IA générative open source : l’openwashing et le règlement sur l’IA de l’UE  », Andreas Liesenfeld et Mark Dingemanse ont montré que de nombreux modèles d’IA « Open-Source » n’offrent guère plus que des poids de modèles ouverts. Signification : Vous pouvez faire fonctionner la chose mais vous ne savez pas vraiment ce que c’est.

      Cela ressemble à quelque chose que nous avons déjà eu : c’est un freeware. Les modèles open source que nous voyons aujourd’hui sont des blobs freeware propriétaires. Ce qui est potentiellement un peu mieux que l’approche totalement fermée d’OpenAI, mais seulement un peu.

      Certains modèles proposent des fiches de présentation du modèle ou d’autres documents, mais la plupart vous laissent dans l’ignorance. Cela s’explique par le fait que la plupart de ces modèles sont développés par des entreprises financées par le capital-risque qui ont besoin d’une voie théorique vers la monétisation.

      L’« open source » est devenu un autocollant comme le « Commerce équitable », quelque chose qui donne l’impression que votre produit est bon et digne de confiance. Pour le positionner en dehors du diabolique espace commercial, en lui donnant un sentiment de proximité. « Nous sommes dans le même bateau » et tout le reste. Mais ce n’est pas le cas. Nous ne sommes pas dans le même bateau que Mark fucking Zuckerberg, même s’il distribue gratuitement des poids de LLM parce que cela nuit à ses concurrents. Nous, en tant que personnes normales vivant sur cette planète qui ne cesse de se réchauffer, ne sommes avec aucune de ces personnes.

      Photo d'un sticker où il est marqué « Open-Source Fuck Yeah ».

      Les libristes adorent pourtant les stickers. Image sous CC BY-SA par Kirsten Comandich.

      Mais il y a un autre aspect à cette question, en dehors de redorer l’image des grands noms de la technologie et de leurs entreprises. Il s’agit de la légalité. Au moins en Allemagne, il existe des exceptions à certaines lois qui concernent normalement les auteurs de LLM : si vous le faites à des fins de recherche, vous êtes autorisé à récupérer pratiquement n’importe quoi. Vous pouvez ensuite entraîner des modèles et publier ces poids, et même s’il y a des contenus de Disney là-dedans, vous n’avez rien à craindre. C’est là que l’idée de l’IA open source joue un rôle important : il s’agit d’un moyen de légitimer un comportement probablement illégal par le biais de l’openwashing : en tant qu’entreprise, vous prenez de l’« IA open source » qui est basée sur tous les éléments que vous ne seriez pas légalement autorisé à toucher et vous l’utilisez pour construire votre produit. Faites de l’entraînement supplémentaire avec des données sous licence, par exemple.

      L’Open Source Initiative a attrapé le syndrome FOMO (N.d.T : Fear of Missing Out) – tout comme le jury du prix Nobel. Elle souhaite également participer à l’engouement pour l’« IA ».

      Mais pour les systèmes que nous appelons aujourd’hui « IA », l’IA open source n’est pas possible dans la pratique. En effet, nous ne pourrons jamais télécharger toutes les données d’entraînement réelles.

      « Mais tante, nous n’aurons jamais d’IA open source ». C’est tout à fait exact. C’est ainsi que fonctionne la réalité. Si vous ne pouvez pas remplir les critères d’une catégorie, vous n’appartenez pas à cette catégorie. La solution n’est pas de changer les critères. C’est comme jouer aux échecs avec les pigeons.

       

      In Appreciation of David Burnham

      Par : David Sobel
      22 octobre 2024 à 16:32

      We at EFF have long recognized the threats posed by the unchecked technological prowess of law enforcement and intelligence agencies. Since our founding in 1990, we have been in the forefront of efforts to impose meaningful legal controls and accountability on the secretive activities of those entities, including the National Security Agency (NSA). While the U.S. Senate’s Church Committee hearings and report in the mid-1970s documented the past abuses of government surveillance powers, it could not anticipate the dangers those interception and collection capabilities would bring to a networked environment. As Sen. Frank Church said in 1975 about an unchecked NSA, “No American would have any privacy left, such is the capability to monitor everything: telephone conversations, telegrams, it doesn't matter. There would be no place to hide.” The communications infrastructure was still in a mid-20th century analog mode.

      One of the first observers to recognize the impact of NSA’s capabilities in the emerging digital landscape was David Burnham, a pioneering investigative journalist and author who passed away earlier this month at 91 years of age. While the obituary that ran at his old home, The New York Times, rightly emphasized Burnham’s ground-breaking investigations of police corruption and the shoddy safety standards of the nuclear power industry (depicted, respectively, in the films “Serpico” and “Silkwood”), those in the digital rights world are especially appreciative of his prescience when it came to the issues we care about deeply.

      In 1983, Burnham published “The Rise of the Computer State,” one of the earliest examinations of the emerging challenges of the digital age. As Walter Cronkite wrote in his foreword to the book, “The same computer that enables us to explore the outer reaches of space and the mysteries of the atom can also be turned into an instrument of tyranny. We must ensure that the rise of the computer state does not also mean the demise of our civil liberties.” Here is what Burnham wrote in a piece for The New York Times Magazine based on the reporting in his book:

      With unknown billions of Federal dollars, the [NSA] purchases the most sophisticated communications and computer equipment in the world. But truly to comprehend the growing reach of this formidable organization, it is necessary to recall once again how the computers that power the NSA are also gradually changing lives of Americans - the way they bank, obtain benefits from the Government and communicate with family and friends. Every day, in almost every area of culture and commerce, systems and procedures are being adopted by private companies and organizations...that make it easier for the NSA to dominate American society...

      Remember, that was written in 1983. Ten years before the launch of the Mosaic browser and three decades before mobile devices became ubiquitous. But Burnham understood the trajectory of the emerging technology, for both the government and its citizens.

      Recognizing the dangers of unchecked surveillance powers, Burnham was a champion of oversight and transparency, and, consequently, he was a skilled and aggressive user of the Freedom of Information Act. In 1989, he partnered with Professor Susan Long to establish the Transactional Records Access Clearinghouse (TRAC) at Syracuse University. TRAC combines sophisticated use of FOIA with data analytics techniques “to develop as comprehensive and detailed a picture as possible about what federal enforcement and regulatory agencies actually do . . . and to organize all of this information to make it readily accessible to the public.” From its FOIA requests, TRAC adds more than 3 billion new records to its database annually. Its work is widely acclaimed by the many academics, journalists and lawyers who make use of its extensive resources. It is a fitting legacy to Burnham’s unwavering belief in the power of information.

      As EFF Executive Director Cindy Cohn has said when describing our work, we stand on the shoulders of giants. With his recognition of technology’s challenges to privacy, his insistence on transparency, and his joy in telling truth to power, David Burnham was one of them.

      Full disclosure: David was a longtime colleague, client and friend.

      How Many U.S. Persons Does Section 702 Spy On? The ODNI Needs to Come Clean.

      22 octobre 2024 à 13:05

      EFF has joined with 23 other organizations including the ACLU, Restore the Fourth, the Brennan Center for Justice, Access Now, and the Freedom of the Press Foundation to demand that the Office of the Director of National Intelligence (ODNI) furnish the public with an estimate of exactly how many U.S. persons’ communications have been hoovered up, and are now sitting on a government server for law enforcement to unconstitutionally sift through at their leisure.

      This letter was motivated by the fact that representatives of the National Security Agency (NSA) have promised in the past to provide the public with an estimate of how many U.S. persons—that is, people on U.S. soil—have had their communications “incidentally” collected through the surveillance authority Section 702 of the FISA Amendments Act. 

      As the letter states, “ODNI and NSA cannot expect public trust to be unconditional. If ODNI and NSA continue to renege on pledges to members of Congress, and to withhold information that lawmakers, civil society, academia, and the press have persistently sought over the course of thirteen years, that public trust will be fatally undermined.”

      Section 702 allows the government to conduct surveillance of foreigners abroad from inside the United States. It operates, in part, through the cooperation of large and small telecommunications service providers which hand over the digital data and communications they oversee. While Section 702 prohibits the NSA from intentionally targeting Americans with this mass surveillance, these agencies routinely acquire a huge amount of innocent Americans' communications “incidentally” because, as it turns out, people in the United States communicate with people overseas all the time. This means that the U.S. government ends up with a massive pool consisting of the U.S.-side of conversations as well as communications from all over the globe. Domestic law enforcement agencies, including the Federal Bureau of Investigation (FBI), can then conduct backdoor warrantless searches of these “incidentally collected” communications. 

      For over 10 years, EFF has fought hard every time Section 702 expires in the hope that we can get some much-needed reforms into any bills that seek to reauthorize the authority. Most recently, in spring 2024, Congress renewed Section 702 for another two years with none of the changes necessary to restore privacy rights

      While we wait for the upcoming opportunity to fight Section 702, joining our allies to sign on to this letter in the fight for transparency will give us a better understanding of the scope of the problem.

      You can read the whole letter here.

      Prosecutors in Washington State Warn Police: Don’t Use Gen AI to Write Reports

      17 octobre 2024 à 10:27

      The King County Prosecuting Attorney’s Office, which handles all prosecutions in the Seattle area, has instructed police in no uncertain terms: do not use AI to write police reports...for now. This is a good development. We hope prosecutors across the country will exercise such caution as companies continue to peddle technology – generative artificial intelligence (genAI) to help write police reports – that could harm people who come into contact with the criminal justice system.

      Chief Deputy Prosecutor Daniel J. Clark said in a memo about AI-based tools to write narrative police reports based on body camera audio that the technology as it exists is “one we are not ready to accept.”

      The memo continues,“We do not fear advances in technology – but we do have legitimate concerns about some of the products on the market now... AI continues to develop and we are hopeful that we will reach a point in the near future where these reports can be relied on. For now, our office has made the decision not to accept any police narratives that were produced with the assistance of AI.” We would add that, while EFF embraces advances in technology, we doubt genAI in the near future will be able to help police write reliable reports.

      We agree with Chief Deputy Clark that: “While an officer is required to edit the narrative and assert under penalty of perjury that it is accurate, some of the [genAI] errors are so small that they will be missed in review.”

      This is a well-reasoned and cautious approach. Some police want to cut the time they spend writing reports, and Axon’s new product DraftOne claims to do so by  exporting the labor to machines. But the public, and other local agencies, should be skeptical of this tech. After all, these documents are often essential for prosecutors to build their case, for district attorneys to recommend charges, and for defenders to cross examine arresting officers.

      To read more on generative AI and police reports, click here

      Civil Rights Commission Pans Face Recognition Technology

      In its recent report, Civil Rights Implications of Face Recognition Technology (FRT), the U.S. Commission on Civil Rights identified serious problems with the federal government’s use of face recognition technology, and in doing so recognized EFF’s expertise on this issue. The Commission focused its investigation on the Department of Justice (DOJ), the Department of Homeland Security (DHS), and the Department of Housing and Urban Development (HUD).

      According to the report, the DOJ primarily uses FRT within the Federal Bureau of Investigation and U.S. Marshals Service to generate leads in criminal investigations. DHS uses it in cross-border criminal investigations and to identify travelers. And HUD implements FRT with surveillance cameras in some federally funded public housing. The report explores how federal training on FRT use in these departments is inadequate, identifies threats that FRT poses to civil rights, and proposes ways to mitigate those threats.

      EFF supports a ban on government use of FRT and strict regulation of private use. In April of this year, we submitted comments to the Commission to voice these views. The Commission’s report quotes our comments explaining how FRT works, including the steps by which FRT uses a probe photo (the photo of the face that will be identified) to run an algorithmic search that matches the face within the probe photo to those in the comparison data set. Although EFF aims to promote a broader understanding of the technology behind FRT, our main purpose in submitting the comments was to sound the alarm about the many dangers the technology poses.

      These disparities in accuracy are due in part to algorithmic bias.

      The government should not use face recognition because it is too inaccurate to determine people’s rights and benefits, its inaccuracies impact people of color and members of the LGBTQ+ community at far higher rates, it threatens privacy, it chills expression, and it introduces information security risks. The report highlights many of the concerns that we've stated about privacy, accuracy (especially in the context of criminal investigations), and use by “inexperienced and inadequately trained operators.” The Commission also included data showing that face recognition is much more likely to reach a false positive (inaccurately matching two photos of different people) than a false negative (inaccurately failing to match two photos of the same person). According to the report, false positives are even more prevalent for Black people, people of East Asian descent, women, and older adults, thereby posing equal protection issues. These disparities in accuracy are due in part to algorithmic bias. Relatedly, photographs are often unable to accurately capture dark skinned people’s faces, which means that the initial inputs to the algorithm can themselves be unreliable. This poses serious problems in many contexts, but especially in criminal investigations, in which the stakes of an FRT misidentification are peoples’ lives and liberty.

      The Commission recommends that Congress and agency chiefs enact better oversight and transparency rules. While EFF agrees with many of the Commission’s critiques, the technology poses grave threats to civil liberties, privacy, and security that require a more aggressive response. We will continue fighting to ban face recognition use by governments and to strictly regulate private use. You can join our About Face project to stop the technology from entering your community and encourage your representatives to ban federal use of FRT.

      New EFF Report Provides Guidance to Ensure Human Rights are Protected Amid Government Use of AI in Latin America

      15 octobre 2024 à 15:48

                              

      Governments increasingly rely on algorithmic systems to support consequential assessments and determinations about people’s lives, from judging eligibility for social assistance to trying to predict crime and criminals. Latin America is no exception. With the use of artificial intelligence (AI) posing human rights challenges in the region, EFF released today the report Inter-American Standards and State Use of AI for Rights-Affecting Determinations in Latin America: Human Rights Implications and Operational Framework.

      This report draws on international human rights law, particularly standards from the Inter-American Human Rights System, to provide guidance on what state institutions must look out for when assessing whether and how to adopt artificial intelligence AI and automated decision-making (ADM) systems for determinations that can affect people’s rights.

      We organized the report’s content and testimonies on current challenges from civil society experts on the ground in our project landing page.

      AI-based Systems Implicate Human Rights

      The report comes amid deployment of AI/ADM-based systems by Latin American state institutions for services and decision-making that affects human rights. Colombians must undergo classification from Sisbén, which measures their degree of poverty and vulnerability, if they want to access social protection programs. News reports in Brazil have once again flagged the problems and perils of Córtex, an algorithmic-powered surveillance system that cross-references various state databases with wide reach and poor controls. Risk-assessment systems seeking to predict school dropout, children’s rights violations or teenage pregnancy have integrated government related programs in countries like México, Chile, and Argentina. Different courts in the region have also implemented AI-based tools for a varied range of tasks.

      EFF’s report aims to address two primary concerns: opacity and lack of human rights protections in state AI-based decision-making. Algorithmic systems are often deployed by state bodies in ways that obscure how decisions are made, leaving affected individuals with little understanding or recourse.

      Additionally, these systems can exacerbate existing inequalities, disproportionately impacting marginalized communities without providing adequate avenues for redress. The lack of public  participation in the development and implementation of these systems further undermines democratic governance, as affected groups are often excluded from meaningful decision-making processes relating to government adoption and use of these technologies.

      This is at odds with the human rights protections most Latin American countries are required to uphold. A majority of states have committed to comply with the American Convention on Human Rights and the Protocol of San Salvador. Under these international instruments, they have the duty to respect human rights and prevent violations from occurring. States’ responsibilities before international human rights law as guarantor of rights, and people and social groups as rights holders—entitled to call for them and participate—are two basic tenets that must guide any legitimate use of AI/ADM systems by state institutions for consequential decision-making, as we underscore in the report.

      Inter-American Human Rights Framework

      Building off extensive research of Inter-American Commission on Human Rights’ reports and Inter-American Court of Human Rights’ decisions and advisory opinions, we devise human rights implications and an operational framework for their due consideration in government use of algorithmic systems.

      We detail what states’ commitments under the Inter-American System mean when state bodies decide to implement AI/ADM technologies for rights-based determinations. We explain why this adoption must fulfill necessary and proportionate principles, and what this entails. We underscore what it means to have a human rights approach to state AI-based policies, including crucial redlines for not moving ahead with their deployment.

      We elaborate on what states must observe to ensure critical rights in line with Inter-American standards. We look particularly at political participation, access to information, equality and non-discrimination, due process, privacy and data protection, freedoms of expression, association and assembly, and the right to a dignified life in connection to social, economic, and cultural rights.

      Some of them embody principles that must cut across the different stages of AI-based policies or initiatives—from scoping the problem state bodies seek to address and assessing whether algorithmic systems can reliably and effectively contribute to achieving its goals, to continuously monitoring and evaluating their implementation.

      These cross-cutting principles integrate the comprehensive operational framework we provide in the report for governments and civil society advocates in the region.

      Transparency, Due Process, and Data Privacy Are Vital

      Our report’s recommendations reinforce that states must ensure transparency at every stage of AI deployment. Governments must provide clear information about how these systems function, including the categories of data processed, performance metrics, and details of the decision-making flow, including human and machine interaction.

      It is also essential to disclose important aspects of how they were designed, such as details on the model’s training and testing datasets. Moreover, decisions based on AI/ADM systems must have a clear, reasoned, and coherent justification. Without such transparency, people cannot effectively understand or challenge the decisions being made about them, and the risk of unchecked rights violations increases.

      Leveraging due process guarantees is also covered. The report highlights that decisions made by AI systems often lack the transparency needed for individuals to challenge them. The lack of human oversight in these processes can lead to arbitrary or unjust outcomes. Ensuring that affected individuals have the right to challenge AI-driven decisions through accessible legal mechanisms and meaningful human review is a critical step in aligning AI use with human rights standards.

      Transparency and due process relate to ensuring people can fully enjoy the rights that unfold from informational self-determination, including the right to know what data about them are contained in state records, where the data came from, and how it’s being processed.

      The Inter-American Court recently recognized informational self-determination as an autonomous right protected by the American Convention. It grants individuals the power to decide when and to what extent aspects of their private life can be revealed, including their personal information. It is intrinsically connected to the free development of one’s personality, and any limitations must be legally established, and necessary and proportionate to achieve a legitimate goal.

      Ensuring Meaningful Public Participation

      Social participation is another cornerstone of the report’s recommendations. We emphasize that marginalized groups, who are most likely to be negatively affected by AI and ADM systems, must have a voice in how these systems are developed and used. Participatory mechanisms must not be mere box-checking exercises and are vital for ensuring that algorithmic-based initiatives do not reinforce discrimination or violate rights. Human Rights Impact Assessments and independent auditing are important vectors for meaningful participation and should be used during all stages of planning and deployment. 

      Robust legal safeguards, appropriate institutional structures, and effective oversight, often neglected, are underlying conditions for any legitimate government use of AI for rights-based determinations. As AI continues to play an increasingly significant role in public life, the findings and recommendations of this report are crucial. Our aim is to make a timely and compelling contribution for a human rights-centric approach to the use of AI/ADM in public decision-making.

      We’d like to thank the consultant Rafaela Cavalcanti de Alcântara for her work on this report, and Clarice Tavares, Jamila Venturini, Joan López Solano, Patricia Díaz Charquero, Priscilla Ruiz Guillén, Raquel Rachid, and Tomás Pomar for their insights and feedback to the report.

      The full report is here.

      🏆 Meilleures contributions LinuxFr.org : les primées de septembre 2024

      Par : Florent Zara
      17 octobre 2024 à 08:13

      Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles, ENI et D-Booker. Voici les gagnants du mois de septembre 2024 :

      Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

      Les livres 📚 sélectionnés

      Bandeau LinuxFr.org

      Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions Eyrolles, ENI et D-Booker.

      Logo éditions ENI Logo éditions Eyrolles Logo éditions B-BookeR
           

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      The X Corp. Shutdown in Brazil: What We Can Learn

      8 octobre 2024 à 12:39

      Update (10/8/2024): Brazil lifted a ban on the X Corp. social media platform today after the country's Supreme Court said the company had complied with all of its orders. Regulators have 24 hours to reinstate the platform, though it could take longer for it to come back online.

      The feud between X Corp. and Brazil’s Supreme Court continues to drag on: After a month-long standoff, X Corp. folded and complied with court orders to suspend several accounts, name a legal representative in Brazil, and pay 28.6 million reais ($5.24 million) in fines. That hasn’t cleared the matter up, though.

      The Court says X paid the wrong bank, which X denies. Justice Alexandre de Moraes has asked that the funds be redirected to the correct bank and for Brazil’s prosecutor general to weigh in on X’s requests to be reinstated in Brazil.

      So the drama continues, as does the collateral damage to millions of Brazilian users who rely on X Corp. to share information and expression. While we watch it unfold, it’s not too early to draw some important lessons for the future.

      Let’s break it down.

      How We Got Here

      The Players

      Unlike courts in many countries, the Brazilian Supreme Court has the power to conduct its own investigations in limited circumstances, and issue orders based on its findings. Justice Moraes has drawn on this power frequently in the past few years to target what he called “digital militias,” anti-democratic acts, and fake news. Many in Brazil believe that these investigations, combined with other police work, have helped rein in genuinely dangerous online activities and protect the survival of Brazil’s democratic processes, particularly in the aftermath of January 2023 riots.

      At the same time, Moraes’ actions have raised concerns about judicial overreach. For instance, his work is less than transparent. And the resulting content blocking orders more often than not demand suspension of entire accounts, rather than specific posts. Other leaked orders include broad requests for subscriber information of people who used a specific hashtag.

      X Corp.’s controversial CEO, Elon Musk has publicly criticized the blocking orders. And while he may be motivated by concern for online expression, it is difficult to untangle that motivation from his personal support for the far-right causes Moraes and others believe threaten democracy in Brazil.

      The Standoff

      In August, as part of an investigation into coordinated actions to spread disinformation and destabilize Brazilian democracy, Moraes ordered X Corp. to suspend accounts that were allegedly used to intimidate and expose law enforcement officers. Musk refused, directly contradicting his past statements that X Corp. “can’t go beyond the laws of a country”—a stance that supposedly justified complying with controversial orders to block accounts and posts in Turkey and India.

      After Moraes gave X Corp. 24 hours to fulfill the order or face fines and the arrest of one of its lawyers, Musk closed down the company’s operations in Brazil altogether. Moraes then ordered Brazilian ISPs to block the platform until Musk designated a legal representative. And people who used tools such as VPNs to circumvent the block can be fined 50,000 reais (approximately $ 9,000 USD) per day.

      These orders remain in place unless or until pending legal challenges succeed. Justice Moraes has also authorized Brazil’s Federal Police to monitor “extreme cases” of X Corp. use. It’s unclear what qualifies as an “extreme case,” or how far the police may take that monitoring authority. Flagged users must be notified that X Corp. has been blocked in Brazil; if they continue to use it via VPNs or other means, they are on the hook for substantial daily fines.

      A Bridge Too Far

      Moraes’ ISP blocking order, combined with the user fines, has been understandably controversial. International freedom of expression standards treat these kinds of orders as extreme measures, permissible only in exceptional circumstances where provided by law and in accordance with necessary and proportionate principles. Justice Moraes said the blocking was necessary given upcoming elections and the risk that X Corp. would ignore future orders and allow the spread of disinformation.

      But it has also meant that millions of Brazilians cannot access a platform that, for them, is a valuable source of information. Indeed, restrictions on accessing X Corp. ended up creating hurdles to understanding and countering electoral disinformation. The Brazilian Association of Newspapers has argued the restrictions adversely impact journalism. At the same time, online electoral disinformation holds steady on other platforms (while possibly at a slower pace).

      Moreover, now that X Corp. has bowed to his demands, Moraes’ concerns that the company cannot be trusted to comply with Brazilian law are harder to justify. In any event, there are far more balanced options now to deal with the remaining fines that don’t create collateral damage to millions of users.

      What Comes Next: Concerns and Open Questions

      There are several structural issues that have helped fuel the conflict and exacerbated its negative effects. First, the mechanisms for legal review of Moraes’ orders are unclear and/or ineffective. The Supreme Court has previously held that X Corp. itself cannot challenge suspension of user accounts, thwarting a legal avenue for platforms to defend their users’ speech—even where they may be the only entities that even know about the order before accounts are shut down.

      A Brazilian political party and the Federal Council of the Brazilian Bar Association filed legal challenges to the blocking order and user fines, respectively, but it is likely that courts will find these challenges procedurally improper as well.

      Back in 2016, a single Supreme Court Justice held back a wave of blocking orders targeting WhatsApp. Eight years later, a single Justice may have created a new precedent in the opposite direction—with little or no means to appeal it.

      Second, this case highlights what can happen when too much power is held by just a few people or institutions. On the one hand, in Brazil as elsewhere, a handful of wealthy corporations wield enormous power over online expression. Here, that problem is exacerbated by Elon Musk’s control of Starlink, an important satellite internet provider in Brazil.

      On the other hand, the Supreme Court also has tremendous power. Although the court’s actions may have played an important role in preserving Brazilian democracy in recent years, powers that are not properly subject to public oversight or meaningful challenge invite overreach.

      All of which speaks to a need for better transparency (in both the public and private sectors) and real checks and balances. Independent observers note that, despite challenges, Brazil has already improved its democratic processes. Strengthening this path includes preventing judicial overreach.

      As for social media platforms, the best way to stave off future threats to online expression may be to promote more alternatives, so no single powerful person, whether a judge, a billionaire, or even a president, can dramatically restrict online expression with the stroke of a pen.

       

       

       

       

      🪶 Les journaux LinuxFr.org les mieux notés de septembre 2024

      Par : Florent Zara
      11 octobre 2024 à 00:59

      LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

      Bannière LinuxFr.org

      Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de septembre passé.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      How to Stop Advertisers From Tracking Your Teen Across the Internet

      This post was written by EFF fellow Miranda McClellan.

      Teens between the ages of  13 and 17 are being tracked across the internet using identifiers known as Advertising IDs. When children turn 13, they age out of the data protections provided by the Children’s Online Privacy Protection Act (COPPA). Then, they become targets for data collection from data brokers that collect their information from social media apps, shopping history, location tracking services, and more. Data brokers then process and sell the data. Deleting Advertising IDs off your teen’s devices can increase their privacy and stop advertisers collecting their data.

      What is an Advertising ID?

      Advertising identifiers – Android's Advertising ID (AAID) and Identifier for Advertising (IDFA) on iOS – enable third-party advertising by providing device and activity tracking information to advertisers. The advertising ID is a string of letters and numbers that uniquely identifies your phone, tablet, or other smart device.

      How Teens Are Left Vulnerable

      In most countries, children must be over 13 years old to manage their own Google account without a supervisory parent account through Google Family Link. Children over 13 gain the right to manage their own account and app downloads without a supervisory parent account—and they also gain an Advertising ID.

      At 13, children transition abruptly between two extremes—from potential helicopter parental surveillance to surveillance advertising that connects their online activity and search history to marketers serving targeted ads.

      Thirteen is a historically significant age. In the United States, both Facebook and Instagram require users to be at least 13 years old to make an account, though many children pretend to be older. The Children’s Online Privacy Protection Act (COPPA), a federal law, requires companies to obtain “verifiable parental consent” before collecting personal information from children under 13 for commercial purposes.

      But this means that teens can lose valuable privacy protections even before becoming adults.

      How to Protect Children and Teens from Tracking

       Here are a few steps we recommend that protect children and teens from behavioral tracking and other privacy-invasive advertising techniques:

      • Delete advertising IDs for minors aged 13-17.
      • Require schools using Chromebooks, Android tablets, or iPads to educate students and parents about deleting advertising IDs off school devices and accounts to preserve student privacy.
      • Advocate for extended privacy protections for everyone.

      How to Delete Advertising IDs

       Advertising IDs track devices and activity from connected accounts. Both Android and iOS users can reset or delete their advertising IDs from the device. Removing the advertising ID removes a key component advertisers use to identify audiences for targeted ad delivery. While users will still see ads after resetting or deleting their advertising ID, the ads will be severed from previous online behaviors and provide less personally targeted ads.

      Follow these instructions, updated from a previous EFF blog post:

      On Android

      With the release of Android 12, Google began allowing users to delete their ad ID permanently. On devices that have this feature enabled, you can open the Settings app and navigate to Security & Privacy > Privacy > Ads. Tap “Delete advertising ID,” then tap it again on the next page to confirm. This will prevent any app on your phone from accessing it in the future.

      The Android opt out should be available to most users on Android 12, but may not be available on older versions. If you don't see an option to "delete" your ad ID, you can use the older version of Android's privacy controls to reset it and ask apps not to track you.

      On iOS

      Apple requires apps to ask permission before they can access your IDFA. When you install a new app, it may ask you for permission to track you.

      Select “Ask App Not to Track” to deny it IDFA access.

      To see which apps you have previously granted access to, go to Settings Privacy & Security > Tracking.

      In this menu, you can disable tracking for individual apps that have previously received permission. Only apps that have permission to track you will be able to access your IDFA.

      You can set the “Allow apps to Request to Track” switch to the “off” position (the slider is to the left and the background is gray). This will prevent apps from asking to track in the future. If you have granted apps permission to track you in the past, this will prompt you to ask those apps to stop tracking as well. You also have the option to grant or revoke tracking access on a per-app basis.

      Apple has its own targeted advertising system, separate from the third-party tracking it enables with IDFA. To disable it, navigate to Settings > Privacy > Apple Advertising and set the “Personalized Ads” switch to the “off” position to disable Apple’s ad targeting.

      Miranda McClellan served as a summer fellow at EFF on the Public Interest Technology team. Miranda has a B.S. and M.Eng. in Computer Science from MIT. Before joining EFF, Miranda completed a Fulbright research fellowship in Spain to apply machine learning to 5G networks, worked as a data scientist at Microsoft where she built machine learning models to detect malware, and was a fellow at the Internet Society. In her free time, Miranda enjoys running, hiking, and crochet.

      At EFF, Miranda conducted research focused on understanding the data broker ecosystem and enhancing children’s privacy. She received funding from the National Science Policy Network.

      PyConFR 2024, planning et inscriptions

      19 septembre 2024 à 12:03

      La PyConFR 2024 a lieu du jeudi 31 octobre au dimanche 3 novembre à l’UFR Mathématique et d’Informatique de Strasbourg. Le planning est disponible et les inscriptions sont ouvertes !

      Comme toujours, la PyConFR est un évènement gratuit et l’inscription est obligatoire.

      Les deux premiers jours de la conférence seront occupés par les sprints. Et les deux jours suivants seront dédiés aux conférences (longues et courtes) et ateliers.

      Trois keynotes sont également au programme :

      • De villageoise à l’itWoman… Quelles actions pour faire de mon rêve TECH une réalité ?, par Houleymatou Baldé
      • Recherche des bonnes pratiques de packaging, par Françoise Conil
      • Reality is not an end-to-end prediction problem: Applied NLP in the age of Generative AI, par Ines Montani

      Cette année, un espace enfants (de 3 ans à 12 ans) est mis à disposition gratuitement sur inscription. Vous pouvez inscrire vos enfants jusqu’au 15 octobre.

      Durant cette édition, c’est aussi le retour du déjeuner PyLadies. Un des objectifs est de tisser des liens entre la communauté PyLadies et le reste de la communauté Python francophone.
      Les inscriptions au déjeuner PyLadies sont ouvertes jusqu’au 27 octobre.

      Le dimanche matin, l'AFP y tiendra son assemblée générale. Si vous souhaitez y voter, assurez vous d'être à jour de cotisation.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      FTC Report Confirms: Commercial Surveillance is Out of Control

      Par : Lena Cohen
      26 septembre 2024 à 10:55

      A new Federal Trade Commission (FTC) report confirms what EFF has been warning about for years: tech giants are widely harvesting and sharing your personal information to fuel their online behavioral advertising businesses. This four-year investigation into the data practices of nine social media and video platforms, including Facebook, YouTube, and X (formerly Twitter), demonstrates how commercial surveillance leaves consumers with little control over their privacy. While not every investigated company committed the same privacy violations, the conclusion is clear: companies prioritized profits over privacy. 

      While EFF has long warned about these practices, the FTC’s investigation offers detailed evidence of how widespread and invasive commercial surveillance has become. Here are key takeaways from the report:

      Companies Collected Personal Data Well Beyond Consumer Expectations

      The FTC report confirms that companies collect data in ways that far exceed user expectations. They’re not just tracking activity on their platforms, but also monitoring activity on other websites and apps, gathering data on non-users, and buying personal information from third-party data brokers. Some companies could not, or would not, disclose exactly where their user data came from. 

      The FTC found companies gathering detailed personal information, such as the websites you visit, your location data, your demographic information, and your interests, including sensitive interests like “divorce support” and “beer and spirits.” Some companies could only report high-level descriptions of the user attributes they tracked, while others produced spreadsheets with thousands of attributes. 

      There’s Unfettered Data Sharing With Third Parties

      Once companies collect your personal information, they don’t always keep it to themselves. Most companies reported sharing your personal information with third parties. Some companies shared so widely that they claimed it was impossible to provide a list of all third-party entities they had shared personal information with. For the companies that could identify recipients, the lists included law enforcement and other companies, both inside and outside the United States. 

      Alarmingly, most companies had no vetting process for third parties before sharing your data, and none conducted ongoing checks to ensure compliance with data use restrictions. For example, when companies say they’re just sharing your personal information for something that seems unintrusive, like analytics, there's no guarantee your data is only used for the stated purpose. The lack of safeguards around data sharing exposes consumers to significant privacy risks.

      Consumers Are Left in the Dark

      The FTC report reveals a disturbing lack of transparency surrounding how personal data is collected, shared, and used by these companies. If companies can’t tell the FTC who they share data with, how can you expect them to be honest with you?

      Data tracking and sharing happens behind the scenes, leaving users largely unaware of how much privacy they’re giving up on different platforms. These companies don't just collect data from their own platforms—they gather information about non-users and from users' activity across the web. This makes it nearly impossible for individuals to avoid having their personal data swept up into these vast digital surveillance networks. Even when companies offer privacy controls, the controls are often opaque or ineffective. The FTC also found that some companies were not actually deleting user data in response to deletion requests.

      The scale and secrecy of commercial surveillance described by the FTC demonstrates why the burden of protecting privacy can’t fall solely on individual consumers.

      Surveillance Advertising Business Models Are the Root Cause

      The FTC report underscores a fundamental issue: these privacy violations are not just occasional missteps—they’re inherent to the business model of online behavioral advertising. Companies collect vast amounts of data to create detailed user profiles, primarily for targeted advertising. The profits generated from targeting ads based on personal information drive companies to develop increasingly invasive methods of data collection. The FTC found that the business models of most of the companies incentivized privacy violations.

      FTC Report Underscores Urgent Need for Legislative Action

      Without federal privacy legislation, companies have been able to collect and share billions of users’ personal data with few safeguards. The FTC report confirms that self-regulation has failed: companies’ internal data privacy policies are inconsistent and inadequate, allowing them to prioritize profits over privacy. In the FTC’s own words, “The report leaves no doubt that without significant action, the commercial surveillance ecosystem will only get worse.”

      To address this, the EFF advocates for federal privacy legislation. It should have many components, but these are key:

      1. Data minimization and user rights: Companies should be prohibited from processing a person’s data beyond what’s necessary to provide them what they asked for. Users should have the right to access their data, port it, correct it, and delete it.
      2. Ban on Online Behavioral Advertising: We should tackle the root cause of commercial surveillance by banning behavioral advertising. Otherwise, businesses will always find ways to skirt around privacy laws to keep profiting from intrusive data collection.
      3. Strong Enforcement with Private Right of Action: To give privacy legislation bite, people should have a private right of action to sue companies that violate their privacy. Otherwise, we’ll continue to see widespread violation of privacy laws due to limited government enforcement resources. 

      Using online services shouldn't mean surrendering your personal information to countless companies to use as they see fit.  When you sign up for an account on a website, you shouldn’t need to worry about random third-parties getting your information or every click being monitored to serve you ads. For now, our Privacy Badger extension can help you block some of the tracking technologies detailed in the FTC report. But the scale of commercial surveillance revealed in this investigation requires significant legislative action. Congress must act now and protect our data from corporate exploitation with a strong federal privacy law.

      Canada’s Leaders Must Reject Overbroad Age Verification Bill

      19 septembre 2024 à 13:14

      Canadian lawmakers are considering a bill, S-210, that’s meant to benefit children, but would sacrifice the security, privacy, and free speech of all internet users.

      First introduced in 2023, S-210 seeks to prevent young people from encountering sexually explicit material by requiring all commercial internet services that “make available” explicit content to adopt age verification services. Typically, these services will require people to show government-issued ID to get on the internet. According to bill authors, this is needed to prevent harms like the “development of pornography addiction” and “the reinforcement of gender stereotypes and the development of attitudes favorable to harassment and violence…particularly against women.”

      The motivation is laudable, but requiring people of all ages to show ID to get online won’t help women or young people. If S-210 isn't stopped before it reaches the third reading and final vote in the House of Commons, Canadians will be forced to a repressive and unworkable age verification regulation. 

      Flawed Definitions Would Encompass Nearly the Entire Internet 

      The bill’s scope is vast. S-210 creates legal risk not just for those who sell or intentionally distribute sexually explicit materials, but also for those who just transmit it–knowingly or not.

      Internet infrastructure intermediaries, which often do not know the type of content they are transmitting, would also be liable, as would all services from social media sites to search engines and messaging platforms. Each would be required to prevent access by any user whose age is not verified, unless they can claim the material is for a “legitimate purpose related to science, medicine, education or the arts,” or by implementing age verification. 

      Basic internet infrastructure shouldn’t be regulating content at all, but S-210 doesn’t make the distinction. When these large services learn they are hosting or transmitting sexually explicit content, most will simply ban or remove it outright, using both automated tools and hasty human decision-making. History shows that over-censorship is inevitable. When platforms seek to ban sexual content, over-censorship is very common.

      Rules banning sexual content usually hurt marginalized communities and groups that serve them the most. That includes organizations that provide support and services to victims of trafficking and child abuse, sex workers, and groups and individuals promoting sexual freedom.

      Promoting Dangerous Age Verification Methods 

      S-210 notes that “online age-verification technology is increasingly sophisticated and can now effectively ascertain the age of users without breaching their privacy rights.”

      This premise is just wrong. There is currently no technology that can verify users’ ages while protecting their privacy. The bill does not specify what technology must be used, leaving it for subsequent regulation. But the age verification systems that exist are very problematic. It is far too likely that any such regulation would embrace tools that retain sensitive user data for potential sale or harms like hacks and lack guardrails preventing companies from doing whatever they like with this data once collected.

      We’ve said it before: age verification systems are surveillance systems. Users have no way to be certain that the data they’re handing over is not going to be retained and used in unexpected ways, or even shared to unknown third parties. The bill asks companies to maintain user privacy and destroy any personal data collected but doesn’t back up that suggestion with comprehensive penalties. That’s not good enough.

      Companies responsible for storing or processing sensitive documents like drivers’ licenses can encounter data breaches, potentially exposing not only personal data about users, but also information about the sites that they visit.

      Finally, age-verification systems that depend on government-issued identification exclude altogether Canadians who do not have that kind of ID.

      Fundamentally, S-210 leads to the end of anonymous access to the web. Instead, Canadian internet access would become a series of checkpoints that many people simply would not pass, either by choice or because the rules are too onerous.

      Dangers for Everyone, But This Can Be Stopped

      Canada’s S-210 is part of a wave of proposals worldwide seeking to gate access to sexual content online. Many of the proposals have similar flaws. Canada’s S-210 is up there with the worst. Both Australia and France have paused the rollout of age verification systems, because both countries found that these systems could not sufficiently protect individuals’ data or address the issues of online harms alone. Canada should take note of these concerns.

      It's not too late for Canadian lawmakers to drop S-210. It’s what has to be done to protect the future of a free Canadian internet. At the very least, the bill’s broad scope must be significantly narrowed to protect user rights.

      ❌
      ❌