So funktioniert LokalPix
im Detail.

Kurzfassung

Kernaussage: Kein Bildinhalt wird an den LokalPix-Server gesendet. Der Server liefert die Anwendung aus und stellt eine aggregierte Aufrufstatistik bereit; die eigentliche Bildverarbeitung findet auf dem Endgerät statt.

Datenfluss einer Konvertierung

1. 1
   Seite laden

   Beim Laden der Startseite kann der Browser HTML, CSS, JavaScript, Manifest, Symbol und Service Worker von derselben LokalPix-Adresse abrufen. Die Startseite liest zusätzlich /api/stats. Die Technikseite selbst lädt nur HTML, CSS und gegebenenfalls das Symbol; sie führt kein App-JavaScript aus.

2. 2
   Datei auswählen

   Die Dateiauswahl erfolgt über das native Datei-Auswahlfeld des Browsers. JavaScript erhält nur die vom Nutzer ausgewählten Dateien.

3. 3
   Datei lokal prüfen

   Dateityp, Dateigröße und Bildabmessungen werden im Browser geprüft. Bei SVG sucht die Anwendung nach festgelegten riskanten Elementen und Mustern und lehnt die Datei bei einem Treffer ab.

4. 4
   Bild lokal dekodieren

   Der Browser dekodiert die Datei über createImageBitmap oder ein lokales Image-Objekt. Die Quelle ist eine lokale Blob-URL, keine Serveradresse.

5. 5
   Neu zeichnen und codieren

   Das Bild wird in ein Canvas gezeichnet. canvas.toBlob() erzeugt PNG, JPG oder WebP. Für JPG wird zuvor ein weißer Hintergrund eingefügt.

6. 6
   Download

   Die Ausgabedatei wird als temporäre Blob-URL im Browser bereitgestellt. Erst der Nutzer speichert sie über „Herunterladen“ auf seinem Gerät.

7. 7
   Speicher freigeben

   Beim Entfernen oder vollständigen Zurücksetzen widerruft die Anwendung zugehörige Blob-URLs. Alte Ausgabe-URLs werden nach erfolgreicher Neukonvertierung beziehungsweise beim Formatwechsel widerrufen. Zusätzlich ist ein Widerruf bei beforeunload registriert; dessen Ausführung ist nicht in allen Browser-Lebenszyklen garantiert.

Bildverarbeitung und Formate

Eingaben

Akzeptiert werden JPEG/JPG, PNG, WebP, SVG und AVIF mit höchstens 25 MB pro Datei. Maximal 20 Dateien werden gleichzeitig in die Warteschlange aufgenommen. Leere oder allgemeine MIME-Angaben dürfen anhand einer bekannten Dateiendung ergänzt werden; ein ausdrücklich fremder MIME-Typ wird nicht durch die Endung überschrieben.

Abmessungsgrenzen

Erlaubt sind höchstens 16.384 Pixel pro Kante und insgesamt 40 Megapixel. Bei PNG, JPEG, WebP und AVIF versucht LokalPix, die Abmessungen bereits aus den ersten 512 Dateibytes auszulesen. Nach dem Dekodieren wird die Grenze erneut geprüft.

Ausgaben

PNG, JPG und WebP werden über die Canvas-Schnittstelle des Browsers erzeugt. Die Qualitätswahl beeinflusst JPG und WebP. AVIF wird nicht als Ausgabe angeboten, weil die Canvas-Unterstützung dafür nicht browserübergreifend zuverlässig ist.

Ausrichtungsmetadaten

Beim bevorzugten Dekodierweg fordert createImageBitmap mit imageOrientation: 'from-image' die Anwendung der in der Quelldatei hinterlegten Ausrichtung an. Beim Rückfall auf ein Image-Objekt ist das Verhalten browserabhängig. Die Wirkung einer EXIF-Ausrichtung kann dadurch in Abmessungen und Ausgabepixel einfließen, obwohl das ursprüngliche Metadatenfeld nicht ausdrücklich in die Ausgabedatei kopiert wird.

SVG-Sonderbehandlung

SVG ist ein XML-basiertes Dokumentformat und kann aktive oder externe Inhalte enthalten. LokalPix parst SVG im Browser und sucht nach einer im Quellcode definierten Denylist, unter anderem nach Skripten, Ereignisattributen, eingebetteten Fremdinhalten, Animationen, Stylesheets, externen href-Zielen, externen CSS-URLs, CSS-Imports, Expressions, maskierten Stilwerten und nicht zuverlässig auflösbaren CSS-Maßeinheiten. Bei einem Treffer wird die Datei abgelehnt; andernfalls wird die serialisierte SVG-Struktur weiterverarbeitet. Diese Prüfung reduziert das Risiko, ist aber keine vollständige Element- und Attribut-Allowlist und garantiert nicht die Erkennung jeder denkbaren aktiven SVG-Funktion.

Welche Netzwerkzugriffe erfolgen?

Startseite

Service-Worker-Installation und Wiederholungsaufrufe

