Privacy Policy

Last updated: 5 October 2026

The short version. Ordinary Lolly editing, rendering and downloads happen on your device and need no account. Features such as sharing, Sync, hosted rendering and optional lolly.work organisation services send the data they need to the destination you or your organisation use. lolly.work can hold shared content, identities, audit records and configured usage telemetry. The sections below distinguish local data from those server-held records.

What this policy covers

Lolly is open-source software - an engine, several app shells (web, desktop, mobile, CLI) and a browser extension - that anyone can run. This policy has two parts:

• The software itself: what it does and doesn't do with your data, wherever it runs. This is a property of the code, so it's true of every Lolly deployment, ours or anyone else's.
• lolly.tools, the reference deployment SUSE operates: the specific choices made running its optional server-side pieces (what's logged, for how long, by whom).

If you're using a self-hosted or enterprise Lolly instance, the software behaviour below still applies, but the operator of that instance - not SUSE - is responsible for anything server-side: their render endpoint, their MCP server, their Content Credentials certificate authority and their optional lolly.work instance, including its accounts, shared content, telemetry and audit records. Ask them for their own policy. See Adoption & Governance for what operating Lolly involves.

The app: what stays on your device

Lolly's web, desktop and mobile shells run the entire render engine client-side. The local render and download path needs no server once its tools, assets and encoders are available. Connected organisation workflows can separately save shared state or submit content for review and delivery, as described below.

Standalone app use sets no cookies. Organisation sign-in and optional CA enrolment have separate cookies, described below. The app keeps these local records; sharing, Sync and organisation workflows are separate data flows:

• Interface preferences - theme, language, sound settings, sidebar/zoom sizing, sort and view choices, which onboarding tips you've seen - in localStorage, so they're available before the app has finished booting.
• An offline cache of the tool catalogue and asset previews, so the gallery works without a connection.
• Local usage counters for your profile card's stats (how many exports, which tools) - a small bounded blob in localStorage, never read by us, never sent anywhere.
• Your own documents, saved sessions, uploaded assets and fonts - stored in IndexedDB on your device. Personal saves stay there unless you choose Sync or sharing; organisation-held sessions and assets are described below.

Local storage itself sends none of these records to us. Optional network features have their own destinations and data handling, described below. Clearing the site's storage in your browser removes the local copy at any time, and so does Settings → Storage → Clear all my data, which also turns off Sync first. (Under the ePrivacy Directive Art. 5(3), storage that is strictly necessary for the service you asked for doesn't require consent - only transparency, which is what this document and the in-app notice both are.)

signed by Lollyvector SVG2026-09-30Check it yourselfGet the signed file32 paths~4.2k nodes86 groups59 KBsigned by Lollyvector SVG2026-09-30Check it yourselfGet the signed file32 paths~4.2k nodes86 groups59 KB

Your own backup of this data - the lolly-backup bundle produced by Export my data - is a file you keep and control. It never touches our servers unless you choose to send it somewhere yourself. See Data Transfer.

On-device utilities

Some tools - Strip Hidden Data, Compress PDF and others carrying the "Runs on your device" badge - operate on a file you provide. The file is read into memory in your browser, transformed locally and offered back as a download. It is never uploaded, because there is no server in the path to upload it to. These utilities work offline, and their output carries no watermark or metadata of ours - the point of most of them is to remove & protect data, not add risk. Rondocode is the one exception, because it makes new audio from your song rather than transforming a file of yours: every audio file it writes carries Content Credentials that record the song and declare any AI-generated singing, the Export panel says so before you export, and Exporting lists exactly what is recorded.

signed by Lollyvector SVG2026-09-30Check it yourselfGet the signed file1 path7 nodes3 KBsigned by Lollyvector SVG2026-09-30Check it yourselfGet the signed file1 path7 nodes3 KB

Prepare for sharing holds working inputs, private findings and replacement maps in memory, without automatically adding them to history, links, backups or sync. Inspection and replacement do not send file contents to a server or validate credentials online. Users choose whether to copy, download, send or explicitly save a result to their library; a saved result then follows normal library backup and sync settings. Recipe files omit prior payloads and literal mappings. Summary reports contain counts, scope IDs and file hashes. The CLI can also save a private review file containing original values, only when explicitly requested with --review-file. Clearing or leaving a browser preparation view releases its working state; this is not a promise of forensic erasure from browser or OS memory.

Every network request the app can make

The table below lists the app's network features. Organisation services are grouped in one row and detailed in their own section. An operator's configured identity and asset providers can add destinations to that deployment.

A Design web page object's Use page action lets you reject cookies or close a banner inside the page. For accessible Lolly pages, Hide cookie banners hides known overlays, including OneTrust, without accepting cookies or changing the site's consent choice. Page CSS changes that object's live page and presentation; exports still use the chosen poster. The rules cannot import resources or fonts. Browsers prevent Lolly from changing another site's CSS. Sandbox previews have their own CSS editor under Edit in Sandbox.

Every fixed host in that table is also the complete allowlist in the app's Content-Security-Policy, which the browser enforces. So the list is not only a description of what the code does today, it is the boundary the browser holds the app to: a future change that tried to contact some other host would be blocked, not silently permitted. One row is the deliberate exception, and its own cell explains it: Send to LinkedIn exists in the desktop apps only, and the web app's policy lists neither of its hosts - the web app could not reach them even if its code tried. Two more rows, Bluesky and Discord, are desktop-only the same way, and their hosts are left out of the web policy for the same reason. Five rows have no fixed host, because you choose the address at the moment of use: a URL you ask a tool to capture, a remote instance you point the shell at, and your own Mastodon server, WebDAV server or S3 bucket (the last two also as a sync home). None of those is in the policy, and each uses the destination you selected. A lolly.work deployment must also permit its configured identity providers and service connections; it does not inherit an unchanging list of public-reference hosts. The Penpot row reaches Penpot through the app's own origin, so it is covered by 'self'. A deployment that wants none of the optional ones (an enterprise instance with its own fonts, say) removes those hosts from its policy and the features fail closed rather than reaching out.

Most fetches bring tools, fonts or models to your device. Send actions transmit the selected file, personal Sync transmits a backup to your chosen storage, and organisation services transmit the content or metadata needed for shared work. Hosted render and MCP requests have the separate data flows described below.

A note on what we removed. Verify can check SEAL signatures, a scheme where a file's signing key is published in DNS. Browsers can't make DNS queries, so any web implementation has to route the lookup through a third-party DNS-over-HTTPS resolver - which would show that operator the domain being checked plus your IP address. We used to use Cloudflare's. We don't any more, and there is no replacement: the web app now passes no resolver at all, so SEAL verification here makes zero network requests. Files whose SEAL record carries its key inline still verify completely offline. Files whose key lives in DNS report "no key resolver" instead, and you can check those in the desktop or command-line app, which resolve DNS natively through your own machine with no third party involved.

signed by Lollyvector SVG2026-09-30Check it yourselfGet the signed file11 paths~4.4k nodes18 groups52 KBsigned by Lollyvector SVG2026-09-30Check it yourselfGet the signed file11 paths~4.4k nodes18 groups52 KB You can confirm this yourself: greppable checks for this and every other claim on this page, with the exact commands and expected output, live at Verify It Yourself.

Organisation services with lolly.work

lolly.work is the Lolly project's optional, separately deployed organisation service. Connecting to an instance introduces server-held data alongside local editing. Its operator is responsible for that deployment's privacy policy, access controls, recipients, retention and backups.

The service uses authentication cookies, including lw_session for signed-in members and lw_guest for guest access where enabled. These are separate from the CA enrolment cookie below. Policy refreshes and enabled usage reporting can make requests while the app is in use; a separate click is not needed for every request. This is traffic to the configured instance, not a report to the Lolly project about deployments it does not operate.

Usage telemetry has three levels: off stores no usage events; aggregate strips user ids; standard can attribute events. The default attribution policy is opt-in, which requires the user's consent before storing a user id. An operator can instead configure attributed reporting with telemetryAttribution: default. Allowed attributes are labels, not tool input values. See the telemetry reference.

Audit is separate. Governed actions can retain an identified audit record regardless of usage-telemetry consent. Turning telemetry off does not turn off shared-session storage, approval records, render-job storage or audit. The operator controls retention and erasure, including any audit pseudonymisation; see data lifecycle.

Local deletion is not server deletion. Leaving an instance or clearing your browser removes local state, not the organisation's stored records or backups. Ask the operator for access, export or erasure of server-held data. Personal Sync and Export my data are backups of your device, not of that organisation service. The public lolly.work sandbox is a demonstration with memory-only state, not durable storage for your work.

Hot-linked render URLs

Live on lolly.tools. Every https://lolly.tools/tool/<tool-id>.<ext>?<inputs> URL renders for real, and the inputs travel in that URL. The section below is what that means for you, and an operator can switch the feature off on their own instance.

The app itself stays entirely on your device. Separately, an operator can enable hot-link render URLs - /tool/<tool-id>.<ext>?<inputs> - so a shared Lolly link can appear as a live image in a README, a wiki or a dashboard. Fetching one asks the server to render public tool and catalogue data with the inputs written into the URL.

• No accounts, no cookies, no state. The endpoint is anonymous, and nothing on your device is read. Your documents, sessions and uploads never leave your browser - they cannot appear in these links at all.
• But the URL itself is recorded. A URL's query string is part of the request line, so it shows up in the hosting platform's ordinary access logs the same way every requested path does. If a link's inputs contain someone's name or email - a name badge, an email signature - that text sits in those logs, and no amount of policy wording changes it. So a hot-link URL is the wrong place for personal details: give it only what you would put on a public page.
• The inputs are public by construction anyway - they are whatever the link's author typed into the URL, readable by anyone the link reaches. Don't put secrets in a shared link. Lolly offers link encryption for sensitive content.
• Responses are cached and rate-limited like any public image, and marked noindex so search engines don't index your renders.

Self-hosting Lolly and don't want a public render surface? Set LOLLY_DISABLE_RENDER_GET=1 and every one of these URLs returns 404.

The MCP server (optional, for AI agents)

Lolly can also be reached by an AI agent over the Model Context Protocol - an operator-run endpoint (lolly.tools runs one; anyone can self-host their own, including fully air-gapped). It shares the render path's no-accounts posture, plus the tools that necessarily handle file bytes:

• lolly_transform (run an on-device utility server-side, on the calling agent's behalf), lolly_verify (check Content Credentials), lolly_redact (black out regions of an image or PDF), lolly_read (read what a slide deck says), lolly_check (check a document or an export, optionally against its source deck), lolly_package (package a Design document as a .lolly, with the pictures and the source deck the caller supplies) and lolly_compose (lay slides out from a slide master, reading the text of a source deck the caller supplies) all accept a file's bytes from the caller. They are processed in-process, in memory, and the result is returned in that same call - the file is never written to disk and never stored once the request completes.
• lolly_rebrand (renovate an old slide deck onto a design system, across its plan, compile and inspect stages) accepts a deck's bytes the same way, and processes them in memory, for that call only - nothing is written to disk or kept once the response is sent. Its first stage, capabilities, states in words where your bytes would go before you send any: on a self-hosted local server the deck never leaves that machine; on a hosted server, calling lolly_rebrand sends the deck there, up to the size and slide limits that same stage gives.
• Every other tool - lolly_render, lolly_build_url, lolly_list_tools, lolly_describe_tool - works from parameters only (text, numbers, colours, URLs, catalogue asset ids), the same inputs a hot-link render URL takes.
• On lolly.tools, lolly.tools/api/mcp is open to anyone with no token. Its calls are limited per address and by a daily budget: the address becomes a one-way-derived bucket key in the abuse-control store, as on the sign-in endpoints below, and the budget counts only CPU time and bytes sent, with no address. mcp.lolly.tools takes a shared token the operator issues to clients they trust, or stateless OAuth 2.1: short-lived signed tokens verified against a shared secret, nothing stored server-side and the token itself is never written to a log or a render URL.

Content Credentials identity (a sign-in you have to start yourself)

Lolly can seal a cryptographic Content Credential into your exports so anyone can verify, offline, that a file is unaltered since it left Lolly. That much is on by default and fully local - the signing key is generated on your device and signing itself happens offline. Without enrolment that key is a throwaway: a fresh keypair minted for each export and dropped with it. Once you enrol, the key becomes a lasting one and is generated non-extractable - not even Lolly's own code can read it, only ask it to sign. Either way it never leaves your device. What a credential records is listed in Exporting: the tool, the time, the coarse export surface, your name only when you turned on Use my details, the credited works an export places, and each rondocode song a video or audio export plays (its name, a hash of its source and how Lolly's sandbox rendered the song). The export panel lists those songs before you export. This section covers the one optional step on top of that: enrolling a verified identity, so your exports say "Verified - signed by \<your email\>" instead of an anonymous key. If you skip enrolment, this certificate service receives no enrolment data from you. Other optional services have the data flows described above.

