L'EFF propose sa propre version de Do Not Track et finalise son Privacy Badger

L’EFF propose sa propre version de Do Not Track et finalise son Privacy Badger

Deux lames pour un même but

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

07/08/2015 11 minutes
36

L'EFF propose sa propre version de Do Not Track et finalise son Privacy Badger

L’EFF fait actuellement la promotion de sa propre formule du Do Not Track. Aidée de plusieurs acteurs, comme AdBlock ou Medium, la fondation espère réussir là où le W3C a pour le moment échoué. Techniquement, les solutions sont pourtant assez proches, mais l’objectif est cette fois de fédérer pour plaire au plus grand nombre, notamment aux éditeurs.

La fonctionnalité Do Not Track a été présentée pour la première en janvier 2010 par Mozilla. Il s’agit d’un mécanisme automatisé permettant à l'internaute d'indiquer aux sites qu'il ne souhaite pas être suivi dans ses déplacements. Un comportement très courant, qui permet par exemple aux régies de placer du contenu lié à vos précédentes visites ou recherche dans les espaces publicitaires que vous rencontrez.

Pas étonnant donc que vous observiez sur un réseau social une promotion sur un voyage pour lequel vous vous êtes renseigné la veille, ou qu'une boutique vous poursuive sur plusieurs sites avec une promotion sur l'aspirateur que vous avez acheté il y a déjà trois semaines. Il existe même des champions en la matière, comme Facebook, Google et Twitter (voir notre article) ou encore le français Criteo.

L'échec d'un standard qui n'est jamais parvenu au consensus

Le problème de cette fonctionnalité est qu’en dépit d’un véritable engouement des éditeurs de navigateurs, le signal émis a été peu suivi. Le W3C s’est emparé de la question pour harmoniser les pratiques, mais tout le monde n'est pas enclin aux changements nécessaires, notamment du côté des publicitaires.

Microsoft avait d’ailleurs en partie accéléré la chute de ce standard en formation en décidant d’activer le DNT par défaut dans Internet Explorer 10, à l’arrivée de Windows 8. De quoi cristalliser les positions. C'était aussi un problème par rapport à l'esprit même de cette fonctionnalité. En effet, le standard impose qu'elle soit activée manuellement, suite à un choix volontaire de l’utilisateur. L’éditeur est donc revenu sur sa position depuis.

De fait, la technologie est pratiquement à l’abandon, de trop nombreux acteurs ayant claqué la porte des négociations. Des annonces ont suivi chez certains pour annoncer qu’ils ne prendraient plus en compte le signal. Le problème ne réside pas dans la technique – le standard est relativement simple à implémenter – mais dans ce qu’il implique, puisqu’on parle bien ici de pertes de revenus liés à l’extrême personnalisation des contenus publicitaires, source de financement pour de nombreux acteurs.

L'EFF reprend l'existant et en fait varier les modalités d'application

Contre toute attente, l’EFF a décidé d’y aller de son propre projet alternatif. Les fondations techniques sont exactement les mêmes et reprennent, pour la partie concernant les navigateurs, le travail déjà réalisé par le W3C sur la partie « Tracking Preference Expression ». L’idée est donc la même : le navigateur, une fois l’option cochée, envoie un signal au serveur pour lui indiquer que l’internaute ne veut pas être suivi, et que des publicités génériques doivent lui être présentées.

Mais comment s’assurer alors que tous les acteurs de cette chaine respectent cette demande ? Tout d'abord en revoyant partiellement la partie « Tracking Compliance and Scope » du standard. Un choix d'autant plus étonnant que celle-ci fait actuellement l'objet d'un dernier appel à commentaires, en cours jusqu'au 7 octobre.

Pour cela, l'EFF s'est focalisée sur deux aspects en particulier. D’une part, la poursuite d’un but réaliste : les annonceurs ne renonceront jamais entièrement au tracking, pour la simple et bonne raison qu’il est souvent nécessaire de personnaliser les contenus. Par contre, il est important de pouvoir certifier à l’utilisateur que lorsque le signal est accepté, il est bel et bien pris en compte.

