Wat een identifier eigenlijk is¶

Een identifier is een label dat aan jou vastzit en dat overal hetzelfde is. Op een telefoon heet dat label de advertentie-ID. Op Android is dat de Advertising ID (AAID), op iOS de Identifier for Advertisers (IDFA). Het is een lange tekenreeks, bijvoorbeeld 38400000-8cf0-11bd-b23e-10b96e40000d. In de browser doet een cookie-id hetzelfde werk. Een site zet een waarde in een cookie, en die waarde komt bij elk volgend bezoek weer mee terug.

Het punt van zo'n label is herkenning. Een adverteerder hoeft je naam niet te weten. Zolang hetzelfde nummer terugkomt bij elk verzoek, weet het systeem dat het weer dezelfde persoon is. Alles wat je doet kan onder dat ene nummer worden opgeteld: welke apps je opent, welke pagina's je bezoekt, waar je op klikt. Het nummer is de spil waar het profiel omheen groeit.

"Resetten" betekent dat je dat label vervangt door een nieuw. Je oude advertentie-ID verdwijnt en er komt een verse tekenreeks voor in de plaats. Het idee erachter is dat je dan weer een schone lei hebt, omdat de nieuwe id nergens nog aan gekoppeld is. Die belofte is de kern van waarom de advertentie-ID als privacyvriendelijk wordt gepresenteerd. Je kunt hem immers zelf wissen.

Wat resetten betekent en wat je meet¶

Een reset doet precies één ding dat je kunt zien: het nummer verandert. Voor de reset staat er waarde A in het verkeer, na de reset waarde B. Dat is meetbaar. Je leest de oude id af, je drukt op reset, je leest de nieuwe af, en ze verschillen. Tot hier is alles vaste grond.

Wat je niet direct ziet, is of A en B intern aan elkaar geknoopt zijn. De reset breekt de zichtbare lijn. Of iemand achter de schermen een brug legt tussen het oude en het nieuwe nummer, staat los van wat je op je scherm afleest. En juist die brug bepaalt of de reset iets oplost.

Voor een meting telt of een sleutel in de praktijk stabiel genoeg is om je te herkennen. Of hij in principe kan veranderen, doet er dan weinig toe. De meeste mensen resetten hun advertentie-ID nooit, en wie het wel doet, doet het zelden. Een resetbare identifier die maandenlang gelijk blijft, functioneert al die maanden als een vaste identifier. Dat hij ooit had kunnen veranderen, verandert niets aan wat hij ondertussen deed.

Waarom een reset de lijn zelden echt doorknipt¶

De reset gaat uit van één aanname: dat de advertentie-ID het enige is wat je herkenbaar maakt. Die aanname klopt niet. Naast het label sturen apps en browsers een stroom aan andere signalen mee, en veel van die signalen veranderen niet als je de advertentie-ID vervangt.

• Fingerprint. Je toestel of browser laat een technisch profiel achter: schermformaat, taalinstelling, tijdzone, lettertypes, versienummers. Bij elkaar is die combinatie vaak zeldzaam genoeg om je uit een grote groep te vissen, zonder dat er iets op je apparaat wordt opgeslagen. Zie Fingerprinting ontwijkt je weigering door niets op te slaan. Reset je de advertentie-ID, dan blijft de fingerprint gelijk. De nieuwe id verschijnt op precies hetzelfde technische profiel, en de link is snel gelegd.
• E-mailhash. Log je ergens in, dan geef je een vast gegeven af: je e-mailadres. Vaak reist het adres mee als hash, een versleuteld ogende tekenreeks. Je leest je adres er niet zomaar uit af. De waarde zelf ligt wel vast, want dezelfde e-mail geeft altijd dezelfde hash. Die hash reist met je oude id mee en straks ook met je nieuwe. Het gedeelde veld verbindt beide.
• Inloggen zelf. Zodra je een account gebruikt, is de advertentie-ID overbodig geworden als anker. Je accountnummer is stabieler dan welke resetbare id ook.
• Cookie-sync. Partijen wisselen onderling id's uit en leren elkaars nummers voor dezelfde persoon kennen. Zie Cookie-sync laat losse partijen dezelfde persoon herkennen. Als het oude nummer al is uitgewisseld voordat jij reset, dan bestaat de koppeling al bij anderen.