signed by Lollyvector SVG2026-09-30Check it yourselfGet the signed file8 paths~1.9k nodes12 groups23 KBsigned by Lollyvector SVG2026-09-30Check it yourselfGet the signed file8 paths~1.9k nodes12 groups23 KB

If you do enrol, here is exactly what happens:

1. You choose a sign-in method - GitHub, Google, SUSE (id.suse.com) or an emailed link. For the three OIDC providers, you're redirected to that provider's own login page, governed by their privacy policy, not ours. Lolly's certificate service receives back only a verified email address and the provider's name. For the email link, the address you type is passed to Resend, a transactional email API, solely to deliver that one link.
2. A short-lived cookie protects the redirect. The certificate service sets lolly_ca_state, HttpOnly, scoped to /api/ca, expiring within ten minutes. It carries a random value, not a tracking identifier, and exists only to stop the OAuth redirect being forged. It is cleared as soon as sign-in completes.
3. Your IP address is used, briefly, to prevent abuse of the sign-in endpoints (so one script can't spam an inbox or exhaust the email quota). Lolly hashes it before creating a short-lived abuse-control bucket; the raw address is not sent to that store. The bucket expires after about a minute and is not used for tracking. Ordinary hosting access logs are separate and described below.
4. The certificate service issues a short-lived certificate (7, 30, 90 or 365 days, your choice, capped by the operator's policy) binding your verified email to the public half of the keypair generated on your device. The private half never leaves your browser.
5. Nothing about the issuance is recorded. The certificate service keeps no issuance log: not your email, not the provider, not a serial number, not a timestamp. No database, no log line, no webhook. Your email address exists in the request only long enough to be written into the certificate that your own device receives, and then it is gone from our side entirely.
6. After that, signing is offline again for the certificate's whole lifetime. Exporting a file never contacts the certificate service - only enrolling did.

The tradeoff, stated plainly. An earlier version of this service did log each issuance, so that a misissued or compromised certificate could be traced. We removed it to avoid retaining personal data in this certificate service. Organisation identity and audit records in lolly.work are separate and follow the operator's retention policy. What we give up is server-side traceability: if a certificate is misused we cannot look up who obtained it. Certificates are short-lived by design - 7 to 365 days, your choice, capped by the operator - and expire on their own, which is the mitigation we rely on instead. Self-hosters whose own obligations require an audit log can add one, and become the controller of that data by doing so.

The browser extension

The Lolly URL Screenshot browser extension does not collect, store or transmit any personal data. No analytics, no tracking, no remote server.

What it does. When you ask the Lolly web app to screenshot a URL, the extension opens that page in a temporary background tab, captures it in your browser using the DevTools Protocol, hands the image back to the app and closes the tab. Everything happens locally, on your own device and network.

Data.

• We collect nothing. The extension has no servers and makes no network requests of its own.
• Captured images go straight to the Lolly app in the same browser - never uploaded by the extension.
• The URLs you capture are used only to load that one page for that one screenshot. They are not logged or shared.

Permissions.

• debugger - to capture the rendered page via the DevTools Protocol (the same mechanism the Lolly desktop app uses).
• tabs - to open and close the temporary tab the page loads in.
• Host access (<all_urls>) - because the page you choose to capture can be on any site. Chrome surfaces this at install time as a broad permission warning. The extension only ever visits the URL you give it.

None of these are used to read, monitor or transmit your browsing beyond that one requested capture.

Infrastructure logs

This section describes the public lolly.tools deployment. Its hosting platform records ordinary request metadata: IP address, requested path, timestamp and user agent. Local edits do not reach that host. A hot-link render's query string can contain the text supplied by its caller, as explained above. MCP file tools process supplied bytes in memory. A separate lolly.work deployment additionally holds the service records described above and has its operator's logging policy.

The public services minimise application logging. The MCP server contains no logging statements at all. The certificate service emits exactly two lines, both on failure and both deliberately stripped: a send-failure status code with no recipient address, and an error message with no stack trace or URL (a stack could carry an enrolment token). Everything else in the log is the hosting platform's, not ours.

For lolly.tools, hosting is Vercel and access-log retention follows Vercel's own platform defaults for our plan. We configure no log drain, no long-term log export and no analytics or monitoring product on top. We keep no copy of these logs ourselves, which also means we have no way to search them for you - see Your rights.

Legal bases, retention and recipients

This table covers the reference lolly.tools deployment. It does not state the legal bases or retention periods of your organisation's lolly.work instance; its operator must provide those in its own policy.

Recipients. The categories of recipient are: our hosting provider (Vercel Inc.); our abuse-control store provider, which receives only short-lived, one-way-derived bucket keys and never the raw IP address; and - only if you use the email sign-in option - a transactional email provider (Resend). If you sign in with GitHub, Google or SUSE (id.suse.com), you interact with that provider directly under their own privacy policy. They tell us a verified email address and nothing else. We share personal data with no one else, and we do not sell data, run advertising or profile users.

Transfers outside the EEA. Vercel and Resend are US companies. Function compute for lolly.tools is pinned to Vercel's Frankfurt (fra1) region so processing happens in the EU, but as US-headquartered providers they may still access data as processors from the US. Those transfers rely on the European Commission's Standard Contractual Clauses and/or the EU-US Data Privacy Framework, as set out in each provider's data processing agreement. Because the personal data reaching these providers is so limited - an email address passed through to send one message, ordinary access logs, and a short-lived derived abuse-control bucket - the exposure is correspondingly small.

Automated decision-making. None. There is no profiling and no automated decision producing legal or similarly significant effects (Art. 22).

Children's privacy

Ordinary local app use does not send personal content to lolly.tools. Its optional Content Credentials enrolment receives an email address and is not directed at or intended for children. Organisation services have separate accounts and data handling; their operator's policy applies.

Your rights

For records stored only on your device, you can access, correct, delete and move the data yourself. Your data lives in your browser's storage, in a form you can inspect, export (Export my data, above) or delete (by clearing the site's storage in your browser, as above).

Formally, under GDPR Articles 15-22 you have the right to access your personal data, to rectify it, to erase it, to restrict or object to its processing (including objecting to anything we base on legitimate interests), to data portability and - where processing rests on consent - to withdraw that consent at any time, without affecting the lawfulness of what happened before you withdrew it.

For the public lolly.tools services described here, we no longer keep an issuance log, so we hold no personal data about you that we can look up, correct, export or delete. If you write and ask what we have on you, the truthful answer is nothing, and we will state it. The one category that exists at all is hosting access logs keyed to an IP address, held by our hosting provider under their retention defaults. We have no facility to search or selectively delete those, and we will tell you that rather than pretend otherwise. Your local records remain accessible on your device. For organisation-held work, identities, telemetry and audit records, contact your lolly.work operator; local export and deletion controls do not manage those copies.

You have the right to complain. If you think we have handled your data improperly, you can lodge a complaint with a data protection supervisory authority - in the EU, the authority in your country of residence, place of work or where you believe the infringement occurred (Art. 77). Our lead supervisory authority is the Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) in Ansbach, Germany. You do not need to contact us first, though we would like the chance to fix it.

We do not sell personal data.

Changes to this policy

The date at the top changes whenever this document does. A change that alters what leaves your device or what's retained gets its own line here, not a silent edit - if you want to see what changed, ask (below) or compare against the public source.

29 September 2026: clarified the optional lolly.work service, its organisation-held content, authentication cookies, usage telemetry and audit records, and the separation between local deletion and server retention. These are existing optional workflows, not a new upload requirement for local editing.

Who is responsible, and how to reach us

The data controller for lolly.tools is:

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

SUSE has appointed a Data Protection Officer, reachable at privacy@suse.com. Use that address for any formal request under "Your rights" above.

For anything about Lolly itself - how it works, why a thing is the way it is or a correction to this document - contact Andy Fitzsimon, fitzy@suse.com.

For a self-hosted or enterprise Lolly instance, contact whoever operates it instead: the operator is the controller for their own deployment. SUSE and the Lolly open source project hold no data for deployments they don't run.