Datenschutzerklärung

Zuletzt aktualisiert: 22. Oktober 2026

Kurzfassung. Die Dokumente, Bilder, Videos und Dateien, die Sie in Lolly erstellen, bleiben auf Ihrem Gerät. Es gibt keine Konten für die normale Nutzung, keine Cookies von der App selbst und keine Analyse- oder Tracking-Tools irgendwo im Code - nicht „wir nutzen die Daten nicht“, sondern tatsächlich nicht im Quellcode vorhanden. Es gibt eine kurze, vollständige Liste von Ausnahmen, in denen die Software überhaupt mit einem Netzwerk spricht, und jede davon wird unten im Detail beschrieben: was das Gerät verlässt, an wen und wann. Die einzige Ausnahme, die etwas Persönliches betrifft, ist eine Anmeldung, die Sie ausdrücklich starten müssen. Steht es nicht in diesem Dokument, geschieht es nicht.

Was diese Richtlinie abdeckt

Lolly ist Open-Source-Software - eine Engine, mehrere App-Shells (Web, Desktop, Mobil, CLI) und eine Browser-Erweiterung -, die jeder betreiben kann. Diese Richtlinie hat zwei Teile:

• Die Software selbst: was sie mit Ihren Daten tut und nicht tut, egal wo sie läuft. Das ist eine Eigenschaft des Codes, also gilt es für jede Lolly-Bereitstellung, unsere und die von jedem anderen.
• lolly.tools, die von SUSE betriebene Referenzbereitstellung: die konkreten Entscheidungen beim Betrieb ihrer optionalen serverseitigen Bausteine (was protokolliert wird, wie lange, von wem).

Wenn Sie eine selbst gehostete oder Enterprise-Lolly-Instanz verwenden, gilt das Softwareverhalten unten weiterhin, aber der Betreiber dieser Instanz - nicht SUSE - ist verantwortlich für alles Serverseitige: dessen Render-Endpunkt, dessen MCP-Server, dessen Content-Credentials-Zertifizierungsstelle, falls er eine betreibt. Fragen Sie ihn nach seiner eigenen Richtlinie. Siehe Einführung & Governance für das, was der Betrieb von Lolly bedeutet.

Die App: was auf Ihrem Gerät bleibt

Lollys Web-, Desktop- und Mobil-Shells führen die gesamte Render-Engine clientseitig aus. Ein Tool öffnen, Eingaben ausfüllen, Vorschau anzeigen und exportieren geschehen alle auf Ihrem Gerät - kein Server ist beteiligt, und die App funktioniert offline, sobald sie geladen ist.

Die App setzt keine Cookies. Um zu funktionieren, hält sie eine kleine Menge Daten nur auf Ihrem Gerät, niemals übertragen:

• Oberflächeneinstellungen - Theme, Sprache, Toneinstellungen, Seitenleisten-/Zoom- Größe, Sortier- und Ansichtsauswahl, welche Onboarding-Hinweise Sie gesehen haben - in localStorage, damit sie verfügbar sind, bevor die App fertig gestartet ist.
• Ein Offline-Cache des Tool-Katalogs und der Asset-Vorschauen, damit die Galerie ohne Verbindung funktioniert.
• Lokale Nutzungszähler für die Statistiken Ihrer Profilkarte (wie viele Exporte, welche Tools) - ein kleiner begrenzter Datensatz in localStorage, von uns nie gelesen, nie irgendwohin gesendet.
• Ihre eigenen Dokumente, gespeicherten Sitzungen, hochgeladenen Assets und Schriften - gespeichert in IndexedDB auf Ihrem Gerät, nie hochgeladen, von niemandem außer Ihnen gelesen.

Nichts davon wird geteilt, verkauft oder dazu verwendet, Sie zu identifizieren oder zu verfolgen. Es gibt nichts, dem zuzustimmen wäre, weil keine Erhebung stattfindet - nur dieser Hinweis, damit Sie wissen, was wo aufbewahrt wird. Das Löschen des Speichers der Seite in Ihrem Browser entfernt jederzeit alles davon, ebenso Einstellungen → Speicher → Alle meine Daten löschen, was außerdem zuerst Sync ausschaltet. (Nach der ePrivacy-Richtlinie Art. 5(3) benötigt eine Speicherung, die für den angeforderten Dienst unbedingt erforderlich ist, keine Einwilligung - nur Transparenz, was sowohl dieses Dokument als auch der In-App-Hinweis bieten.)

signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBPrüfen Sie es selbstSignierte Datei holen

