L'extension du jour : Request Blocker pour Firefox

Rédigé par antistress le 19 avril 2020 - 12 commentaires

Super heros capé arborant le logo de Firefox sur la poitrine
Captain Extensions recommande Request Blocker

Pfiou… Les gens ordinaires n'imaginent pas la difficulté d'être un super-héros.

Prenez mon cas : la dernière fois que j'ai enfilé mon costume, c'était il y a une éternité. En le ressortant, j'ai bien dû reconnaître qu'il était passé de mode, et que j'allais devoir en confectionner un nouveau… Heureusement que ma mission n'était pas urgente ! En tout cas, j'espère que le nouveau vous plaît.

Bref, tout ça pour pouvoir vous présenter aujourd'hui Request Blocker, une extension libre pour Firefox qui permet de bloquer les sites/domaines de son choix.

Pourquoi Request Blocker ?

Avec l'incroyable outil de blocage des sites tiers pisteurs dorénavant inclus dans Firefox, je n'utilise plus d'extension conventionnelle de blocage (uBlock Origin, Privacy Badger…).

Le mode « Strict » de la « Protection renforcée contre le pistage », configurable depuis les Préférences, fait vraiment un super boulot.

Aller plus loin nécessite parfois de se passer de fonctionnalités de certains sites : jolies polices hébergées sur des sites tiers centralisateurs comme le propose « généreusement » Google, commentaires délégués à des sites tiers centralisateurs comme Disqus, meilleure performance supposée en passant par des CDN centralisateurs, intégration de vidéos hébergées sur des sites tiers centralisateurs comme Youtube… Autant de compromis que je suis, pour la plupart, prêt à faire.

J'aime pour ma part l'idée – soyons honnêtes : réservée aux plus geeks d'entre nous – de traquer les traqueurs résiduels.

Grâce à l'extension libre Lightbeam 3.0 il est possible de repérer les sites tiers indélicats qui continuent de suivre en douce votre navigation. En revanche Firefox ne vous permet pas de bloquer individuellement ces sites (il vous permet d'empêcher tel site de stocker des cookies et autres données de sites mais ce n'est pas aussi efficace que de bloquer le site lui-même pour, tout simplement, l'empêcher de vous voir).

En fait il y a trois possibilités de blocage individuel des sites repérés :

  1. par les bloqueurs habituels, qui sont capables de vous révéler, derrière chaque site de premier niveau que vous visitez, les sites tiers qui vous espionnent, et vous permettent de les bloquer dans la foulée ;
  2. par le fichier /etc/hosts du système d'exploitation que l'ont peut modifier pour ajouter, un à un, les domaines à bloquer ;
  3. par cette extension que je vous présente aujourd'hui, qui permet la même chose que le fichier /etc/hosts mais au niveau du navigateur.

