Datenschutzhinweis der Seite sowie Unterseiten von http://valentin.hilbig.de/ und https://valentin.hilbig.de/

Die Seiten hier enthalten keinerlei Anteile, die gem. DSGVO geregelt werden müssten.

Diese Seite wird rein privat betrieben und wendet sich ausschließlich an Privatpersonen.
Diese Seite verwendet standardmäßig weder Cookies noch DrittURLs.
Cookies werden nur auf ausdrückliches Verlangen des Nutzers angelegt.
Achtung! Einige Links zeigen auf DrittURLs und einige Browser laden solche DrittURLs schon bevor man sie anklickt. Das ist aber ein Fehler in der Einstellung der Browser und kann von mir nicht wirklich unterbunden werden.
JavaScript wird lediglich zum Abruf, Aufbereitung und Darstellung der Coronadaten verwendet.
Die Corona-Daten werden hier per Mirror bereitgestellt (Same Origin). CORS, also Drittseiten, werden für den Datenabruf nicht verwendet.
Abgesehen von der IP werden keinerlei personenbezogene Daten erhoben, verarbeitet oder gespeichert.
Die IP wird nicht an Dritte weitergegeben.
Ich habe außerdem keinerlei Möglichkeit, die IP zu deanonymisieren.
Somit stellt die IP in dem hier verwendeten Kontext ein pseudonymes Datum gem. DSGVO dar.
Somit fallen keinerlei Daten an, auf die weitergehende Regeln der DSGVO angewandt werden müssten.

Sicherheitshinweis bei der Verwendung von HTTPS

Meine Seite unterstützt HTTP und HTTPS. Wer Webseiten per HTTPS abruft tut dies auf eigene Gefahr! Ich empfehle deshalb aus Datenschutzgründen dringend, wenn möglich auf HTTPS zu verzichten.

Ich verwende LetsEncrypt für mein HTTPS-Zertifikat. Dies wird also über Amerika bereitgestellt.
LetsEncrypt stellt keinen Warrant Canary bereit und muss somit als Sicherheitsrisiko (durch NSL) angesehen werden.
Außerdem ist OCSP-Stapling extrem fragil und funktioniert meistens nicht richtig.
Deshalb funken Browser per OCSP-Request das verwendete Zertifikat nach Hause, sprich: Wer beim Aufruf meiner Seite HTTPS verwendet teilt LetsEncrypt diesen Seitenaufruf und damit die IP mit. Da Amerika die Möglichkeit hat die IP zu deanonymisieren, wird durch den ubiquitären Einsatz von HTTPS der Datenschutz untergraben.
Dagegen kann ich auf meiner Seite leider gar nichts tun (außer ggf. HTTPS abzuschalten), der Fehler steckt nämlich leider tief in der Konstruktion von HTTPS.
OCSP abzuschalten ist extrem gefährlich, denn das hebelt das ganze Schutzgerüst rund um HTTPS gegen MitM und Fakezertifikate aus. Deshalb niemals OCSP im Browser abschalten außer man braucht HTTPS überhaupt niemals (wieso dann aber verwenden?).
Das richtige Verhalten ist somit:
- HTTPS ausschließlich dort verwenden wo es unabdingbar notwendig ist.
- Unabdingbar notwendig ist es z. B. beim Onlinebanking.
- Nicht notwendig ist HTTPS für die sicher Passworteingabe bei Logins! Aber Warnung! Die meisten Logins benötigen HTTPS weil sie fehlkonstruiert sind! Sie ohne HTTPS zu verwenden wäre äußerst gefährlich! Es zeigt aber, dass der Seitenbetreiber das Problem nicht verstanden hat (höchstwahrscheinlich weil sich der Betreiber einen feuchten Kehrricht um ehrliche Sicherheit schert)!
- Auf die Klartextübertragung eines Passworts zu setzen ist schon lange nicht mehr zeitgemäß.
- HTTPS zu verwenden um das Passwort an den Server zu übermitteln ändert daran exakt gar nichts, denn das Passwort landet ja trotzdem im Klartext auf dem Server! (Und im Klartext auf jeder dazwischengeschalteten Middlebox wie CloudFlare.)
HTTPS wird für nicht-sicherheitsrelevante Seiten wie meine nicht benötigt.
Die Übertragung selbst wird hierzulande bereits durch DSGVO sowie Fernmeldegeheimnis geschützt.
Der Datenschutz kann somit nur durch den Verzicht auf HTTPS eingehalten werden.

Ein zusätzliches wirklich funktionierendes verschlüsselndes E2E-Layer wäre technisch selbstverständlich äußerst wünschenswert. Leider ist HTTPS eine Krücke die kein wirklich sicheres E2E-Layer bereitstellt.

Hier sind die Browserhersteller gefragt. Aber Browser kennen nicht einmal einen eingebauten Mechanismus, der wirksam verhindert, dass ein Passwort den Browser im Klartext verlässt (unabhängig vom Einsatz von HTTPS)! Wenn sich die Browserhersteller selbst gegen diese allereinfachste Form der Sicherheit sperren, wie kann man da erwarten, dass die Browserhersteller jemals einen effektiven Schutz von P2P in den Browser einbauen?

Leider wurden signiertes JavaScript zusammen mit Java Webstart beerdigt, weshalb Webseiten den fehlenden Schutz im Browser nicht wirklich sinnvoll selbst nachrüsten können. (Subressource-Integrity hat leider das Henne-Ei-Problem, am Anfang steht leider immer etwas komplett unsigniertes. HTTPS authentisiert ja nicht den Seiteninhalt, es schützt lediglich die Übertragung der ansonsten unauthentisierten Seite, löst unser Problem genau exakt nicht.)

Es gibt also nur das plakative Fazit: HTTPS gefährdet den Datenschutz. Punkt.

[ Code | Data | Datenschutzhinweis | Impressum ]