Dans sa version, cela se fera par l’intermédiaire d’un fichier « dnt-policy.txt » que les éditeurs peuvent mettre en place, indiquant qu’un domaine en particulier respecte ce choix et les règles qu'il respecte. Des règles plus strictes que celles imposées actuellement par le standard du W3C, avec moins d'exceptions. Les éditeurs se refusent ainsi à préserver un identifiant unique, à ne pas garder les logs en contenant plus de 10 jours, à s'assurer que rien n'est transmis à des domaines tiers, à informer les utilisateurs lorsqu'ils sont concernés par une demande de la justice ou encore à réviser tous les 12 mois que ces règles sont bien respectées.

Une méthode qui concerne avant tout les domaines fournissant des publicités, widgets, images, scripts et autres hyperliens tiers. Tout ce qui fonctionne à base de HTTP ou accepte d’en lire les en-têtes est théoriquement compatible. Attention tout de même, il faudra veiller à ne pas exploiter d'intégration tierce qui va à l'encontre des règles, ce qui peut vite poser problème pour les sites embarquant des tweets ou des vidéos YouTube par exemple.

De même pour les sites qui n'utilisent pas de publicité ciblée, mais dont la régie exploite les données pour un ciblage des utilisateurs. L'EFF précise alors dans sa FAQ que l'éditeur doit s'arranger pour que le tracking soit rendu inopérant ou qu'il utilise des intégrations qui respectent elle-même sa DNT Policy. Pas toujours si simple.

Tout acteur désireux de mieux respecter les choix de l’utilisateur en matière de vie privée pourra déclarer précisément quels domaines et sous-domaines acceptent ou pas de prendre en compte ce réglage. L’essentiel est alors d’indiquer clairement à l’utilisateur si son choix est accepté ou refusé, ce qui était jusqu’à présent impossible (rien n’étant prévu pour transmettre cette information).

Quel intérêt ? Un service quelconque pourrait par exemple collecter des informations sur ce que vous faîtes, sans pour autant les utiliser pour personnaliser des contenus ou des espaces publicitaires, et sans que cela soit visible.

Un consensus dur, mais qui doit permettre une entente

La réflexion autour du DNT à l’EFF provient essentiellement d’un constat faisant consensus chez plusieurs acteurs réunis pour l’occasion, notamment Disconnect, DuckDuckGo, AdBlock (à ne pas confondre avec Adblock Plus), Medium et MixPanel. Casey Oppenheim, PDG de Disconnect, explique la situation :

« L’échec de l’industrie publicitaire et des groupes de défense de la vie privée à trouver un compromis sur le DNT a conduit à une explosion du blocage des publicités, d’énormes pertes pour les sociétés Internet qui dépendent de ces revenus, et des méthodes de plus en plus insidieuses pour traquer les utilisateurs et l’affichage des publicités en ligne. Notre espoir est que cette nouvelle approche du DNT protègera le droit de consommateur à la vie privée et incitera les annonceurs à respecter le choix des utilisateurs, ouvrant la voie à une cohabitation de la vie privée et de la publicité. »

Une déclaration qui semble tout de même oublier que la problématique des bloqueurs de publicité ne provient pas que de la question du ciblage, mais surtout des abus importants et répétés des éditeurs et de leurs régies en terme de volume, d'envahissement et de pratiques détestables (comme la lecture automatique de vidéos qui débarquent de nulle part).

Mais l'émergence d'un consensus pourrait être à l'avantage d'un nombre beaucoup plus important d’acteurs : les internautes verraient leur vie privée mieux protégée, et les annonceurs auraient moins de publicités bloquées (d’où la participation d’Adblock).