De volgorde is het venijnige. De koppeling tussen oud en nieuw hoeft niet na de reset gelegd te worden. Ze kan al klaarliggen voordat jij op de knop drukt. Zolang oude id A en de e-mailhash samen in één verzoek stonden, en straks nieuwe id B en dezelfde hash samen in een ander verzoek staan, is de hash de scharnier waarlangs A en B elkaar vinden. De reset kwam te laat.

Doe het zelf: vind je advertentie-ID en reset hem¶

Dit kun je als student zelf nalopen. Je hebt alleen je telefoon nodig, en voor het laatste deel een manier om netwerkverkeer te lezen.

Android. Ga naar Instellingen, dan Privacy, dan Advertenties (op sommige toestellen staat het onder Google, dan Advertenties). Daar zie je je advertentie-ID staan of een knop om hem te verwijderen. Noteer de huidige waarde. Kies "Advertentie-ID verwijderen" of "resetten". Kijk daarna opnieuw. De tekenreeks is anders.

iOS. Ga naar Instellingen, dan Privacy en beveiliging, dan Tracking. De IDFA is niet als tekst zichtbaar in de instellingen. Wat je wel kunt sturen is "Verzoeken om tracking toestaan". Zet je dat uit, dan geeft iOS voor apps een IDFA van louter nullen terug (00000000-0000-0000-0000-000000000000). Dat is de iOS-manier om het label onbruikbaar te maken zonder dat je zelf een nummer aftikt.

De continuïteit zien. Hier wordt het interessant. Vang het netwerkverkeer van een app of website op in een HAR-bestand. Hoe je een HAR maakt en leest, staat in Netwerkverkeer lezen via HAR-files. Doe één opname voor de reset en één erna. Zoek in beide naar velden met namen als advertising_id, idfa, ifa, rdid of gaid. Je zult zien dat die waarde is veranderd. Zoek daarna naar velden die niet veranderden: em, email, sha256_email, user_id, of een fingerprint-achtig blok met scherm- en taalgegevens. Blijft zo'n veld gelijk over de reset heen, dan heb je in je eigen opname het scharnier gevonden waarlangs oud en nieuw aan elkaar vast kunnen zitten.

Wat je in de HAR direct aantoont, is dat het ene veld wisselde en het andere niet. Of een ontvanger de twee waarden ook echt samenvoegt, gebeurt op hun server en valt buiten je opname. Dat onderscheid moet je scherp houden, en het komt onderaan terug.

Twee id's aan elkaar knopen via een e-mailhash¶

Om te laten zien hoe simpel de herkoppeling is, hoef je geen tracker te zijn. De volgende Python laat het mechanisme zien met verzonnen voorbeeldgegevens. Stel dat een ontvanger twee losse waarnemingen heeft. De eerste is van voor je reset, de tweede van erna. De advertentie-ID verschilt. Het gehashte e-mailveld is gelijk, want je e-mailadres veranderde niet.

import hashlib

def email_hash(email: str) -> str:
    # normaliseren zoals gangbaar is: kleine letters, spaties eraf
    genormaliseerd = email.strip().lower()
    return hashlib.sha256(genormaliseerd.encode()).hexdigest()

# twee waarnemingen die de ontvanger los binnenkreeg
voor_reset = {
    "advertising_id": "38400000-8cf0-11bd-b23e-10b96e40000d",
    "em": email_hash("student@voorbeeld.nl"),
    "gebeurtenis": "app geopend, sportnieuws bekeken",
}

na_reset = {
    "advertising_id": "a1b2c3d4-0000-4444-8888-abcdefabcdef",
    "em": email_hash("student@voorbeeld.nl"),
    "gebeurtenis": "webshop bezocht, schoenen bekeken",
}

# de advertentie-id's verschillen: de reset is echt gebeurd
print(voor_reset["advertising_id"] == na_reset["advertising_id"])  # False

# de e-mailhash is identiek: het scharnier
print(voor_reset["em"] == na_reset["em"])                          # True

