Does TYPO3 set cookies in the frontend at all?

Not without a reason. A frontend session cookie appears once there is a session, for instance in a protected area with a login, or a shopping basket. The backend is different, it has a login cookie, but that concerns editors rather than visitors. This is why an informational site built on TYPO3 can work without a consent banner. This site does exactly that.

Is hosting fonts locally enough?

For the fonts question, yes, and it is the easiest step of all: download the font files, ship them with the site, reference them from CSS. No connection to a third-party server happens when the page loads. As a side effect the page usually gets faster, because an extra DNS lookup and a second connection setup disappear.

Do we need a consent tool?

Only if something is embedded that requires consent. The order often gets reversed: a tool is bought first, and then nobody asks whether the embeds were necessary in the first place. The better route runs the other way. Go through the list of third-party services first and check what can be replaced. Whatever remains determines whether a tool is needed, and how extensive it has to be.

What about analytics? We do want to know what gets read.

That is a legitimate interest, and there are several gradations. Evaluating server logs works without cookies and without any script in the browser. Self-hosted analytics software can be configured so that nothing personally identifiable is stored. What matters is being honest with yourself: collecting numbers nobody reads regularly means gathering data without a purpose. In data protection terms that is the worst possible starting point.

TYPO3 and Privacy: Cookies and Embeds

TYPO3 itself needs very little in the frontend. Almost everything that makes a banner necessary comes from what somebody added on top: fonts, maps, videos, analytics.

What TYPO3 does by itself

The core is restrained. A page without a login, without a basket and without a form session sets no cookie in the frontend. The session cookie appears once a session is needed.

The backend is different, where a login cookie is necessary. It only affects logged-in editors, not visitors to the website, so it plays no part in the question of a frontend banner.

That leaves the server logs. They are written whenever a file is served and contain the IP address among other things. This is neither a cookie nor a matter of consent, but a question of retention periods and of describing them in the privacy statement.

Where the banners really come from

In practice almost every consent prompt comes from something added on. The list is short and repeats itself in nearly every project.

Fonts from a foreign server. Loading the page opens a connection to a third party before the visitor has decided anything.

Embedded maps. The map service loads scripts and usually sets cookies as soon as the map is part of the document, whether or not anybody uses it.

Videos from a video platform. The same pattern. Some providers offer a more privacy-friendly embed mode, which improves the situation without resolving it.

Analytics and advertising tags. Here consent is rarely in dispute.

Icon fonts, mapping libraries, scripts from a delivery network. The most easily overlooked item, because it is invisible on the page and often comes with a purchased template.

The route that makes the question smaller

Serve everything static locally. Fonts, icons, libraries. They live in the project, go through the asset pipeline, generate no outbound connection. What that does to load times is covered under page speed work.

Maps as an image with a link. A static map section with a link to a route planner covers the real need almost every time. Anyone who genuinely needs an interactive map can load it after a click.

Load videos on click. Preview image and play button sit locally; the connection to the platform happens once somebody wants to watch. This is also the faster solution, since an embedded video otherwise pulls a considerable amount of data during page load.

Forms without a detour. A form processed in your own system needs no consent for the processing itself, but a clear description of what the entries are used for and how long they are kept.

If a genuinely needed service remains at the end, a consent tool is the right answer. By then it is a deliberate decision for a specific purpose rather than a blanket precaution.

What belongs to this in the backend

Data protection does not stop at the frontend. Data accumulates in the backend that few people think about: form submissions left sitting in the database, logs of editorial activity, old accounts belonging to people who left long ago.

The routines for this are unspectacular. Give form data a retention period and delete it automatically, for example through a task in the scheduler. Disable accounts when somebody leaves rather than at the next audit. Grant permissions so that nobody has access to data they do not need for their work.

The side effect that gets underestimated

A site without third-party services is not only easier in data protection terms, it is technically calmer. Every external call is a possible outage, a possible delay and a dependency on somebody whose changes you do not control.

This site is the experiment: no third-party resources, no cookies, no banner. What that means in detail is set out in our privacy statement.

One clear note on the legal side: this text describes the technical part. Whether a specific embed requires consent is a legal question, and in case of doubt it belongs with somebody qualified to answer it.

Cookies, Consent and Embeds in TYPO3