Ihre eigene Sicherung dieser Daten - das lolly-backup -Bündel, erzeugt von Meine Daten exportieren - ist eine Datei, die Sie behalten und kontrollieren. Sie berührt nie unsere Server, es sei denn, Sie entscheiden sich, sie selbst irgendwohin zu senden. Siehe Datenübertragung.

Geräteinterne Werkzeuge

Manche Tools - Verborgene Daten entfernen, PDF komprimieren und andere mit dem "Läuft auf Ihrem Gerät"-Abzeichen - arbeiten mit einer Datei, die Sie bereitstellen. Die Datei wird in den Arbeitsspeicher Ihres Browsers gelesen, lokal umgewandelt und als Download angeboten. Sie wird nie hochgeladen, weil kein Server im Übertragungsweg vorhanden ist, an den sie hochgeladen werden könnte. Diese Werkzeuge funktionieren offline, und ihre Ausgabe trägt kein Wasserzeichen und keine Metadaten von uns - der Zweck der meisten von ihnen ist, Daten zu entfernen & zu schützen, nicht Risiken hinzuzufügen.

signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBPrüfen Sie es selbstSignierte Datei holen

Prepare for sharing hält Arbeitseingaben, private Funde und Ersetzungszuordnungen im Arbeitsspeicher, ohne sie automatisch zum Verlauf, zu Links, Backups oder zur Synchronisierung hinzuzufügen. Prüfung und Ersetzung senden weder Dateiinhalte an einen Server noch validieren sie Zugangsdaten online. Nutzer entscheiden, ob sie ein Ergebnis kopieren, herunterladen, senden oder ausdrücklich in ihrer Bibliothek speichern; ein gespeichertes Ergebnis folgt danach den normalen Backup- und Synchronisierungseinstellungen der Bibliothek. Rezept-Dateien lassen frühere Nutzlasten und wörtliche Zuordnungen aus. Zusammenfassende Berichte enthalten Zählungen, Bereichs-IDs und Datei-Hashes. Die CLI kann außerdem eine private Prüfdatei mit den Originalwerten speichern, aber nur, wenn dies mit --review-file ausdrücklich angefordert wird. Das Leeren oder Verlassen einer Browser-Vorbereitungsansicht gibt ihren Arbeitszustand frei; das ist kein Versprechen forensischer Löschung aus dem Speicher des Browsers oder Betriebssystems.

Jede Netzwerkanfrage, die die App stellen kann

Die untenstehende Tabelle ist die vollständige Liste von allem, was die App über ein Netzwerk abruft oder sendet. Steht es nicht hier, tut die App es nicht.

Jeder feste Host in dieser Tabelle ist zugleich die vollständige Positivliste in der Content-Security-Policy der App, die der Browser durchsetzt. Die Liste ist also nicht nur eine Beschreibung dessen, was der Code heute tut, sondern die Grenze, an die der Browser die App bindet: Eine künftige Änderung, die versuchte, einen anderen Host zu kontaktieren, würde blockiert, nicht stillschweigend erlaubt. Eine Zeile ist die bewusste Ausnahme, und ihre eigene Zelle sagt das auch: Send to LinkedIn existiert nur in den Desktop-Apps, daher nennt die Richtlinie der Web-App keinen der beiden Hosts - die Web-App könnte sie nicht erreichen, selbst wenn ihr Code es versuchte. Zwei weitere Zeilen, Bluesky und Discord, sind auf dieselbe Weise nur für Desktop, und ihre Hosts fehlen aus demselben Grund in der Web-Richtlinie. Fünf Zeilen haben keinen festen Host, weil Sie die Adresse im Moment der Nutzung selbst wählen: eine URL, die Sie ein Tool erfassen lassen, eine Remote-Instanz, auf die Sie die Shell richten, sowie Ihr eigener Mastodon-Server, WebDAV-Server oder S3-Bucket (die letzten beiden auch als Synchronisierungs-Ziel). Keine davon steht in der Richtlinie, und jede tritt nur ein, wenn Sie eine Adresse eingeben und darauf handeln. Die Penpot-Zeile erreicht Penpot über den eigenen Ursprung der App, sie ist also durch 'self' abgedeckt. Ein Deployment, das keine der optionalen Verbindungen möchte (etwa eine Unternehmensinstanz mit eigenen Schriften), entfernt diese Hosts aus seiner Richtlinie, und die Funktionen schlagen dann kontrolliert fehl (fail closed), statt nach außen zu greifen.

