Cambiare server VPN ti disconnette da un negozio?
Un nuovo indirizzo di uscita non svuota il barattolo dei cookie. Decidi prima se stai testando il percorso di rete, la sessione connessa o i dati memorizzati del sito.
Cambia l’uscita della VPN mentre un negozio è aperto in un’altra scheda, e il carrello di solito è ancora lì. Non è un guasto della VPN; è il browser che fa esattamente ciò che gli è stato detto. Il cookie lo invia il browser, e un nuovo percorso di rete non cambia ciò che il browser memorizza. Dietro «il sito mi conosce ancora» si nascondono tre domande diverse, e la risposta dipende da quale stai davvero ponendo.
Tre domande, un sintomo
Prima: il sito riconosce un cookie memorizzato? Seconda: riconosce un account connesso, che sopravvive indipendentemente da qualsiasi singolo cookie? Terza: riconosce qualcosa del browser o del dispositivo anziché uno stato memorizzato? Ognuna ha il suo test e il suo rimedio.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
La maggior parte della confusione nasce dal cambiare la prima e aspettarsi che segua la seconda. Un indirizzo di rete e un archivio del browser sono sistemi separati che la stessa pagina usa per caso.
Che cosa trasporta davvero un cookie
La gestione dello stato HTTP, come specificata nella RFC 6265, è volutamente semplice: il server imposta un nome e un valore con un ambito, e il browser li restituisce per le richieste che corrispondono a quell’ambito. Il valore può essere un identificatore di sessione, una preferenza o un token opaco che il server associa a un record del carrello. Nulla nel meccanismo menziona l’indirizzo del client.
È questo progetto che permette agli accessi e ai carrelli ordinari di sopravvivere a un cambio di rete, ed è anche ciò che permette loro di sopravvivere per i tracker. Lo stesso meccanismo serve entrambi gli scopi e non li distingue. Nel protocollo non esiste alcun campo per l’indirizzo del client, quindi una nuova uscita non ha nulla da invalidare. Un sito che volesse legare un cookie a un’origine di rete dovrebbe aggiungere quella logica da solo.
Quando un sito restituisce un cookie, il server cerca il record a cui punta quel valore. Cambiare il percorso seguito dalla richiesta non cambia quella ricerca, ed è tutta qui la spiegazione dell’osservazione sul carrello.
Decidi che cosa misura il tuo test
Prima di cambiare qualsiasi cosa, annota lo stato da cui parti: quale profilo del browser, quale account, quali dati del sito, quale percorso di rete. Poi cambia esattamente uno di questi e osserva. Un test che cambia insieme l’indirizzo di uscita e il profilo del browser non dimostra nulla su nessuno dei due.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartEntrambi i comandi riutilizzano lo stesso file di cookie, e il secondo impone un diverso indirizzo di origine locale dove l’host lo consente. La risposta del carrello è la stessa in entrambi i casi perché il server non ha mai visto un’identità client diversa, solo un percorso diverso. Questo è il meccanismo in una coppia di richieste riproducibile.
Se l’obiettivo è vedere se il sito ti riconosce senza stato memorizzato, cancella i dati di quel sito e ripeti. Se ti riconosce ancora, i sospetti successivi sono l’account connesso, un link che hai seguito o le caratteristiche del browser anziché un cookie.
Cancella lo stato giusto, non la rete
Rimuovere l’archiviazione di un solo sito spetta ai controlli del browser stesso, e spesso ti disconnetterà o azzererà le preferenze come effetto collaterale. Non elimina l’account né i record che il servizio già detiene; per quelli serve la procedura del servizio stesso.
Le restrizioni tra siti affrontano un’altra parte del problema. I browser possono bloccare o partizionare l’archiviazione che i servizi incorporati condividerebbero altrimenti tra siti, mentre un accesso di prima parte continua a funzionare. Un accesso riuscito non è quindi prova che il tracciamento tra siti funzioni.
Le finestre private sono un altro strumento con una portata più stretta di quanto la gente si aspetti. I siti possono comunque impostare cookie durante la sessione, e un accesso identifica comunque l’account. È la fine della sessione privata a scartare lo stato temporaneo, il che significa chiudere tutte le finestre private e non una sola scheda.
Infine, tratta l’identificazione tramite impronta come una possibilità e non come la prima spiegazione. Le caratteristiche del dispositivo e del browser possono collegare le visite senza alcun cookie memorizzato, e cancellare l’archiviazione non le toccherà. Controlla prima le cause semplici, poi amplia l’indagine, e annota quale stato hai cambiato perché il confronto successivo abbia senso.