De quoi poser problème à ceux qui veulent vendre des espaces par millions de pages vues selon des critères de ciblage ultra-précis, mais qui va dans le sens de pratiques bien plus raisonnables, visant un juste milieu de toutes parts. Reste à convaincre l'ensemble de la chaîne. Dans sa FAQ, l’EFF indique d’ailleurs clairement que la méthode proposée n’est pas compatible avec les entreprises qui veulent dans tous les cas continuer à utiliser un tracking permanent.

Difficile pour l’instant de savoir si une telle initiative peut fonctionner et si d'autres sites pourront facilement sauter le pas, et décider de jouer le jeu. À voir la capacité de certains à imposer cookies et autres fingerprints par dizaines, et ce malgré les règles en la matière (voir notre article), on peut aisément penser que la route sera encore longue. On peut aussi se demander ce qu'il adviendra si un site indique respecter le choix de l'utilisateur mais ne le fait pas.

La fondation est en tout cas clairement décidée à fédérer le plus d’acteurs possibles en proposant une solution où chacun peut y trouver son compte, ou presque. Un consensus qui pourrait fonctionner et court-circuiter la recherche perpétuelle de nouveaux moyens toujours plus intrusifs pour collecter des données et afficher coûte que coûte de la publicité. D'autres pourraient suivre, comme Mozilla dont on s'étonne d'ailleurs qu'il ne soit pas déjà de la partie. On regrettera également que cette bataille de l'EFF se fasse hors du standard du W3C, ce qui risque de mener à des confusions. D'autant plus que le dernier appel à commentaires du TCS n'est pas encore terminé.

Tracking : l'extension Privacy Badger arrive dans une version finale renforcée

Dans un autre registre, la fondation vient de publier la version 1.0 de son extension Privacy Badger. Dédiée à Chrome et Firefox, elle est destinée à repérer l’ensemble des trackers sur un site web et à bloquer de manière automatique ou manuelle tous ceux que l’extension estime trop intrusive pour la vie privée de l’utilisateur.

Cette version 1.0 est l’aboutissement d’une longue phase de développement. Les moutures alpha et bêta avaient, selon la fondation, été testées par plus de 250 000 utilisateurs. La finalisation amène avec elle des améliorations notamment sur la capacité à détecter les fingerprints, mais aussi les super-cookies (voir cet exemple). Ces derniers sont pour rappel des versions survitaminées des cookies classiques, qui sont plus difficiles à supprimer, permanents et peuvent contenir des informations beaucoup plus nombreuses, notamment tout ou partie de votre historique web. 

Privacy Badger est en outre traduit dans plusieurs nouvelles langues, dont le français. Une traduction qui reste encore assez approximative parfois. Il en est de même pour l'extension elle-même qui détecte parfois des éléments qui ne sont pas forcément des sources de tracking. Si ses options et sa façon de bloquer ou non un domaine de manière plus ou moins complète sont appréciables, les adeptes d'outils du même genre comme Ghostery pourraient décider d'attendre encore un peu avant de changer de crèmerie.

Mais ici, la fondation expose une nouvelle fois sa vision de ce que devrait être le web et le respect de la vie privée. Elle indique ne pas être contre les entreprises qui cherchent à bâtir un réseau publicitaire, mais ces contenus ne peuvent pas se faire au détriment de l’internaute et via une « approche sans aucun consensus ». Et d’enfoncer le clou : « Jusqu’à ce que l’industrie du pistage en ligne change ses méthodes, la seule option pour les utilisateurs est de se protéger eux-mêmes en installant des outils tels que Privacy Badger ».

Et puisque l’EFF parle de consensus, Privacy Badger est justement conçue pour « travailler en tandem » avec sa nouvelle version du DNT. En clair, si l’extension détecte que les domaines contactés prennent en charge le signal correctement et définissent clairement ce qui va être fait, elle les débloque. Seront concernés évidemment les collectes de données anonymes et les publicités non-ciblées. Pour les autres, la situation sera toute aussi claire : ils seront bloqués.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

