Un ETAG est un en-tête HTTP envoyé en arrière-plan entre un navigateur Web et un serveur Web. Cette valeur est destinée à contrôler la durée pendant laquelle un fichier particulier est mis en cache côté client.
Il y a un effet secondaire intéressant à cette technologie; Les ETAG sont enregistrés sur une machine même si les cookies sont supprimés. Certaines personnes/logiciels ont exploité ce fait pour faire un ETAG "agir" comme un cookie.
Cela signifie qu'il ne suffit pas de supprimer les cookies. Il faut également supprimer la totalité du cache Web. C'est un processus douloureux à traverser chaque fois que je surfe sur le net sur ma machine de test.
Question
Quelle est la manière la plus fiable d'empêcher le suivi qui se produit par les en-têtes ETAG?
Je ne connais aucune excellente solution. Je peux suggérer trois défenses possibles, bien que toutes aient des limites:
Privoxy. Privoxy peut bloquer les en-têtes ETag.
En particulier, vous pouvez utiliser crunch-server-header
ou server-header-filter
dans votre configuration Privoxy pour bloquer ETag:
en-têtes du serveur. Vous pouvez également utiliser crunch-client-header
ou client-header-filter
dans votre configuration Privoxy pour bloquer If-None-Match:
et If-Modified-Since:
en-têtes du client. Cependant, je ne connais aucune formule standard que vous pouvez simplement saisir et utiliser: vous devez créer votre propre configuration Privoxy vous-même.
Votre navigateur. Si vous utilisez Firefox, vous pouvez configurer Firefox pour vider votre cache à chaque fois que vous quittez le navigateur. Cela peut être mauvais pour les performances. De plus, avec cette approche, les ETags peuvent toujours être utilisés pour vous suivre dans une session de navigateur, ce n'est donc pas parfait, mais il devrait effacer tout cookie ETag lorsque vous quittez votre navigateur.
RequestPolicy. Si vous utilisez Firefox, vous pouvez utiliser l'extension RequestPolicy . Un auteur a souligné que RequestPolicy peut aider à se défendre contre le suivi ETag . Souvent, les sites Web vous suivent en incluant des ressources provenant d'annonceurs tiers ou de fournisseurs d'analyses. RequestPolicy vous permet de contrôler les ressources tierces que votre navigateur demandera lors de la visite d'une page Web et peut ainsi vous protéger contre ce type de suivi: si votre navigateur ne charge jamais les ressources de l'annonceur tiers, alors le tiers l'annonceur n'a pas la possibilité de vous suivre (en utilisant un ETag ou tout autre mécanisme). Cette défense n'est pas idéale, car elle vous oblige à assembler laborieusement votre politique, et parce que les sites Web peuvent toujours vous suivre directement s'ils ne dépendent pas de ressources tierces.
Malheureusement, si vous accédez au Web via un proxy transparent, la présence du proxy peut compliquer vos tentatives pour éviter d'être suivi .
En plus des solutions plus impliquées proposées par @ D.W., Vous pouvez envisager d'utiliser votre mode de navigation privée du navigateur , ala InPrivate (IE), PrivateBrowsing (FF), Incognito (Chrome), etc.
L'essentiel ici est que le cache du navigateur n'est pas utilisé (ou du moins, pas utilisé au-delà de la durée de la session privée). En tant que tel, l'Etag n'est pas enregistré par votre navigateur.
Il y a encore quelques inconvénients à cette approche, comme le suivi au sein de la session et les procurations comme @ D.W. mentionné. Cela dit, il est assez simple à utiliser.
Si vous utilisez Firefox, vous pourriez être intéressé par une fonctionnalité (facultative) de mon add-on SecretAgent ... qui crée des en-têtes ETag usurpés pour supprimer le suivi.
L'inconvénient est que l'usurpation des ETags altérera évidemment la mise en cache sur les sites qui utilisent des ETags pour optimiser le trafic (bien que cela semble avoir un impact très mineur sur les performances).
Voir www.secretagent.org.uk .
(Avertissement: je suis l'auteur de SecretAgent).
mise à jour: a écrit la réponse différemment et plus clairement
J'ai une solution qui fonctionne sans modifier le protocole HTTP actuel. J'adorerais voir une implémentation de cela.
Au lieu de dire au serveur notre Etag nous DEMANDONS au serveur son Etag , et nous le comparons à celui que nous avons déjà.
Pseudo code:
If (file_not_in_cache)
{
page=http_get_request();
page.display();
page.put_in_cache();
}
else
{
page=load_from_cache();
client_etag=page.extract_etag();
server_etag=http_HEAD_request().extract_etag();
//Instead of saying "my etag is xyz",
//the client says: what is YOUR etag, server?"
if (server_etag==client_etag)
{
page.display();
}
else
{
page.remove_from_cache();
page=http_get_request();
page.display();
page.put_in_cache();
}
}
Exemple de conversation HTTP avec la solution 1:
Client:
HEAD /posts/46328
Host: security.stackexchange.com
Serveur:
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
ETag: "ABCDE"
Content-Type: text/html
Content-Length: 131
Cas 1, le client a une étiquette identique:
Connection closes, client loads page from cache.
Cas 2, le client a un etag qui ne correspond pas:
GET...... //and a normal http conversation begins.
Edit: Il convient de noter qu'il y a une surcharge mineure, le serveur doit envoyer l'en-tête HTTP deux fois: une fois en réponse à HEAD, et une fois en réponse à l'EEG. Une solution théorique à cela consiste à modifier le protocole HTTP et à ajouter une nouvelle méthode qui demande du contenu sans en-tête. Ensuite, le client demanderait le HEAD uniquement, puis le contenu uniquement, si les étiquettes ne correspondent pas.
Edit 2: J'ai suivi les conseils de makerofthings7 et l'ai posté comme question sur stackoverflow .
Une future solution pourrait être une préférence de navigateur qui désactive les étiquettes.
Pour Mozilla, le problème est abordé dans: ETag: filtrage pour contrer le suivi Web .