Bei der Installation ruft cache.addAll() die Cache-Liste ab: /, /technik-datenschutz.html, /styles.css, /app.mjs, /converter-core.mjs, /manifest.webmanifest und /icon.svg. Spätere Abrufe statischer Dateien können aus Cache Storage beantwortet werden. Seitennavigationen bleiben network-first; bei einem Netzwerkfehler wird eine vorhandene Cachekopie verwendet. Die konkrete Anfragemenge hängt deshalb von Browser, HTTP-Cache und Service-Worker-Zustand ab.

Technikseite

Ein direkter Aufruf dieser Seite lädt HTML und CSS sowie browserabhängig /icon.svg. Die Seite selbst lädt weder app.mjs noch /api/stats und registriert keinen Service Worker. Ein bereits von der Startseite aktiver Service Worker kann ihre Navigation dennoch verarbeiten.

Die Anwendung enthält keine Analyse-, Werbe-, Social-Media-, Schriftarten- oder sonstigen Drittanbieter-Skripte. Ihre Content Security Policy erlaubt Skripte, Styles und Netzwerkverbindungen nur zur eigenen Herkunft. Vorschaubilder und Ergebnisse verwenden lokale blob:- beziehungsweise eingebettete data:-Quellen.

Abgrenzung: Technisch notwendige Vorgänge des Betriebssystems oder Browsers – beispielsweise DNS-Auflösung oder Zertifikatsprüfung – liegen außerhalb der Anwendungslogik und sind nicht mit einem Bild-Upload gleichzusetzen.

Besucherstatistik

Ein Seitenaufruf wird serverseitig gezählt, wenn eine GET-Anfrage für / oder /index.html eingeht. Der geprüfte Node-Anwendungscode greift nicht auf die im Socket verfügbare Client-IP zu, protokolliert sie nicht, setzt keine Cookies und speichert keine Gerätekennung. Jede HTTP-Verbindung offenbart die Quell-IP technisch mindestens dem Netzwerk- und Hosting-Stack; dessen Verhalten ist separat zu prüfen.

Eine neu angelegte, unveränderte Statistikdatei enthält:

• Datum des Zählbeginns,
• Gesamtzahl der Seitenaufrufe,
• Anzahl der Seitenaufrufe je Kalendertag in der Zeitzone Europe/Berlin.

Vorhandene Statistikdateien werden derzeit nicht gegen ein Schema validiert; bereits enthaltene zusätzliche Felder können bei späteren Schreibvorgängen erhalten bleiben. Bei einer fehlerhaften oder nicht lesbaren Statistikdatei fällt der Store auf einen neuen Zustand im Arbeitsspeicher zurück; ein späterer erfolgreicher Schreibvorgang kann die vorherige Datei ersetzen. Strukturell ungeeignete, aber parsebare Werte können die Statistik auch unverfügbar machen. Persistenz erfolgt best effort: Ein Schreibfehler wird gegenüber dem Seitenaufruf abgefangen; der aktualisierte Zähler kann dann nur lokal im Prozess vorliegen und bei einem Neustart verloren gehen.

Gesamtsumme und Zählbeginn bleiben bis zur administrativen Löschung oder Ersetzung der Statistikdatei erhalten. Tageswerte werden bei einem neuen gezählten Aufruf auf höchstens 370 vorhandene Datumsschlüssel reduziert. Dies ist keine zeitbasierte 370-Tage-Löschfrist; bei weniger als 370 Nutzungstagen können alte Werte bestehen bleiben. Bei erfolgreicher Persistenz wird die temporäre JSON-Datei mit Dateirechten 0600 angelegt und umbenannt. Verzeichnisrechte, Backups und privilegierte Systemzugriffe sind davon nicht erfasst. Der öffentliche Statistik-Endpunkt gibt nur den heutigen Wert, die Gesamtsumme und das Startdatum aus und erhält Cache-Control: no-store.

Wichtig: Auch der initiale Service-Worker-Vorabruf von / kann den Zähler erhöhen. Die Zählung unterscheidet außerdem nicht zwischen Menschen, Bots, mehrfachen Aufrufen oder wiederholtem Neuladen. Sie ist eine Aufrufstatistik, keine Messung eindeutiger Besucher.

Was wird wo gespeichert?

Davon zu unterscheiden sind zwei Cache-Ebenen: Der Server antwortet für HTML mit Cache-Control: no-cache, für andere statische Dateien mit public, max-age=3600 und für /api/stats mit no-store. Der Service Worker nutzt für vorab gespeicherte Nicht-Navigationsressourcen cache-first.

LokalPix verwendet für die Konvertierung weder localStorage noch Cookies, IndexedDB oder ein Benutzerkonto.

Sicherheitsmaßnahmen

