Googles FLoC auf Uberspace 7 blocken

Googles neues FLoC bezieht prinzipiell jede Website ein die nicht opt-outet.
(Hier sehe ich noch einige relativ große Rechtsstreitigkeiten auf Google zukommen).

Google sichert seinen Umsatz durch Werbung, der öffentliche Trend hin zu Datenschutz trieb die Browser immer weiter zum Blockieren von Drittanbieter-Cookies, eben jenen die Seitenübergreifendes Tracking ermöglichen. Selbst Google Chrome muss dies auf Druck der Öffentlichkeit nun umsetzen.
Da Google finanziell von eben jenen kleinen Textschnipseln abhängt ist Google gezwungen eine Alternative zu finden. Der Trick mit dem sie die DSGVO und die Privatsphärebedenken umgehen ist wie so üblich die Verhinderung von Einzel-Tracking, per Design erlaubt FLoC nur Tracking von so genannten Interessensgruppen. Wer hier weiter gehen will liest auf GitHub weiter, hier soll es ja um das Verhindern auf Uberspaces gehen.

Zum Blocken ist ein Anpassen des Headers notwendig. Damit ist nicht <head>der HTML-Header</head> gemeint:

Permissions-Policy "interest-cohort=()" muss in jedem HTTP-REPLY mitgegeben werden.

Sehr sehr trickreich von Google. Ich schätze mal dass genau 5% aller kleinen bis mittelgroßen Websites überhaupt die Möglichkeit auf einen OptOut haben, weil es der Hosting-Dienstleister schlicht nicht möglich macht (Hallo Anwälte, ich gebe euch hiermit schon Ansätze gegen Google vor)

Kurze unqualifizierte Erklärungen für die Laien von jemandem der sich selbst noch nicht als Experte ansehen würde: Nach dem Three-Way-Handshake muss der Server auf jede Anfrage reagieren, auf ein HTTP-GET (Anforderung einer Internetseite eines Users) müssen also Pakete zurückgegeben werden. In diesen Antwortpaketen muss der Text im HTTP-REPLY Header mitgegeben werden. Das sieht hier dann eben so aus, könnt ihr mit jedem curl nachvollziehen:

StatusCode        : 200
StatusDescription : OK
RawContent        : HTTP/1.1 200 OK
                    Transfer-Encoding: chunked
                    Connection: keep-alive
                    Vary: Accept-Encoding,Accept-Encoding
                    Pragma: no-cache
                    X-UA-Compatible: IE=edge
                    X-Xss-Protection: 1; mode=block
                    Permissions-Pol...

Zurück zum Thema: auf Uberspace 7 geht das in der SSH-Shell so:

uberspace web header set / Permissions-Policy "interest-cohort=()"

und genau deswegen solltet ihr alle Uberspace nutzen.
Für alle Fortgeschritteneren geht das so: FLoC opt out (zgp.org)
Für alle die bei Uberspace bleiben wollen geht es hier weiter.
Für alle die bei etwas anderem sind geht in dieser großartigen Auflistung weiter.

Selbstverständlich habe ich dies hier auch getan – wie im Code oben ja schon zu sehen.
Ich würde sogar versuchen eine Let’s Encrypt Mäßige Welle zu starten um genau diesen Optout mehr und mehr zum Standard zu machen. Nur so bekommt man solche Geschäftspraktiken im Keim erstickt. Größere Webhoster die eben jene Permissions-Policy genau so rigoros als Standard für alle setzen wie Google diejenigen ohne Eintrag ungefragt kategorisiert.

Dank an den Uberspace Support, der immer super unterstützt und oft im genau richtigen Maß Tipps gibt ohne dass gleich alles Vorweg genommen wird.

Update: WordPress ohne Apache-Anpassungsmöglichkeit

Ich erwähnte oben dass es nicht jedem möglich ist den Apache-Reply-Header einfach so anzupassen. Viele Websites laufen tatsächlich auf Basis von WordPress und das geht in dem Fall dann so:

Das hier muss in eure functions.php, entweder via SSH oder über den Dateieditor in eurem Theme von WordPress.

add_filter(
	'wp_headers',
	function ( $headers ) {
		if ( empty( $headers['Permissions-Policy'] ) ) {
			$headers['Permissions-Policy'] = 'interest-cohort=()';
		} elseif (
			! empty( $headers['Permissions-Policy'] )
			&& false === strpos( $headers['Permissions-Policy'], 'interest-cohort' )
		) {
			$headers['Permissions-Policy'] .= ', interest-cohort=()';
		}

		return $headers;
	}
);

Der Code ist von Paramedo, die ich hier im Beitrag schon mindestens drei mal verlinkt habe.
Habt ihr die Möglichkeit den Apache oder nginx Header anzupassen, dann tut das bitte auch über die Apache oder nginx, diese Variante ist sicherer als WordPress-Files.

Aktueller Stand zur Geschichte

Ich möchte hier einmal laufend aktualisieren was auf dem Gebiet so passiert: