Door Anoniem: Google moet toch kunnen zien vanaf welke pagina de fonts geladen worden? Anders kan het toch niet werken?
Je browser zal wel een referer-header meegeven, maar als dat niet gebeurt wordt nog steeds hetzelfde font-bestand geladen. Waarom zou de inhoud daarvan afhangen van welke pagina het font gebruikt?
Browsers hebben trouwens handige hulpmiddelen waarmee je kan zien wat er gebeurt. Ik heb een maagdelijke Firefox-sessie gestart (niet mijn gewone profiel maar een browser zonder add-ons of eerdere historie), en daar:
• de developer tools geopend met F12;
• naar de tab "netwerk" gegaan;
• op het tandwiel-icoontje geklikt en in het menu "registraties aanhouden" aangevinkt — dit zorgt dat niet per opgevraagde pagina de netwerklog geschoond wordt maar alles bewaard blijft;
• in de adresbalk https://www.stemwijzer.nl/ ingevuld — als de pagina geladen wordt zie je de requests in de log verschijnen;
• rondgebladerd in die website — dat levert meer en meer logregels op;
• bij "urls filteren" heb ik "fonts" ingevuld — dan levert precies de font-gerelateerde requests naar Google op.
Dan zie ik dat de eerste request naar een stylesheet is die van fonts.googleapis.com wordt geladen. Die wordt niet meer opnieuw uitgevoerd als ik rondblader. Vervolgens zie ik een hele rij requests naar fonts.gstatic.com voor steeds hetzelfde font-bestand. De eerste twee daarvan vonden plaats toen de eerste pagina van de website geladen werd:
• De eerste bracht 47,54 kB over in 31 ms.
• De tweede bracht ook 47,54 kB over in 6 ms, met de toevoeging "raced".
En alle volgende kwamen bij het laden van andere pagina's:
• De response was gebufferd (kwam dus uit de browser-cache), en was in 0 ms beschikbaar.
De tweede request is gek, de rest is duidelijk: het fontbestand wordt maar één keer bij Google opgehaald en staat daarna in de cache. Als ik de eerste request aanklik worden de aanvraag- en antwoordheaders getoond, en daaruit blijkt dat de download pas over een jaar expireert. Dus dat fontbestand kan een jaar lang in de browsercache blijven staan en wordt gedurende die tijd niet opnieuw opgehaald. Als het niet opnieuw wordt opgehaald valt er voor Google niets te tracken.
Dan die vreemde tweede request. "Raced" doet denken aan de term "race condition", die erop neerkomt dat twee processen parallel dezelfde resource benaderen en daar kunnen dan dingen bij misgaan als dat niet zorgvuldig wordt afgevangen. Als ik goed naar de tijdlijn van de requests kijk kan ik zien dat die tweede request werd afgevuurd nog voordat de eerste was afgerond. Ze liepen dus inderdaad parallel. Als ik op die tweede request klik valt op dat er geen antwoordheaders zijn, er is nooit een antwoord teruggekomen van Google, of het is niet geregistreerd. Waarom niet? Het lijkt erop dat de aanvraag wel voor de tweede keer naar Google is gestuurd maar dat de browser niet op het antwoord heeft gewacht omdat het font een paar milliseconden later al vanuit de eerste aanvraag binnen was. Ik heb de aanvraagheaders bekeken en die zijn identiek. Beide aanvragen hadden verder geen payload, en dus ook geen extra informatie voor Google in de payload. Het twee keer versturen (wat een foutje in stemwijzer kan zijn) heeft Google twee keer identieke informatie gegeven.
En vaak geven url's extra informatie weer, kan mij niet voorstellen dat Google hier niets mee doet.
Gelukkig kan je via de hierboven beschreven methode precies zien wat er in de URL staat: niets meer dan de URL van het font-bestand. In de aanvraagheaders zitten de gebruikelijke dingen: de user agent-string, de referer, je taalvoorkeuren voor de inhoud van de website. Natuurlijk ziet de server ook je IP-adres.
Zoals je ziet hoef je je wantrouwen niet op aannames te baseren maar kan je zelf kijken wat er over de lijn gaat. Probeer het eens en leer ervan. Developer tools die erg lijken op die in Firefox zitten ook in Chromium/Chrome en in Edge.