Abgesehen von zwei Arten von Zeilen sendet nichts davon Ihre Dokumente, Projekte, Sitzungen oder hochgeladenen Dateien irgendwohin: Sie existieren, um Dinge zu Ihrem Gerät zu bringen (Tools, Schriften, Modelle). Die zwei Arten sind die Senden-Zeilen, die die eine von Ihnen gewählte Datei senden, und die Synchronisierungs-Zeile, die eine Kopie Ihrer Arbeit an den von Ihnen gewählten Speicherort sendet und an keinen Lolly-Server. Jede andere Ausnahme wird ausdrücklich in den Abschnitten unten genannt.

Eine Anmerkung dazu, was wir entfernt haben. Verify kann SEAL-Signaturen prüfen, ein Verfahren, bei dem der Signierschlüssel einer Datei im DNS veröffentlicht wird. Browser können keine DNS-Anfragen stellen, also muss jede Web-Implementierung die Abfrage über einen DNS-over-HTTPS-Resolver eines Dritten leiten - was diesem Betreiber die geprüfte Domain plus Ihre IP- Adresse zeigen würde. Wir nutzten früher den von Cloudflare. Wir tun das nicht mehr, und es gibt keinen Ersatz: Verify übergibt jetzt überhaupt keinen Resolver, sodass die SEAL-Verifizierung null Netzwerkanfragen stellt. Keine Lolly-App schlägt SEAL-Schlüssel heute im DNS nach: Die Desktop- und Mobil-Apps führen dieselbe Verify-Ansicht aus, und das Kommandozeilenwerkzeug lolly validate prüft SEAL nicht. Eine Datei, deren SEAL-Datensatz den Schlüssel inline trägt, wird offline geprüft, und Verify nennt die Signatur in sich stimmig, ohne die Domain zu bestätigen. Eine Datei, deren Schlüssel nur im DNS liegt, zeigt SEAL-Signatur konnte nicht verifiziert werden mit der Begründung "no key resolver and no inline key".

signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBPrüfen Sie es selbstSignierte Datei holen Sie können dies selbst nachprüfen: greifbare Prüfungen für diese und jede andere Behauptung auf dieser Seite, mit den genauen Befehlen und erwarteten Ausgaben, finden Sie unter Verify It Yourself.

Hot-verlinkte Render-URLs

Live auf lolly.tools. Jede https://lolly.tools/tool/<tool-id>.<ext>?<inputs> -URL wird tatsächlich gerendert, und die Eingaben reisen in dieser URL mit. Der Abschnitt unten erklärt, was das für Sie bedeutet, und ein Betreiber kann die Funktion auf seiner eigenen Instanz abschalten.

Die App selbst bleibt vollständig auf Ihrem Gerät. Separat kann ein Betreiber Hot-Link-Render-URLs aktivieren - /tool/<tool-id>.<ext>?<inputs> -, sodass ein geteilter Lolly-Link als Live-Bild in einer README, einem Wiki oder einem Dashboard erscheinen kann. Einen solchen abzurufen bittet den Server, öffentliche Tool- und Katalogdaten mit den in die URL geschriebenen Eingaben zu rendern.

• Keine Konten, keine Cookies, kein Zustand. Der Endpunkt ist anonym, und es wird nichts auf Ihrem Gerät gelesen. Ihre Dokumente, Sitzungen und Uploads verlassen niemals Ihren Browser - sie können in diesen Links überhaupt nicht auftauchen.
• Aber die URL selbst wird protokolliert. Der Query-String einer URL ist Teil der Anfragezeile, daher erscheint er in den gewöhnlichen Zugriffsprotokollen der Hosting-Plattform, genauso wie jeder angeforderte Pfad. Enthalten die Eingaben eines Links den Namen oder die E-Mail-Adresse jemandes - ein Namensschild, eine E-Mail-Signatur - steht dieser Text in diesen Protokollen, und keine noch so sorgfältige Formulierung einer Richtlinie ändert das. Eine Hot-Link-URL ist deshalb der falsche Ort für persönliche Angaben: geben Sie ihr nur, was Sie auch auf eine öffentliche Seite stellen würden.
• Die Eingaben sind ohnehin von Natur aus öffentlich - sie sind das, was die Autorin oder der Autor des Links in die URL getippt hat, lesbar für jeden, den der Link erreicht. Geben Sie keine Geheimnisse in einen geteilten Link. Lolly bietet Link-Verschlüsselung für sensible Inhalte an.
• Antworten werden zwischengespeichert und ratenbegrenzt wie jedes öffentliche Bild, und mit noindex markiert, damit Suchmaschinen Ihre Renderings nicht indexieren.