• Content Security Policy: Standardmäßig sind nur Ressourcen derselben Herkunft erlaubt; Objekte, fremde Frames und fremde Formularziele sind blockiert.
• Frame-Schutz: frame-ancestors 'none' und X-Frame-Options: DENY weisen unterstützende Browser an, die Einbettung in andere Seiten abzulehnen.
• MIME-Schutz: X-Content-Type-Options: nosniff schränkt MIME-Sniffing insbesondere für Script- und Style-Ziele ein.
• Referrer-Schutz: Referrer-Policy: no-referrer unterbindet das Senden einer Referrer-Adresse.
• Berechtigungen: Kamera, Mikrofon, Geolocation und Payment API werden per Permissions-Policy deaktiviert.
• Dateigrenzen: Anzahl, Dateigröße, Kantenlänge und Pixelzahl sind begrenzt.
• SVG-Prüfung: Dateien mit den im Quellcode aufgeführten riskanten Elementen, Referenzen oder Stilwerten werden abgelehnt.
• Keine schreibende Bild-API: Der Server akzeptiert nur GET und HEAD; andere Methoden werden mit Status 405 zurückgewiesen.

Hosting- und Reverse-Proxy-Ebene

Der geprüfte Node-Anwendungscode liest oder persistiert keine Client-IP, setzt keine Cookies und nimmt keine Bilder entgegen. Jede Verbindung erreicht jedoch einen Netzwerk- und Hosting-Stack, der die Quell-IP technisch verarbeiten kann. Ein VPS-Anbieter, Reverse Proxy, CDN, eine Firewall, DDoS-Schutz, DNS-Dienst oder Systemprotokolle können zusätzliche Verbindungsdaten, Header oder Cookies verarbeiten beziehungsweise setzen.

Vor Veröffentlichung sollte deshalb separat dokumentiert und geprüft werden:

• welcher Hosting-Anbieter und Serverstandort verwendet wird,
• ob und wie lange Access- und Fehlerprotokolle gespeichert werden,
• ob IP-Adressen gekürzt oder vollständig vermieden werden können,
• welche Auftragsverarbeitungs- und Unterauftragnehmerbeziehungen bestehen,
• wie TLS, Backups, Updates, Zugriffsrechte und Löschfristen organisiert sind.

Diese Grenze ist entscheidend: „Keine Bild-Uploads“ ist eine Eigenschaft der Anwendung. Aussagen über vollständige Server-Protokollfreiheit sind erst nach Prüfung der konkreten Produktionsumgebung möglich.

Was diese Architektur nicht garantiert

• Ein kompromittierter Browser, eine schädliche Browser-Erweiterung oder ein kompromittiertes Endgerät liegt außerhalb der Kontrolle von LokalPix.
• Browser-Decoder können Sicherheitsfehler enthalten; Größenprüfungen reduzieren Risiken, ersetzen aber keine Browser-Updates.
• Die SVG-Prüfung ist eine vorsichtige Ablehnungslogik, keine formale Sicherheitszertifizierung jedes denkbaren SVG-Inhalts.
• Quell-EXIF-, IPTC- und XMP-Felder werden vom Anwendungscode nicht kopiert; die Rasterausgabe wird über Canvas neu codiert. Es gibt keine nachgelagerte Byte-Prüfung, Browser können eigene Metadaten erzeugen, und sichtbare beziehungsweise in Pixel eingebrannte Informationen bleiben erhalten.
• Die Ausgabequalität hängt vom Browser, Eingabeformat und gewählten Qualitätswert ab.
• Die technische Beschreibung ersetzt weder Datenschutz-Folgenabschätzung noch Rechtsprüfung, sofern eine solche im konkreten Einsatz erforderlich ist.

Empfohlene Prüfschritte

1. Browser-Netzwerkprotokoll öffnen: Einen Erstbesuch mit leeren Browserdaten, einen Wiederholungsbesuch, den direkten Aufruf der Technikseite und einen Offline-Fall getrennt prüfen. Danach ein Bild auswählen und konvertieren; während Auswahl und Konvertierung darf keine Anfrage mit Bildinhalt erscheinen.
2. Anfragen kontrollieren: Zulässig sind nur Ressourcen der eigenen Herkunft und lokale blob:-URLs. Es dürfen keine Drittanbieter-Domains erscheinen.
3. Server-Routen prüfen: Der Quellcode in server.mjs enthält keinen Upload-Endpunkt und akzeptiert nur GET und HEAD.
4. Konvertierungslogik prüfen: public/app.mjs dekodiert, zeichnet und codiert die Bilder ausschließlich über Browser-APIs.
5. Statistik prüfen: stats-store.mjs sowie die produktive Statistikdatei auf reguläre Zählerfelder, unerwartete Zusatzfelder, Dateirechte, Backups und administrative Löschung prüfen.
6. Service Worker prüfen: public/sw.js darf nur Anwendungsdateien, niemals ausgewählte Bilddateien, vorab cachen. Auch Cache-Persistenz und präfixgebundene Bereinigung prüfen.
7. Produktionsumgebung prüfen: Reverse-Proxy-Konfiguration, Zugriffsprotokolle, TLS, Firewall, Backups, Benutzerrechte und Anbietervereinbarungen separat dokumentieren.
8. Regressionstests ausführen: npm test und npm run test:e2e prüfen Kernfunktionen, Sicherheitsgrenzen und den Browserablauf.

Dokumentationsstand: September 2026 · Technische Beschreibung Version 1.2