L'échec d'un standard qui n'est jamais parvenu au consensus

L'EFF reprend l'existant et en fait varier les modalités d'application

Un consensus dur, mais qui doit permettre une entente

Tracking : l'extension Privacy Badger arrive dans une version finale renforcée

Commentaires (36)


Rien qu’en lisant le sous-titre, j’étais sûr que l’auteur en serait Vincent qui ne jure que par les doubles lames <img data-src=" />


privacy badger et no-script sont intéressants ne serait-ce que par le fait de faire prendre conscience du nombre de noms de domaines auxquels on se trouve connecté en consultant une seule page web.


&nbsp;Bof, Do Not Track part d’un bon sentiment mais n’est absolument pas applicable dans les faits. Si l’on s’attend à ce que les sites web (surtout commerciaux) respectent d’eux même la vie privée des internautes…

&nbsp;



&nbsp;Privacy Badger, uBlock, noscript, self destructing cookie et les autres extensions côté client sont une approche beaucoup plus réaliste.

&nbsp;

&nbsp;Une autre solution serait de restreindre (sous forme de norme W3C par exemple) certains fonctionnement.

Interdire (aux navigateurs) les scripts/requête d’une page vers d’autres sites, faire un peu comme uBlock/noscript mais pour tous le monde et par défaut. C’est sur ça peut être vu comme une régression, on pourra plus inclure de scripts FB/twitter et autres merdes du genre dans un site web, mais quand on regarde ce que permette de faire les sites web à cause de la permissivité des normes du web, ce serait une solution (radicale certes) pour que l’internaute moyen retrouve un minimum de sécurité sur internet.

&nbsp;

&nbsp;Mais quand on voit que les cookies tiers sont toujours autorisés par défauts sur Firefox, probablement pour rester compatible avec des sites qui chient sur leurs utilisateurs, il reste du chemin à faire…


Perso je ne vis pas dans la même salle de bain pour tout savoir du rasage préféré, mais j’apprécie la news et maintenant j’ai un gros blaireau installé dans mon FF. D’autant que je me suis rendu compte hier que sous Win10 les cookies tiers sont OK par défaut, y a même pas la base du privacy…


Tout bloquer sans aucune distinction n’est pas une solution non plus, d’où l’intérêt d’approches plus subtiles à travers DNT, la CNIL, etc. M’enfin il est trop tard pour les comportements raisonnés, et ce des deux côtés, ça ne changera plus qu’à long terme maintenant.


Y a Lightbeam ausi qui est sympa pour avoir une représentation visuelle de la galaxie de sites qu’on viste juste avec un clic.https://www.mozilla.org/en-US/lightbeam/


Pourquoi pas ? Les seuls cas de figure où une page web nécessitent de manière obligatoire des appels à des ressources extérieurs sont les cas de tracking. Pour les utilisations de ressources externe, par exemple intégrer une carte OSM, il serait possible technologiquement que ce soit géré côté serveur, plus lourd certes, mais possible.

&nbsp;



Alors oui il faudra intégrer les scripts de police, jquery à ses propres serveurs, du coup plus possible d’alléger son serveur en faisant aller taper des ressources externes au client, et ? C’est un moindre mal je pense.

&nbsp;



D’ailleurs David, j’avais demandé pourquoi vous intégriez à NXi des ressources de msecdn et visualstudio (coucou MS) ? Je peux comprendre que vous aillez vos propres besoin de tracking et de déporter la charge de vos serveurs mais alors pourquoi faire une option «désactiver tous les trackers» pour les abonnés ?


Depuis que Privacy Badger est passé à sa version “finale” sans rien me demander (<img data-src=" /> , je sais bien que c’est un réglage dans FF <img data-src=" /> ), j’ai ce bug (Win 10, Firefox 39.0.3 et une crâlée d’add-ons).



Je m’étais habitué à la version bêta (à checker chaque fois que des images n’apparaissaient pas dans un site) mais là c’est carrément inutilisable (et ça doit bien continuer à bloquer certaines images).


