Maps, Videos and Fonts Without Leaking Visitor Data

Two sets of rules interlock here, and they test different things. Section 25 of the German Telecommunications and Digital Services Data Protection Act governs access to the end device: storing information on the device and accessing information already stored there is only permitted with consent — unless the operation serves solely to transmit a message, or is strictly necessary to provide a service the user has explicitly requested (TDDDG, Section 25). The General Data Protection Regulation separately governs the processing of the data itself. That includes transmitting the IP address to a foreign server even when not a single cookie is set. Passing the first test still leaves the second one ahead of you.

How concrete this can get is shown by a ruling of the Munich Regional Court I. A site operator had loaded a typeface dynamically from the vendor's server, which transmitted every visitor's IP address there. The court found this to infringe the general right of personality and awarded the claimant 100 euros (Munich Regional Court I, case no. 3 O 17493/20) in damages, plus an injunction (Munich Regional Court I, case no. 3 O 17493/20). Two elements of the reasoning reach beyond the individual case. First, the dynamic IP address was classified as personal data, because the operator has legal means to have the person behind it identified. Second, the transfer to a server in the United States mattered, for which no adequate level of protection had been established at the time (Munich Regional Court I, case no. 3 O 17493/20). The ruling is uncomfortable in practice precisely because a data-frugal alternative is right there: serving the same font from your own domain is not an elaborate workaround, it is the ordinary way of doing it.

The second landmark decision comes from the Court of Justice of the European Union. It is older but more fundamental. In the Fashion ID case, brought by the consumer association Verbraucherzentrale North Rhine-Westphalia, the subject was a social media button on a fashion retailer's website. The Court found that personal data was transmitted to the button's provider when the site was loaded, „without that visitor being aware of it and regardless of whether or not he or she is a member of the social network Facebook or has clicked on the ‚Like‘ button“ (CJEU, C-40/17). The site operator was held to be a joint controller — but in a limited way: not for whatever the provider does with the data afterwards, but for „the collection of the personal data of visitors to its website and their disclosure by transmission“ (CJEU, C-40/17). That is exactly the part the operator decides on, by placing the embed.

The reasoning carries over to maps, videos and fonts without any strain: there too, the page load alone triggers the transmission, there too the person has no idea, and there too the operator decides whether that connection exists at all. The German Data Protection Conference draws a practical conclusion about timing from this. Additional services such as a map service, a chat or a contact form are, on their reading, not requested simply by opening the page: users „request“ such functions only once they explicitly make use of them (German Data Protection Conference, guidance for providers of telemedia services). Access may therefore begin only when the function is actually used — not merely because it exists somewhere on the page.

Web fonts are the norm today: 87 percent (HTTP Archive Web Almanac) of all websites examined use at least one. How they are obtained, however, is very unevenly distributed. Only 28 percent (HTTP Archive Web Almanac) of desktop pages and 34 percent (HTTP Archive Web Almanac) of mobile pages serve their fonts exclusively themselves; 57 percent (HTTP Archive Web Almanac) of desktop pages load at least one font from one of the large font services. The switch is nevertheless the easiest item on the whole list, because nothing changes about the visible result: same typeface, same weights, same look — just a different source.

Legally the route is uncomplicated for the widely used open font families, because their licences explicitly permit redistribution and self-hosting. For purchased typefaces it is worth reading the licence to see whether web font use on your own servers is included; many foundries include it, some sell it as a separate component. Technically, though, the expectation of a speed gain deserves an honest framing: web.dev states that a self-hosted font should on paper deliver better performance because it eliminates a third-party connection setup, but that in practice the differences are less clear cut and depend on how your own files are delivered (web.dev). The privacy gain depends on no measurement at all — it consists in the connection no longer existing.

One final point about font choice that is often overlooked: fewer weights mean fewer files, shorter loading time and less shifting in the layout. Embedding a family in eight weights while using two of them means downloading six files for nothing. And when a typeface is only needed for headings, it can be reduced to the characters actually required — web.dev notes that removing unused glyphs significantly reduces the file size (web.dev). How text volume and readability interact is covered in the article on writing website copy people actually read.

An embedded video player is the most expensive embed on the whole list — in data as well as in loading time. The pattern that solves both is called a facade: instead of the player, the page first shows only a static preview image with a play symbol that looks the same but loads nothing. Only the click replaces the facade with the real player. The order of magnitude from the example in the Lighthouse documentation: the facade weighs 3 KB (Chrome for Developers, Lighthouse), while the player loaded on interaction weighs 540 KB (Chrome for Developers, Lighthouse).

In data protection terms the difference is even sharper than in weight. Before the click there is no connection to the video provider: no IP transmission, no cookie, no third-country question. After the click there is a deliberate action — exactly the situation the supervisory authorities describe for additional functions (German Data Protection Conference, guidance for providers of telemedia services). The prerequisite is that the area says, before the click, what is about to happen: which provider, what gets transmitted, and where to read up on it. That notice is not legal boilerplate, it is one normal sentence in normal language.

For short clips — thirty seconds of the workshop, a walkthrough, a product note — the fourth variant is particularly worthwhile. A well compressed file in a modern format often weighs less than the player alone, is served from your own domain, and needs neither a release nor a notice. For long videos, an entire media library, or content that is meant to earn reach on a video platform anyway, the facade remains the better route. That the release area has to be keyboard-reachable and labelled is not optional extra polish: it is a control like any other and falls under the requirements described in the article on an accessible business website.

Every foreign domain costs more than the file it delivers. Before the first byte arrives there is name resolution, connection setup and encryption negotiation — and all of that again for every additional server. On top of that comes an effect the Web Almanac describes well: third-party content pulls in third-party content of its own. The median depth of such inclusion chains is 3.4 (HTTP Archive Web Almanac), and 34 percent (HTTP Archive Web Almanac) of all chains are longer than one link. So in roughly a third of cases an embedded resource drags further ones along that do not appear in your own source at all — and that you therefore will not see if you only search the HTML.

The honest part of the story: a speed gain is likely but not automatic. web.dev explicitly points out that the advantage of self-hosted fonts is less clear cut in practice than in theory and depends on the route and protocol used to deliver your own files (web.dev). Serve those files with a long cache lifetime, modern compression and a current protocol and you come out ahead. Put them on a slow server and you have only moved the problem. The privacy gain, by contrast, materialises either way — and fewer requests are still a gain even when the stopwatch does not show a dramatic jump.

What stands out about this list is how little of it is a question of expertise. Almost every item describes a default setting: where do fonts come from? Where do images live? When does a player load? Anyone who has to answer those questions afresh with every rebuild will eventually answer one of them wrongly — not out of carelessness, but because a copied embed line takes ten seconds and the clean route takes half an hour. So the more interesting question is not how to clean up, but how to keep the same pile from accumulating again within a year.

The difference does not show on publication day but on the fifth change request: when a subpage is added, a video swapped or the typeface changed, the default setting decides whether a foreign connection appears again. In XICflow that default is set to be data-frugal — fonts, symbols and media come from your own domain, maps and videos require a release. Which building blocks are available for that is listed in the overview of features; how a site goes from idea to publication is shown in the process at a glance, and what the result looks like is shown by the example sites.