« Google veut mettre à mort les bloqueurs de publicité ». Un discours qui n'a rien de nouveau, mais qui prend plus d'ampleur ces derniers mois à travers le travail autour de la v3 du manifeste des extensions et l'évolution de certaines API. Face aux critiques, Google évolue et détaille à nouveau sa position.
L'équipe de Chromium travaille à la v3 du manifeste de ses extensions et la modification profonde de certaines API depuis des mois. Fin 2018, un point a été mis en lumière concernant l'évolution de Web Request et sa capacité à bloquer des requêtes. Les développeurs du navigateur estiment que son impact sur les performances est néfaste, en plus de poser des problèmes de sécurité et la vie privée pour l'utilisateur.
Faire évoluer un écosystème, c'est compliqué
Elle doit donc être remplacée par Declarative Net Request, aux possibilités moins nombreuses. Mais voilà, cela pose souci à certains concepteurs d'extensions qui voient dans cette API une limitation de leurs possibilités plus qu'une évolution intéressante. C'est notamment le cas des bloqueurs de publicités. La suite était prévisible.
Rapidement, Google a été accusé de vouloir compliquer la vie de ces derniers, voire de signer leur arrêt de mort. Il y a quelques jours, les choses ont repris de plus belle suite à de nouvelles déclarations et l'annonce d'une exception limitée à la version Entreprise de Chrome. Les développeurs d'autres navigateurs basés sur Chromium, interrogés par ZDNet, ont déclaré qu'ils ne suivraient pas cette modification, de quoi initier la création d'un « fork ».
Google ne pouvait donc plus rester dans l'ombre et a décidé de communiquer.
Les risques de Web Request, l'évolution nécessaire de Declarative Net Request
Dans un long billet de blog, l'équipe de développement revient sur le fonctionnement des deux API, ses choix et ses motivations, évoquant « de la confusion et des malentendus » dans cette affaire, notamment par les objectifs visés. Elle y rappelle que, « historiquement, lorsque les développeurs ont eu à faire le choix entre les capacités de leurs extensions et la vie privée, c'est le premier point qui l'a emporté ».
Google ajoute de son côté une couche via son blog dédié à la sécurité. Il faut dire que la société ne veut sans doute pas finir par être accusée de laxisme lorsqu'un scandale éclatera parce que des milliers d'utilisateurs s'apercevront avoir été espionnés en détail par une extension qui utilisait discrètement Web Request.
La position des équipes de Chromium ne change donc pas sur un point : Declarative Net Request prendra le relais à terme, à la manière des choix d'Apple en la matière, le travail sur le manifeste v3 étant de toute façon loin d'être terminé. Mais des évolutions ont déjà été intégrées ou vont l'être pour répondre aux demandes des développeurs.
Manifest v3 : la négociation continue, des changements prévus
Des éléments de pistages peuvent ainsi être retirés des requêtes (referer, cookies), des règles peuvent être ajoutées ou supprimées de manière dynamique, ces dernières devraient d'ailleurs pouvoir être plus complexes à l'avenir.
Surtout, leur nombre maximal va passer de 30 000 à 150 000 pour s'assurer que des logiciels comme les bloqueurs peuvent continuer de fonctionner. Les extensions devront néanmoins évoluer pour s'adapter à ce changement, dont la mise en place est encore lointaine. Les développeurs d'extensions ne manqueront sans doute pas de réagir à cette déclaration dans les jours qui viennent, il faudra suivre attentivement leur réaction.
Notamment leurs propos concernant des points de blocage qui pourraient encore exister dans la v3 du manifeste. Il faut également s'attendre à ce que certains en profitent pour continuer de pousser les navigateurs tiers à faire scission avec le code de base de Chromium. Alors que Microsoft s'apprête à sortir son nouvel Edge, sa position est attendue.
Commentaires (66)
#1
Actuellement, mon uBlock Origin est réglé ainsi :
« 128 222 filtre(s) réseau et 101 438 filtre(s) esthétique(s) sont actuellement en vigueur » (soit 229 660 cumulés)
Est-ce que, dans ces conditions, ça suffira (quitte à virer les filtres esthétiques) ?
#2
Vive Firefox
#3
C’est l’objectif ;)
#4
Il serait bon aussi d’encadrer plus durement la publicité en ligne, de mettre en place des standards, etc …
En l’état c’est une jungle ou l’utilisateur est constamment agressé ! l’ARPD se sert absolument à rien …
Les traceurs, les cookies, les informations collectés, pour le moment tout reste flou, nous ne savons toujours pas ce qui est réellement fait en la matière et ce malgré les avancés de la RGPD …
#5
Si je comprends bien, les extensions devront faire confiance à chrome pour appliquer les filtres voulus donc potentiellement google peut mettre en place une liste blanche (à la adblock plus)?
#6
Le principe de la délégation du filtrage afin que l’extension ne voient pas les données est une bonne intention et peut s’avérer judicieux si c’est bien fait. Ce qui parait idiot, c’est de fixer une limite sur la quantité de filtres utilisables. Qu’apporte t’elle de plus ? Rien du point de vue de la protection de la vie privée en tout cas.
C’est cette limite le problème, pas le principe.
#7
Il y a déjà des standards dans la publicité en ligne, même plein de label. Cela n’empêche rien. Comme toute industrie, elle abuse des possibilités à sa disposition. Et comme les instances en charge tardent à réellement taper du poing sur la table, ça continue.
#8
Pourquoi ne pas simplement avertir l’utilisateur que l’extension demande à utiliser webrequest ?
Le nombre d’applications doit être relativement limité, non ?
#9
#10
Sinon vous avez le fichier hosts. Comme ça à vous de voir quel site essaye de vous entourlouper par d’autres moyens sophistiqués.
Google ajoute de son côté une couche via son blog dédié à la sécurité. Il faut dire que la société ne veut sans doute pas finir par être accusée de laxisme lorsqu’un scandale éclatera parce que des milliers d’utilisateurs s’apercevront avoir été espionnés en détail par une extension qui utilisait discrètement Web Request.
J’avais cru comprendre que ces méthodes de voyous étaient normales depuis que modifier les paramètres de localisation sur Android ne changeait rien. Cohérence quand tu nous tiens. " />
#11
#12
Le fichier host n’applique pas de règles CSS
#13
#14
C’est un problème connu lorsque le fichier hosts devient trop “gros”. Il faut impérativement désactiver le service “Client DNS” (en réalité, un cache DNS) qui est responsable de cette instabilité. Plus d’infos ici.
#15
Ça alors !
Histoire de s’habituer au DDI plutôt qu’au DPI !
#16
Un petit pi-hole et c’est réglé
#17
#18
Oui mais il n’y a pas que la publicité qui est visée… et là au moins l’information est on ne peut plus claire.
Avec les statistiques le quidam peut comprendre de quoi il s’agit, je pense notamment à ceux ayant un accès limité en Mo ou Go, par exemple. (oui je sais en France c’est dépassé sur une connexion ADSL mais pas dans tous les pays)
#19
Je vais également installer un pihole mais en étant conscient qu’aucun système n’est infaillible.
Si les publicitaires ne peuvent passer par devant ils tenteront par derrière !
À ce moment-là nous trouverons une autre solution également.
#20
Google qui nous explique qu’un bloqueur de pub est plus dangereux pour notre vie privé que… les publicitaires qui sont payés pour voler de la vie privée et manipuler les gens " />
#21
Déjà dit, mais ils ne disent pas que le souci vient des bloqueurs de pub, Web Request ne concerne pas que les bloqueurs de pub, le problème des limites de DNR non plus… et le problème soulevé par les dévs de Chromium est réel. Après on peut juste troller, mais ça ne fait pas avancer le débat.
#22
#23
Dans ce cas nous sommes en droit d’attendre un article sur les projets de Ronald Minnich. " />
#24
Quel rapport ?
De plus, tu n’es en droit d’attendre rien du tout.
#25
@David_L, et pourquoi pas implement mettre leur 30.000 règles et autorisé certaine extension (genre ublock et adblock au pure hasard) a monté a 130.000, et si l’extension autorisée a besoin de plus demandé a l’utilisateur, en lui expliquant ce qu’il risque en acceptant.
#26
pourquoi n’aurait-il pas le droit d’attendre ? Il peux, si il veut, personne ne va l’en empêcher " />
#27
Ne pas confondre “être en droit de” et “avoir le droit de”. Et, oui, il peut toujours attendre. " />
#28
Je suis plutôt d’accord avec @stratic pour le coup. La limitation devrait être simplement la RAM. Certes, une extension mal codée fera planter le PC, mais n’importe quelle application mal codée fera planter le PC. C’est souvent ça qui va faire que les utilisateurs ne vont plus l’utiliser au final.
Aussi, il n’y avait pas de limitation avant (à ce que je sache), et les extensions ne se sentaient pas obligées de prendre toute la RAM pour autant.
Je comprends le principe de vie privée, et effectivement Firefox va devoir rentrer dans la danse à un moment ou à un autre. Mais la limitation du nombre de règles n’a pas de rapport avec la protection de la vie privée.
#29
Ce monsieur travaille chez Google dont les parcs de serveurs reposent sur des micro-logiciels propriétaires et lui et d’autres souhaitent sécuriser par l’ouverture ce qui peut l’être, à juste titre.
C’est exactement la même idée que les développeurs de chrome avec Net Request.
J’attends seulement un peu de cohérence, et accessoirement une information payée de qualité… mais comme les cerveaux de certains qui font des “rapports” ne s’achètent pas. " />
#30
On parle des USA là… Ce genre de message fonctionnerait en Europe, mais pas dans une nation où même le fait d’être un admin ne suffit pas à te donner le droit de tout faire (cf Windows, etc.) simplement parce qu’ils ont peur d’éventuels procès.
#31
#32
Enfin la preuve que les fantômes ont une existence matérielle, bonne nouvelle. " />
#33
Merci d’avoir confirmé que tu mélanges tout.
Google et sécurité ne suffit pas pour établir un rapport entre les 2 sujets.
Quant aux cerveaux, j’ai peur que tu te sois fait avoir sur la qualité du tien pour faire des rapports entre des sujets.
Et le fait de payer ne donne pas tous les droits, surtout pas celui de faire le cuistre et de réclamer quelque chose parce que tu payes.
#34
#35
“mes droits”… j’avais pris soin de déclarer “nous” dans mon premier message, mais là encore l’individualisme règne, c’est intéressant de noter que certains l’exploitent contre rémunération et que d’autres sont obligés de subir. " />
Je mélange quoi au juste ? [question tout à fait sérieuse]
#36
Oui et je reprécise que c’était bien l’idée de dégager les noms de domaine pourris pour voir qui fait quoi ensuite sur navigateur.
#37
Je pense que tout le problème est de savoir à qui (quel codeur/programme/extension) chacun accorde sa confiance
J’attend de voir ce que ça va donner en pratique … dans quelques temps (attendons le premier sois-disant-bug=scandale). Je vais donc mettre un Vivaldi, un Iridium et un Chromium dans une VM et archiver le tout pour faire le comparatif quand l’heure sera venue :)
Et sinon, Palemoon, c’est pas mal du tout (pour faire ce qu’on veut), et j’ai même monté mon propre serveur de synchro (FsyncMS) pour ne même plus dépendre de Mozilla " />
#38
Cet article de blog est remplit de bullshit, c’est impressionnant.
J’ai suivi de près la discussion dans les Google Groups, et tous les arguments avancés par Google ont été démontés.
Perfs, sécurité, contrôle. Tout a été démonté.
#39
#40
#41
Faudrait voir ce que wireshark en pense pour trancher. " />
#42
#43
Oui à l’usage sur le long terme c’est très chiant. Surtout depuis quelques mois. :/
Mais pour faire un test ça reste l’option la plus rapide, avec wireshark en prime tu comprends déjà mieux ce qu’il se passe plutôt que le brouillard.
Après y’a pihole…
#44
Pas convaincu.
Même si les règles d’interception sont suffisamment souples pour exprimer les conditions d’interception et de remplacement de contenu il y aura sans doute des usages qui vont devenir impossibles :
Comment changer le user-agent ?
Ignorer le CORS ?
Injecter du contenu dans une page qui tourne sur sharepoint ?
#45
J’ai parlé de serveur DNS sous Windows car Pihole n’est pas une solution satisfaisante pour tout à chacun, déjà que sous Windows ce serait très limite…
Pihole, c’est très cher (il faut paier l’équipement), c’est coûteux en énergie (équipement online en permanence) et de fait l’est financièrement (EDF) et donc écologiquement (sauf si on a d’autres fonctions à lui ajouter pour justifier sa raison d’être). A la limite ce serait tolérable dans le cadre d’une action groupée, mais seul des groupes de geeks mettront ça en place.
#46
Le coût électrique est dérisoire si branché à une box qui pourrait très bien faire serveur dns si les opérateurs s’y décidaient. Le seul coût c’est l’achat d’un PI et le temps passé à paramétrer. C’est un effort mental pas un effort financier.
A croire que dans l’inertie que tu évoques il y a aussi la peur de s’auto-gérer. " />
#47
Les box consomment déjà trop d’énergie, pas la peine d’en rajouter. La pire bouffe 45 €/an à elle-seule de mémoire. Multiplié par des millions d’unités, c’est un gâchi énorme.
#48
Je suis tout à fait d’accord mais le seul ennui c’est que la mutualisation est en pratique très limitée là où elle pourrait être utile et faire mal.
Par exemple de plus en plus de syndics qui sont complètement à l’ouest et imposent sans même y penser les accès individuels en fibre alors qu’il n’y a qu’un opérateur de dispo dans l’immeuble… et le problème n’est pas technique : c’est l’imposition d’un gestionnaire ayant trop d’immeubles à gérer qui rend possible ce type de bêtise. Donc ce n’est pas que technique ou écologique, c’est un problème de communication voir d’étanchéité entre publics et fonctions.
Défendre la forme associative c’est bien, mais lui donner un sens économique c’est hélas mieux. Là il y a une boite à monter pour diviser les coûts des abonnements par exemple, d’une pierre deux coups…
Je maintiens tout de même que la consommation individuelle d’un pi est négligeable et masquée par celle des box déjà là. Les objets connectés à tout va par contre ça c’est une catastrophe, sans parler du coût global des imprimantes 3D oui.
#49
C’est clairement l’ère du temps. La brève sur le CERN plus haut le confirme aussi.
Mais je peux comprendre le syndic qui préfère individualiser, car sinon il faudrait gérer la question du partage de la BP alors que c’est un service essentiel à chacun, et parfois plus à certains qu’à d’autres " />
On devrait déjà mutualiser ce qui relève de l’optionnel, de l’obligatoire à usage trop irrégulier/rare, ou ce qui est facile à réaliser. Les Pihole et similaires, jusqu’à peut-être des services e-mails/blogs/autres, en passant par de vrais outils comme les tondeuses à gazon que l’on doit avoir alors que l’on s’en sert rarement…
Et je suis d’accord, la mise en place et l’organisation de l’entité qui gérera le tout sera le plus dur à faire.
#50
Il y a syndics et syndics tu sais. Les syndics sont praticables humainement car la proximité culturelle le permet, ou pas. Dans beaucoup de cas aujourd’hui c’est l’aculturation par un non contrat douteux peu engageant pour les copropriétaires et c’est ce modèle d’individualisation de tous les tuyaux qui déconne.
Combien de locataires se soucient des charges communes ? Il n’y a pas d’offre payante de services informatiques proposant l’installation et la gestion d’un réseau commun et géré à chaque immeuble : les opérateurs gèrent donc tout sans dire que le coût est dérisoire pour eux. Faut pas espérer réussir à faire un réseau propre sans argument de coût.
Si tu démontres à un syndic qu’une fibre suffit à relier 20 logements et que sa gestion mutualisée est possible tout en permettant des usages en plus type DNS, hébergement des délibérations du syndic, partage de fichiers entre locataires bref, et est moins onéreuse qu’un des 4 gros du marché tu gagnes un contrat sur 10 ans d’entretien.
Les BP ne changent rien. D’ailleurs elles sont souvent dans le même meuble pour info comme quoi ! Tu peux évidemment faire des services webs individualisés mais sans demande les gros ne feront rien.
#51
Ni le syndic de copropriété, ni le gestionnaire n’imposent quoique ce soit concernant l’accès fibre individuelle.
C’est la loi qui l’impose, et c’est un droit accordé à chacun de pouvoir demander un raccordement à la fibre.
Le syndic ne fait que mettre en oeuvre une convention de fibrage par un opérateur lorsque l’AG le vote.
Et d’ordre générale, le syndic de copropriété ne peut rien imposer sans validation en AG. Sinon cela signifie que vos copropriétaires et votre conseil syndical laissent la copro se gérer en pilote automatique.
Pour résumer : une catastrophe.
#52
#53
A tout hasard… Qu’est-ce qui interdirait à un propriétaire de demander un accès fibre dans sa cave et de se déclarer à l’Arcep ?
La suite c’est assez simple, mais cela doit être une décision de l’AG de déployer du RJ45 (ou de la fibre ahah) dans les parties communes.
Regarde shadow, c’est rentable car tout le monde certes sollicite leurs machines 24⁄24 mais pas au même moment. Un immeuble avec une grosse fibre fera la même chose. Et au prix de la fibre l’idée est loin d’être économiquement non viable pour une copro.
#54
#55
Je ne faisais que repositionner le contexte et les droits de chacun. C’est surtout l’expression “le syndic impose” qui m’a fait tiquer.
Je pense qu’il n’y a rien qui puisse empêcher légalement que la copropriété propose ce service (et en cherchant un peu, il existe déjà des opérateurs proposant un wifi partagé).
La seule incompatibilité que j’y verrais, c’est qu’elle ne peut empêcher un copropriétaire ou un locataire de faire valoir son droit à la FTTH.
#56
Le coût du gros œuvre est assuré par les opérateurs pour les copropriétés. (de mémoire)
Pour un particulier non.
#57
Il impose sans même y penser car son représentant est rarement issu des copropriétaires de nos jours !
Faut voir ce que les grosses agences font.
Oui. Le modèle du wifi partagé peut fonctionner en cablé. (avec moins de coupures, pas de problèmes d’ondes, pas de multiplication des boitiers et tout le bazar que cela peut générer).
Oui mais ce locataire pourrait aussi voir qu’entre une fibre à 40€ et un RJ45 à 2€ il a de la chance d’avoir un propriétaire pas trop con…
#58
#59
Dans mon hypothèse un opérateur pourra toujours installer des fibres si il le souhaite.
Je dis seulement que le coût d’accès à internet est divisible par le nombre de copropriétaires.
Donc peut être réduit drastiquement sans pour autant en affecter le débit. La fibre, c’est surfait.
#60
Je le redis, le syndic ne peut rien imposer aux copropriétaires en dehors des obligations légales inhérentes au droit des copropriétés.
Si le gestionnaire impose des choses, c’est que votre conseil syndical ne fait pas son travail. (et ne pas oublier que les membres du CS peuvent voir engagé leur responsabilité civile… D’où le fait qu’une assurance est recommandée)
Et je parle en connaissance de cause, je suis un emmerdeur fini pour Foncia en tant que membre et président du conseil syndical de notre copropriété. " />
Et en AG je vote contre le quitus, apportant à chaque fois la liste des manquements du gestionnaire motivant cette décision. Car accorder le quitus au syndic signifie lever tout recours possible quant à l’éventuelle négligence de sa gestion.
Et nous faisons joindre en annexe à chaque convocation d’AG la liste de tous les litiges et défauts de gestion constatés sur l’exercice.
C’est sûr que quand on laisse le syndic piloter en automatique, c’est plus simple pour lui… Mais faut juste aimer se faire tondre.
#61
#62
existant:
rue -> partie commune -> gaine -> logements
Je dis juste :
rue -> partie commune | Local privé | -> gaine -> logements
La fibre est bien plus chère oui. Mais en RJ45 pas tellement. " />