Posté par flagos .
Évalué à 0.
Dernière modification le 27 janvier 2021 à 15:59.
J’espère qu'il y aura des exceptions pour les sources considérées comme sures, comme jquery ou les polices google. Ce serait dommage de devoir recharger et stocker sur le disque quasiment toujours le même contenu a chaque site visite…
les sources considérées comme sures, comme jquery ou les polices google.
J'ai ri sur tes exemples pour "sûres", l'idée me semble bien d’empêcher ces entités de te tracer (et monétiser la chose).
Troll sur l'actu : moi, je trouve surtout rigolo que la moins (voire pas) de foule ne défende Google qui a construit son business model sur la monétisation de ces flux, comme quoi le business model à protéger est une excuse quand l'entité est considérée gentille…
Ce serait dommage de devoir recharger et stocker sur le disque quasiment toujours le même contenu a chaque site visite…
Perso je priorise la vie privée à ce petit gain de bande passante, qui est utile qu'à la première connexion sur un nouveau site et/ou le business model basé sur les données privées.
Posté par flagos .
Évalué à 1.
Dernière modification le 27 janvier 2021 à 19:57.
J'ai ri sur tes exemples pour "sûres", l'idée me semble bien d’empêcher ces entités de te tracer (et monétiser la chose).
Je pense que tu n'as pas compris le principe de ce traçage. Je t'invite à relire l'article. Google ne fait clairement pas ce genre de choses.
D'ailleurs je te fais remarquer que Google implemente le même truc dans Chrome, ce qui n'est pas compréhensible suivant ta lecture des choses… Bref, lis l'article si tu veux en savoir plus.
In fact, there are many different caches trackers can abuse to build supercookies. Firefox 85 partitions all of the following caches by the top-level site being visited: HTTP cache, image cache, favicon cache, HSTS cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authentication cache, Alt-Svc cache, and TLS certificate cache.
Justement l'article dit bien qu'on peut utiliser les polices de caractères pour tracer l'utilisateur, comme tout autre asset dans un cache d'ailleurs.
Et google ne se gène sûrement pas. Quel intérêt à mettre à disposition sinon.
D'ailleurs je te fais remarquer que Google implémente le même truc dans
Ca ne suffit pas. Il faut en plus ajouter une information à la volée dans la font ou l'image qui permet d'identifier l'utilisateur.
Unfortunately, some trackers have found ways to abuse these shared resources to follow users around the web. In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image.
Je peux me tromper, mais je ne pense pas que Google s'amuse à faire ce genre de trucs. Ca me semble bien trop risqué, ils en savent déjà bien assez sur nous par ailleurs.
Et google ne se gène sûrement pas. Quel intérêt à mettre à disposition sinon.
Faciliter le web un peu ouvert vs des réseaux sociaux fermés aux bots ?
Je peux me tromper, mais je ne pense pas que Google s'amuse à faire ce genre de trucs
Ca me semble bien trop risqué, …
La stratégie de Google est d'être présent partout : sur le mobile, sur le desktop, sur le mail, sur le web, la vidéo, le DNS, le cloud, les stats des sites, le search, les annonce publicitaires sur les sites des autres, le CDN (dont font+css+lib javascript), la maison, le liaison internet (aux US), la santé, les montres, la TV.
Donc je vois pas le "risque". Genre les gens accepteraient d'être pistés partout sauf quand leur navigateur télécharge une police de caractères ?
TLD+1 d'après cet article
TLD+1 ça veut dire que le cache "par site web" est le même pour "trucmuche.net" et "toto.trucmuche.net" mais pas pour "trucmuche.net" et "machin.com". Plus précisément, si ces trois sites pointent sur la même ressource "cdn.cloudflare.com/avatar32.jpg", cette ressource sera téléchargée deux fois : une fois pour "trucmuche.net" et "toto.trucmuche.net", une fois pour "machin.com".
Ce que je voulais dire, c'est que rien ne te dit que quand tu visites avec GoogleChrome le site "machin.com" qui utilise une ressource de "fonts.google.com/bla" et le site "bidule.org" qui utilise la même ressource de "fonts.google.com/bla", le navigateur applique bien la même séparation des caches.
Google s'estime souvent au dessus de ses propres lois : genre on vous protège des méchants mais nous on sais bien qu'on est pas méchants.
Donc je vois pas le "risque". Genre les gens accepteraient d'être pistés partout sauf quand leur navigateur télécharge une police de caractères ?
En fouillant un peu, Google ne recommande même plus de passer par leur serveur et de hoster leur font… Justement à cause du cache partitioning.
Donc je résume la situation :
- Google bloque sur Chrome le principal avantage d'avoir un cdn
- Google déconseille son usage aux développeurs.
Mais, de toute évidence, pour toi ils s'en servent pour traquer les gens.
Ce que je voulais dire, c'est que rien ne te dit que quand tu visites avec GoogleChrome le site "machin.com" qui utilise une ressource de "fonts.google.com/bla" et le site "bidule.org" qui utilise la même ressource de "fonts.google.com/bla", le navigateur applique bien la même séparation des caches.
Ca peut se tester puisque tu n'as pas confiance… C'est pas comme si tu avais des millions de développeurs qui analysent les temps de réponses sur leur site a chaque instant.
Google ne fait clairement pas ce genre de choses.
D'ailleurs je te fais remarquer que Google implemente le même truc dans Chrome, ce qui n'est pas compréhensible suivant ta lecture des choses…
Logique: Google peut te suivre via Chrome et ses autres services. Il a donc tout intérêt à défoncer les autres méthodes pour avoir le monopole du tracking.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Je viens de vérifier sur le site phys.org qui utilise les polices distantes de google, j'ai bien deux requêtes GET dans la console du navigateur (ctrl + maj +j) :
Alors que j'ai bien décoché l'option dans Firefox 78 "Autoriser les pages web à utiliser leurs propres polices plutôt que celles choisies ci-dessus" et dans uBlock Origin, activé l'option bloquer les polices d'écriture distantes.
Qu'à cela ne tienne, cette utilisation de police distante passe par un script et donc n'est bloquée qu'en bloquant le script correspondant fonts.googleapis.com toujours avec uBlock origin ou autre bloqueur de script.
Dernière touche, le blocage ou non de ces polices ne change quasiment pas l'affichage ou l'esthétique du site, même après purge du cache. Autrement dit du trafic web pour rien. C'est vraiment ridicule.
Perso je priorise la vie privée à ce petit gain de bande passante
Parfaitement d’accord, d’autant plus que l’excuse de la bande passante ne me parait pas très pertinente, sachant que la solution actuelle pour éviter ce type de pistage, c’est les onglets en navigation privée où les profils de navigation qui ne conservent ni historique ni cache. Au moins, avec le système de caches distincts, on évite de re-télécharger tout le site à chaque visite.
Perso je priorise la vie privée à ce petit gain de bande passante
Parfaitement d’accord, d’autant plus que l’excuse de la bande passante ne me parait pas très pertinente
C'est encore pire que ça : comment pourrait-on économiser de la bande-passante en téléchargeant des fontes chez Google… comparé à ne pas télécharger ces même fontes ?
En bloquant tous ces machins, on gagne en vie privée et en bande-passante.
Posté par steph1978 .
Évalué à 3.
Dernière modification le 27 janvier 2021 à 23:23.
C'est pas un peu du flan comme protection sachant qu'un site qui veut traquer des utilisateurs peut toujours le faire à partir de l'IP ?
Je pense que la meilleure protection est le blocage à la source, par exempla avec µblock0. Et que Firefox 85 apporte cette fonctionnalité parce que les autres, safari et chrome l'on déjà et donc qu'ils ne peuvent pas donner l'image d'être à la traîne.
L'IP n'est pas très fiable. Il peut y avoir beaucoup d'utilisateurs derrière une adresse IP (bureau par exemple). Un utilisateur, au cours de sa journée, va passer sur différents réseaux (mobile, maison, bureau) et donc différentes IP.
# En français :
Posté par remico . Évalué à 3. Dernière modification le 27 janvier 2021 à 09:18.
Un article en français qui reprend à peu près l'original :
https://web.developpez.com/actu/312007/Firefox-85-debarque-avec-le-blocage-des-supercookies-la-suppression-du-support-de-Flash-sans-possibilite-de-reactivation-et-apporte-des-ameliorations-au-gestionnaire-de-mots-de-passe/
# jquery
Posté par flagos . Évalué à 0. Dernière modification le 27 janvier 2021 à 15:59.
J’espère qu'il y aura des exceptions pour les sources considérées comme sures, comme jquery ou les polices google. Ce serait dommage de devoir recharger et stocker sur le disque quasiment toujours le même contenu a chaque site visite…
[^] # Re: jquery
Posté par Zenitram (site web personnel) . Évalué à 5.
J'ai ri sur tes exemples pour "sûres", l'idée me semble bien d’empêcher ces entités de te tracer (et monétiser la chose).
Troll sur l'actu : moi, je trouve surtout rigolo que la moins (voire pas) de foule ne défende Google qui a construit son business model sur la monétisation de ces flux, comme quoi le business model à protéger est une excuse quand l'entité est considérée gentille…
Perso je priorise la vie privée à ce petit gain de bande passante, qui est utile qu'à la première connexion sur un nouveau site et/ou le business model basé sur les données privées.
[^] # Re: jquery
Posté par flagos . Évalué à 1. Dernière modification le 27 janvier 2021 à 19:57.
Je pense que tu n'as pas compris le principe de ce traçage. Je t'invite à relire l'article. Google ne fait clairement pas ce genre de choses.
D'ailleurs je te fais remarquer que Google implemente le même truc dans Chrome, ce qui n'est pas compréhensible suivant ta lecture des choses… Bref, lis l'article si tu veux en savoir plus.
[^] # Re: jquery
Posté par steph1978 . Évalué à 5.
Justement l'article dit bien qu'on peut utiliser les polices de caractères pour tracer l'utilisateur, comme tout autre asset dans un cache d'ailleurs.
Et google ne se gène sûrement pas. Quel intérêt à mettre à disposition sinon.
Vers tous les domaines même les siens ?
[^] # Re: jquery
Posté par flagos . Évalué à 0.
Ca ne suffit pas. Il faut en plus ajouter une information à la volée dans la font ou l'image qui permet d'identifier l'utilisateur.
Je peux me tromper, mais je ne pense pas que Google s'amuse à faire ce genre de trucs. Ca me semble bien trop risqué, ils en savent déjà bien assez sur nous par ailleurs.
Faciliter le web un peu ouvert vs des réseaux sociaux fermés aux bots ?
TLD+1 d'après cet article :
https://developers.google.com/web/updates/2020/10/http-cache-partitioning#what_is_the_impact_of_this_behavioral_change
[^] # Re: jquery
Posté par steph1978 . Évalué à 5.
La stratégie de Google est d'être présent partout : sur le mobile, sur le desktop, sur le mail, sur le web, la vidéo, le DNS, le cloud, les stats des sites, le search, les annonce publicitaires sur les sites des autres, le CDN (dont font+css+lib javascript), la maison, le liaison internet (aux US), la santé, les montres, la TV.
Donc je vois pas le "risque". Genre les gens accepteraient d'être pistés partout sauf quand leur navigateur télécharge une police de caractères ?
TLD+1 ça veut dire que le cache "par site web" est le même pour "trucmuche.net" et "toto.trucmuche.net" mais pas pour "trucmuche.net" et "machin.com". Plus précisément, si ces trois sites pointent sur la même ressource "cdn.cloudflare.com/avatar32.jpg", cette ressource sera téléchargée deux fois : une fois pour "trucmuche.net" et "toto.trucmuche.net", une fois pour "machin.com".
Ce que je voulais dire, c'est que rien ne te dit que quand tu visites avec GoogleChrome le site "machin.com" qui utilise une ressource de "fonts.google.com/bla" et le site "bidule.org" qui utilise la même ressource de "fonts.google.com/bla", le navigateur applique bien la même séparation des caches.
Google s'estime souvent au dessus de ses propres lois : genre on vous protège des méchants mais nous on sais bien qu'on est pas méchants.
[^] # Re: jquery
Posté par flagos . Évalué à 1.
En fouillant un peu, Google ne recommande même plus de passer par leur serveur et de hoster leur font… Justement à cause du cache partitioning.
Donc je résume la situation :
- Google bloque sur Chrome le principal avantage d'avoir un cdn
- Google déconseille son usage aux développeurs.
Mais, de toute évidence, pour toi ils s'en servent pour traquer les gens.
Ca peut se tester puisque tu n'as pas confiance… C'est pas comme si tu avais des millions de développeurs qui analysent les temps de réponses sur leur site a chaque instant.
https://www.zdnet.com/article/chromes-new-cache-partitioning-system-impacts-google-fonts-performance/
[^] # Re: jquery
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Logique: Google peut te suivre via Chrome et ses autres services. Il a donc tout intérêt à défoncer les autres méthodes pour avoir le monopole du tracking.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: jquery
Posté par remico . Évalué à -1.
Je viens de vérifier sur le site phys.org qui utilise les polices distantes de google, j'ai bien deux requêtes GET dans la console du navigateur (ctrl + maj +j) :
https://fonts.googleapis.com/css?family=Roboto:400,500,700
https://fonts.googleapis.com/css?family=Open+Sans:400,400i,700
Alors que j'ai bien décoché l'option dans Firefox 78 "Autoriser les pages web à utiliser leurs propres polices plutôt que celles choisies ci-dessus" et dans uBlock Origin, activé l'option bloquer les polices d'écriture distantes.
Qu'à cela ne tienne, cette utilisation de police distante passe par un script et donc n'est bloquée qu'en bloquant le script correspondant fonts.googleapis.com toujours avec uBlock origin ou autre bloqueur de script.
Dernière touche, le blocage ou non de ces polices ne change quasiment pas l'affichage ou l'esthétique du site, même après purge du cache. Autrement dit du trafic web pour rien. C'est vraiment ridicule.
[^] # Re: jquery
Posté par jyes . Évalué à 3.
Parfaitement d’accord, d’autant plus que l’excuse de la bande passante ne me parait pas très pertinente, sachant que la solution actuelle pour éviter ce type de pistage, c’est les onglets en navigation privée où les profils de navigation qui ne conservent ni historique ni cache. Au moins, avec le système de caches distincts, on évite de re-télécharger tout le site à chaque visite.
[^] # Re: jquery
Posté par vv222 . Évalué à 4.
C'est encore pire que ça : comment pourrait-on économiser de la bande-passante en téléchargeant des fontes chez Google… comparé à ne pas télécharger ces même fontes ?
En bloquant tous ces machins, on gagne en vie privée et en bande-passante.
# du flan ?
Posté par steph1978 . Évalué à 3. Dernière modification le 27 janvier 2021 à 23:23.
C'est pas un peu du flan comme protection sachant qu'un site qui veut traquer des utilisateurs peut toujours le faire à partir de l'IP ?
Je pense que la meilleure protection est le blocage à la source, par exempla avec µblock0. Et que Firefox 85 apporte cette fonctionnalité parce que les autres, safari et chrome l'on déjà et donc qu'ils ne peuvent pas donner l'image d'être à la traîne.
[^] # Re: du flan ?
Posté par flagos . Évalué à 6.
L'IP n'est pas très fiable. Il peut y avoir beaucoup d'utilisateurs derrière une adresse IP (bureau par exemple). Un utilisateur, au cours de sa journée, va passer sur différents réseaux (mobile, maison, bureau) et donc différentes IP.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.