Version 2.4 vom 30. August 2026 (ursprüngliche Version 1.0 vom 12. Mai 2026).
Version 1.0 beschrieb einen Dienst, den es nicht gab. Sie wurde nicht aktualisiert, sondern vollständig neu geschrieben, und es ist redlicher, dies hier zu sagen, als die Ersetzung stillschweigend vorzunehmen: Wer die vorherige Fassung gelesen hat, hat unzutreffende Angaben erhalten und muss wissen, worin.
Sechs namentlich genannte Cookies standen darin und wurden nie gesetzt. session, csrf_token, cookie_consent, lang_pref, theme_pref und last_visit hat es nie gegeben. Eine Cookie-Richtlinie, die Cookies aufzählt, die der Dienst nicht setzt, ist nicht etwa zu streng, sie ist unzutreffend: Sie hindert den Leser daran zu überprüfen, was tatsächlich in seinem Browser liegt, und sie untergräbt das Vertrauen in die Aufzählung, auf die es ankommt.
Zwei Einwilligungsmechanismen wurden angekündigt und existierten ebenso wenig. Version 1.0 verwies auf ein Einwilligungsbanner, das beim ersten Besuch angezeigt werde, und auf einen Link "Meine Cookies verwalten" am Fuß der Website. Keines von beiden gibt es. Ein Nutzer, der seine Wahl überdenken wollte, suchte nach einer Schaltfläche, die nicht vorhanden war.
Die angeführte Rechtsgrundlage war aufgehoben. Version 1.0 verwies auf Artikel 129 des Gesetzes vom 13. Juni 2005 über die elektronische Kommunikation. Dieser Artikel wurde durch Artikel 256 des Gesetzes vom 21. Dezember 2021 mit Wirkung vom 10. Januar 2022 aufgehoben. Maßgeblich ist seither Artikel 10/2 des Gesetzes vom 30. Juli 2018, und zuständige Behörde für Tracking-Technologien ist die Datenschutzbehörde und nicht mehr das BIPT.
Die vorliegende Version beschreibt ausschließlich, was tatsächlich gesetzt und gelesen wird, und sie ist kurz, weil die Wirklichkeit es ist.
Die vorliegende Richtlinie erfasst die Präsenz-Website gunbix.com und die unter app.gunbix.com erreichbare Anwendung. Sie ergänzt die Datenschutzerklärung, auf die sie für alles verweist, was die Verarbeitung personenbezogener Daten betrifft.
Ein Cookie ist eine kleine Textdatei, die beim Aufruf einer Website auf dem Endgerät des Nutzers abgelegt wird. Cookies im Sinne dieses Dokuments gleichgestellt sind ähnliche Technologien: Pixel, Tags und lokaler Speicher des Browsers.
Ihr Setzen und ihr Auslesen richten sich nach Artikel 5 Absatz 3 der Richtlinie 2002/58/EG, der sogenannten "ePrivacy"-Richtlinie, in belgisches Recht umgesetzt durch Artikel 10/2 des Gesetzes vom 30. Juli 2018 über den Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, sowie nach der Verordnung (EU) 2016/679 für die daraus folgenden Verarbeitungen personenbezogener Daten.
Diese Bestimmung hat Artikel 129 des Gesetzes vom 13. Juni 2005 über die elektronische Kommunikation ersetzt, der durch Artikel 256 des Gesetzes vom 21. Dezember 2021 mit Wirkung vom 10. Januar 2022 aufgehoben wurde. Seit diesem Zeitpunkt ist in Belgien die Datenschutzbehörde für Tracking-Technologien zuständig und nicht mehr das BIPT.
Die Regel lautet: Ein Cookie, das für die Erbringung eines vom Nutzer ausdrücklich gewünschten Dienstes unbedingt erforderlich ist, bedarf seiner Einwilligung nicht. Jedes andere Cookie bedarf ihrer.
Die Präsenz-Website besteht aus statischen Seiten. Sie enthält kein Skript zur Reichweitenmessung, kein Pixel, keinen iframe, keine entfernte Schrift und keinen Bestandteil eines Dritten. Ihre Content-Security-Policy untersagt dem Browser im Übrigen, irgendeine externe Herkunft zu kontaktieren.
Es wird dort kein Cookie gesetzt.
Eine einzige Information wird im Browser gespeichert, im lokalen Speicher und nicht in einem Cookie:
| Schlüssel | Inhalt | Wann sie geschrieben wird | Dauer |
|---|---|---|---|
gx-theme |
hell oder dunkel |
Nur wenn der Nutzer den Umschalter für das Erscheinungsbild selbst betätigt | Bis zur Löschung durch den Nutzer |
Dieser Wert wird niemals an einen Server übermittelt, erlaubt keine Identifizierung und wird nur infolge einer ausdrücklichen Handlung des Nutzers geschrieben. Er fällt damit unter die Ausnahme des Artikels 5 Absatz 3.
Die Anwendung setzt kein Authentifizierungs-Cookie. Das ist eine bewusste Entwurfsentscheidung und kein Versäumnis, und es lohnt, dies genau zu sagen, denn der Mechanismus ist ungewöhnlich.
Die Authentifizierung funktioniert folgendermaßen. Der Nutzer fordert einen Anmeldecode an, der an seine E-Mail-Adresse gesendet wird; der Code ist zehn Minuten gültig, lässt fünf Versuche zu und wird in konstanter Zeit verglichen. Nach der Prüfung stellt der Server ein Sitzungstoken aus, das die Anwendung auf dem Gerät speichert und bei jeder Anfrage im Authorization-Header mitsendet.
Dieses Token wird aufbewahrt:
| Plattform | Wo | Was das schützt und was nicht |
|---|---|---|
| Web | Lokaler Speicher des Browsers, nach Herkunft getrennt (app.gunbix.com) |
Isoliert das Token von jeder anderen Website. Schützt nicht gegen ein in unsere eigene Seite eingeschleustes Skript; dafür ist die Content-Security-Policy da |
| Android | Die private Einstellungsdatei der Anwendung, durch die Sandbox des Systems isoliert und von der Geräteverschlüsselung erfasst | Es ist nicht der Hardware-Schlüsselspeicher |
Der Server nimmt das Token ausschließlich im Authorization-Header entgegen, niemals in einem Cookie. Ein Cookie wird vom Browser automatisch mitgesendet, sodass eine über Cookie authentifizierte Schnittstelle sich gegen die websiteübergreifende Anfragenfälschung verteidigen muss. Einen ausdrücklichen Header zu verlangen beseitigt diese Angriffsklasse, statt sie abzumildern.
Die Folge für diese Richtlinie ist einfach: Da das Token kein Cookie ist, könnte kein Einwilligungsbanner anbieten, es abzulehnen, und den lokalen Speicher des Browsers abzulehnen macht die Anwendung ebenso unbenutzbar, wie es die Ablehnung eines Authentifizierungs-Cookies täte.
Der wirkliche Schutz vor einem gestohlenen Token ist nicht der Aufbewahrungsort, sondern die Widerrufbarkeit: Eine Sitzung dauert höchstens dreißig Tage, ihr Ablauf ist absolut und wird durch Nutzung nicht verlängert, in der Datenbank wird vom Token nur ein Fingerabdruck gehalten, und eine Sitzung kann von jedem Gerät des Nutzers aus mit Wirkung für alle widerrufen werden.
Cloudflare, der Hosting-Anbieter, kann darüber hinaus ein technisches Sicherheits-Cookie setzen, das einen menschlichen Besucher von einem Roboter unterscheiden soll. Es ist für den Schutz des Dienstes unbedingt erforderlich und dient keinem anderen Zweck.
Die Anwendung speichert im lokalen Speicher des Browsers, und nicht in Cookies, das gewählte Thema, die Akzentfarbe, die Anzeigesprache und den ein- oder ausgeklappten Zustand des Seitenmenüs. Diese Werte werden an keinen Server übermittelt und erlauben keine Identifizierung.
Die Anwendung lädt die Google-Maps-Bibliothek in dem Augenblick, in dem ein Bildschirm eine Karte benötigt, sowie beim ersten Tastenanschlag in einem Adressfeld für die Vervollständigung. Sie lädt sie nicht mehr beim Öffnen: Bis zum 22. August 2026 ging der Ladevorgang auf allen Bildschirmen ab, auch auf jenen ohne Karte, und Google erhielt somit die IP-Adresse jedes Besuchers, bevor dieser irgendetwas verlangt hatte. Ein Nutzer, der weder eine Karte noch ein Adressformular öffnet, nimmt keinen Kontakt zu Google auf.
Wird sie geladen, erhält Google die IP-Adresse des Endgeräts und die Adresse der Seite und kann eigene Cookies setzen, die seiner Richtlinie unterliegen. Die Einzelheiten finden sich in der Liste der Auftragsverarbeiter.
Der Nutzer, der dem widersprechen möchte, kann die Domain maps.googleapis.com in seinem Browser sperren; die Kartenbildschirme funktionieren dann nicht mehr, während der übrige Dienst nutzbar bleibt.
Eine Webseite lädt nicht nur Tracking-Technologien: Sie lädt auch den Code und die Schriften, die sie zur Darstellung benötigt. Diese Anfragen legen nichts ab und lesen nichts auf dem Endgerät, sie offenbaren dem Server, der sie beantwortet, jedoch die IP-Adresse des Besuchers und die Adresse der aufgerufenen Seite. Diese Seite führt sie auf, weil ein Nutzer, der wissen will, wen sein Browser beim Öffnen kontaktiert, dies nachlesen können muss, auch wenn die Antwort kein Cookie ist.
Beim Öffnen der Anwendung geht keine Anfrage an einen Dritten. Die Rendering-Engine, die Schriften der Hausgestaltung, die Ersatzschriften und die Bilder werden sämtlich von den Servern von Gunbix ausgeliefert. Festgestellt am 23. August 2026 durch Beobachtung des tatsächlichen Netzwerkverkehrs der veröffentlichten Anwendung und nicht durch Lektüre des Codes.
Am Tag zuvor war das nicht so. Vier Ladevorgänge gingen bei jedem Öffnen an Google, von denen keiner von einem Bildschirm aus sichtbar war:
| Was abging | An | Entfernt am |
|---|---|---|
| Das Google-Anmeldeskript, geerbt von einem aufgegebenen Modul, das kein Bildschirm mehr nutzte, und in der Lage, Cookies zu setzen | accounts.google.com |
23. August 2026 |
| Die Module eines Datenbankdienstes, der nicht mehr genutzt wurde | www.gstatic.com |
22. August 2026 |
| Die Rendering-Engine der Anwendung | www.gstatic.com |
22. August 2026 |
| Zwei Ersatzschriften der Rendering-Engine, darunter die allgemeine Schrift Roboto | fonts.gstatic.com |
23. August 2026 |
Was gewährleistet, dass es dabei bleibt. Die Rendering-Engine meldet nichts, wenn ihr eine Schrift fehlt: Sie zeigt anstelle der betroffenen Zeichen leere Kästchen an. Niemand würde es bemerken, bevor ein Nutzer sich darüber beschwert, wie sein Name geschrieben wird, und die Versuchung wäre dann, das Laden bei Google wiederherzustellen. Da die Adressen dieser Schriften eine Versionsnummer tragen, verlangt eine Aktualisierung der Engine andere, welche die bei Gunbix vorhandene Kopie nicht enthielte. Bei jeder Veröffentlichung wird daher eine automatische Prüfung ausgeführt: sie lässt die Veröffentlichung scheitern, wenn eine einzige Schriftdatei fehlt. Die Aussage dieses Artikels wird von dieser Prüfung getragen und nicht allein von der Wachsamkeit dessen, der sie geschrieben hat.
Die Anforderung eines Anmeldecodes kann durch Turnstile geschützt werden, eine Prüfung von Cloudflare, die einen menschlichen Besucher von einem Programm unterscheidet. Dazu lädt sie ein von challenges.cloudflare.com ausgeliefertes Skript.
Diese Prüfung ist zum 30. August 2026 ausgeschaltet, und solange sie es ist, geht keine Anfrage an diese Domain: Der Browser fragt den Server, ob die Prüfung aktiv ist, bevor er den Anmeldebildschirm anzeigt, und lädt das Skript nur, wenn die Antwort ja lautet. Sie wird hier vorsorglich beschrieben, weil die Verdrahtung vorhanden ist und ihre Aktivierung lediglich eine Konfigurationsänderung erfordert.
Sobald sie aktiv ist, wird diese Prüfung zum Schutz des Dienstes vor dem automatisierten Versand von Anmeldecodes unbedingt erforderlich sein und keinem anderen Zweck dienen, insbesondere keiner Reichweitenmessung.
Gunbix setzt kein Werkzeug zur Reichweitenmessung ein, weder ein eigenes noch das eines Dritten. Es wird keine Besuchsstatistik über Cookie oder Tag erhoben.
Gunbix setzt kein Werbe-Cookie, erstellt kein Marketingprofil und teilt nichts mit einem Werbenetzwerk.
Würde eine Reichweitenmessung eingeführt, würde diese Seite aktualisiert und die vorherige Einwilligung des Nutzers eingeholt.
Ein in eine E-Mail eingefügtes Zählpixel ist ein Bild von einem Pixel, auf einem Server gehostet, das die Mailsoftware in dem Augenblick abruft, in dem die Nachricht angezeigt wird. Diese Anfrage offenbart, dass die Nachricht geöffnet wurde, zu welcher Uhrzeit und von welcher IP-Adresse aus. Es ist eine Tracking-Technologie, und sie fällt unter denselben Artikel 5 Absatz 3 der ePrivacy-Richtlinie wie ein Cookie: Die Vorschrift erfasst nicht nur Cookies, sondern das Speichern von Informationen und den Zugriff auf bereits im Endgerät des Nutzers gespeicherte Informationen. Gleiches gilt für einen umgeschriebenen Link zur Zählung von Klicks.
Die E-Mails von Gunbix enthalten keine davon. Die Vorlage, die sie erzeugt, enthält kein Bild, weder entfernt noch eingebettet, und kein Link wird umgeschrieben. Gemessen wird hingegen die Zustellung der Nachricht: ihre Annahme oder Zurückweisung durch den Mailserver des Empfängers. Diese Information wird von Mailservern gemeldet und nicht von der Software des Empfängers; sie setzt weder ein Ablegen in noch ein Auslesen aus seinem Endgerät voraus und fällt daher nicht unter Artikel 5 Absatz 3. Die Einzelheiten finden sich in Artikel 2.8 der Datenschutzerklärung.
Sollte eine Lesemessung eingeführt werden, würde diese Seite zuvor aktualisiert und die vorherige Einwilligung des Nutzers eingeholt, wobei der Widerruf ebenso einfach wäre wie die Zustimmung.
Ein Einwilligungsbanner ergibt nur dann einen Sinn, wenn es ein Cookie abzulehnen gibt. Bis heute sind die einzigen Mechanismen, die eine Information auf dem Endgerät schreiben oder lesen, entweder unbedingt erforderlich oder durch eine ausdrückliche Handlung des Nutzers ausgelöst, und keiner unterliegt der Einwilligung.
Keine Inanspruchnahme eines Dritten geht der ersten Handlung des Nutzers voraus: Die Anfragen, die dies noch taten, wurden nicht gerechtfertigt, sie wurden entfernt (Artikel 3.4).
An dem Tag, an dem ein nicht unbedingt erforderliches Cookie gesetzt wird, wird ein Verfahren zur Einholung der Einwilligung eingerichtet, bei dem die Ablehnung ebenso einfach auszudrücken ist wie die Annahme, und diese Seite wird zuvor aktualisiert.
Der Nutzer kann jederzeit über die Einstellungen seines Browsers die Cookies und den lokalen Speicher der Website sperren oder löschen. Das Löschen des lokalen Speichers meldet ihn ab, weil das Sitzungstoken dort aufbewahrt wird (Artikel 3.1), und setzt die Anzeige auf ihre Standardwerte zurück.
Die Hilfeseiten der wichtigsten Browser erläutern das Vorgehen: Mozilla Firefox (support.mozilla.org), Google Chrome (support.google.com), Microsoft Edge (support.microsoft.com), Apple Safari (support.apple.com), Brave (support.brave.com).
Die anlässlich der oben beschriebenen Mechanismen verarbeiteten Daten werden unter den in der Datenschutzerklärung genannten Bedingungen verarbeitet. Dem Nutzer stehen ihnen gegenüber sämtliche in den Artikeln 15 bis 22 DSGVO vorgesehenen Rechte zu.
Die vorliegende Richtlinie wird aktualisiert, sobald sich die beschriebenen Mechanismen ändern, und vor dem Setzen eines Cookies, das nicht darin aufgeführt ist.
Für jede Frage zur Verwendung von Cookies: privacy@takion.be.
TAKION SRL Rue Mansart 39/A 7534 Tournai Belgien