Duitse website veroordeeld voor doorgeven ip-adres bezoeker via Google Fonts

Een Duitse rechtbank heeft een Duitse website veroordeeld voor het zonder toestemming doorgeven van het ip-adres van een bezoeker aan Google door middel van Google Fonts. Dat meldde Security.nl afgelopen maandag. De klagende bezoeker krijgt 100 euro schadevergoeding. Volgens de rechter heeft de website geen gerechtvaardigd belang, aangezien Google Fonts ook lokaal is te gebruiken waarbij er geen ip-adres van bezoekers naar Google wordt gestuurd. Exit Google Fonts?

De dienst Google Fonts is bedoeld om website-eigenaren makkelijker mooie lettertypes te kunnen laten serveren. Natuurlijk kan iedereen eigen fonts op de eigen site zetten, maar dan blijf je downloaden. Google zet ze centraal neer (fonts.googlea.com), en dan onthoudt je browser welke fonts al gedownload. Dat scheelt, en als er updates zijn (een ontbrekend karakter, een nieuwe emoji, noem maar op) kan dat op één plek doorgevoerd.

Nadeel: je browser maakt dan verbinding met een site van Google, waardoor die je IP-adres te pakken krijgt. En -als ik even snel in mijn eigen cookiejar kijk- ook analyticscookies en andere gezellige trackers, die ongetwijfeld gecombineerd zijn met mijn Google-profiel en ander online gedrag. Dit ter verbetering van de gebruikerservaring, veronderstel ik.

Dit is dus een probleem, om dezelfde reden als waarom Google Analytics een probleem is. Als website forceer je zo dat mensen hun persoonsgegevens (IP-adres en/of cookie) naar Amerika gaan. En hier is er ook een eenvoudig alternatief, aldus de rechtbank: je mag die fonts gewoon lokaal hosten. Je hebt dan wel een beetje overhead en extra downloads, maar toen ik dat schreef twee alinea’s terug zat ik ondertussen te Netflixen met Spotify aan én een AI model te renderen dus ik twijfelde al of ik dat nog wel een serieus argument vind in 2022.

De rechtbank bevestigt nog eens dat een IP-adres een persoonsgegeven is, ook als het “maar” dynamisch is. Gecombineeerd met datum en tijd is het gewoon het adres van een persoon – de netsurfer – en zeker voor Google, die het zo kan koppelen aan nog veel meer gegevens. En dat alles dus zonder toestemming en zonder goede reden (gerechtvaardigd belang).

In de comments bij Security.nl wordt gewezen op moderne beveiligingsmaatregelen in Firefox, waarmee je sowieso al niet meer profiteert van centrale opslag: fonts worden opnieuw opgehaald vanaf de Google-site bij iedere nieuwe site, zodat er niet één centraal overzicht komt voor de beheerder van de Google Fonts site. Wat dus specifiek bij Google niet werkt, maar bij andere meegluurders wel.

De 100 euro is een interessante opsteker voor de vele AVG-schadeclaimverzoekers. Heel hard wordt het niet onderbouwd:

The amount of the claimed damages is appropriate in view of the seriousness and duration of the infringement and is not challenged by the defendant.
Oftewel, “mja dat klinkt niet onredelijk en ik hoor ook geen serieus bezwaar van de website-eigenaar”.

Arnoud

