Door Anoniem: Zolang het anoniem geladen word zou het niet zo'n probleem hoeven zijn op technisch gebied.

Door Anoniem:
In de huidge setup is het niet "anoniem". Op het moment je nu naar stemwijzer gaat stuurt
je browser direct naar google je IP-adres en welke browser je gebruikt (user-agent). Zoals
de andere poster al zei, kan google dus exact zien hoeveel mensen de stemwijzder doen
en *waar* deze mensen zich bevinden.

Door Anoniem: Geen probleem, want als je je moet verlaten op een onzinnig ding als de stemwijzer weet je toch al niet waar je mee bezig bent. Dat ding duwt je de kant uit die de makers al dan niet bewust voor je bedacht hebben,

Door Anoniem: Goed dat security.nl dit "aankaart" in een poll.

Dit betekent *minimaal* dat google per IP-adres weet *hoevaak* mensen de stemwijzer doen.

Door Anoniem: Alles van google is problematisch

Door Briolet:
Dat betwijfel ik. Bij mij staat "fonts.googleapis.com" op de blocklist en laad hij dus in het geheel geen font. Maar als ik kijk wat hij probeert te laden, dan is dat: "https://fonts.googleapis.com/css2?family=Inter%3Awght%40400%3B700&display=swap"

Daar zit geen herkennende code van de site bij. De google servers zien alleen dat iemand een bepaald font ophaalt en niet welke site dat doet.

Maar ook met een blokkade van de google fonts, ziet de layout van de site er correct uit. Dan vraag ik me af waarom ze een extern font willen gebruiken.

Door Anoniem: Heel lullig, het beste kunt u een GNU+Linux Live-CD gebruiken of een VM. (Virtual Machine)
Of nog beter; nuet de stemwijzer gebruiken en zelf informatie opzoeken, bijvoorbeeld via ons geweldige security.nl
Dan is na één blik wel duidelijk op welke kant (Links, Rechts) u wilt stemmen.
https://www.security.nl/posting/816132/De+verkiezingsprogramma%27s+doorgelicht%3A+wat+willen+politieke+partijen+met+privacy%3F

Door Anoniem: Google moet toch kunnen zien vanaf welke pagina de fonts geladen worden? Anders kan het toch niet werken?

En vaak geven url's extra informatie weer, kan mij niet voorstellen dat Google hier niets mee doet.

Door Anoniem:

Waarom is alleen Google daarbij een probleem, en niet de stemwijzer zelf? Die verzamelen net zo goed de data en doen daar 'iets' mee waarvan we niet weten wat dan.

Door Anoniem: 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.

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.

Door Anoniem: Stemwijzer wordt gefinancieerd door links. Je kunt beter gaan kijken bij partijpeiler.nl. Is ook beter voor je privacy en bevat nuttiger vragen dan die corrupte stemwijzer.