Poll
image

Het laden van Google fonts op stemwijzer.nl:

maandag 30 oktober 2023, 11:52 door Redactie, 24 reacties
Geen probleem
22.59%
Problematisch
77.41%
Reacties (24)
30-10-2023, 12:54 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,
30-10-2023, 13:01 door Anoniem
Geen probleem op mijn werklaptop.
Klein (privacy) probleem voor mijn thuiscomputer.
30-10-2023, 15:52 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. Dus google kan heel duidelijk zien in welke regio's mensen bijvoorbeeld "swing voters" zijn, dat niet ze nog niet weten wat ze willen stemmen. Dat staat nog even los van het feit dat uberhaupt al onze IP-addressen naar google worden gestuurd (voor een font, een font!!!!)
30-10-2023, 18:12 door Anoniem
Alles van google is problematisch
30-10-2023, 18:17 door Anoniem
Zolang het anoniem geladen word zou het niet zo'n probleem hoeven zijn op technisch gebied.

Echter als je voor integriteit gaat, wil je de hele site self-contained hebben.
Maar dat is lastig voor de moderne webdeveloper, zelfs onze router heeft dit niet.
31-10-2023, 08:26 door Anoniem
Door Anoniem: Zolang het anoniem geladen word zou het niet zo'n probleem hoeven zijn op technisch gebied.

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.
31-10-2023, 09:33 door Anoniem
Door Anoniem:
Door Anoniem: Zolang het anoniem geladen word zou het niet zo'n probleem hoeven zijn op technisch gebied.

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.

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.
31-10-2023, 12:08 door Anoniem
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,
Vind ik ook, als je zelf nog niet eens kunt bepalen op welke partij je moet stemmen dan ben je niet in staat om
te stemmen en mijn advies is blijf thuis of neem de moeite om onderzoek te doen wie het beste bij je past.
31-10-2023, 12:12 door Anoniem
Vaag aspectje aan a la Cambridge Analytica.
31-10-2023, 14:14 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
31-10-2023, 15:56 door Briolet
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.

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.
31-10-2023, 16:43 door Anoniem
Nog problematischer: ze doen geen intergriteitscheck op wat ontvangen wordt vanuit die server.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity ontbreekt dus.
31-10-2023, 19:25 door Anoniem
Door Anoniem: Alles van google is problematisch
+1

Je kan er vanuit gaan dat je door google uitgemolken wordt op basis van alle info in je headers (eventuele cookies, referrer headers, enz).
01-11-2023, 03:26 door Anoniem
Door Briolet:
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.

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.
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.
01-11-2023, 12:29 door Anoniem
wat is de reden om zo websites te bouwen? heeft de stemwijzer daar ook iets aan, is dit onwetendheid, luiheid, wat? In AVG wordt gesproken over privacy-by-design, dit soort implementaties zit daar ver vandaan lijkt me. Ik zou zo weinig mogelijk extern inladen, en zoals één van de anderen hier zegt, blokkeer je de Google fonts dan werkt de site nog prima, dus wat is het nut hiervan??
01-11-2023, 14:41 door Anoniem
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

Goed advies voor je oma van 90 die niet meer kan dan een paar knoppen aan klikken. We leven niet een land met alleen IT nerds. Ook heeft het grootste deel van de Nederlanders niet eens een idee wat er in de programma's staat. groot deel neem niet de moeite of kan de ingewikkelde taal in die documenten niet eens lezen.
01-11-2023, 16:09 door Anoniem
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.
02-11-2023, 11:44 door Anoniem
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.

Omdat Prodemos een stichting is ter versterking van de democratie en Google een surveillance kapitalist met dataroof als primair verdienmodel. Wat ProDemos met je data doet staat in de privacy verklaring: https://www.stemwijzer.nl/privacy

Op zich een nette privacy verklaring, ware het niet dat ze hierin niet vermelden dat ze je IP, Useragent en browser fingerprint met Google delen (en met Cloudflare). Dit is in strijd met de AVG.

Om conform AVG te werken horen ze een deugdelijk verwerkersovereenkomst te sluiten met Google en Cloudflare (kan dus niet met Google, tenzij je de NL overheid bent, anders is het aanvinken bij het kruisje) En dit in de privacyverklaring te melden.
02-11-2023, 11:59 door Anoniem
Door Anoniem:
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.


Je mag nog wel wat aan je F12 skills werken, in de de referer die naar Google gaat staat gewoon de origin "www.stemwijzer.nl", dus Google krijgt precies te zien voor welke site dit letter type wordt opgevraagd.

Hier het HTTP verzoek:

https://fonts.gstatic.com/s/inter/v13/UcC73FwrK3iLTeHuS_fvQtMwCp50KnMa1ZL7.woff2
Host: fonts.gstatic.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Accept: application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: identity
Referer: https://fonts.googleapis.com/
Origin: https://www.stemwijzer.nl
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: font
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
02-11-2023, 16:01 door _R0N_
Waarom zou je dat doen als webbouwer? Luiheid?
02-11-2023, 17:07 door nicolaasjan
Geen probleem hier.
Met de extensie LocalCDN worden Google fonts geblokkeerd. :)

Of anders:
In Firefox uitvinken:
"Pagina’s toestaan om hun eigen lettertypen te kiezen, in plaats van uw selecties hierboven".

Resultaat:
Geen requests naar 'fonts.googleapis.com'.
02-11-2023, 22:32 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.
03-11-2023, 14:38 door Anoniem
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.

Die stellingen zul je dan wel even moeten onderbouwen, anders is de waarde NUL.
05-11-2023, 13:20 door Anoniem
Bij NSC kan je het verkiezingsprogramma alleen maar downloaden bij google, wel handig dat ze op die manier google helpen aan informatie over politieke voorkeur.
Wel handig, weer een partij minder om te overwegen :-).
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.