43 reacties

  1. Dit is aan de ene kant te begrijpen, maar dit gaat erg ver. als ik de inspect window open op bijvoorbeeld tweakers dan zie ik requests gaan naar google, maar ook naar cdn.persgroep.digital, en er zijn natuurlijk talloze sites die een CDN aanbieden voor fonts, CSS, JS enz enz, die loggen ook allemaal je IP, datum en tijd en hoogst waarschijnlijk je User-Agent. natuurlijk is het zo dat jouw internet verbinding breed genoeg is maar er zijn mensen die het niet zo goed hebben (zelfs in Duidsland) en dan is een CDN die via anycast snel te benaderen is wel handig.

    1. Aangezien Tweakers onderdeel is van de Persgroep, is een verbinding naar die CDN binnen de richtlijnen. Wanneer de CDN in handen is van een organisatie waar jij geen zeggenschap in/over hebt, wordt het anders. Je kunt dan niet zomaar voldoen aan de regels volgens de GDPR (AVG). Is dit ook nog eens buiten de EU, dan moet je dus uitgebreide waarborgen hebben en die waarborgen zijn, zoals bekend, bij VS-bedrijven nog zachter dan een pakje boter dat in de zon ligt, omdat de locale wetgever zich allerlei rechten toedicht.

      1. Ok, in dit geval goed punt maar niet het punt wat ik wilde maken, kijk bijvoorbeeld even naar telegraaf[.]nl, deze haalt JS op van sdk[.]privacy-center[.]org nu[.]nl die haalt JS op van code[.]jquery[.]com, wat heel veel sites doen natuurlijk. En ik zeg niet dat het dit het goed maakt, ik wil alleen even aangeven dat dit veel breder is dan alleen Google en dat het merendeel van alle sites zoiets doet.

  2. Toch wel even schrikken. Want op zich klopt het dat het IP op deze manier kán worden bijgehouden door Google. Maar het concept van externe resources gebruiken via een CDN is wel erg gebruikelijk. Denk alleen al aan ajax.googleapis.com/jquery.

    Ik snap alleen niet precies wat het probleem was. Dat Google het IP adres kon zien, of dat Google daarboven op nog cookies plaatste.

    Wat zou er voldoende moeten zijn om dit legaal te krijgen? Wat als Google schriftelijk zou verklaren dat ze de gegevens niet verwerken of bewaren? En dar Google de analytics cookies zou verwijderen. Zodat de IP adressen daardoor ook niet opvraagbaar zijn door geheime diensten?

    1. Gaat nog wel verder eigenlijk, nu ik er twee tellen langer over nadenk. Mag je überhaupt nog wel gebruik maken van een CDN ? Want die zijn allemaal Amerikaans, lijkt het wel. En mag ik mijn site bij een Amerikaanse hoster hosten?

  3. Ik krijg aan de ene kant een ‘er mag ook helemaal niks meer!’ gevoel, maar aan de andere kant ook wel ‘wat goed dat site eigenaren een keer moeten nadenken over waar hun bezoekersdata blijft’. Maar het is wel moeilijk. Je wil alle die gemakkelijke diensten blijven gebruiken als ontwikkelaar. Maar blijven betalen met de data van je bezoekers is geen oplossing.

    Iets anders: ik vind steeds snapchat cookies op mijn computer, zonder dat ik een logische aanleiding daarvoor zie. Iemand enig idee wat ze daar aan het doen zijn?

  4. Ik vraag mij af of op deze manier ook CloudFlare aan te pakken is. Immers, veel bedrijven maken hier gebruik van om hun website beter mee te beveiligen maar dan wordt wel al het dataverkeer via een Amerikaans bedrijf aangeleverd en is het maar de vraag of CloudFlare niet stiekem ook allerlei gegevens verzameld. Je zou ervan uitgaan dat ze dat niet doen, maar zeker weten doen we dat niet.

    Sowieso zorgt het gebruik van Google Fonts rechtstreeks via Google wel ervoor dat de fonts altijd up-to-date zijn. Een font kan immers besmet raken door malware, zeker als je daar een eigen kopie van moet bewaren. Fonts bevatten veelal uitvoerbare code die lijntjes en bochten tekenen op je scherm en dus mogelijk ook extra, kwaadwillende code kunnen bevatten. Dus ik weet niet of ik blij word van sites die zelf hun fonts beheren.

    Sowieso is Google niet het enige bedrijf dat stiekem kan meeluisteren met wat er op een website gebeurt via dit soort middelen. Wie b.v. met node.js websites ontwikkelt dan weet je niet of er in al die pakketten die je daarbij gebruik niet iets zit dat stiekem data vanuit een andere site mee verwerkt. En wie React gebruikt moet ook nog eens oppassen omdat React door Facebook is ontwikkeld en mogelijk resources via Facebook ophaalt en zo dus data aan Facebook doorspeelt. En met ASP.NET en C# heb je weer dat er mogelijk Microsoft Analytics meekomt met de code. En wie b.v. Bootstrap gebruikt moet ook even opletten waar je de Bootstrap code vandaan haalt want het is wel makkelijk als dit van een externe content provider komt, zodat je eigen server minder bandbreedte nodig heeft…

    Want een geldige reden om Google Fonts niet lokaal te gebruiken is om te bezuinigen op het dataverkeer van je server. Zeker als je veel bezoekers hebt die steeds weer deze data-bestanden moeten downloaden. Een font is al snel 100 kilobytes en als er ieder uur 100 bezoekers deze downloaden dan is dat al 10 megabyte per uur, alleen voor een font. Da’s 240 MB per dag en ruim 7 GB per maand. Dat valt op zich nog wel mee, maar bij sommige hosts betaal je wel voor het totaal aantal gebruikte gigabytes. Gelukkig zijn er steeds meet hosts die onbeperkt dataverkeer toelaten, maar er zijn er nog genoeg die dataverkeer wel in rekening brengen als het flink oploopt. En dan is het logisch om hierop te besparen via een externe bron…

    1. Waarom ga je ervan uit dat Cloudflare geen data verzameld? Wat een vrolijk wereldbeeld moet je dan hebben, ben eigenlijk wel jaloers 🙂 Het ‘mooie’ aan cloudflare is dat het (uit noodzaak) zelfs beschikt over de SSL sleutel van je website en dus ook daadwerkelijk de inhoud van de webpagina’s kan analyseren. Daar kun je prachtige analyses op loslaten en het lijkt mij heel sterk dat zij niet een lijstje IP adressen hebben gekregen van hun overheid waarvan ze alle communicatie moeten tappen. Dat is echt een veel te mooie kans om zomaar te laten liggen.

      Als een aanvaller het verder voor elkaar krijgt om een font te infecteren welke op jouw webserver wordt gehost dan heeft die aanvaller wel meer mogelijkheden om te rommelen met je klanten… Een bedrijf dat bewust gebruik zou willen (durven) maken van zo’n enorm waardevolle zero-day die zal gewoon geen Google fonts vanuit CDN embedden.

      Je punt over alle andere partijen die mee zouden kunnen luisteren is een hele goede. Dat is zo en je dient daar als ontwikkelaar wel degelijk rekening mee te houden. Als Microsoft tracking toe zou voegen aan alle code die met Visual Studio wordt gecompileerd dan staat het hele internet op stelten. Voor web-libraries is de kans van dergelijk meuk een stuk groter. Juist daarom is het belangrijk dat je als websitebeheerder niet zomaar meuk embed van alles en iedereen zodat dergelijke requests sneller opvallen. Een mooi voorbeeld is deze website van Arnoud. Alle data komt van blog.iusmentis.com en er is welgeteld één cookie geplaatst met een duidelijke reden. Daarom is er ook geen stomme cookie-toestemming nodig.

      1. Waarom ga je ervan uit dat Cloudflare geen data verzameld?

        Zeg ik dat?

        is het maar de vraag of CloudFlare niet stiekem ook allerlei gegevens verzameld
        Nee dus. Ik weet het alleen niet. Websites vermelden ook niet in hun cookie-popups en dat zou misschien wel moeten gebeuren. We weten wel dat Cloudflare meeluistert met het verkeer omdat ze “ongewenste bezoekers” blokkeren, wie dat ook maar zijn. Hoe ze dat precies doen zou ik dan weer niet weten, maar ik kan mij wel voorstellen dat ze al het dataverkeer analyseren. Maar dat betekent dus dat data door een Amerikaans bedrijf bekeken kunnen worden en dat is zorgelijk.

        Geen fonts embedden is een aardige optie maar dan ben je beperkt tot de fonts van de browser self en dan moet je b.v. Comic Sans missen. 😀 Of de vele andere fonts. De script-fonts mis je dan ook. Bovendien kan een font onderdeel zijn van de stijl van een bedrijf. Op https://fonts.google.com/ is een mooi lijstje fonts te zien die best mooi staan op een website. Waaronder ook fonts voor Chinees, Koreaans en Arabische letters die bij moderne browsers veelal erg beperkt zijn. En soms gaat het er ook om dat een tekst goed leesbaar moet zijn en ook daar zijn aparte fonts voor beschikbaar. Zo zijn er fonts voor dyslectici die wel interessant kunnen zijn. (Jammer dat die website een cookie-muur mist maar wel Google tags gebruikt…) Het moderne web kan eigenlijk moeilijk zonder extra fonts…

        Sowieso kun je als ontwikkelaar gewoon even je eigen website controleren via de developer tools in je browser. Dan zie je vaak ook naast wat je website allemaal gebruikt vanuit de browser ook wat al je extensies toevoegen aan iedere website die je bezoekt! Zo heb ik een dummy statische webpagina die bestaat uit een HTML bestand en een achtergrondsplaatje en verder niets, maar bij het laden ervan zie ik onder network monitor ook een ‘detector.js’, een ‘dom.js’ en een ‘js.js’ worden geladen. Maar ik gebruik geen Javascript! Zelfs geen stylesheet. Die blijken dan aan “Wappalizer” gerelateerd te zijn. En via de Sources in developer tools zie ik ook koppelingen met Malwarebytes, NetCraft, Google Translate en een paar andere extensies.

        Maar dat gebeurt aan de browser-kant terwijl Microsoft Analytics aan de serverkant gebeurt en dus niet gedetecteerd kan worden door de bezoekers! En datzelfde geldt voor nog wel meer libraries die bij al dit soort ontwikkelomgevingen horen. Alleen node.js bestaat al uit tientallen, zoniet honderden bestanden met Javascript en het blijkt dat hier relatief eenvoudig malware aan toegevoegd kan worden. Even zoeken op “node.js malware” levert al een miljoen resultaten op, terwijl deze techniek steeds populairder wordt.

        Zo heeft een developer van open source modules in node.js zijn eigen code gesaboteerd! Geen idee waarom, precies. Kennelijk gefrustreerd dat grote bedrijven zijn code gebruikten. De bug was wel snel opgemerkt maar de schade was al gepleegd en je kunt je afvragen in hoeverre de auteur aansprakelijk kan stellen. Immers, “gebruik op eigen risico”… (Zijn overigens wel leuke anecdotes over…)

        De vraag is nu of al het werk van deze auteur misschien uit NPM verwijderd moet worden als hij kennelijk niet wil dat zijn code zomaar door iedereen gebruikt kan worden. Als developer is hij nu wel aan de kant gezet, maar hij blijft de auteur van zijn eigen code en als hij daarvan de licentie intrekt, pech…

      2. Het ‘mooie’ aan cloudflare is dat het (uit noodzaak) zelfs beschikt over de SSL sleutel van je website /

        Lijkt me niet. Hangt er ook vanaf of je TLS (SSL is verouderd) toepast op alleen het verkeer tussen bezoeker en Cloudflare, waarbij dan dat tussen Cloudflare en de achterliggende hosting in klare tekst gaat; dat is gratis, want met certificaten van Cloudflare; of dat je het hele verkeer laat TLS’en. Dan moet je zelf een certificaat hebben op het domain, betaald of gratis (bijv. LetsEncrypt). In dat laatste geval heeft Cloudflare alleen de publieke sleutel, net als elke willekeurige bezoeker van een gewone website die niet via Cloudflare loopt. De geheime sleutel heeft alleen de websitebeheerder.

        Dus: ik snap het probleem niet. Leg uit.

        / en dus ook daadwerkelijk de inhoud van de webpagina’s kan analyseren.

        Websitecontent is toch uit zijn aard openbaar? Waarom zet je het anders op een website, als je niet wilt dat iedereen het kan zien? Dus ook hier: wat is het probleem, wat is het voordeel voor Cloudflare?

        Of bedoel je eerder de verkeersgegevens i.p.v. de content? Die ziet Cloudflare inderdaad, maar de websitebeheerder niet meer, want alleen IP-adressen van Cloudflare zelf. Maar via een omweg is meer weten wel mogelijk.

        1. Troy Hunt heeft een mooie blogpost gemaakt over de voor- en nadelen van Cloudflare: https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-absolutism/

          Je hoeft inderdaad niet je private key af te geven, Cloudflare genereert een eigen key. Ze zetten (met deze key) een TLS (inderdaad geen SSL tegenwoordig :D) verbinding op met de webbrowser van de gebruiker. Aan de achterkant zetten ze wel of geen TLS verbinding met de webserver van de klant op, dit is te configureren in het control panel van Cloudflare. Feit blijft dat Cloudflare zich gedraagt als een Man in the Middle en op deze manier al het verkeer tussen gebruiker en webserver onversleuteld langs zien komen. Dat kan ook niet anders als ze hun diensten willen leveren en tegelijkertijd de gebruiker via TLS laten verbinden.

          Websitecontent is al zo’n 20 jaar niet meer per definitie openbaar. Op websites vinden we tegenwoordig al onze financiële informatie, steeds meer medische informatie, religieuze informatie, alle communicatie met familie en vrienden, pittige communicatie met partner (of niet-partner). Bijna alle apps op je telefoon communiceren met hun online backend via HTTPS. Bovendien kan Cloudflare ook bijv. alle wachtwoorden en andere POST informatie inzien die je naar een website stuurt. Als ik even snel zoek naar gevoelige websites valt al snel op dat bijvoorbeeld Grindr en Secondlove gebruik maken van Cloudflare.

          Nog meer voorbeelden zijn te zien in deze post van een Google onderzoeker uit 2017 die een lek heeft gevonden waarmee hij privé informatie uit Cloudflare kon onttrekken: https://bugs.chromium.org/p/project-zero/issues/detail?id=1139 Quote: I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.

      3. Alle data komt van blog.iusmentis.com en er is welgeteld één cookie geplaatst met een duidelijke reden. Daarom is er ook geen stomme cookie-toestemming nodig.

        Alleen jammer dat die niet werkt, want ik moet al jaren bij elke reactie mijn gegevens herhalen, onthouden zit er niet in. En er rammelt veel meer aan deze site: links naar reacties gaan naar het artikel, maar niet naar de reactie; van links naar eerdere artikelen rechtboven werkt alleen de eerste, alle andere zijn leeg en dood. Enz. enz.

        Jammer dat Arnoud niet eens wat euro’s besteedt om een handige techneut dit blog technisch goed te laten functioneren. Inhoudelijk is het namelijk ZO interessant en belangrijk, en dat meen ik.

            1. Het grootste probleem is de enorm agressieve caching. Als je een comment toevoegt aan een post dan kan het soms een kwartiertje duren voordat je die ziet verschijnen (en dan is de edit timer al verlopen). Verder zie je soms edit knoppen voor andermans posts en zie je bijna nooit een edit van je post direct verschijnen.

    2. Het “rechtvaardige belang” is, zo lijkt mij, inderdaad ook niet veel anders dan voor alle sites die CloudFlare e.d. gebruiken: vermindering serverload. Wanneer je een text-only site hebt zou het meeserveren van de fonts zomaar een vertienvoudiging kunnen zijn van het verkeer. Argument is natuurlijk minder goed te maken wanneer je andere assets in totaal ook > 100kb wegen.

      Een verbinding naar fonts.gstatic.com leidt bij mij naar een EU-gebaseerd IP adres (https://ipinfo.io/142.250.179.163). Er worden géén cookies geplaatst vanuit dat domein. En caching staat op een jaar, dus zolang je de pagina niet zou geforceerd zou herladen zou Google niet opnieuw geïnformeerd moeten worden. Helaas is het wel zo dat de CDN caches niet meer gedeeld worden zoals weleer, dus dat ene bezoek aan die site zal gelogd zijn door Google.

      Moet wel zeggen dat ik het inconsistent zou vinden dat hiervan een probleem wordt gemaakt, terwijl de EU ooit wel expliciet heeft gemaakt dat basis analytics verzamelen wél mag. Nu is dat met de Schrems-zaak met Google Analytics weer een ander verhaal, maar als ik dat verhaal goed begrijp mag daarvoor nog steeds een externe dienst gebruikt worden, met lekken van IP-adressen tot gevolg, zolang deze maar voldoet aan de GDPR-wetgeving en gegevens in EU blijven.

    3. Sowieso zorgt het gebruik van Google Fonts rechtstreeks via Google wel ervoor dat de fonts altijd up-to-date zijn. Een font kan immers besmet raken door malware, zeker als je daar een eigen kopie van moet bewaren. Fonts bevatten veelal uitvoerbare code die lijntjes en bochten tekenen op je scherm en dus mogelijk ook extra, kwaadwillende code kunnen bevatten. Dus ik weet niet of ik blij word van sites die zelf hun fonts beheren.

      Als je dit wilt is het niet al te moeilijk om regelmatig automatisch de laatste versie the downloaden (en beschikbaar te maken – of een update bericht te sturen aan een beheerder).

  5. Ik weet dat het niet helemaal gerelateerd is aan het onderwerp, maar zou het een idee zijn om ook wat alternatieve fonts voor jou blog te definiëren Arnoud?

    De content van de artikelen verschijnen in “font-family: Georgia, serif;” en dat is nogal beperkt en bovendien alleen ondersteund op Windows. “font-family: Cambria, Cochin, Georgia, Times, ‘Times New Roman’, serif;” Zal veel meer ondersteuning vinden op Mac en iOS, Android, en Linux.

    En ook handig, niets downloaden van externe bronnen

    1. Doorlezen. Want ik heb het over data-limieten die sommige hosts toepassen op dataverkeer. Vooral de goedkopere hosts doen dit. Veelal ook bij de gratis hosts. Dan heb je een datalimiet van 1 GB tot 4 TB, afhankelijk van de host. Da’s per maand. Dan is 100 KB misschien wel weinig, maar nadat 10.000 keet het font is gedownload dan is de kleinste limiet al op. En dat alleen maar voor 1 font.

      1. Is waar. Staat tegenover dat als je veel webpagina’s van één site dezelfde fontresource laat gebruiken, het downloaden per gelezen pagina erg meevalt, want je mag toch hopen dat de access provider, of de browser, of allebei, van de lezer/bezoeker die na de eerste keer cachet?

        Maar als je een miljoen verspreide lezers hebt, die allemaal maar één kleine HTML-pagina lezen, én dus die 100 kB aan fontdata moeten ophalen, dan is het inderdaad ongunstig.

        1. Probleem is alleen dat veel gebruikers ook antivirus software gebruiken die daarbij ook de computer “optimaliseren”. McAfee doet dat onder andere door regelmatig de browser cache leeg te gooien en dan ook cookies te verwijderen. Erg vervelend, want die functie is best lastig uit te zetten. En andere virusscanners hebben vergelijkbare toepassingen naast hun functie als scanner wat best irritant is. (Norton schijnt daarbij ook nog eens cryptomunten te minen op de PC van de gebruiker, die dan deels voor de gebruiker zijn…)

          Het probleem is vooral van belang bij kleinere websites met beperkt dataverkeer. Een miljoen bezoekers die dat bestandje van 100 KB ophalen zou met onbeperkt dataverkeer geen probleem moeten zijn. Maar er zijn best veel kleine websites die een limiet hebben van 1 GB tot 4 TB, voor zover ik kan zien. En met 1 GB per maand is 1000 keer 100 KB al een probleem…

    2. Gefeliciteerd. Je hebt het geluk om te wonen in een land met zo’n beetje de hoogste graad breedbandverbindingen ter wereld, direct naast één van de grootste internet exchanges. Al zegt dat ook niet alles. Een jaar of 10 geleden heb ik nog 1/4 DSL lijntjes geleverd bij ambassades in Den Haag. Dat was het snelste dat beschikbaar was toen.

      Denk nu eens aan landen waar het wat minder goed geregeld is, dan hoef je niet eens heel ver weg te gaan. Wallonië is een goed voorbeeld maar in landelijke gebieden in Frankrijk, Duitsland en Polen ga je ook niet veel breedbandverbindingen vinden. Dan zijn we de westerse 1e wereld Europa nog niet eens uit…

  6. Interessant, iedere keer als je een website met TLS bezoekt waarvan de leverancier van het certificaat uit de US komt, stuurt je browser een OCSP verzoek naar dat bedrijf in de US om te kijken of het certificaat nog wel valide is. (Mits stapling aan staat) Deze CA weet dan je IP adres, je browser en de website die je dan bezoekt. Maar daar hoor je niemand over 🙂

  7. Vermits meer dan 99% van de websites perfect kan werken met de ingebouwde fonts zie ik zelfs geen noodzaak om een font bestand op te halen. Meestal is het onkunde of luiheid om een specifieke externe font te gebruiken.

    Voor de resterende minder dan 1% van de websites zal de 100Kb echt niet uitmaken.

    1. Het is een nogal vreemde conclusie om te stellen dat een extern font gebruiken onkunde of luiheid betreft, wanneer het gebruik van een ingebouwd lettertype vele malen sneller en eenvoudiger is te implementeren. Iemand die niet voldoende kundig is, of lui, zou juist voor een dergelijk ingebouwd lettertype kiezen. De behoefte aan externe fonts is juist het gevolg van mensen die er enige moeite in willen steken om een website een eigen identiteit en leeservaring te bieden. Ik ben persoonlijk blij dat ik niet het hele Internet in 12pt Times New Roman hoef te lezen…

      Deze uitspraak legt wel een aardige bom onder het ophalen van ook maar enig middel uit een externe bron, wat op Internet een gangbare praktijk is. Een video embedden? Een plattegrond opnemen van een externe dienst? Een veelgebruikte library uit een CDN halen? Je afbeeldingen door een image host laten serveren? Een Twitter feed opnemen? Gebruik maken van een extern reactie-platform? De meeste van dat soort diensten bevinden zich niet in de EU, dus tsja…

      1. Je zou ook kunnen gaan cachen op basis van een content-hash van een resource, en dan als site een content-hash opsturen (al bij de link), dan kun je alsnog cross-site cachen, zonder (te veel) gegevens weg te geven. Wel even zorgen dat je voor die content-hash niet redelijkerwijs een collision kunt genereren.

        Mechanismes voor hashing bestaan trouwens al onder de noemer “subresource integrity”.

        1. Dan include ik een uniek .js bestand van en kijk hoe lang het duurt om deze te laten. Als dat bijna instant is dan ben je blijkbaar recent op die website geweest 😉 Dat noemt met een timing attack en is ook daadwerkelijk praktisch toepasbaar. (Maar niet meer met die nieuwe Firefox functie die cache op een per-domein basis bijhoud.

      2. Er zijn veel “templates” die standaard één of andere Google-font gebruiken. Het is dan meestal prutsen om die eruit te krijgen.

        Mensen die een website een deftige eigen identiteit en leeservaring willen geven, zijn al snel ettelijke 10.000’en euro’s kwijt aan het bijhorende onderzoek. Da’s echt niet vanzelfsprekend om goed te doen, er is een reden waarom sommige fonts veel gebruikt worden. Als je 10.000 euro’s aan onderzoek hebt uitgegeven, is de font zelf hosten dan “peanuts” en trouwens een goede praktijk.

        Links en recht wat zaken van het internet gebruiken en dan zonder zelfs zelf te hosten, is om problemen vragen. Vaak ook gewoon illegaal, wegens schending auteursrechten e.a..

        1. Op het moment dat je gebruik maakt van een template waarin een extern font gebruikt wordt, dan is het uiteraard meer werk om deze eruit te halen dan om hem erin te laten zitten. Dat gezegd hebbende, als het gaat om een template waar je toegang toe hebt en zelf kunt wijzigen, is het voor iemand met was basiskennis van HTML/CSS vrij triviaal om te doen.

          Ik ben het niet met je eens dat je (veel) geld zou moeten steken in één of ander onderzoek om een eigen identiteit of leeservaring aan een (web)document te geven. Dat is iets dat je automatisch doet op het moment dat je voor een bepaalde layout en/of lettertype kiest. Als ik mijn documenten in Word altijd opstel in 11pt Century Gothic in plaats van 12pt Calibri of Times New Roman, dan doe ik dat al. Mijn persoonlijke website maakt ook gebruik van een aantal externe fonts omdat die mijn pagina’s de stijl geven die ik wens over te brengen, en daar heb ik echt geen marktonderzoek voor gedaan. Dat gaat niet via Google Fonts, maar ik neem aan dat andere leveranciers net zo min toegestaan zouden zijn volgens deze uitspraak.

          Het is ook onzin om te stellen dat het gebruik maken van extern gehoste resources vaak illegaal zou zijn – er zijn talloze diensten die juist zo werken en het internet hangt aan elkaar van integraties tussen verschillende diensten en sites. Je hebt een punt dat bij het gebruik van extern gehoste resources je er op zult moeten vertrouwen dat die resources en leveranciers bona fide zijn, maar dat is niet exclusief aan het internet. Je komt dan op het punt dat je ook je eigen groente moet gaan verbouwen, omdat het vragen om problemen is wanneer je eten op je bord legt dat door andere mensen is klaargemaakt.

    1. Het is de webbrowser, niet de webserver, die de Referer header zet end zendt. Het versturen van een Referer header is helaas default gedrag van een webbrowser. Er zijn diverse plugins voor webbrowsers om het versturen van de Referer header tegen te gaan. Een webserver kan met de html een Referrer-Policy header meesturen. In die Referrer-Policy header kun je bijvoorbeeld instellen dat de Referer header alleen meegezonden moet worden in andere requests aan dezelfde server, maar niet verzonden moet worden naar servers in een ander domain. Als je gebruikt wilt maken van Google fonts, zou je dus zo’n Referrer-Policy mee kunnen sturen. Google ziet dan wel dat jij fonts download, maar niet voor welke website. Overigens wordt Referrer-Policy nog niet door alle webbrowsers ondersteund. Internet-Explorer en Safari op iOS ondersteunen het niet. Ik denk dat veel reclameboeren het jammer vinden als de Referer header niet aankomt. Misschien een leuke taak voor de AP om de privacy-consequenties van het default meesturen van Referer headers eens te belichten.

  8. Net als de cookie-wet had men de gebruiker zelf hier verantwoordelijk voor moeten stellen. Je wil geen cookies? Stel u browser zo in dat u geen (third-party) cookies kunt ontvangen, en white-list sites waar u dit wel wil. Geen cookie walls. Een kleine reclame campagne voor bewustwording, en klaar!

    Hier kun je instellen dat je, mocht JIJ daar problemen mee hebben (en niet je overheid, die gaat dat niets aan, de verbinding is tussen MIJ en de website/service), geen Google fonts kunt gebruiken. Val je netjes terug naar Georgia of Times New Roman of iets dergelijks. Dan mogen websites externe plaatjes op een Amerikaanse server blijven gebruiken. Kunnen mensen die er niets om geven sneller browsen. Wordt er bandbreedte bespaard, etc.

    Door de verantwoordelijkheid bij de website-bouwer te leggen, zodat die ineens moet checken of dat IP anders behandeld dient te worden. In plaats van de overheid te laten bepalen of Google je IP sturen nu inbreuk is op je privacy (met je Chrome browser, Google email, Youtube videos, Google Calendar, Google Assistant, etc.), gewoon de gebruiker verantwoordelijk stellen voor iets wat hij/zij zelf aan kan passen in de browser, het gemakkelijkste en gepersoonaliseerste van al.

    Valt er dan een informatie-website van de overheid om, dan moet je daar meteen naar kijken, focus je je op de echte belangrijke dingen.

    En Google hoeft geen bait-en-switch meer te doen: Die Font-service was gratis en ontworpen om data binnen te slurpen. Wil Google de snelheid van het internet of gebruikersgemak dienen, dan hadden die fonts wel op een non-profit server gestaan “openwebfonts.org”, met bijdragen van Apple, Microsoft, Adobe, Google, … en een wekelijks opschonen van de logs. Of de Duitse overheid maakt zich nuttig, en gebruikt 1 boete per maand om die fonts zelf te hosten op een gesponsorde Hertzner server. Dit heeft nu lang genoeg geduurd. En omdat je de buitenlandse websites die ook aan Duitsland leveren niet beboet, werk je in de hand dat webmasters naar buitenland vluchten, en beloon je de reeds gevluchte webmasters met een server in Canada.

  9. Op de rijksweg tussen Duitsland en Nederland kun je 150 km/uur blijven rijden, en dat is tegen de Nederlandse wet. Nu ga je niet Duitse autobestuurders een boete geven als ze te hard rijden, dat zou te boerenverstand zijn. Nee, je gaat aan de wegenbouwer geld vragen, omdat men te hard kan rijden daar. De wegenbouwer heeft geen gerechtvaardig belang om dat mogelijk te maken, maar had ook zelf meer bordjes of plastic drempels kunnen plaatsen. En je gaat klagen waarom ze in Duitsland zo hard mogen rijden. En het boetegeld geef je aan de Duitse automobilist die express hard op het gaspedaal drukte om te kijken of deze de snelheidslimiet kon overtreden.

    Waanzin!

    Als je niet wil dat je een connectie maakt met Google servers, omdat dit schadelijk is aan je privacy, maar het gebeurd toch, omdat je zelf geen maatregelingen treft, dan ben je onbekwaam bezig. Enige privacy schade is het gevolg van jouw individueel handelen. Ga je dan klagen, of de schuld bij een ander leggen, dan kun je dus niet met privacy omgaan. De overheid zou een toezichthouder moeten instellen, zodat je opnieuw kan leren met geld of privacy om kan gaan, zonder schulden en inbreuk. Je laat immers een kind ook niet een auto besturen.

    1. Helemaal mee eens. Dat eeuwige cookiepupopgezeik had ook voorkomen kunnen worden het een voorlichtingscampagne over hoe thirdpartycookies te weigeren in je browser. En browserbouwers te verplichting dat die er is en goed werkt. Goedkoper, beter, effectiever en met veel minder overlast. Win-win, iedereen blij.

      Maar nee, EU-parlementariërs snappen geen IT en komen met zo’n draak aanzetten, waar iedereen alleen maar last van heeft, en waardoor het aantal cookies ook nog eens NIET afneemt.

  10. Dit is dus een probleem, om dezelfde reden als waarom Google Analytics een probleem is. Als website forceer je zo dat mensen hun persoonsgegevens (IP-adres en/of cookie) naar Amerika gaan. En hier is er ook een eenvoudig alternatief, aldus de rechtbank: je mag die fonts gewoon lokaal hosten. Je hebt dan wel een beetje overhead en extra downloads.

    En YouTube videos embedden op een website dan? Dan gaan de persoonsgegevens (inclusief nog meer, als de gebruiker ingelogd is bij Google) naar Amerika. Hoef je niets een op Afspelen te drukken. Eenvoudig alternatief: gewoon die video lokaal hosten, met een klein beetje overhead en extra downloads?

    Of… volledig accepteren dat faciliteren van data doorspelen naar Amerika een invasie op de privacy van je burgers inhoud. Website bouwers aansprakelijk stellen bij hotlinken van een plaatje op ImgUrl naar een Duits IP address. Googlebot verplicht laten verwijderen. YouTube en Facebook verboden maken, of burgers verklaring laten tekenen dat ze snappen hoe ze inbraak op privacy van zichzelf en vrienden faciliteren. Duitse ISP’s blokkeren natuurlijk alle links naar Google Webfonts en Google Analytics servers, en je moet een welbewuste en weloverwogen opt-in doen. Amerikaanse ambassadeurs op matje roepen. Geen sleepwet-data meer delen over terroristen.

    Halfbakken en willekeurig nu. GDPR niet bedoeld om website bouwers te pesten. GDPR bedoeld om grootschalig data-drain uit Europa tegen te gaan. De rijke adverteerders vinden wel een oplossing om om de wet heen te werken als ze niet specifiek aangepakt worden. Dan betalen ze maar een privacy-invasion-tax of iets dergelijks concreets. Do Not Track-header vakkundig om zeep geholpen. Als mensen het hebben over ingewild tracken, dan bedoelen ze allemaal een handvol bedrijven met cross-site cross-browser advertentie tracken, en niet een website met Google fonts of een webserver die requests logged.

    1. Er zijn steeds meer websites die het embedden van video en tweets oplossen door een ‘content-warning’ te tonen. Als een gebruiker toestemming heeft gegeven in de cookie pop-up dan tonen ze gewoon de YouTube video en tweets. Heeft de gebruiker dat niet gedaan, dan zien ze een melding dat de content geblokkeerd is met een knop om deze (bewust) alsnog te tonen of door te klikken naar de betreffende website. Content als tweets zijn ook heel geschikt om te kopiëren en lokaal te hosten, al weet ik niet direct wat voor juridische haken daar aan zitten

      Wat is er overigens mis met de Google bot? Die link zie ik niet helemaal.

      Wat mij betreft wordt heel snel gewoon besloten dat: – Embedden van third party content van een niet-Europees bedrijf verboden is
      – Volgen van gebruikers over meerdere websites verboden wordt
      – Gepersonaliseerde reclame tonen alleen is toegestaan met informatie die is verzameld binnen het eigen platform en uit te schakelen moet zijn door de gebruiker.

      Mooie van zulke regels is dat ze heel duidelijk zijn. De impact voor websitebeheerders is op korte termijn enorm. (Maar, heel eerlijk? Als je daar als beheerder nu nog niet over hebt nagedacht dan heb je al jaren onder een steen geleefd.) Op middelange termijn is de impact verwaarloosbaar. Impact voor gebruikers is er nauwelijks

    2. Websitebouwers moeten leren dat ze aan dezelfde regels en normen onderworpen worden dan andere bedrijven en personen. Het is echt niet zo moeilijk om een website volgens de regels te maken. 6 jaar na de invoering van de AVG moet dat zelfs een vanzelfsprekendheid zijn voor de privacy regels.

      Nu goed ik krijg ook nog wel eens websitebouwers die jammeren over een schikkingsvoorstel voor het illegaal hergebruiken van een afbeelding/foto. Tja.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.