Hosten Sie Lolly selbst und möchten keine öffentliche Render-Oberfläche? Setzen Sie LOLLY_DISABLE_RENDER_GET=1 , und jede dieser URLs liefert 404.

Der MCP-Server (optional, für KI-Agenten)

Lolly kann auch von einem KI-Agenten über das Model Context Protocol erreicht werden - ein von einem Betreiber betriebener Endpunkt (lolly.tools betreibt einen; jeder kann seinen eigenen selbst hosten, einschließlich vollständig abgeschottet). Er teilt die Kein-Konten-Haltung des Render-Pfads, plus vier Tools, die zwangsläufig Datei-Bytes verarbeiten:

• lolly_transform (ein geräteinternes Werkzeug serverseitig ausführen, im Auftrag des aufrufenden Agenten), lolly_verify (Content Credentials prüfen) und lolly_redact (Bereiche eines Bildes oder PDFs schwärzen) nehmen alle die Bytes einer Datei vom Aufrufer entgegen. Sie werden im Prozess, im Arbeitsspeicher verarbeitet, und das Ergebnis wird in demselben Aufruf zurückgegeben - die Datei wird nie auf Datenträger geschrieben und nie gespeichert, sobald die Anfrage abgeschlossen ist.
• lolly_rebrand (ein altes Foliendeck auf ein Designsystem

umstellen, über seine Phasen plan , compile und inspect ) nimmt die Bytes eines Decks auf dieselbe Weise entgegen und verarbeitet sie nur im Arbeitsspeicher, nur für diesen Aufruf - nichts wird auf Datenträger geschrieben oder aufbewahrt, sobald die Antwort gesendet ist. Seine erste Phase, capabilities , sagt in Worten, wohin Ihre Bytes gelangen würden, bevor Sie welche senden: Auf einem selbst gehosteten lokalen Server verlässt das Deck diese Maschine nie; auf einem gehosteten Server sendet der Aufruf von lolly_rebrand das Deck dorthin, bis zu den Größen- und Folienlimits, die dieselbe Phase angibt.

• Die Bildwerkzeuge (lolly_look, lolly_sample_color und lolly_trace_edges) können ebenfalls eine Bilddatei vom Aufrufer entgegennehmen und behandeln sie auf dieselbe Weise: im Arbeitsspeicher, nur für diesen Aufruf. Jedes andere Tool arbeitet mit den Parametern des Aufrufs: Text, Zahlen, Farben, URLs, Katalog-Asset-IDs oder einem Dokument, das der Aufrufer mitliefert.
• Auf lolly.tools ist lolly.tools/api/mcp für alle ohne Token offen. Die Aufrufe sind pro Adresse und durch ein Tagesbudget begrenzt: Die Adresse wird zu einem einweg-abgeleiteten Bucket-Schlüssel im Speicher der Missbrauchskontrolle, wie bei den Anmelde-Endpunkten weiter unten, und das Budget zählt nur CPU-Zeit und gesendete Bytes, ohne Adresse. Der geplante optionale eingeschränkte Endpunkt unter mcp.lolly.tools nutzt ein Bearer-Token, das der Betreiber an vertrauenswürdige Clients ausgibt, oder zustandsloses OAuth 2.1: kurzlebige signierte Tokens, geprüft gegen ein gemeinsames Geheimnis. Die Aktivierung steht noch aus. Das Bearer-Token selbst wird nie in ein Protokoll oder eine Render-URL geschrieben.

Content-Credentials-Identität (eine Anmeldung, die Sie selbst starten müssen)

Lolly kann Ihre Exporte mit einem kryptografischen Content Credential versiegeln, sodass jeder offline überprüfen kann, dass eine Datei seit dem Verlassen von Lolly unverändert ist. Das ist standardmäßig aktiviert und vollständig lokal - der Signierschlüssel wird auf Ihrem Gerät erzeugt, und das Signieren selbst geschieht offline. Ohne Registrierung ist dieser Schlüssel ein Wegwerfschlüssel: Für jeden Export wird ein frisches Schlüsselpaar erzeugt und zusammen mit ihm verworfen. Sobald Sie sich registrieren, wird der Schlüssel dauerhaft und nicht extrahierbar erzeugt - nicht einmal Lollys eigener Code kann ihn lesen, sondern ihn nur um eine Signatur bitten. So oder so verlässt er nie Ihr Gerät. Dieser Abschnitt behandelt den einen optionalen Schritt darüber hinaus: die Registrierung einer verifizierten Identität, sodass Ihre Exporte "Verifiziert - signiert von \<your email\>" anzeigen statt eines anonymen Schlüssels. Wenn Sie die Registrierung überspringen, betrifft Sie nichts in diesem Abschnitt, und es verlassen niemals persönliche Daten Ihr Gerät.

signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups24 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups25 KBPrüfen Sie es selbstSignierte Datei holen

Wenn Sie sich tatsächlich registrieren, geschieht genau Folgendes:

1. Sie wählen eine Anmeldemethode - GitHub, Google, SUSE (id.suse.com) oder einen per E-Mail zugesandten Link. Bei den drei OIDC-Anbietern werden Sie auf die eigene Anmeldeseite des Anbieters weitergeleitet, die dessen Datenschutzerklärung unterliegt, nicht unserer. Lollys Zertifikatsdienst erhält zurück nur eine verifizierte E-Mail-Adresse und den Namen des Anbieters. Beim E-Mail-Link wird die von Ihnen eingegebene Adresse an Resend übermittelt, eine transaktionale E-Mail-API, ausschließlich um diesen einen Link zuzustellen.
2. Ein kurzlebiges Cookie schützt die Weiterleitung. Das ist das einzige Cookie, das das gesamte Lolly-System setzt: lolly_ca_state, HttpOnly, auf /api/ca beschränkt, läuft innerhalb von zehn Minuten ab. Es trägt einen Zufallswert, keine Tracking- Kennung, und existiert nur, um zu verhindern, dass die OAuth-Weiterleitung gefälscht wird. Es wird gelöscht, sobald die Anmeldung abgeschlossen ist.
3. Ihre IP-Adresse wird kurzzeitig verwendet, um Missbrauch der Anmelde-Endpunkte

zu verhindern (damit ein Skript nicht einen Posteingang zuspammen oder das E-Mail-Kontingent aufbrauchen kann). Lolly hasht sie, bevor daraus ein kurzlebiger Missbrauchskontroll-Bucket erzeugt wird; die rohe Adresse wird nie an diesen Speicher gesendet. Der Bucket läuft nach etwa einer Minute ab und wird nicht zur Verfolgung genutzt. Gewöhnliche Hosting-Zugriffsprotokolle sind davon getrennt und werden weiter unten beschrieben.

4. Der Zertifikatsdienst stellt ein kurzlebiges Zertifikat aus (7, 30, 90 oder 365 Tage, Ihre Wahl, begrenzt durch die Richtlinie des Betreibers), das Ihre verifizierte E-Mail-Adresse an die öffentliche Hälfte des auf Ihrem Gerät erzeugten Schlüsselpaars bindet. Die private Hälfte verlässt nie Ihren Browser.
5. Nichts über die Ausstellung wird aufgezeichnet. Der Zertifikatsdienst führt kein Ausstellungs- protokoll: nicht Ihre E-Mail, nicht den Anbieter, nicht eine Seriennummer, nicht einen Zeitstempel. Keine Datenbank, keine Protokollzeile, kein Webhook. Ihre E-Mail-Adresse existiert in der Anfrage nur so lange, bis sie in das Zertifikat geschrieben ist, das Ihr eigenes Gerät erhält, danach ist sie auf unserer Seite vollständig verschwunden.
6. Danach ist das Signieren wieder offline, für die gesamte Laufzeit des Zertifikats. Der Export einer Datei kontaktiert nie den Zertifikatsdienst - nur die Registrierung tat das.

Der Kompromiss, unverblümt gesagt. Eine frühere Version dieses Dienstes protokollierte tatsächlich jede Ausstellung, damit ein fehlerhaft ausgestelltes oder kompromittiertes Zertifikat nachverfolgt werden konnte. Wir haben das entfernt, weil dieses Protokoll die einzige Stelle in ganz Lolly war, an der personenbezogene Daten auf einem Server zur Ruhe kamen, und wir sie lieber gar nicht halten als sorgfältig halten. Was wir aufgeben, ist serverseitige Nachverfolgbarkeit: Wird ein Zertifikat missbraucht, können wir nicht nachschlagen, wer es erhalten hat. Zertifikate sind von Natur aus kurzlebig - 7 bis 365 Tage, Ihre Wahl, begrenzt durch den Betreiber - und laufen von selbst ab, was die Abhilfe ist, auf die wir stattdessen setzen. Selbst-Hoster, deren eigene Pflichten ein Prüfprotokoll verlangen, können eines hinzufügen und werden dadurch zum Verantwortlichen für diese Daten.

Die Browser-Erweiterung

Die Browser-Erweiterung Lolly URL Screenshot erhebt für uns keine personenbezogenen Daten. Sie hat keine Analyse, kein Tracking und keinen eigenen Server. Die Seite Browser-Erweiterung beschreibt, wie sie funktioniert.

Was sie tut. Die Lolly-Web-App kann sie um einen Screenshot einer Webseite bitten oder um den Inhalt einer Seite, um aus einer Website ein Designsystem zu starten. Jede Anfrage öffnet in der Erweiterung ein Freigabefenster, das die anfragende Website zeigt, ob ein Screenshot oder der Seiteninhalt gewünscht ist, und die Adresse der Seite. Erst nachdem Sie auf Approve once geklickt haben, öffnet die Erweiterung diese Seite in einem temporären Hintergrundtab, nimmt den Screenshot auf oder liest die Seite, übergibt das Ergebnis an den Lolly-Tab, der angefragt hat, und schließt den Tab. Jede Anfrage braucht ihre eigene Freigabe.

Daten.

• Wir sammeln nichts. Das Ergebnis geht nur an die Lolly-Seite, die angefragt hat, im selben Browser. Die Erweiterung speichert keine Seiteninhalte und fügt keinen weiteren Empfänger hinzu.
• Netzwerkanfragen. Die Seite, die Sie freigeben, wird geladen wie in jedem Tab, zusammen mit allem, was die Seite selbst anfragt. Beim Lesen des Seiteninhalts werden außerdem die Stylesheets der Seite und einige ihrer Icon- und Logo-Bilder aus der Seite heraus abgerufen, und diese Abrufe senden keine Cookies an andere Websites. Die Erweiterung stellt keine weiteren Anfragen, und keine geht an einen Lolly-Server.
• Ihre Browsersitzung. Die Seite wird mit Ihrer Browsersitzung geladen, so wie wenn Sie sie selbst öffnen würden, daher kann eine Seite, bei der Sie angemeldet sind, private Informationen im Ergebnis zeigen.
• Die Adressen, die Sie freigeben, werden nur verwendet, um diese eine Seite für diese eine Anfrage zu laden. Sie werden nicht protokolliert oder weitergegeben.

Berechtigungen.

