C’est la procédure : les développeurs soumettent de nouvelles versions d’extensions dans le Chrome Web Store. Google effectue des analyses automatisées de ces dernières et peut également procéder à un examen manuel des contenus soumis avant de les autoriser ou de les rejeter. Chez uBlock Origin, le passage à une nouvelle version est en préparation. Le développeur (Raymond Hill) a donc, au début de ce mois, soumis une nouvelle build (à l’intention des développeurs) au processus de revue de la firme de Mountain View. Le retour de Google en image : Dans son courriel adressé à l’auteur, Google justifie le rejet par l’intégration au sein de l’extension de « fonctionnalités non liées. »
« Cher développeur, nous confrontons de façon régulière la conformité des éléments de la boutique en ligne Chrome avec nos politiques afin d'assurer une expérience sûre et fiable pour nos utilisateurs. Votre extension, "uBlock Origin development build" avec ID : cgbcahbpdhpcegmbfconppldiemgcoii n'a pas respecté nos règles et a été supprimée de la boutique en ligne Google Chrome. Elle n'était pas conforme à la section suivante de notre politique : une extension doit avoir un but unique et clair pour les utilisateurs. Ne créez pas d'extension qui oblige les utilisateurs à accepter des paquets de fonctionnalités non liées telles qu'un générateur de notification par courrier électronique et un agrégateur de titres de nouvelles. Si deux éléments de fonctionnalité sont clairement séparés, ils doivent être placés dans deux extensions différentes et les utilisateurs doivent avoir la possibilité de les installer et de les désinstaller de façon séparée », indique la firme de Mountain View.
Sur le conseil d’utilisateurs de l’extension, Raymond Hill a procédé à une nouvelle tentative et la réponse de Google pour la 1.22.5rc2 a été la même : rejet pour les mêmes motifs. Y faisant suite, le développeur de l’extension n’a pas manqué d’exprimer un avis fortement teinté de déception.
« Puisque la prochaine version d'uBlock sera essentiellement ce qu'est la 1.22.5rc2, considérez que c'est la fin de l'extension sur le Chrome Web Store. Il n'y a aucune bonne raison de croire que uBlock 1.22.5rc2 ne fera plus l'objet de rejet en opérant seulement un changement du numéro de version vers 1.23.0. Pensez à migrer vers un navigateur qui prend uBlock Origin en charge », a-t-il lancé.
Un processus de revue à problèmes sur le Chrome Web Store
Les débats autour de ces développements portent sur ce que d’aucuns qualifient de « processus de revue à problèmes » chez Google. D’après les retours des utilisateurs de l’extension, ce n’est pas la première fois qu’une telle situation se produit. Certains rapportent que Raymond Hill a déjà vu une build recalée pour une question de nommage de fichiers. D’après ce que rapporte un des intervenants du processus de revue chez Google, la version 1.22.5rc2 de l’extension soumise à l’examen a finalement été autorisée et c’est même là que des interrogations naissent. En effet, Raymond Hill a signifié son désaccord avec le message que le système automatisé mis en place par Google laisse filtrer : le rejet découlait de l’intégration de « fonctionnalités non liées. » Il vient donc que les utilisateurs restent dubitatifs sur les éléments qui ont conduit au rejet initial des dernières builds de l’extension. Google ne dit rien quant à savoir s’il s’agit d’un bogue de son script d’évaluation automatisé ou d’une erreur humaine. Certains évoquent même l’éventualité d’une intervention humaine comme moyen subtil pour Google de tenter de tacler l’extension.
uBlock Origin : une extension qui est bel et bien en danger
L’API que le navigateur Chrome fournit aux navigateurs est rendue à sa version 2. Depuis la fin d’année dernière, Google parle des changements à venir au sein d’une mise à jour de l’API dénommée manifest v3. Grosso modo, l’annonce génère des débats autour des API web Request et declarativeNetRequest. Alors qu'au début, il n'y avait que peu de discussions sur les modifications à venir au sein du Manifest V3, en janvier, les mainteneurs de plusieurs bloqueurs de pubs ont soulevé un problème avec la mise en touche de l'API web Request au profit de l’API declarativeNetRequest. La crainte mise en avant par les développeurs : la nouvelle API risque d’empêcher leurs extensions d’inspecter les pages web avec la même efficacité. Dans une publication parue à mi-parcours de l’année en cours, Google est revenu de façon imagée sur les différences entre les deux approches.
L'API web Request originale interrompt le chargement d'une page pendant la scrutation de son contenu pour rechercher des annonces ou d'autres contenus susceptibles de faire l'objet de blocage ou de modification par l'extension. Dans sa dernière sortie, la firme de Mountain View souligne que cette ancienne API était une source d’abus. Dans les chiffres publiés par Google, 42 % des extensions malveillantes détectées depuis le mois de janvier de l’année dernière se sont appuyées sur l’API web Request. « Avec web Request, Chrome envoie toutes les données d'une requête réseau à l'extension d'écoute - y compris toutes les données sensibles contenues dans cette requête, comme les photos personnelles ou les e-mails », précise Google à propos du risque en matière de vie privée. « Comme toutes les données d'une requête sont exposées à l'extension, il est très facile pour un développeur malveillant d'en abuser pour avoir accès aux informations d'identification, aux comptes ou aux informations personnelles d'un utilisateur », ajoute l’entreprise.
L’API declarativeNetRequest fonctionne sur une approche différente. Au lieu que l'extension basée sur cette dernière arrête les requêtes web et inspecte la totalité du contenu, cette dernière établit des règles que le navigateur lit et applique à chaque page web avant son chargement. Avec cette nouvelle API, les extensions ne reçoivent jamais les données d'une page et le navigateur n'apporte toutes les modifications à une page que lorsqu'une ou plusieurs règles déclarées sont respectées. De cette façon, toutes les données sensibles qui peuvent être incluses dans une page (e-mails, photos, mots de passe, etc.) restent au niveau du navigateur et ne sont jamais transmises aux extensions. D'après Google, la nouvelle API est meilleure en termes de confidentialité, mais aussi de vitesse, car le code hautement optimisé de Chrome gère tout le filtrage des requêtes web au lieu de laisser cette opération au code JavaScript d'une extension.
D’après Hill, l’incompatibilité de son extension avec l’API que Google entend proposer découle de ceci que cette dernière ne permet de s’appuyer que sur un unique moteur de filtrage ; à contrario, uBlock Origin s’appuie sur plusieurs pour faire le travail. En fait, l’un des problèmes de fond est que le draft initial limite le nombre de filtres à 30 000. À ce propos, le développeur précise qu’uBlock s’appuie (entre autres) sur Easylist, la très populaire liste de blocage avec ses 42 000 filtres – ce que Hill estime même insuffisant pour les besoins de blocage d’un internaute moderne. Google est revenu sur ce détail et a annoncé le passage de la limite de filtres de 30 000 à 150 000. Les travaux sur le manifest v3 se poursuivent et on continue d’attendre quel sera l’impact sur les bloqueurs de publicités.
Source : GitHub
Et vous ?
Qu’en pensez-vous ? Google fait-il express de mettre à mal les extensions de blocage de publicités ? Est-ce simplement un incident à mettre en compte sur le dos du système automatisé de revue ?Voir aussi :
Navigateur Chromium : Google propose des changements qui pourraient désactiver uBlock Origin, l'extension dédiée au blocage de publicités Navigateur Chromium : des changements annoncés dans l'API pourrait désactiver une panoplie d'autres extensions et pas seulement uBlock Origin Extensions Chrome : Google pourrait renoncer aux modifications annoncées, une analyse révèle que des extensions sont conformes au Manifest V3 Non, Chrome ne va pas tuer les bloqueurs de pub, mais les rendre plus sûrs annonce Google en désaccord avec Opera, Brave et Vivaldi 
Envoyé par matthius