Je viens de voir que vous veniez tout juste de supprimer le script visualstudio surement présent dans vos pages par erreur. Quelle réactivité <img data-src=" />

&nbsp;



J’en profite aussi, sur la page de gestion du compte NXi, pour un abonné avec l’option «désactiver tous les trackers», le script&nbsp; google analytics est toujours présent…

&nbsp;



Merci à l’équipe de faire autant d’efforts pour respecter les internautes (ou au moins ses abonnés) même si je comprends bien que le tracking, même minimum est une nécessité pour beaucoup de sites.




Dans sa version, cela se fera par l’intermédiaire d’un fichier « dnt-policy.txt » que les éditeurs peuvent mettre en place, indiquant qu’un domaine en particulier respecte ce choix et les règles qu’il respecte.





Plus simple: je propose que les editeurs qui sont gentils ajoutent un header “GoodGuy” à leurs contenus, et ceux qui sont méchants ajoutent un header “BadGuy”.



Après tout, c’est juste une histoire de confiance.








127.0.0.1 a écrit :



Plus simple: je propose que les editeurs qui sont gentils ajoutent un header “GoodGuy” à leurs contenus, et ceux qui sont méchants ajoutent un header “BadGuy”.



Après tout, c’est juste une histoire de confiance.





+1



Ce sont nos outils de dév ;) Ca doit venir de là, mais il n’y a pas de raison particulière que ce soit présent hors périodes spécifiques.

&nbsp;

Pour le reste, un tracking peut ne pas dépendre de ressources tierces ou être utile (voir le cas des analytics par exemple). Tout bazarder pour résoudre le souci c’est comme miser sur adblock pour résoudre la problématique de la pub en ligne : à court terme c’est cool, à plus long terme ça se paie d’une manière ou d’une autre.

&nbsp;

Pour analytics pas normal, remonte le souci via le formulaire tech avec capture si tu peux, que l’équipe regarde ça :&nbsp;

&nbsp;

&nbsphttp://www.nextinpact.com/a-propos.htm#nouscontacter_section


C’est un peu le souci, surtout que l’EFF précise qu’elle n’a pas de moyen de vérifier ou d’agir. Après, un site qui place ce fichier et propose un tracker, ce sera dur de faire croire que c’était de bonne foi <img data-src=" />


Tu fais comment sur le site de la Police ?



<img data-src=" />


Dans le cas d’OSM, mon site l’utilise et OSM ne dépose pas de cookie sur le client. Les seules infos transmises sont celles de la requêtes GET normalement : soit ton IP, ton user agent et le referer.



Ensuite, c’est une question de confiance envers OSM <img data-src=" />



Pour l’instant, c’est chaud quand même de stocker soit même l’ensemble des cartes (44 Go en XML ou 29 Go en PBF, à mettre à jour régulièrement <img data-src=" /> <img data-src=" />)


NoScript mon meilleur ami, mon faiseur d’extrême paranoïa et mon poids mort pour voir certain contenu <img data-src=" />








David_L a écrit :



Pour le reste, un tracking peut ne pas dépendre de ressources tierces ou être utile (voir le cas des analytics par exemple). Tout bazarder pour résoudre le souci c’est comme miser sur adblock pour résoudre la problématique de la pub en ligne : à court terme c’est cool, à plus long terme ça se paie d’une manière ou d’une autre.



