URL: https://linuxfr.org/users/f6k/journaux/alienbob-et-les-dedales-de-chromium-sous-slackware Title: AlienBob et les dédales de Chromium sous Slackware Authors: f6k Date: 2021年03月08日T19:38:03+01:00 License: CC By-SA Tags: debian, firefox, slackware, chromium et google Score: 51> **Remarque :** les développements traités dans ce fichier s'appuient sur l'article d'AlienBob [*How to 'un-google' your Chromium browser experience*][0] et en reprennent certains éléments. [0]: https://alien.slackbook.org/blog/how-to-un-google-your-chromium-browser-experience/ Un peu de contexte. Chromium est un logiciel libre développé depuis 2008 par le *Chromium project*, équipe dirigée et financée par Google. L'idée de l'entreprise était de proposer un navigateur simple, efficace et surtout permettant une intégration maîtrisée avec les produits que propose la société. S'attaquant aux mastodontes de l'époque, le choix de développement a été celui de l'ouverture via la [BSD-3-Clause License][1] et profiter ainsi d'une vaste communauté mondiale pouvant apporter son aide, tout en ouvrant la possibilité d'adoption du navigateur par des tierces parties. S'appuyant sur les possibilités offertes par la licence, Google peut ensuite utiliser les sources de Chromium, y ajouter différentes portions de codes fermés et propriétaires, et diffuser le tout sous forme binaire à l'utilisateur final : Google Chrome. [1]: https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22) Parmi les différences entre Google Chrome et Chromium, on peut retrouver les mises à jour automatiques, des modules vidéo et audio propriétaires, ou encore des mécanismes de suivi (optionnels ou non). Google Chrome intègre aussi la fameuse technologie controversée de DRM Widevine utilisée notamment par Amazon Prime Video, Netflix ou encore Spotify pour ces contenus en *premium*. Mais surtout Google Chrome permet un accès aux services de la société Google via des interfaces de programmation (API) accessibles par système de clefs. # Des accords entre Google et les développeurs Ce dernier point est important. En effet l'intégration de ces APIs par clefs uniquement accessibles via Google Chrome pouvait gêner les développeurs extérieur à Google de deux façons. La première est que ces développeurs, qui contribuaient librement et (souvent) gratuitement au code de Chromium, voulaient pouvoir non seulement compiler les sources mais, pour eux aussi et leurs utilisateurs, avoir accès aisément aux APIs proposées par Google depuis Chromium. Par ailleurs, en terme de promotion, le système d'accès par clefs aux APIs réservé à Google pouvait freiner le développement d'applications tierces ou embarquées pour ce navigateur. Prenons un exemple simple, juste pour comprendre. Je suis développeur indépendant et je souhaite créer un petit jeu pour Chrome. Je prévois que mon jeu puisse notamment sauvegarder les scores et les parties en cours en les synchronisant avec le compte Google du joueur. En tant que développeur, pour faire interagir mon programme avec le produit Google Sync (qui s'occupe justement des services de synchronisation de fichiers), il me faut nécessairement passer par l'API que propose ce service. Évidemment un service a un coût. Un utilisateur lambda de Google Chrome va payer le coût de ces services avec toutes ses données personnelles. Mais dans le cas de Chromium ou d'applications Google Chrome ou Chromium tierces, c'est moins évident. Partant de là Google a décidé de passer des accords avec certaines tierces parties pour les autoriser à avoir un accès aux APIs des différents services de la firme. C'était aussi, bien sûr, une jolie manière d'amplifier l'intérêt que pouvait susciter Google Chrome et Chromium auprès des entreprises et des développeurs du monde entier, mais aussi du grand public en proposant un environnement plus riche. Pour ce dernier cas, on peut penser par exemple à Rovio et son Angry Birds intégré par extension dans Chrome qui a aidé à faire une bonne publicité pour Chrome à une certaine époque, tout en ramenant des joueurs monétisables vers l'entreprise productrice du jeu. Google a donc commencé à proposer à certains développeurs des clefs personnelles donnant accès à ces APIs et qui sont intégrées au moment de la compilation des binaires. De sorte qu'à chaque fois qu'une personne utilise le programme, il utilise forcément la clef du développeur, et le compteur lié audit développeur incrémente de un. Et ce qu'il faut comprendre c'est que Google passait des accords avec ces développeurs pour un certain nombre d'accès *gratuit* à ces APIs. Autrement dit, au-delà d'un certain seuil, l'accès à l'API par ces clefs est coupé et le développeur doit passer à la caisse. Reprenons mon exemple. Mon jeu intègre des publicités qui me permettent de monétiser mon travail. En passant un accord avec Google pour avoir accès à leurs APIs je leur explique ma situation financière encore précaire. Après négociation, ils acceptent de me donner deux mille accès gratuits pour les trois premiers mois. Au deux mille et unième accès, Google coupe les autorisations de ma clef, mes joueurs ne peuvent plus accéder à leurs scores et à leurs parties enregistrées (autrement dit le jeu est tronqué) ; je dois passer à la caisse. Il s'agit ici d'un cas où l'accès aux APIs génère un revenu pour le développeur. On comprend donc que Google, à un moment donné, demande une partie des bénéfices du développeur pour l'utilisation de ses services (qui ont un coût pour l'entreprise, rappelons-le). # Des APIs et des logiciels libres et gratuits Mais qu'en est-il des développeurs utilisant les APIs de Google mais dont le travail ne génère absolument aucun revenu. Si vous êtes sous une distribution GNU/Linux, c'est un cas qui vous concerne. En effet, les packageurs créant des binaires de Chromium pour leur communauté, s'ils veulent que les utilisateurs aient accès à, mettons, Google Sync pour synchroniser leurs mots de passe et leurs signets, doivent demander à Google des clefs officielles aux APIs, clefs qui leur sont liées personnellement. Par exemple, individuellement, sous Slackware j'utilise principalement Mozilla Firefox. Cependant, il se trouve que, parfois, j'ai besoin d'utiliser Chromium. Ce programme n'est pas proposé par défaut sous Slackware, et il nous faut donc compter sur la communauté. Une personne bien connue pour nous est Eric '[AlienBob][2]' Hameleers qui propose justement depuis des années un paquet tout prêt pour Slackware. Et si l'on regarde attentivement [son dépôt pour Chromium][3], on voit parfaitement dans le script les appels aux différentes clefs pour les APIs Google de même que les clefs elles-mêmes. [2]: https://alien.slackbook.org/blog/ [3]: http://www.slackware.com/~alien/slackbuilds/chromium/build/ C'est ainsi que chaque fois que j'ouvre Chromium sur ma Slackware le programme contacte les serveurs de Google avec la clef d'AlienBob, incrémentant son compte d'accès de un, et m'autorisant, si je le veux, à utiliser les différents APIs de cette entreprise en toute transparence. C'est très pratique pour moi, et pour tant d'autres utilisateurs de Slackware et de ses dérivées. Mais, au bout d'un moment, forcément, le quota d'accès gratuit offert par Google à AlienBob est dépassé et il doit passer à la caisse. Il faut noter, chose importante, que ces seuils ont été significativement augmentés pour les packageurs de distributions GNU/Linux au fur et à mesure du temps, ce qui évitait de trop payer si le paquet devenait vraiment trop populaire. Mais il arrive toujours un moment où il faut passer à la caisse. Et, apparemment, la facture peut être particulièrement salée. Sauf qu'il y a plusieurs mois, différents cadres chez Google ont décidé que tout cela, et bien c'était terminé. # De la bascule à venir du 15 mars 2021 Dans un [article très récent][5], AlienBob est notamment revenu sur son ressenti eu égard au fait qu'il doive payer après un certain nombre d'accès via ses clefs. Ainsi qu'il le dit, pour Slackware cela ne le gène pas. Cela fait parti de l'effort qu'il souhaite apporter à la communauté. Et si donner à Slackware un Chromium lié aux APIs de Google permet de continuer à faire briller cette distribution auprès des utilisateurs actuels ainsi que de potentiels à venir, c'est un coût qu'il entend prendre en charge. Surtout que, rappelle-t-il, il reçoit des dons de la communauté pour le travail qu'il fourni, dons qu'il utilise pour payer une partie des infrastructures qu'il gère pour le bien de Slackware — y compris la facture à Google. [5]: https://alien.slackbook.org/blog/how-to-un-google-your-chromium-browser-experience/ L'une des questions qu'il soulève par contre est celle des dérivées de Slackware, dont certaines sont très utilisées. On pense notamment à une des versions de Puppy Linux, ou encore à Slint. Il se trouve que les packageurs de ces distributions reprennent les excellents *builds* d'AlienBob, y compris Chromium. Et, dès lors, utilisant ses clefs, ces utilisateurs d'autres distributions incrémentent de façon non négligeable son compteur d'accès aux APIs. On sent bien ici la guerre de chapelles entre les packageurs de différentes communautés et je renvoie simplement au début de l'article d'AlienBob ainsi qu'aux commentaires (où interviennent justement lesdits packageurs) pour se faire une idée plus précise de la situation présente. Seulement cette situation, si elle était prise dans une sorte de *status quo* ces dernières années, va grandement changer dès le 15 mars prochain. En effet à partir de cette date [Google a décidé de bloquer les accès à une grande partie des APIs de toutes les versions de Chromium qui ne sont pas issues de Google][6]. Et cela dépasse en réalité le cadre du simple navigateur de bureau car vont être impactés aussi tout ce qui regarde l'embarqué et ChromiumOS. Une grande partie donc mais pas tout. Restera accessible notamment le fameux *safe browsing*, service qui identifie des sites frauduleux ou dangereux et en informe l'utilisateur. Dans les choses à noter par contre, sera bloqué l'accès à Google Sync — il ne sera donc plus possible de synchroniser via Chromium ses mots de passe, signets, etc., par ce service. Enfin, et surtout, les possibilités d'accès gratuits vont être tout bonnement supprimées. Car en effet, et comme dit, certains services restant accessibles, l'une des clefs reste valide pour ces cas là. Mais le développeur qui proposera un tel accès sera facturé dès la première connexion. [6]: https://groups.google.com/a/chromium.org/g/chromium-packagers/c/SG6jnsP4pWM C'est là je crois le premier nœud de l'article d'AlienBob qui, s'il accepte de prendre en charge les connexions des utilisateurs de la communauté pour laquelle il se dévoue, refuse catégoriquement de payer pour des utilisateurs auxquels il n'est lié en aucune manière, et qui n'ont, par ailleurs, même aucune conscience que quelqu'un d'une autre distribution va payer pour eux. En parallèle, il faut aussi noter une chose importante qui est que la discussion dépasse en réalité les différentes distributions libres et ouvertes qui proposent une version Chromium non tronquée des services de Google. En effet, depuis quelques années énormément de constructeurs utilisent des systèmes embarqués basés sur Chromium, systèmes qui ne sont donc pas officiellement issus de Google et qui vont être coupés d'une grande partie des services de Google. On pense notamment aux télévisions connectées. S'il est clair que de très grands groupes ont probablement déjà négocié des accès privilégiés, d'autres sociétés vont se retrouver avec des clients mécontents qui ne comprendront pas d'où vient le problème. On peut d'ailleurs lire [l'une des discussions sur ce sujet ici][7] pour se rendre compte de la catastrophe pour ces entreprises. [7]: https://groups.google.com/a/chromium.org/g/embedder-dev/c/STyM5ZNTHMM # De l'avenir de Chromium sous Slackware C'est la deuxième grande question abordée par AlienBob. Car même en acceptant de payer pour les quelques services qui resteront, il prend acte de la situation perdante pour l'utilisateur de Chromium, pour la communauté Slackware en général et pour lui-même. En effet, une bonne hygiène numérique implique d'avoir installé des extensions tierces qui remplissent le rôle de *safe browsing*. En somme AlienBob se retrouve dans une situation où nous devrions payer alors que l'un des services phares, à savoir celui de la synchronisation, n'est plus accessible. Il faut dire que l'usage de la synchronisation de mots de passe, des signets et autres, entre différents terminaux s'est largement répandue ces dernières années et, puisque l'accès à Google Sync ne sera bientôt plus possible, son parti pris est de se débarrasser complètement des liens avec Google et de se focaliser sur un navigateur Chromium respectueux de la vie privée de ses utilisateurs. Et pour ceux qui ne peuvent se passer des services Google, il reste toujours la possibilité d'installer les binaires de Chrome proposées par Google. AlienBob a ainsi entamé un travail vers la production d'un paquet Chromium *dégooglisé*, complètement coupé de tous les liens avec les services proposés par Google — ce qui donne le paquet [*chromium-ungoogled*][8]. Pour arriver à cela il utilise différents patchs et scripts issus notamment de projets comme [ungoogled-chromium][9], d'[inox patchset][10] ou de la version Debian de Chromium. À terme, note-il, ce paquet viendra définitivement remplacer le paquet Chromium qu'il a produit jusque-là avec ses clefs. [8]: http://www.slackware.com/~alien/slackbuilds/chromium-ungoogled/ [9]: https://github.com/Eloston/ungoogled-chromium [10]: https://github.com/gcarq/inox-patchset Évidemment, au niveau de l'utilisateur final, cela demande quelques adaptations. Puisque cette version n'offre plus le *safe browsing*, il faut donc en passer par des extensions comme uBlock Origin ou uMatrix que l'on installera soit manuellement ou soit via le *Chromium Web Store* [après avoir installé celui-ci manuellement][11]. De la même manière, il faudra troquer Google Sync pour [KeePassXC][12] et [xBrowserSync][13]. [11]: https://github.com/NeverDecaf/chromium-web-store/blob/master/README.md [12]: https://keepassxc.org/ [13]: https://www.xbrowsersync.org/ En dernier point, voici la procédure à suivre pour installer manuellement des extensions sous Chromium. Il suffit de se rendre sur `chrome://extensions/` et d'activer en haut à droite le mode développeur. On récupère ensuite une extension (disons [uBlock Origin][14], en cliquant en l'occurrence sur `Ajouter à Chromium`). Si l'extension *Chromium Web Store* n'est pas installée, cela va se matérialiser par le téléchargement d'un fichier `.crx`. Après avoir décompressé le contenu de ce fichier dans un dossier, il suffira depuis l'onglet extensions de Chromium de cliquer sur `Load unpacked` puis d'indiquer le chemin vers le dossier. Sans la présence du *Store*, les mises à jour devront être faîtes manuellement en suivant la même procédure (idéalement après avoir supprimé de Chromium l'ancienne version). [14]: https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm Notez aussi que l'option d'effacement des cookies et des données des sites lorsque l'on quitte Chromium est activée par défaut (voir `chrome://settings/cookies`). Il faudra la désactiver si l'on souhaite garder les informations de connexion aux sites d'une session à l'autre à moins d'utiliser des choses comme KeePassXC.

AltStyle によって変換されたページ (->オリジナル) /