• debugger - um den Screenshot über das DevTools-Protokoll aufzunehmen (derselbe Mechanismus, den die Lolly-Desktop-App verwendet).
• tabs - um den temporären Tab zu öffnen und zu schließen und zu prüfen, dass sich weder die Lolly-Seite noch die Zielseite seit Ihrer Freigabe verändert hat.
• scripting - um den Seiteninhalt im temporären Tab zu lesen, nachdem Sie diese Anfrage freigegeben haben.
• storage - um die IDs seiner temporären Tabs im Sitzungsspeicher zu vermerken, damit sie sich auch dann schließen, wenn der Browser die Erweiterung während einer Anfrage anhält. Seiteninhalte werden nicht gespeichert.
• *Optionaler Website-Zugriff (http:///, https:///) - wird bei der Installation nicht gewährt. Wenn Sie auf Approve once* klicken, bittet die Erweiterung Chrome um Zugriff auf die eine Website dieser Anfrage, und Chrome fragt Sie bei jeder Website beim ersten Mal. Eine Website, die Sie früher erlaubt haben, braucht für jede Anfrage trotzdem eine neue Freigabe.

Keine dieser Berechtigungen wird verwendet, um Ihr Surfverhalten über die eine Anfrage hinaus zu lesen, zu überwachen oder zu übertragen, die Sie freigegeben haben.

Infrastruktur-Protokolle

Wie jede Website erzeugen die Server hinter lolly.tools - und hinter jeder Lolly-Bereitstellung - standardmäßige Webserver-Zugriffsprotokolle, sobald überhaupt eine Anfrage sie erreicht: IP-Adresse, angeforderter Pfad, Zeitstempel, User-Agent. Das ist grundlegendes Hosting-Verhalten, nichts, was Lolly zusätzlich hinzufügt, und es enthält nie den Inhalt Ihrer Dokumente, weil diese von vornherein nie einen Server erreichen. Die eine bewusste Ausnahme ist eine Datei, die Sie ausdrücklich an einen MCP-Aufruf lolly_transform , lolly_verify , lolly_redact oder lolly_rebrand übergeben, der im Arbeitsspeicher verarbeitet und nie auf Festplatte oder in ein Protokoll geschrieben wird, wie oben beschrieben.

Lollys eigener Code schreibt nichts in diese Protokolle. Der MCP-Server protokolliert Start, Konfiguration und Render-Warnungen; er führt kein eigenes Anfrageprotokoll und protokolliert weder Tokens noch Adressen der Aufrufer. Die Penpot-Durchleitung protokolliert jeden Befehlsnamen und den Antwortstatus von Penpot, nie Header, Tokens oder die Datei. Der Zertifikatsdienst protokolliert seine Starteinstellungen und Konfigurationswarnungen, dazu zwei reduzierte Zeilen bei einem Fehler: einen Fehlercode für einen gescheiterten Versand ohne Empfängeradresse und eine feste Fehlerzeile ohne Fehlertext, Stack-Trace oder URL (ein Fehler des Anbieters kann Identitätswerte oder Zugangsdaten enthalten). Alles andere im Protokoll stammt von der Hosting-Plattform, nicht von uns.

Für lolly.tools ist Vercel der Hoster, und die Aufbewahrung der Zugriffsprotokolle folgt Vercels eigenen Plattform-Standardwerten für unseren Tarif. Wir richten keinen Log-Drain, keinen langfristigen Log- Export und kein zusätzliches Analyse- oder Monitoring-Produkt ein. Wir behalten selbst keine Kopie dieser Protokolle, was auch bedeutet, dass wir keine Möglichkeit haben, sie für Sie zu durchsuchen - siehe Ihre Rechte.

Rechtsgrundlagen, Aufbewahrung und Empfänger

Für fast nichts hier braucht es eine Rechtsgrundlage, weil fast nichts verarbeitet wird. Der Vollständigkeit halber die gesamte Liste:

Empfänger. Die Kategorien von Empfängern sind: unser Hosting-Anbieter (Vercel Inc.); unser Anbieter für den Missbrauchskontroll-Speicher, der nur kurzlebige, einweg-abgeleitete Bucket-Schlüssel erhält und niemals die rohe IP-Adresse; und - nur wenn Sie die E-Mail-Anmeldeoption nutzen - ein Anbieter für Transaktions-E-Mails (Resend). Wenn Sie sich mit GitHub, Google oder SUSE (id.suse.com) anmelden, interagieren Sie direkt mit diesem Anbieter unter dessen eigener Datenschutzrichtlinie. Diese teilen uns eine verifizierte E-Mail-Adresse mit und sonst nichts. Wir geben personenbezogene Daten an niemand anderen weiter, und wir verkaufen keine Daten, betreiben keine Werbung und erstellen keine Nutzerprofile.

Übermittlungen außerhalb des EWR. Vercel und Resend sind US-Unternehmen. Die Rechenleistung für lolly.tools ist an Vercels Frankfurt-Region ( fra1 ) gebunden, sodass die Verarbeitung in der EU stattfindet, aber als in den USA ansässige Anbieter können sie weiterhin als Auftragsverarbeiter aus den USA auf Daten zugreifen. Diese Übermittlungen stützen sich auf die Standardvertragsklauseln der Europäischen Kommission und/oder das EU-US Data Privacy Framework, wie im Auftragsverarbeitungsvertrag jedes Anbieters festgelegt. Weil die personenbezogenen Daten, die diese Anbieter erreichen, so begrenzt sind - eine E-Mail-Adresse, die zum Versand einer Nachricht weitergegeben wird, gewöhnliche Zugriffsprotokolle und ein kurzlebiger, abgeleiteter Missbrauchskontroll-Bucket - ist die Exposition entsprechend gering.

Automatisierte Entscheidungsfindung. Keine. Es gibt kein Profiling und keine automatisierte Entscheidung, die rechtliche oder ähnlich bedeutsame Auswirkungen hat (Art. 22).

Datenschutz für Kinder

Lolly sammelt wissentlich von niemandem, jeden Alters, im gewöhnlichen Verlauf der App-Nutzung personenbezogene Informationen - es gibt nichts zu sammeln. Der einzige Ort, an dem personenbezogene Informationen (eine E-Mail-Adresse) überhaupt erhoben werden, ist die oben beschriebene Content-Credentials-Registrierung, die sich nicht an Kinder richtet und nicht für sie bestimmt ist.

Ihre Rechte

Weil fast alles, womit Lolly in Berührung kommt, nur auf Ihrem eigenen Gerät gespeichert wird, sind die meisten der Dinge, die das Datenschutzrecht „Ihre Rechte“ nennt - Auskunft, Berichtigung, Löschung, Datenübertragbarkeit - Dinge, die Sie bereits selbst tun können, sofort, ohne jemanden zu fragen: Ihre Daten liegen im Speicher Ihres Browsers, in einer Form, die Sie einsehen, exportieren (Meine Daten exportieren, oben) oder löschen können (indem Sie den Speicher der Seite in Ihrem Browser leeren, wie oben).

Formal haben Sie gemäß den Artikeln 15-22 DSGVO das Recht auf Auskunft über Ihre personenbezogenen Daten, auf deren Berichtigung, auf deren Löschung, auf Einschränkung oder Widerspruch gegen deren Verarbeitung (einschließlich Widerspruch gegen alles, was wir auf berechtigte Interessen stützen), auf Datenübertragbarkeit und - wo die Verarbeitung auf Einwilligung beruht - auf die jederzeitige Widerrufung dieser Einwilligung, ohne dass die Rechtmäßigkeit dessen berührt wird, was vor dem Widerruf geschah.

Hier die ehrliche Position zur Ausübung dieser Rechte uns gegenüber. Da wir kein Ausstellungsprotokoll mehr führen, halten wir keine personenbezogenen Daten über Sie, die wir nachschlagen, korrigieren, exportieren oder löschen könnten. Wenn Sie uns schreiben und fragen, was wir über Sie gespeichert haben, lautet die wahrheitsgemäße Antwort: nichts, und das werden wir Ihnen so sagen. Die einzige überhaupt existierende Kategorie sind Hosting-Zugriffsprotokolle, die einer IP-Adresse zugeordnet sind und von unserem Hosting-Anbieter nach dessen Standard-Aufbewahrungsfristen gehalten werden. Wir haben keine Möglichkeit, diese zu durchsuchen oder selektiv zu löschen, und wir werden Ihnen das mitteilen, statt etwas anderes vorzugeben. Alles, was tatsächlich Ihnen gehört, liegt auf Ihrem Gerät, wo Sie es bereits lesen, exportieren und vernichten können, ohne jemanden um Erlaubnis zu fragen.

Sie haben das Recht auf Beschwerde. Wenn Sie glauben, dass wir Ihre Daten unsachgemäß behandelt haben, können Sie eine Beschwerde bei einer Datenschutz-Aufsichtsbehörde einreichen - in der EU die Behörde Ihres Wohnsitzlands, Ihres Arbeitsorts oder des Orts, an dem der Verstoß Ihrer Meinung nach stattgefunden hat (Art. 77). Unsere federführende Aufsichtsbehörde ist das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) in Ansbach, Deutschland. Sie müssen sich nicht zuerst an uns wenden, auch wenn wir gerne die Gelegenheit hätten, es zu beheben.