L'avantage que je vois à cette extension (#3) par rapport à une intervention au niveau du système d'exploitation (#2) c'est que, si le blocage s'avère finalement gênant, il me suffit d'ouvrir le site dans une fenêtre de navigation privée (Ctrl+Maj+P) pour outrepasser le blocage (dans le panneau de gestion des extensions de Firefox, je prends soin de ne pas autoriser les bloqueurs en navigation privée pour cette raison).
L'inconvénient serait d'alourdir le navigateur d'une extension de plus. Mais le gestionnaire de tâches de Firefox ne révèle aucune consommation processeur significative et montre un usage mémoire très raisonnable d'environ 440 Ko.

Par rapport aux bloqueurs habituels (#1), j'aime bien la philosophie KISS à laquelle me paraît correspondre cette extension. Je trouvais aussi qu'il y avait une certaine logique pratique à inscrire dans un répertoire, l'un après l'autre, les domaines indélicats repérés avec Lightbeam. À la réflexion je ne suis plus si sûr de cela, car si vous avez coupé trop de choses sur un site, il n'est pas possible de savoir facilement laquelle des entrées du répertoire en est responsable ! Chacun se fera son idée.

Au final j'ai décidé de faire confiance à cette extension plutôt que d'autres similaires : sous licence libre, elle comporte 800 utilisateurs, a été mise à jour récemment, son développeur a 10 extensions à son actif sur addons.mozilla.org et j'ai mesuré qu'elle consommait peu.

Comment Request Blocker ?

Là on va pouvoir être bref : vous ouvrez le répertoire des domaines à bloquer à partir des préférences de l'extension, onglet « Block List ». Vous respectez bien la syntaxe officielle (sinon vous recevrez un avertissement au moment d'enregistrer). Comme d'habitude vous faites attention à ne pas bloquer les domaines des CDN que decentraleyes intercepte sous peine d’empêcher ce dernier de faire son travail. Vous sauvegardez : le blocage est effectif immédiatement.
Dans l’onglet suivant, « Stats », vous mesurez l'efficacité de chacun de vos filtres.
Bonus : le dernier onglet vous permet de choisir un thème sombre.

Au final vous pourrez faire des allers-retours entre Lightbeam et Request Blocker jusqu'à arriver à un résultat satisfaisant. Je vous mets la liste à laquelle je suis arrivé en quelques jours, à titre d'exemple.

Détection du pistage avec Lightbeam
Ci-dessus, aucun des « ponts » entre sites de premier niveau n'est souhaité

À part le domaine cdnjs.cloudflare.com qui relie quelques sites de premier niveau en haut à gauche (que je ne veux pas bloquer, étant pris en charge par decentreleyes), le reste des points de connexion visibles dans cette configuration tiennent tous à YouTube (Google) (j'ai bien un peu de dailymotion mais à peu près isolé au niveau de France Inter, non visibles ci-dessus). Pour isoler parfaitement mon surf des pisteurs indiscrets (Google, en l’occurrence), il faudrait que je sois prêt à couper les vidéos YouTube des sites que je visite.

Conclusion

Hors réseaux sociaux privateurs attitrés qui n’apparaissent pas ici (puisque je ne les utilise pas), on ne peut malheureusement que constater l'importance qu'a pris en particulier YouTube sur le web. Un problème qu'adresse : en surface, une extension comme Invidition, qui permet de rediriger les requêtes YouTube vers un proxy (un peu comme StartPage sert les résultats de Google Search) ; à la racine, PeerTube, développé par Framasoft. À condition, pour ce dernier, que les uploaders y recourent : si pas exclusivement, au moins conjointement.

Un autre point est que pour l'instant, étonnamment, il n'y a pas encore trop d'anti-fonctionnalités qui soient implémentées sur les sites pour les rendre artificiellement inutilisables en cas de blocage de traceurs par l'utilisateur. Du coup, il n'y a quasiment que des avantages à bloquer les domaines tiers (chargement plus rapide des pages et consommation réduite de bande passante et d'énergie). Et ça, c'est dingue.


Table des matières de cette série de billets dédiée à la protection contre le pistage de nos comportements en ligne :


L'illustration de ce billet est une composition réalisée par mes soins avec GIMP à partir de cette image et donc soumise à la même licence CC BY-SA 2.0 que cette dernière.

12 commentaires

#1  - romainsphere a dit :

Bonjour,
Quel sont les avantages de cette extension par rapport à Third-party Request Blocker utilisée par défaut avec Icecat?

Répondre
#2  - antistress a dit :

Je ne connaissais pas. Avec Third-party Request Blocker on est plutôt dans la logique de uBlock Origin ou Privacy Badger (solutions #1). Comme je disais à ce sujet : « les bloqueurs habituels, qui sont capables de vous révéler, derrière chaque site de premier niveau que vous visitez, les sites tiers qui vous espionnent, et vous permettent de les bloquer dans la foulée ». C-a-d qu'il y un lien entre le domaine bloqué et le site visité, ce n'est pas une base déportée de sites à bloquer (solutions #2 et #3).
Après ça pourrait être une bonne alternative, en étant plus dans la philosophie KISS qu'un uBlock Origin par exemple. Par contre moins de 300 utilisateurs, une seule version dans l'historique (du 15 janv. 2019) et le seul lien donné (Site d’assistance) est une page de pub avec un tracker : moi je tente pas !

Répondre
#3  - barmic a dit :

> Aller plus loin nécessite parfois de se passer de fonctionnalités de certains sites : jolies polices hébergées sur des sites tiers centralisateurs comme le propose « généreusement » Google, commentaires délégués à des sites tiers centralisateurs comme Disqus, meilleure performance supposée en passant par des CDN centralisateurs, intégration de vidéos hébergées sur des sites tiers centralisateurs comme Youtube…

Hum… Je comprends pour pas mal de choses, mais pour les CDN je ne comprends pas. Les CDN indiquent les propriétés de mise en cache les plus longues possibles (un an). Les CDN ont affaire à des charges particulièrement monstrueuses. Si on prends des exemple de facebook ou google, si leur CDN sont visibles (qu'ils ont des noms de domaines dédiers) c'est pour réduire leur trafic. En effet si google utilisait google.com pour son CDN (et qu'il route ensuite la requête sur via le reste de l'URL par exemple), ton navigateur uploaderait les cookies de google. Si l'objectif de ce genre de services était de suivre les gens, ils le font vraiment mal (maximiser le cache navigateur et minimiser les données que tu envoie). Par contre il y a d'autres raisons qui font que ça apporte à google : google a besoin du web. Il faut que l'utilisation du web soit la plus logique, rapide, efficace possible, ça donne de l'importance à son navigateur, à son moteur de recherche, potentiellement à ses techno comme angular par exemple, ça donne de l'importance à sa plateforme de publicité,… Ça explique aussi tout le travail autour de TCP, de HTTP, du js et cette manière de vouloir faire pleins de choses en HTML5 quitte à laisser le w3c ou le whatwg derrière.

Bref tout ça pour dire les CDN en soit je ne vois pas bien le problème. Je me demande d'ailleurs si Lightbeam prend en compte le cache ou s'il regarde simplement les liens.

Répondre
#4  - antistress a dit :

Je comprends l'intérêt pour certains des CDN et le fait que tous les CDN ne sont pas obligés de se nommer quelquechose-cdn ou cdn-quelquechose si je comprends bien ton propos, mais je ne vois pas en quoi ça enlève l’intérêt pour certains de s'appuyer sur des CDN pour pister les internautes.
Ce risque est connu https://en.wikipedia.org/wiki/Content_delivery_network#Security_and_privacy
Et, de fait, de nombreux CDN servent effectivement à pister :
https://github.com/EFForg/privacybadger/issues/1598 (mais aussi https://github.com/EFForg/privacybadger/issues?q=is%3Aissue+cdn & https://github.com/disconnectme/disconnect-tracking-protection & https://github.com/mozilla-services/shavar-prod-lists).
L'avantage c'est que Lightbeam ne s'arrête pas au nom du domaine (quelquechose-cdn ou cdn-quelquechose) mais regarde effectivement les sites tiers qui suivent ta navigation.
Après chacun est libre de faire – ou non – confiance à des inconnus (notamment des sociétés commerciales dont ne nous sommes même pas les client·e·s)

Répondre
#5  - barmic a dit :

C'est intéressant. C'est dommage que les rapports de bug ne pointent pas l'explication de cloudflare.
https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies

C'est un point effectivement. J'ai personnellement une grande confiance en cloudflare (le modèle économique de cloudflare n'est pas celui de google).

Répondre
#6  - antistress a dit :

Écoute, je suis arrivé à la même conclusion que toi ! Suite à leur partenariat avec Mozilla et leur initiative récente sur les captchas pour se détacher de Google, j'ai lu leurs conditions d'utilisation (vite fait) et j'ai trouvé ça très propre. Ils ont vraiment l'air de faire un boulot de cdn, payé comme tel, sans chercher à gratter sur les à-côtés (vie privée). Je ne l'ai pas fait figurer dans ma liste de blocage :)

Répondre
#7  - antistress a dit :

Tiens, regarde ça : https://github.com/EFForg/privacybadger/issues/1237 !

Répondre
#8  - romainsphere a dit :

Je ne suis pas certain que l'on parle du même bloqueur.

Le TPRB de Icecat est mis à jour régulièrement, developpé par Searxes.
<a href="https://imgur.com/Dc8FqcK.png">
<img src="https://imgur.com/Dc8FqcK.png" />
</a>
On peut aussi bloquer par nom de domaine. Faire des listes blanches, noires, exporter ou importer les listes blancehes ou noires.

Répondre
#9  - antistress a dit :

Sur le lien que tu indiques, https://searxes.danwin1210.me/, conduit à https://danwin1210.me/hosting/ qui ne mentionne aucune extension pour Firefox. Il n'y a rien non plus à ce sujet sur son GitHub https://github.com/DanWin/. Et je ne trouve pas le pseudo danwin sur addons.mozilla.org (AMO) non plus. Le seul Third-party Request Blocker qui figure sur AMO est celui dont je parle avec méfiance plus haut…
Ni Wikipedia ni gnu.org ne mentionnent une telle extension dans IceCat (https://en.wikipedia.org/wiki/GNU_IceCat#Additional_security_features & https://www.gnu.org/software/gnuzilla/

Répondre
#10  - Denis a dit :

L'utilisation des containers sous Firefox est pas mal non plus. Un peu long à configurer !

Répondre
#11  - romainsphere a dit :

Je crois que tu pointes là les limites de la documentation faite par la communautée GNU. Cette dernière fournit des outils sans documentation!

Répondre
#12  - Bichon a dit :

Ces quelques discussions à propos des CDN principalement m'ont amené à me renseigner un peu plus sur la question du pistage des CDN. Par défaut je bloque tous les cookie tiers (jamais eu de problèmes) et ai une liste blanche avec Cookie AutoDelete, donc peu de soucis de ce côté là. J'ai Decentraleyes qui semble ne pas bloquer toutes les connexions vers Cloudflare et consorts d'après l'activité réseau (accessible sur Firefox en faisant Ctrl+Shift+E).
Un lien Wikipedia donné plus haut sur les risques de pistage des CDN expliquait que les requêtes envoyaient les referrer (site d'origine), or je ne le voyais pas dans mes requêtes à divers CDN. C'est là que je me suis souvenu d'options que j'avais modifié dans le about:config (toujours sur Firefox) afin de limiter les données transmises voire ne pas en envoyer. Pour ceux que ça intéresse je vous indique quelques paramètres modifiés qui jusqu'ici ne m'ont pas « cassés » de sites.
network.http.referer.defaultPolicy à 2, ça n'envoie plus le chemin complet dans le referer (par défaut à 3).
network.http.referer.trimmingPolicy à 1, ça n'envoie plus la chaine de requête (query string) dans le referer, peu importe l'origine (par défaut à 0).
network.http.referer.XOriginTrimmingPolicy à 2, ça n'envoie plus le chemin complet dans le referer, ça semble faire double emploi avec la première option, mais la première peut être outrepassée par les politiques(?) des sites (par défaut à 0).
Enfin, avec le suivant j'ai rencontré un seul problème en plusieurs années, ça faisait boguer l'interface de la box SFR, impossibilité de valider les options, ce paramètre est : network.http.referer.XOriginPolicy à 1, ça n'envoie un referrer que quand le domaine de base (deuxième niveau ?) est le même que la page visitée. C'est cette option qui fait que je n'envoie aucun referrer aux CDN et tous les sites externes aux sites que je visite. Par défaut elle est à 0.

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

NB : en publiant votre commentaire, vous acceptez qu'il soit placé sous la licence CC BY-SA comme indiqué aux conditions d'utilisation du site

Quelle est le quatrième caractère du mot kr0tlsvc ?