Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

40PARTAGES

12  0 
Annonce Google en désaccord avec Opera, Brave et Vivaldi

Déjà 9 mois que Google a annoncé des changements majeurs au sein du Manifest – un document au sein duquel l’entreprise donne des détails sur les capacités des extensions pour son navigateur. Une version 3 est en cours de gestation et les débats à son propos sont plutôt houleux. Après avoir été repris à maintes reprises par des utilisateurs en colère, les ingénieurs de Google viennent de promettre que les futurs changements au système d'extensions de Chrome ne paralyseront pas les bloqueurs de publicité comme tout le monde le craint.

L’entreprise affirme que les changements via la nouvelle API amélioreront la vie privée des utilisateurs et apporteront des améliorations en termes de vitesse. En outre, Google a promis d’augmenter la limite maximale du nombre de filtres, ce, pour mettre fin à la principale critique émise par les développeurs de bloqueurs de pubs au cours des derniers mois.

Débats autour des API web Request et declarativeNetRequest

Google est sous les regards à propos de ces changements depuis le mois d’octobre de l’année dernière. En pleine bataille contre la montée en puissance des extensions malicieuses sur sa plateforme, la firme de Mountain View a annoncé l’entrée en vigueur de nouvelles règles dans le processus de revue des extensions, mais aussi des changements à la base de code de prise en charge des extensions. L’ensemble des modifications à venir ont fait l’objet de publication au sein du brouillon de la troisième version du Manifest l’an dernier.

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 récente publication, Google revient de façon imagée sur les différence 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.


Le plus gros grief porté à l’encontre de Google

Seulement, au mois de janvier de l'année en cours, les développeurs de bloqueurs de pubs ont fait valoir qu'en dépit des avantages mis en avant via la nouvelle API, Google prévoyait de limiter les filtres à 30 000 – un nombre jugé bien insuffisant par les mainteneurs de pubs. En janvier, Raymond Hill que les extensions uBlock Origin et uMatrix dont il est l’auteur s’appuient (entre autres) sur la populaire liste de blocage Easylist avec 42 000 filtres. Google est revenu sur ce détail et annonce le passage de la limite de filtres de 30 000 à 150 000.

Les positions d’Opera, Brave et Vivaldi

De façon globale, les responsables de cette suite de navigateur basés sur Chromium ont fait des annonces pour signifier qu’ils ne s’aligneront pas à des changements susceptibles de défavoriser les utilisateurs. En plus des bloqueurs de pubs que leurs navigateurs respectifs intègrent, la tendance chez Opera et Brave est de poursuivre avec la prise en charge de l’ancienne API web Request, ce qui permettra à des extensions comme uBlock et uMatrix de continuer à tourner sans problème. Chez Vivaldi, la façon dont le changement d’API sera abordé dépendra des décisions finales de Google. D’après Pieter Nielsen – développeur chez Vivaldi – plusieurs scénarios sont envisageables après l’introduction du changement dans Chromium par l’équipe Google. Ici, on n’exclut pas un maintien sur les bases de l’API web Request si les intérêts des utilisateurs devaient prendre un coup. En effet, d’après de récents développements, seuls les utilisateurs de Chrome pour les entreprises sont pressentis pour une version du navigateur sans publicités, ce qui semble confirmer la thèse selon laquelle l’approche avec la nouvelle API vise à renforcer le business de la firme de Mountain View autour de la pub.

Source : blog Chromium

Et vous ?

Qu’en pensez-vous ?
Quel commentaire faites-vous de l’approche avec l’API declarativeNetRequest ?
Les débats autour de Chrome peuvent-il permettre à Firefox d'émerger encore plus ?
Peut-on faire confiance à Google ?

Voir aussi :

La part de marché de Firefox augmente pour la deuxième fois consécutive en 2 mois. Le navigateur libre pourrait-il survivre auprès de Chrome ?
C'est officiel, Microsoft Edge sera désormais basé sur Chromium et enfin disponible sur Windows 7, Windows 8 et d'autres plateformes comme macOS
Mozilla n'est pas du tout content de l'adoption de Chromium par Microsoft, les navigateurs non basés sur la techno de Google sont-ils en danger ?
Comme Microsoft Edge, Brave adopte à son tour Chromium avec Brave 0.57 et assure que la nouvelle version de son navigateur est plus rapide de 22 %

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de StraToN
Membre actif https://www.developpez.com
Le 14/06/2019 à 9:53
J'ai du mal à entrevoir comment Google, qui est parmi les plus gros fournisseurs de publicité online avec Adsense, peut être digne de confiance pour faire du blocage de publicité. C'est comme donner les clés du commissariat de police aux trafiquants de drogue.
6  0