Exactement, les gens doivent payer, mais pas en vendant leur vie privée, j’ai moi même le fait choix de payer, en argent comme pour Nxi&nbsp; et plein d’autres sites/journaux/blogs… Je souhaite que tous le monde paye de leur poche pour soutenir/financer les projets/personnes qui leur apporte. Que tous le monde utilise uBlock/noscript&nbsp; (adblock c’est dépassé <img data-src=" />) et que les sites/journaux/blogs utilisant le modèle économique lié à la publicité s’adaptent ou crèvent !

&nbsp;

Petits conseils de lecture en passant (Oui du même mec, mais ploum aborde les différents aspects du problème pub/presse/payer sur le web, &nbsp; avec des solutions pertinentes):



&nbsp;&nbsp;

https://ploum.net/ce-blog-est-payant/

https://ploum.net/la-mort-de-la-presse-tant-mieux/

&nbsp;



Oui il faudrait tout «bazarder», un «noscript» pour les ressources externes par défaut et dans tous les navigateurs, plus de cookies tiers, plus de plugins, plus de DRM (merci le W3C pour avoir fait l’immense connerie de standardiser une norme de DRM…).

&nbsp;

Mais je sais, on peut rêver, surtout avec l’arrivée des sites propriétaires et encore moins transparent grâce aux DRM et Bytecodes généralisés chez tous le monde histoire d’aller plus loin dans l’intrusion de la vie privée…

&nbsp;





David_L a écrit :



Ce sont nos outils de dév ;) Ca doit venir de là, mais il n’y a pas de raison particulière que ce soit présent hors périodes spécifiques.





Vous utilisez visualstudio ?&nbsp;:eek:&nbsp;&nbsp; Et le script msecdn c’est quoi ? J’ai l’impression que le site est entièrement fonctionnel sans que ça soit activé, ce n’est donc pas un cdn. Faudrait peut être penser à faire le ménage non ? Ça fait quelques mois que je vous ai signalé le problème, sur le forum, dans un email… Je remonte les soucis avec ton lien merci.









John Shaft a écrit :



Dans le cas d’OSM, mon site l’utilise et OSM ne dépose pas de cookie sur le client. Les seules infos transmises sont celles de la requêtes GET normalement : soit ton IP, ton user agent et le referer.



Ensuite, c’est une question de confiance envers OSM <img data-src=" />



Pour l’instant, c’est chaud quand même de stocker soit même l’ensemble des cartes (44 Go en XML ou 29 Go en PBF, à mettre à jour régulièrement <img data-src=" /> <img data-src=" />)





Dans ton cas d’OSM et dans ce que je propose (noscript par défaut) on peut trouver des solutions. J’en imagine déjà 2 qui peuvent marcher et être utilisé en même temps.



On peut imaginer un protocole asynchrone qui ferait que sur ton site, le client requête les données d’OSM à travers ton serveur. OSM pourrait créer des scripts pour établir un protocole propre à son site pour que le client face une requête. Le client ferait donc une requete OSM vers ton serveur, ton serveur la traite l’envoie au site d’OSM. OSM répond à ton serveur, ton serveur répond au client. Possible.



Évidement cette solution ferait fuir les webmasters qui aiment bien déporter un max la charge de leurs serveurs sur d’autres sites même pour un vieux jquery ou une police à la con…

D’où ma deuxième solution qui pourrait être combinée à la première : Les scripts/modules de sites externes pourraient être utilisé mais non par défaut, seulement à la demande explicite de l’utilisateur. Un peu ce que fait noscript en fait, mais on peut imaginer un truc plus propre, et surtout l’essentiel :&nbsp;que ce soit par défaut et en standard, pourquoi pas une norme du html5 type &lt;extern-module&gt;&lt;/…&gt; qui s’active en un clic avec une demande de confirmation.



Tout est possible.









marba a écrit :



Évidement cette solution ferait fuir les webmasters qui aiment bien déporter un max la charge de leurs serveurs sur d’autres sites même pour un vieux jquery ou une police à la con…







Perso, mon serveur en branle pas une de la journée, donc un peu plus de charge… Changera pas grand chose <img data-src=" />



Faire faire les requêtes par le serveur, pourquoi pas. Ça ferait un script un peu plus lourd, mais pas la mort à mon avis. Et la charge réseau (dans le cas d’OSM) n’est pas des plus lourdes non plus (les tuiles des cartes sont des PNG de moins de 45-50 ko et les tuiles initiales à afficher peuvent se mettre en cache). Faudrait prendre le code source de Leaflet (c’est lui le coupable dans mon cas) et voir ce qu’il est possible d’en faire.