Wir verkaufen keine Daten. Wir haben keine zu verkaufen.

Änderungen an dieser Richtlinie

Das Datum oben ändert sich, wann immer sich dieses Dokument ändert. Eine Änderung, die betrifft, was Ihr Gerät verlässt oder was gespeichert wird, bekommt hier eine eigene Zeile, keine stille Änderung - wenn Sie sehen möchten, was sich geändert hat, fragen Sie (unten) oder vergleichen Sie mit der öffentlichen Quelle.

22. Oktober 2026: Die Beschreibung des bestehenden Verhaltens wurde korrigiert. Der Abschnitt zur Browser-Erweiterung behandelt jetzt das Freigabefenster für jede Anfrage, den Website-Zugriff, der jeweils für eine Website einzeln angefragt wird, und die Abrufe von Stylesheets und Icons beim Lesen einer Website. Ebenfalls korrigiert: die Zeilen zu Send to Google Drive und Meeting Planner, der Hinweis zu SEAL (keine Lolly-App schlägt SEAL-Schlüssel im DNS nach), die Standardstufe der Nutzungstelemetrie des Organisationsdienstes, die MCP-Bildwerkzeuge und die Anwendungsprotokollierung der öffentlichen Dienste. Die Software selbst hat sich nicht geändert.

Wer verantwortlich ist, und wie Sie uns erreichen

Der Verantwortliche für lolly.tools ist:

SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Deutschland

SUSE hat einen Datenschutzbeauftragten benannt, erreichbar unter privacy@suse.com. Nutzen Sie diese Adresse für jede formale Anfrage im Sinne von "Ihre Rechte" oben.

Für alles rund um Lolly selbst - wie es funktioniert, warum etwas so ist, wie es ist, oder eine Korrektur an diesem Dokument - kontaktieren Sie Andy Fitzsimon, fitzy@suse.com.

Für eine selbst gehostete oder Enterprise-Lolly-Instanz kontaktieren Sie stattdessen den Betreiber: Der Betreiber ist der Verantwortliche für seine eigene Bereitstellung. SUSE und das Lolly-Open-Source-Projekt halten keine Daten für Bereitstellungen, die sie nicht selbst betreiben.