"I am pointing out that removing the blocking ability of the webRequest API means the death of uBO, I won't work to make uBO less than what it is now."
Ce qui est bien avec le libre c'est que si un développeur fait un caca nerveux parce qu'on lui a enlevé un moyen, il peut y en avoir un autre qui prend la relève à moindre coût si il y un intérêt. Soit proposer un patch qui sera accepté, soit un fork. Ne pas dépendre que d'une personne.
A noter que le post date et que donc ça a peut-être changé, entre compréhension du changement ou changement de point de vue de l'auteur.
(en vrai je n'ai pas compris les "moins qu'avant", à ma connaissance uBlockOrigin fait surtout du blocage et non pas du remplacement donc la nouvelle API devrait convenir pour lui au contraire de ceux qui font des modifs à la volée)
Posté par El Titi .
Évalué à 9.
Dernière modification le 25 août 2022 à 23:40.
Ce qui est bien avec le libre c'est que si un développeur fait un caca nerveux parce qu'on lui a enlevé un moyen
Sarcasme vs diplomatie. Même remarque formulée subtilement sous la forme d'une question en apparence innocente, plutôt qu'une attaque pleine de mépris pour des devs qui consacrent leur temps sans forcément de retour. Eux n'ont pas été capables de trouver un business model viable, contrairement à certains qui ne manquent jamais de nous le rappeler.
C'est moi ou Google n'en a plus rien à faire de dégrader son image, et d'apparaître de plus en plus comme le grand méchant loup ?
Certes, dans l'article il est mentionné qu'ils défendent leur choix en prétendant que ça améliorera le respect de la vie privé, des perfs, et de la sécurité ("Google has presented the changes as a benefit to privacy, security, and performance"). Mais (au moins dans l'article), c'est pauvre en arguments, et ça semble démonté par tout le monde, et contredit par leur rapport annuel auprès de la SEC (https://www.sec.gov/Archives/edgar/data/1652044/000165204422000019/goog-20211231.htm).
Pour un meilleur avis, j'aimerai trouver une source montrant l'argumentaire complet de Google ; mais j'ai pas trouvé pour l'instant - si quelqu'un a ça…
Maintenant que les gens sont pieds et poings liés à Google, je pense en effet qu'ils n'en n'ont rien à foutre.
Une raison supplémentaire pour tout faire pour que Firefox ne disparaisse pas.
J'ai l'impression que la plupart des réponses sont des outils automatiques, non ? Ça ne nous renseigne pas beaucoup.
Et à moins que Firefox n'écrase tous ses concurrents de très très loin, le fait qu'il n'y ait rien qui ressemble à un autre navigateur dans les 15 premiers laisse entendre que toutes ces réponses sont des outils automatiques, y compris la première (ne serait-ce qu'un lecteur de flux dans un navigateur web).
Sinon ça voudrait dire que la première ligne représente Firefox et que le second navigateur est en dessous de 40 fois moins d'utilisateurs, donc quasiment rien. Ça ne paraît pas beaucoup quand même…
Autre possibilité : les chaînes d'identification d'autres navigateurs sont très éparpillées (par version ou autre), ce qui fait que chacun d'entre eux se trouve réparti sur une multitude de lignes.
Posté par El Titi .
Évalué à 6.
Dernière modification le 25 août 2022 à 13:51.
De ce que je comprends, cette spec va être implémentée dans Chromium et va donc impacter tous les autres browsers qui s'appuient dessus comme Brave qui fait de la vie privée son argument de vente.
Un fork en perspective ?
Autre question: Autant je comprends que ce soit problématique l'impact pour Ghostery qui modifie les flux, autant pour uBlock qui ne fait que les bloquer, la nouvelle API pourra le permettre aussi.
Autre question: Autant je comprends que ce soit problématique l'impact pour Ghostery qui modifie les flux, autant pour uBlock qui ne fait que les bloquer, la nouvelle API pourra le permettre aussi.
Quelqu'un a une explication ?
Dans le modèle actuel, c’est "Wesh frère, fait voir la requête et je me débrouille avec"
Dans le nouveau modèle, c’est "Frère, voici la liste des URL pour lesquelles je veux que tu fasses un truc"
Si je comprends bien l'extension n'a plus la main nulle part dans le cycle de la requête. Ca les rend quasi obsolètes.
Ce qui m'intrigue encore plus avec ce schéma, c'est que certaines extensions permettaient aussi de modifier le rendu des pages et pas seulement des bloqueurs comme par exemple DarkReader. J'espère qu'elles ne seront pas impactées.
On en viendrai presque à croire que Google n'est pas aussi méchant dans l'alternative qu'il propose qu'on voudrait l'afficher…
Quelqu'un peut dire ce qui est réellement plus possible avec l'évolution? Nombre de règles? Mais en quoi ça impacterait?
(c'est une vraie question, j'avais compris que la v3 empêchait de modifier et que c'est ça qui faisait crier, et maintenant on me démontre qu'on peut modifier avec de la v3)
PS : merci pour la découverte de cette extension. Mais par contre LinuxFr est joueur, ça "flashe" 1/10 seconde avant de passer en noir, et même si je désactive l'extension pour le site, peut-être à cause d'un thème que j'ai, du coup j’hésite à garder.
On en viendrai presque à croire que Google n'est pas aussi méchant dans l'alternative qu'il propose qu'on voudrait l'afficher…
Je dois me sentir visé par cette remarque ?
PS : merci pour la découverte de cette extension. Mais par contre LinuxFr est joueur, ça "flashe" 1/10 seconde avant de passer en noir, et même si je désactive l'extension pour le site, peut-être à cause d'un thème que j'ai, du coup j’hésite à garder.
Aucun souci de mon côté avec Chrome, tout comme FF et ce depuis des années. C'est vraiment une extension que je trouve indispensable perso et j'encourage les utilisateurs à récompenser ce LL partagé sans limitations. Il arrive parfois que les contrastes ne soient pas assez appuyés sur certains sites et je la désactive sur ceux qui proposent un dark mode, puisque ça se fait en un clic.
Quelqu'un peut dire ce qui est réellement plus possible avec l'évolution? Nombre de règles? Mais en quoi ça impacterait?
De ce que je comprends (mais j'ai pas regardé en détail), le problème est multiple :
Le nombre limité d'url intercepté; or le nombre de serveur fournissant de la pub est bien au delà des limite imposées.
le fait qu'elles doivent venir avec l'app; ce qui gène le chargement à chaud des liste et config utilisateurs.
J'imagine que certains trucs doivent pouvoir être contournés pour un bloqueur de pub, pour les truc comme ghostery et umatrix qui eux bloquent le monde sauf le site visité (a peu de choses près) et gère les exception au cas pas cas, c'est tout simplement mort.
Mais je dois dire que je me suis pas trop penché sur le problème, vu que j'utilise firefox pour naviguer, et que ce dernier continu de gérer le MV2; je laisse aux utilisateurs de chrome leur propre combat, j'en ai déjà suffisamment d'autre :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# commentaire du devloppeur de uBlock Origin
Posté par jtremesay (site web personnel) . Évalué à 10.
"I am pointing out that removing the blocking ability of the webRequest API means the death of uBO, I won't work to make uBO less than what it is now."
https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-456179825
[^] # Re: commentaire du devloppeur de uBlock Origin
Posté par Jean-Baptiste Faure . Évalué à 2.
Ça date de 2019, depuis il y a eu des évolutions. Il faut lire les messages suivants.
[^] # Re: commentaire du devloppeur de uBlock Origin
Posté par jtremesay (site web personnel) . Évalué à 2.
ça m’apprendra à lire des trucs sur reddit avant mon premier café. Mea Culpa.
[^] # Re: commentaire du devloppeur de uBlock Origin
Posté par Zenitram (site web personnel) . Évalué à -8. Dernière modification le 25 août 2022 à 14:26.
Ce qui est bien avec le libre c'est que si un développeur fait un caca nerveux parce qu'on lui a enlevé un moyen, il peut y en avoir un autre qui prend la relève à moindre coût si il y un intérêt. Soit proposer un patch qui sera accepté, soit un fork. Ne pas dépendre que d'une personne.
A noter que le post date et que donc ça a peut-être changé, entre compréhension du changement ou changement de point de vue de l'auteur.
(en vrai je n'ai pas compris les "moins qu'avant", à ma connaissance uBlockOrigin fait surtout du blocage et non pas du remplacement donc la nouvelle API devrait convenir pour lui au contraire de ceux qui font des modifs à la volée)
[^] # Re: commentaire du devloppeur de uBlock Origin
Posté par El Titi . Évalué à 9. Dernière modification le 25 août 2022 à 23:40.
Sarcasme vs diplomatie. Même remarque formulée subtilement sous la forme d'une question en apparence innocente, plutôt qu'une attaque pleine de mépris pour des devs qui consacrent leur temps sans forcément de retour. Eux n'ont pas été capables de trouver un business model viable, contrairement à certains qui ne manquent jamais de nous le rappeler.
C'est vraiment plus fort que toi, hein.
# Communication de Google
Posté par Dring . Évalué à 9.
C'est moi ou Google n'en a plus rien à faire de dégrader son image, et d'apparaître de plus en plus comme le grand méchant loup ?
Certes, dans l'article il est mentionné qu'ils défendent leur choix en prétendant que ça améliorera le respect de la vie privé, des perfs, et de la sécurité ("Google has presented the changes as a benefit to privacy, security, and performance"). Mais (au moins dans l'article), c'est pauvre en arguments, et ça semble démonté par tout le monde, et contredit par leur rapport annuel auprès de la SEC (https://www.sec.gov/Archives/edgar/data/1652044/000165204422000019/goog-20211231.htm).
Pour un meilleur avis, j'aimerai trouver une source montrant l'argumentaire complet de Google ; mais j'ai pas trouvé pour l'instant - si quelqu'un a ça…
[^] # Re: Communication de Google
Posté par ploppor . Évalué à 10.
Maintenant que les gens sont pieds et poings liés à Google, je pense en effet qu'ils n'en n'ont rien à foutre.
Une raison supplémentaire pour tout faire pour que Firefox ne disparaisse pas.
[^] # Re: Communication de Google
Posté par mahikeulbody . Évalué à 4.
A commencer par l'utiliser soi-même.
Il y a des statistiques sur les navigateurs utilisés par les visiteurs de LinuxFR (ou, à défaut, un sondage pas trop ancien) ?
[^] # Re: Communication de Google
Posté par fearan . Évalué à 4.
au pire tu peux toujours reproposer un sondage :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Communication de Google
Posté par Tonton Th (Mastodon) . Évalué à 6.
https://linuxfr.org/webalizer/usage_202208.html#TOPAGENTS
[^] # Re: Communication de Google
Posté par ylsul . Évalué à 3.
J'ai l'impression que la plupart des réponses sont des outils automatiques, non ? Ça ne nous renseigne pas beaucoup.
Et à moins que Firefox n'écrase tous ses concurrents de très très loin, le fait qu'il n'y ait rien qui ressemble à un autre navigateur dans les 15 premiers laisse entendre que toutes ces réponses sont des outils automatiques, y compris la première (ne serait-ce qu'un lecteur de flux dans un navigateur web).
Sinon ça voudrait dire que la première ligne représente Firefox et que le second navigateur est en dessous de 40 fois moins d'utilisateurs, donc quasiment rien. Ça ne paraît pas beaucoup quand même…
Autre possibilité : les chaînes d'identification d'autres navigateurs sont très éparpillées (par version ou autre), ce qui fait que chacun d'entre eux se trouve réparti sur une multitude de lignes.
[^] # Re: Communication de Google
Posté par Jérôme FIX (site web personnel) . Évalué à 7.
C'est surtout que tous les user-agent des navigateurs actuels contiennent "Mozilla/5.0", que ce soit Firefox, Chrome, Chromium, Edge, …, cf. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
La stats fournie par webalizer n'apporte rien ici.
[^] # Re: Communication de Google
Posté par ylsul . Évalué à 4.
D'accord, merci. Cette page fait un petit historique de l'en-tête http user-agent :
https://webaim.org/blog/user-agent-string-history/
# Un fork ?
Posté par El Titi . Évalué à 6. Dernière modification le 25 août 2022 à 13:51.
De ce que je comprends, cette spec va être implémentée dans Chromium et va donc impacter tous les autres browsers qui s'appuient dessus comme Brave qui fait de la vie privée son argument de vente.
Un fork en perspective ?
Autre question: Autant je comprends que ce soit problématique l'impact pour Ghostery qui modifie les flux, autant pour uBlock qui ne fait que les bloquer, la nouvelle API pourra le permettre aussi.
Quelqu'un a une explication ?
[^] # Re: Un fork ?
Posté par jtremesay (site web personnel) . Évalué à 7.
Dans le modèle actuel, c’est "Wesh frère, fait voir la requête et je me débrouille avec"
Dans le nouveau modèle, c’est "Frère, voici la liste des URL pour lesquelles je veux que tu fasses un truc"
(source des images : https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html)
Sauf que le nombre de règles de filtrage a l’air trop faible pour les besoins des bloqueurs de pub et assimilés, cf https://github.com/w3c/webextensions/issues/82
[^] # Re: Un fork ?
Posté par El Titi . Évalué à 3.
Super intéressant merci.
Si je comprends bien l'extension n'a plus la main nulle part dans le cycle de la requête. Ca les rend quasi obsolètes.
Ce qui m'intrigue encore plus avec ce schéma, c'est que certaines extensions permettaient aussi de modifier le rendu des pages et pas seulement des bloqueurs comme par exemple DarkReader. J'espère qu'elles ne seront pas impactées.
[^] # Re: Un fork ?
Posté par jtremesay (site web personnel) . Évalué à 4.
DarkReader utilise déjà le standard d’extension "Manifest v3" dont il est question dans l’article, donc eux ne sont pas concernés :)
https://github.com/darkreader/darkreader/blob/main/src/manifest-chrome-mv3.json
[^] # Re: Un fork ?
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 25 août 2022 à 20:34.
On en viendrai presque à croire que Google n'est pas aussi méchant dans l'alternative qu'il propose qu'on voudrait l'afficher…
Quelqu'un peut dire ce qui est réellement plus possible avec l'évolution? Nombre de règles? Mais en quoi ça impacterait?
(c'est une vraie question, j'avais compris que la v3 empêchait de modifier et que c'est ça qui faisait crier, et maintenant on me démontre qu'on peut modifier avec de la v3)
PS : merci pour la découverte de cette extension. Mais par contre LinuxFr est joueur, ça "flashe" 1/10 seconde avant de passer en noir, et même si je désactive l'extension pour le site, peut-être à cause d'un thème que j'ai, du coup j’hésite à garder.
[^] # Re: Un fork ?
Posté par El Titi . Évalué à 2.
Je dois me sentir visé par cette remarque ?
Aucun souci de mon côté avec Chrome, tout comme FF et ce depuis des années. C'est vraiment une extension que je trouve indispensable perso et j'encourage les utilisateurs à récompenser ce LL partagé sans limitations. Il arrive parfois que les contrastes ne soient pas assez appuyés sur certains sites et je la désactive sur ceux qui proposent un dark mode, puisque ça se fait en un clic.
[^] # Re: Un fork ?
Posté par fearan . Évalué à 9.
De ce que je comprends (mais j'ai pas regardé en détail), le problème est multiple :
J'imagine que certains trucs doivent pouvoir être contournés pour un bloqueur de pub, pour les truc comme ghostery et umatrix qui eux bloquent le monde sauf le site visité (a peu de choses près) et gère les exception au cas pas cas, c'est tout simplement mort.
Mais je dois dire que je me suis pas trop penché sur le problème, vu que j'utilise firefox pour naviguer, et que ce dernier continu de gérer le MV2; je laisse aux utilisateurs de chrome leur propre combat, j'en ai déjà suffisamment d'autre :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Réchauffé (mais ce n'est pas forcément plus mal)
Posté par Jean-Baptiste Faure . Évalué à 5. Dernière modification le 25 août 2022 à 14:37.
Il me semblait bien qu'on en avait déjà parlé ici : https://linuxfr.org/users/blobmaster/liens/chrome-anti-bloqueur-pourquoi-je-reste-sur-firefox
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.