Si y a des spécialistes du javascript dans les parages <img data-src=" />









John Shaft a écrit :



Perso, mon serveur en branle pas une de la journée, donc un peu plus de charge… Changera pas grand chose <img data-src=" />



Faire faire les requêtes par le serveur, pourquoi pas. Ça ferait un script un peu plus lourd, mais pas la mort à mon avis. Et la charge réseau (dans le cas d’OSM) n’est pas des plus lourdes non plus (les tuiles des cartes sont des PNG de moins de 45-50 ko et les tuiles initiales à afficher peuvent se mettre en cache). Faudrait prendre le code source de Leaflet (c’est lui le coupable dans mon cas) et voir ce qu’il est possible d’en faire.



Si y a des spécialistes du javascript dans les parages <img data-src=" />





Je ne suis pas un expert OSM même si j’admire le projet (je me suis jamais penché dessus du côté dev) mais il est pas possible d’avoir carrément toutes les données en vectoriel (pour la bande passante) ?



Tout en vectoriel pas sûr. Vu les données qu’ils diffusent, il faut créer l’image soit même. Ceci dit, en France notamment, les données cadastrales sont récupérables en raster et en vectoriel (si j’en crois le wiki français)



EDIT : les mecs d’OSM France était passé à Pas Sage en Seine il y a quelque temps. Faudrait que je mate la conf à l’occasion <img data-src=" />


Y’a aussi gogol analytics sur forum.nextinpact.com au passage.








John Shaft a écrit :



Perso, mon serveur en branle pas une de la journée, donc un peu plus de charge… Changera pas grand chose <img data-src=" />



Faire faire les requêtes par le serveur, pourquoi pas. Ça ferait un script un peu plus lourd, mais pas la mort à mon avis. Et la charge réseau (dans le cas d’OSM) n’est pas des plus lourdes non plus (les tuiles des cartes sont des PNG de moins de 45-50 ko et les tuiles initiales à afficher peuvent se mettre en cache). Faudrait prendre le code source de Leaflet (c’est lui le coupable dans mon cas) et voir ce qu’il est possible d’en faire.



Si y a des spécialistes du javascript dans les parages <img data-src=" />







J’ai regardé vite fait, Leaflet permet de définir l’url pour choper les tiles donc il suffit de faire un wrapper côté serveur :




  • Leaflet requête ton serveur pour les images

  • sur ton serveur, tu fais juste un GET vers OSM pour récupérer la bonne image selon les paramètres passés

  • tu renvoies l’image en question (tu peux stocker temporairement ou autre, c’est selon)



    C’est juste quelques lignes côté serveur, par contre le nombre de requêtes par client risque d’augmenter nettement.



Ah bin du coup, j’ai trouvé comment héberger son propre serveur de tuiles. Faut prévoir un bon gros monstre pour la mappemonde <img data-src=" />


Mon histoire de wrapper est plus artisanal mais beaucoup moins lourd <img data-src=" /> Et si tu n’as jamais eu de soucis avec les serveurs d’OSM, je pense que ton utilisation ne requiert pas l’artillerie lourde ^^


Non jamais eut de soucis. Si un jour, j’ai un doute, je coupe le plugin qui l’utilise. Et tant pis s’il n’y a plus de cartes à côté des mes photos


C’est stupide, ça ne fonctionnera pas.

Le tracking est un rapport de force.



La seule vraie solution, c’est de se débrouiller pour surfer anonymement, sans laisser la possibilité aux éditeurs de nous tracer. Ça commence à gérer correctement ses cookies.



Firefox pourrait par exemple mettre une fenêtre pour chaque site permettant de conserver ou non les cookies.


