
Selon l’Alphabet, certains fournisseurs de services en ligne disposent de technologies intégrées susceptibles de compromettre les fonctionnalités essentielles de la publicité numérique tierce. Il explique clairement dans le document que la plupart des revenus de Google proviennent des frais qui ont été versés pour l'affichage d'annonces en ligne. Par conséquent, ces technologies et outils pourraient avoir une incidence défavorable sur ses résultats. On comprend aisément donc que Google ne fera pas marche arrière dans sa décision et que l’entreprise reste ferme sur les modifications apportées au blocage de publicités dans le navigateur Chrome. Comme alternative, Google a annoncé qu’il fournira en lieu et de l’API webRequest, l’API declarativeNetRequest.
Néanmoins, retenons que la firme laisse une marge de manœuvre aux entreprises. Google dit essentiellement que Chrome aura toujours la capacité de bloquer le contenu indésirable, mais que cela sera limité aux seuls utilisateurs professionnels de Chrome qui sont payés. Cela permettra probablement aux entreprises de développer des extensions Chrome internes, mais pas pour bloquer les publicités. Mais la décision frustre plus d’un et particulièrement ceux qui conçoivent ces bloqueurs. Raymond Hill, principal développeur de uBlock Origin, par exemple, condamne cette décision de la firme de Mountain View.
D’après ce dernier, le passage à l’API declarativeNetRequest signifierait probablement la mort de ces extensions utilisées à minima par 10 millions d’internautes. « Si cette API déclarativeNetRequest (assez limitée) finit par être le seul moyen pour les bloqueurs de contenu d'accomplir leur tâche, cela signifie essentiellement que deux bloqueurs de contenu que j'ai maintenus pendant des années, uBlock Origin et uMatrix ne peuvent plus exister », avait-il commenté. Pour lui, Google veut éviter à tout prix que ses activités liées à la publicité soient perturbées et, ce, jusqu’au point de rendre les bloqueurs d’annonces inefficaces dans son navigateur Chrome.
Après les nombreuses déclarations de Google sur cette affaire, c’est au tour des développeurs de Google Chrome de monter au créneau. Chris Palmer, l’un des ingénieurs en sécurité des logiciels Google Chrome, s'est exprimé sur Twitter cette semaine pour affirmer que le déménagement vers la nouvelle API visait à améliorer l'expérience de navigation des utilisateurs finaux, bien que les utilisateurs professionnels rémunérés seraient exemptés des modifications. Il n’est pas le seul à être apparu pour soutenir la décision de Google d’interdire l'utilisation de l’API webRequest pour bloquer une demande particulière avant son chargement.
L’ingénieur en chef de la sécurité du navigateur Chrome, Justin Schuh, s’est également prononcé sur le sujet qui divise. Il a déclaré que les changements résultaient de préoccupations liées à la confidentialité et à la sécurité. « La seule motivation ici est de corriger les principales lacunes du système actuel en matière de confidentialité et de sécurité. Je sais, parce que je me suis fixé cet objectif et que l'équipe rend compte par moi », a-t-il déclaré sur son compte Twitter. Pour lui donc, les bloqueurs de publicités actuels possèdent des failles de sécurité qui sont liées à des vulnérabilités présentes dans l’API webRequest exploitée par ces derniers.
En parlant des extensions de Raymond Hill et en particulier de uBlock Origin, il a expliqué que « le gros problème de webRequest est la confidentialité et les failles de sécurité qui ne peuvent être résolues. Ils (les développeurs de uBlock Origin) ont ignoré cela uniquement pour argumenter la performance, mais ont ensuite ignoré le coût en performances de chaque extension webRequest empilant un processus de rendu complet, etc. ». Cependant ces différentes déclarations des ingénieurs de Google Chrome ne semblent pas convaincre les développeurs et encore moins Raymond Hill qui revient à la charge.
Il a déclaré que si l’amélioration de l’expérience utilisateur était le but principal de Google, les changements qu’il a apportés ne gêneraient pas les extensions existantes. « Les pages Web se chargent lentement à cause du volume excessif, pas à cause de la capacité de blocage de l’API webRequest, du moins pour les extensions bien conçues », a déclaré Hill. Il poursuit en disant que la motivation de Google n'avait ici que peu à voir avec l'expérience de l'utilisateur final et bien plus à protéger les revenus publicitaires de la popularité croissante des extensions adblock.
« Pour que Google Chrome puisse atteindre sa base d'utilisateurs actuelle, il devait prendre en charge les bloqueurs de contenu. Ce sont les extensions les plus populaires de tous les navigateurs », a-t-il déclaré. Selon ces dires, la stratégie de Google a consisté à trouver le point optimal entre les deux objectifs de développement de la base d'utilisateurs de Google Chrome et d'empêcher les bloqueurs de contenu de nuire à son activité publicitaire. Hill a affirmé que la capacité de blocage de l'API webRequest a amené Google à donner un certain contrôle sur le blocage aux développeurs tiers.
D’après lui, maintenant que la part de marché de Chrome est plus grande, la société est mieux placée pour déplacer le point optimal entre les deux objectifs, ce qui profite à l'activité principale de Google, les annonces. Il n’est pas le seul cependant. D’autres également ne sont pas du tout convaincus que Google dit vrai en affirmant qu’il recherche la sécurité et la confidentialité pour ses utilisateurs. Ils notent que les changements pourraient également nuire à l'efficacité de certaines extensions du contrôle parental, de la confidentialité et de la sécurité, ce qui n’illustre en rien le but poursuivi par Google dans le Manifest V3.
« C'est une très mauvaise décision de la part de Google », a déclaré Justin Brookman, directeur de la politique en matière de protection de la vie privée chez Consumer Reports. Il a attiré l’attention de la communauté sur le fait que des millions d'utilisateurs s'appuient sur des extensions telles que uBlock, Disconnect et Ghostery pour limiter le suivi et bloquer le code malveillant provenant de serveurs tiers et que le fait d'inciter ces extensions à utiliser une API différente avec des fonctionnalités moins importantes les affaiblirait.
« Il est difficile d'échapper à la suspicion selon laquelle cela est principalement motivé...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.