# dus koppel je op het veld dat niet veranderde
if voor_reset["em"] == na_reset["em"]:
    profiel = {
        voor_reset["em"]: [
            voor_reset["gebeurtenis"],
            na_reset["gebeurtenis"],
        ]
    }
    print(profiel)

De uitvoer voegt het sportnieuws van voor de reset en de schoenen van erna samen onder één sleutel. Die sleutel is de e-mailhash. De twee verschillende advertentie-ID's zijn nu twee namen voor dezelfde persoon. Merk op wat de hash wel en niet doet. Hij verbergt je e-mailadres voor wie de tabel leest. Hij verbergt jou niet, want dezelfde invoer geeft altijd dezelfde uitvoer. Wie jouw e-mail ook maar één keer weet, kan de hash zelf uitrekenen en er alsnog jouw naam op plakken. Dat is het punt uit de KERN, in vijf regels code.

De denkfout: nieuwe sleutel, zelfde slot¶

De reset laat zich makkelijk begrijpen als het vervangen van een sleutel. Je oude sleutel werkt niet meer, je hebt een nieuwe, dus je bent veilig. De vergelijking gaat mank op één punt. Bij een echte sleutelwissel vervang je ook het slot, of je verandert op zijn minst iets aan de deur. Bij een advertentie-ID-reset verander je alleen de sleutel. Het slot, de manier waarop je herkend wordt, staat er nog precies zo.

En het slot heeft meer dan één sleutelgat. De advertentie-ID is er één van. De fingerprint, de e-mailhash en je login zijn de andere. Je hebt de sleutel in het eerste gat vervangen. In de andere gaten past je oude sleutel nog, of ze zaten nooit op slot. Zo lang die openstaan, koop je met een reset weinig tijd. De herkenning verschuift gewoon naar het volgende signaal.

Daar komt de timing bovenop. Je vervangt de sleutel op het moment dat je reset. De koppeling tussen oud en nieuw kan al gelegd zijn toen beide sleutels nog samen met dezelfde e-mailhash langskwamen. Je maakt de deur schoon nadat de sleutel al is gekopieerd. Dat is waarom ik het een resetbare identifier blijf noemen. Voor de herkenning gedraagt hij zich als een vaste identifier, en dat is wat telt. Hoe gevoeliger de context, hoe harder die stabiliteit aankomt. Zie Hoe gevoeliger de context, hoe langer de identifier meegaat.

Wat hiervan gemeten is en wat afgeleid¶

Ik houd de bewijsniveaus uit elkaar, zoals altijd. Zie Label elke bevinding op bewijsniveau.

• Gemeten. Dat de advertentie-ID verandert bij een reset, kun je zelf aflezen in de instellingen en in een HAR. Dat een e-mailhash- of fingerprintveld over die reset heen gelijk blijft, kun je in dezelfde HAR aantonen. Dat het om hetzelfde toestel gaat is dan direct zichtbaar.
• Afgeleid. Dat een ontvanger de oude en de nieuwe id daadwerkelijk samenvoegt tot één profiel, gebeurt op zijn server en zie je in het verkeer niet gebeuren. Je leidt het af uit de aanwezigheid van een gedeeld stabiel veld dat naar hetzelfde eindpunt gaat. Dat is een sterke afleiding, want het veld heeft weinig ander nut dan koppelen, maar het blijft een afleiding.
• Wanneer het gemeten wordt. Zie je in het verkeer één verzoek waarin de oude id en de e-mailhash samen staan, en een later verzoek waarin de nieuwe id en dezelfde hash samen staan, dan is de koppelbaarheid zelf zichtbaar in de data. De samenvoeging tot een profiel blijft dan nog steeds afgeleid, maar het scharnier is dan gemeten, niet vermoed.

Voor mijn eigen werk betekent dit een simpele werkregel. Ik behandel elke id die maandenlang stabiel is als een identifier, ongeacht het label "resetbaar" dat eraan hangt. En ik zoek in elke opname eerst naar het veld dat niet verandert, want dat veld vertelt me of een reset iets voorstelt of alleen de sleutel wisselt terwijl het slot blijft staan.

Zie ook Cookie-sync laat losse partijen dezelfde persoon herkennen, Fingerprinting ontwijkt je weigering door niets op te slaan en Hoe gevoeliger de context, hoe langer de identifier meegaat.