Ce serait bien c’est vrai, mais quand la moitié des gens pensent juste qu’un cookie ca se mange, que l’autre moitié se fiche d’être pisté( vous savez le «j’ai rien à cacher»), c’est pas gagné


Et pendant ce temps, en Europe : <img data-src=" />


Je me demande si on peut vraiment trouver un compromis avec l’industrie publicitaire. Pour moi elle conchie le droit à la vie privée, donc pas possible qu’elle accepte de moins pister. Et s’il est impossible de discuter, il ne reste que le rapport de force, avec les bloqueurs de pubs/script/tracking. Ca fera des dégâts, mais il n’y a pas d’autre solution pour se faire entendre.








Goldoark a écrit :



Firefox pourrait par exemple mettre une fenêtre pour chaque site permettant de conserver ou non les cookies.





Firefox propose déjà un paramétrage fin des cookies, avec un liste blanche et une noire. Le reste ne serait que de la complication, qui n’intéresse que 1% des internautes (les autres s’en moquant du tracking et activant tout par défaut).

&nbsp;

De plus, je doute qu’une fenêtre supplémentaire qui apparaît pour chaque site soit une bonne idée. Le bandeau imposé par la CNIL sur les cookies part d’un bon sentiment mais excède déjà internaute qui navigue sur

plus de trois sites par jour, je ne pense pas que cela soit une bonne idée.

&nbsp;









Jarodd a écrit :



Firefox propose déjà un paramétrage fin des cookies, avec un liste blanche et une noire. Le reste ne serait que de la complication, qui n’intéresse que 1% des internautes (les autres s’en moquant du tracking et activant tout par défaut).

&nbsp;

De plus, je doute qu’une fenêtre supplémentaire qui apparaît pour chaque site soit une bonne idée. Le bandeau imposé par la CNIL sur les cookies part d’un bon sentiment mais excède déjà internaute qui navigue sur

plus de trois sites par jour, je ne pense pas que cela soit une bonne idée.

&nbsp;





C’est la gestion dans les navigateur et par défaut qui pose problème. Une gestion liste noire liste blanche n’est pas forcément pertinente. L’addon self destructing cookie, qui supprime a la fermeture de l’onglet par défaut serait bien plus adapté pour une utilisation standard. Les utilisateurs qui veulent que le site conserve son cookie doivent faire une action volontaire à ce moment là. Ça plus virer les cookie tiers par défaut ça serait déjà énorme.

La plupart des internautes ne se fichent pas d’être trackés mais les logiciel type navigateur devraient avoir des comportement par défaut plus sécurisés.



mais la plupart des internautes ne savent pas comment ça fonctionne (par exemple, comment faire fonctionner un site qui a besoin d’un cookie tiers pour permettre une connexion à un compte en ligne).



Ce serait une bonne idée si tout le monde était disposé à rechercher la source d’un problème d’affichage de sa page web, à chaque fois. Or quand on a besoin que “ça” s’affiche et qu’on n’y connait peu de chose en web (à part cliquer sur l’icône du navigateur et taper des identifiant/mot de passe au clavier), il faut que “ça” fonctionne.



S’il faut à chaque fois se demander s’il s’agit d’un problème de cookie ou pas, c’est comme demander à un boulanger de jouer les électriciens et c’est surtout frustrant pour l’utilisateur : il perd du temps, il a besoin d’aide… C’est un navigateur inutilisable pour l’utilisateur lambda.



C’est pour cette raison qu’il y a besoin d’un standard, d’une norme, d’un consensus entre les différents acteurs du web.


Dire ça c’est oublier que limiter le problème au cookies c’est avoir 10 batailles de retard.


Par rapport au tracking IP ? Si les navigateurs avait des comportements par défauts comme je l’ai décris, il ne resterais que ça. Et ça se règle avec un bon vieux VPN avec plusieurs personnes sur la même IP publique.


Quelle que soit la forme, fingerprint, identifiant dans le LocalStorage ou autre. L’inventivité en la matière est loin d’être limitée ;)