Les cookies sont de petits fichiers textes stockés par le navigateur web sur le disque dur du visiteur d'un site web et qui servent (entre autres) à enregistrer des informations sur le visiteur ou encore sur son parcours dans le site. Le webmaster peut ainsi reconnaître les habitudes d'un visiteur et personnaliser la présentation de son site pour chaque visiteur ; les cookies permettent alors de garder en mémoire combien d'articles il faut afficher en page d'accueil ou encore de retenir les identifiants de connexion à une éventuelle partie privée : lorsque le visiteur revient sur le site, il ne lui est plus nécessaire de taper son nom et son mot de passe pour se faire reconnaître, puisqu'ils sont automatiquement envoyés par le cookie.
Un cookie a une durée de vie limitée, fixée par le concepteur du site. Ils peuvent aussi expirer à la fin de la session sur le site, ce qui correspond à la fermeture du navigateur. Les cookies sont largement utilisés pour simplifier la vie des visiteurs et leur présenter des informations plus pertinentes. Mais une technique particulière permet sur d'anciens navigateurs de suivre un visiteur sur plusieurs sites et ainsi de collecter et recouper des informations très étendues sur ses habitudes. Cette méthode a donné à l'usage des cookies une réputation de technique de surveillance violant la sphère privée des visiteurs.
En réponse à ces craintes légitimes, un mécanisme appelé P3P a été mis en place afin de prémunir les internautes des éventuelles utilisations abusives.
Certaines opérations qui peuvent être réalisées en utilisant les cookies peut aussi être réalisées en utilisant d'autres mécanismes.
Les utilisateurs peuvent être suivis avec l'adresse IP de l'ordinateur appelant la page. Cette technique a été disponible depuis l'introduction du Monde Élargit du Web (WWW), au fur et à mesure que les pages sont téléchargées le serveur demande l'adresse IP de l'ordinateur faisant fonctionner le navigateur ou le proxy, si aucun est utilisé. Le serveur peut suivre cette information qu'il n'y ai ou pas de cookies utilisés. Cependant, ces adresses sont typiquement moins fiables dans l'identification d'un utilisateur que les cookies car les ordinateurs et les proxy peuvent être partagés par plusieurs utilisateurs, et le même ordinateur peut recevoir une adresse IP différente sur chaque session de travail (comme c'est souvent le cas pour les connexions téléphoniques).
Le suivi par les adresses IP peut être fiable dans certaines situations, comme le cas des connexions à bandes larges qui maintiennent la même adresse IP pour une longue période, aussi longtemps que le courant passe.
Certains systèmes comme Tor sont conçus pour maintenir l'anonymat d'Internet et rendre impossible ou impraticable le suivi par l'adresse IP.
Une technique plus précise est basée sur l'encastrement d'information dans les URLs. La partie requête de chaînes de caractères de l'URL est l'une des techniques qui est typiquement utilisée dans ce but, mais d'autres parties peuvent être utilisées aussi bien. Le Servelet Java et les mécanismes de session PHP utilisent tous les deux cette méthode si les cookies ne sont pas activés.
Cette méthode comprend le serveur Web apposant des requêtes de chaînes de caractères aux liens de la page Web qui la porte quand elle est envoyée au navigateur. Quand l'utilisateur suit un lien, le navigateur retourne la chaîne de requête attachée, au serveur.
Les chaînes de requête utilisées dans ce but et les cookies sont très similaires, tous les deux étant des informations arbitrairement choisies par le serveur et renvoyées par le navigateur. Cependant, il y a quelques différences: depuis que la chaîne de requête est une partie de l'URL, si cette URL est réutilisée plus tard, la même partie d'information attachée est envoyée au serveur. Par exemple, si les préférences d'un utilisateur sont encodées dans une chaîne de requête d'une URL et que l'utilisateur envoie cette URL à un autre utilisateur par e-mail, ces préférences peuvent aussi bien être utilisées pour un autre utilisateur.
D'ailleurs, même si le même utilisateur accède à la même page deux fois, il y a pas de garantie que la même chaîne de requête soit utilisée les deux fois. Par exemple, si le même utilisateur arrive à la même page mais vient d'une page interne du site une première fois et provient d'une page externe de recherche une seconde fois, la chaîne de requête relative (à la page du site) est typiquement différente alors que les cookies sont les mêmes. Pour plus de détails, regardez la chaîne de requête.
Les autres désavantages des chaînes de requêtes liés à la sécurité: garder les données qui identifient une session en chaînes de requêtes permet ou simplifie les attaques de fixation de session, les attaques de référence au login et d'autres exploitations des failles. Transférer les identifiants de session en tant que cookies HTTP est plus sécurisé.
Une forme de suivi de session, utilisée par ASP.NET, est d'utiliser les formulaires web avec des champs cachés. Cette technique est très similaire à l'utilisation des chaînes de requêtes par URL pour porter l'information et a les mêmes avantages et désavantages ; et si le formulaire est traité avec la méthode HTTP GET, les champs deviennent en fait une partie de l'URL du navigateur qui l'enverra lors de la soumission du formulaire. Mais la plupart des formulaires sont traités avec HTTP POST, qui provoque le formulaire d'information, incluant les champs cachés, pour être ajouté comme une entrée supplémentaire qui n'est ni une partie de l'URL, ni d'un cookie.
Cette approche présente deux avantages du point de vue du suivi: premièrement, en ayant le suivi de l'information placée dans le code source HTML et en entrée POST plutôt qu'au moyen de l'URL ce qui ne sera pas remarqué par l'utilisateur moyen; deuxièmement, la session d'information n'est pas copié quand l'utilisateur copie l'URL (pour sauvegarder la page sur disque ou l'envoyer via l'e-mail, par exemple).
Tous les navigateurs webs courants peuvent stocker une assez grande quantité de données (2-32 MB) via JavaScript en utilisant la propriété windows.name DOM. Cette donnée peut être utilisée à la place des sessions de cookies et l'est aussi à travers les domaines. La technique peut être couplée avec les objets JSON/JavaScript pour stocker un ensemble complexe de variables de sessions du côté client.
L'inconvénient est que chaque fenêtre séparée ou onglet aura initialement un windows.name vide; lors de la navigation par onglets (ouverture par l'utilisateur) cela veut dire que les onglets ouvert individuellement n'auront pas de nom de fenêtre. De plus windows.name peut être utilisé pour suivre les visiteurs à travers différents sites, en ce qui concerne la vie privée sur Internet.
À certains égards cela peut être plus sécurisé que les cookies qui est du à la non implication du serveur, donc invulnérable à l'attaque réseau des cookies renifleurs. Cependant si des mesures spéciales sont prises pour protéger les données, elles sont vulnérables à d'autres attaques car les données sont disponibles à travers d'autres sites ouverts dans la même fenêtre ou onglet.
Le protocole HTTP inclus les protocoles d'authentification d'accès de base et la digestion de l'authentification d'accès, qui permet l'accès à une page Web seulement lorsque l'utilisateur a donné le nom d'utilisateur et le mot de passe correct. Si le serveur demande tel certificat pour accorder l'accès à une page web, le navigateur les demande à l'utilisateur et, une fois obtenu, le navigateur les stocke et les envoie dans toutes les pages suivantes demandées. Cette information peut être utilisée pour suivre l'utilisateur.
Si un navigateur inclus le plugin Adobe Flash Player, la fonctionalité "Objets localement partagés" peut être utilisée dans le même but que les cookies. Les objets localement partagés peut être un choix attractif pour les développeurs web parce que la majorité des utilisateur Windows ont installé Flash Player , la taille limite par défaut est de 100 kB, et les contrôle de sécurité sont distincts des contrôles des cookies de l'utilisateur, donc les objets localement partagé peut être permit quand les cookies ne le sont pas.
Dans certains cas, des sites web ont créé Flash LSOs qui se comporte différemment de ce que l'utilisateur spécifie pour les http cookies, qui a soulevé des inquiétudes concernant les sites web qui ont besoin de spécifier une politique de confidentialité à travers différent types de cookies.
Le désavantage majeur avec cette approche est la même que toutes les approches plateformes/fournisseur-spécifique: cela bloque l'accessibilité global au web et l'inter-polarité, en immobilisant le développement web à une plateforme client spécifique, en excluant les utilisateurs qui utilisent les agents utilisateur des normes du web et les force à la place d'utiliser les agents plateformes/fournisseur-spécifique du web, qui perepétuent les programmes payants.
Certains navigateurs web supportent un script basé sur le mécanisme de persistance qui permet à la page de stocker les informations localement pour une utilisation ultérieur. Internet Explorer, par exemple, supporte les informations persistantes dans l'historique du navigateur, en favoris, dans un format stocké en XML, ou directement avec une page Web sauvée sur disque. Avec HTML 5 il y aura une méthode de stockage DOM (stockage local), couramment supporté par seulement certains navigateurs . Pour Internet Explorer 5+ il y a une méthode "utilisateur-donnée" disponible à travers les comportements DHTML.
Un mécanisme différent s'appuie normalement sur la mise en cache des navigateurs (portant sur la mémoire plutôt que le rafraichissement) utilisant les programmes JavaScript dans les pages web. Par exemple, une page peut contenir un lien comme