Patakaran sa Privacy

Huling na-update: 22 Oktubre 2026

Ang maikling bersyon. Ang mga dokumento, larawan, video, at file na ginagawa mo sa Lolly ay nananatili sa device mo. Walang account para sa ordinaryong paggamit, walang cookie mula sa app mismo, at walang analytics o tracker kahit saan sa codebase - hindi ito kaso ng "hindi namin ginagamit ang datos," kundi talagang wala ito sa source. May maikli, kumpletong listahan ng mga eksepsiyon kung saan nakikipag-ugnayan ang software sa network, at bawat isa sa mga ito ay inilalarawan nang detalyado sa ibaba: ano ang umaalis, kanino, at kailan. Ang tanging eksepsiyon na may kinalaman sa anumang personal ay isang sign-in na kailangan mong sadyang simulan. Kung wala ito sa dokumentong ito, hindi ito nangyayari.

Ano ang sinasaklaw ng patakarang ito

Ang Lolly ay open-source software - isang engine, ilang app shell (web, desktop, mobile, CLI) at isang browser extension - na kayang patakbuhin ng sinuman. May dalawang bahagi ang patakarang ito:

• Ang software mismo: kung ano ang ginagawa at hindi ginagawa nito sa iyong data, saan man ito tumakbo. Ito ay katangian ng code, kaya totoo ito para sa bawat Lolly deployment, sa amin man o sa iba.
• lolly.tools, ang reference deployment na pinapatakbo ng SUSE: ang mga partikular na desisyon sa pagpapatakbo ng mga opsyonal na server-side na bahagi nito (kung ano ang naka-log, gaano katagal, at ng sino).

Kung gumagamit ka ng self-hosted o enterprise Lolly instance, nananatiling angkop ang paggana ng software sa ibaba, ngunit ang operator ng instance na iyon - hindi ang SUSE - ang may pananagutan sa anumang server-side: ang kanilang render endpoint, ang kanilang MCP server, ang kanilang Content Credentials certificate authority, kung nagpapatakbo sila nito. Hilingin sa kanila ang kanilang sariling patakaran. Tingnan ang Adopsyon at Pamamahala para sa kung ano ang kasama sa pagpapatakbo ng Lolly.

Ang app: ano ang nananatili sa iyong device

Ang web, desktop at mobile shell ng Lolly ay nagpapatakbo ng buong render engine sa client-side. Ang pagbukas ng tool, paglagay ng mga input, pag-preview at pag-export ay lahat nangyayari sa iyong device - walang kasamang server, at gumagana ang app offline kapag na-load na.

Walang inilalagay na cookies ang app. Para gumana, nagpapanatili ito ng kaunting data sa iyong device lamang, hindi kailanman ipinapadala:

• Mga interface preference - theme, wika, mga setting ng tunog, laki ng sidebar/zoom, mga pagpili sa sort at view, kung aling mga onboarding tip na ang nakita mo - sa localStorage, para available ang mga ito bago pa matapos mag-boot ang app.
• Isang offline cache ng tool catalogue at asset preview, para gumana ang gallery kahit walang koneksyon.
• Mga lokal na usage counter para sa mga stats ng iyong profile card (ilang export, aling mga tool) - isang maliit at bounded na blob sa localStorage, hindi kailanman binabasa namin, hindi kailanman ipinapadala kahit saan.
• Ang iyong sariling mga dokumento, na-save na session, na-upload na asset at font - nakaimbak sa IndexedDB sa iyong device, hindi kailanman ina-upload, hindi kailanman binabasa ng kahit sino maliban sa iyo.

Wala sa mga ito ang ibinabahagi, ibinebenta, o ginagamit para kilalanin o subaybayan ka. Walang dapat pahintulutan, dahil walang collection na nagaganap - itong abiso lang, para malaman mo kung ano ang naka-imbak at saan. Tinatanggal ng pag-clear ng storage ng site sa browser mo ang lahat nito anumang oras, at ganoon din ang Mga Setting → Imbakan → Burahin ang lahat ng aking data, na nag-o-off din sa Sync muna. (Sa ilalim ng ePrivacy Directive Art. 5(3), ang storage na mahigpit na kailangan para sa serbisyong hiniling mo ay hindi nangangailangan ng pahintulot - transparency lamang, na siyang katuturan ng dokumentong ito at ng abiso sa loob ng app.)

signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBI-check mo mismoKunin ang signed na file signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBI-check mo mismoKunin ang signed na file

Ang sarili mong backup ng data na ito - ang lolly-backup bundle na ginawa ng I-export ang data ko - ay isang file na hawak at kontrolado mo. Hindi ito kailanman nakakadikit sa aming mga server maliban kung pipiliin mong ipadala ito sa iba sa iyong sarili. Tingnan ang Data Transfer.

Mga on-device na utility

May mga tool - Strip Hidden Data, Compress PDF at iba pa na may badge na "Runs on your device" - na gumagana sa file na ibinibigay mo. Binabasa ang file papunta sa memory sa iyong browser, tino-transform nang lokal, at ibinabalik bilang download. Hindi ito kailanman ina-upload, dahil walang server sa daan na pagpapadalhan nito. Gumagana offline ang mga utility na ito, at ang output nila ay walang dalang watermark o metadata mula sa amin - ang layunin ng karamihan sa mga ito ay alisin at protektahan ang data, hindi magdagdag ng panganib.

signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBI-check mo mismoKunin ang signed na file signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBI-check mo mismoKunin ang signed na file

Ang Prepare for sharing ay iniingatan sa memory ang mga working input, pribadong natuklasan at replacement map, nang hindi awtomatikong idinaragdag ang mga ito sa history, mga link, backup o sync. Ang inspection at replacement ay hindi nagpapadala ng laman ng file sa isang server o nagpapatunay ng mga kredensyal online. Pipiliin ng user kung kokopyahin, ida-download, ipapadala o tahasang ise-save ang resulta sa library nila; ang isang na-save na resulta ay sumusunod na sa normal na setting ng library backup at sync. Ang mga recipe file ay hindi kasama ang mga naunang payload at literal na mapping. Ang mga summary report ay naglalaman ng mga bilang, scope ID at file hash. Puwede ring i-save ng CLI ang isang pribadong review file na naglalaman ng mga orihinal na value, kapag tahasang hiniling lang ito gamit ang --review-file. Ang pag-clear o pag-alis sa isang browser preparation view ay nagpapalaya sa working state nito; hindi ito isang pangako ng forensic erasure mula sa memory ng browser o OS.

Bawat network request na maaaring gawin ng app

Ang talahanayan sa ibaba ang kumpletong listahan ng lahat ng kinukuha o ipinapadala ng app sa network. Kung wala ito rito, hindi ito ginagawa ng app.

Ang bawat nakapirming host sa talahanayang iyon ay kabilang din sa kumpletong allowlist sa Content-Security-Policy ng app, na ipinapatupad ng browser. Kaya ang listahan ay hindi lamang isang paglalarawan kung ano ang ginagawa ng code ngayon, ito ang hangganan na ipinapataw ng browser sa app: ang isang pagbabago sa hinaharap na susubukang makipag-ugnayan sa ibang host ay babawalan, hindi tahimik na papayagan. Isang hilera ang sinadyang eksepsyon, at sinasabi mismo ito ng sarili nitong cell: umiiral lang ang Send to LinkedIn sa desktop apps, kaya walang pinapangalanan ang patakaran ng web app sa dalawa nitong host - hindi maaabot ng web app ang mga ito kahit subukan pa ng code nito. Dalawa pang hilera, ang Bluesky at Discord, ay desktop-only din sa parehong paraan, at hindi kasama sa web policy ang mga host nila sa parehong dahilan. Limang hilera ang walang nakapirming host, dahil ikaw mismo ang pumipili ng address sa sandali ng paggamit: isang URL na hinihiling mong kunin ng tool, isang remote instance na itinuturo mo ng shell, at ang sarili mong Mastodon server, WebDAV server o S3 bucket (ang huling dalawa ay pati na rin bilang sync home). Wala sa mga iyon ang kasama sa patakaran, at bawat isa ay nangyayari lamang kapag nag-type ka ng address at kumilos dito. Naaabot ng Penpot row ang Penpot sa pamamagitan ng sariling origin ng app, kaya saklaw ito ng 'self'. Ang isang deployment na ayaw sa alinman sa mga opsyonal na ito (halimbawa, isang enterprise instance na may sariling mga font) ay inaalis ang mga host na iyon sa sarili nitong patakaran, at ang mga feature ay nabibigo nang closed sa halip na makipag-ugnayan sa labas.

Maliban sa dalawang uri ng hilera, wala sa mga ito ang nagpapadala ng iyong mga dokumento, proyekto, session, o na-upload na file kahit saan: ang mga ito ay umiiral para magdala ng mga bagay papunta sa iyong device (mga tool, font, modelo). Ang dalawang uri ay ang mga Send row, na nagpapadala ng iisang file na pinili mo, at ang sync row, na nagpapadala ng kopya ng gawa mo sa imbakang pinili mo at hindi sa anumang Lolly server. Anumang iba pang eksepsiyon ay tahasang pinapangalanan sa mga seksyon sa ibaba.

Isang tala tungkol sa inalis namin. Kayang suriin ng Verify ang mga SEAL signature, isang scheme kung saan ang signing key ng isang file ay na-publish sa DNS. Hindi kayang gumawa ng DNS query ang mga browser, kaya ang anumang web implementation ay kailangang i-route ang lookup sa pamamagitan ng isang third-party na DNS-over-HTTPS resolver - na magpapakita sa operator na iyon ng domain na sinusuri kasama ng iyong IP address. Ginamit namin dati ang sa Cloudflare. Hindi na namin ito ginagamit, at walang kapalit: hindi na nagpapasa ng resolver ang Verify ngayon, kaya walang network request na inilalabas ng pag-verify ng SEAL dito. Walang Lolly app ang nagla-lookup ng mga SEAL key sa DNS ngayon: pareho ang Verify view na pinapatakbo ng desktop at mobile apps, at hindi sinusuri ng command-line na lolly validate ang SEAL. Ang file na ang SEAL record ay may dalang key nang inline ay sinusuri offline, at sinasabi ng Verify na internally consistent ang signature nang hindi kinukumpirma ang domain. Ang file na ang key ay nasa DNS lang ay nagpapakita ng SEAL signature did not verify, na may dahilang "no key resolver and no inline key".

signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBI-check mo mismoKunin ang signed na file signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBI-check mo mismoKunin ang signed na file Puwede mo itong kumpirmahin sa iyong sarili: ang mga greppable check para dito at sa bawat iba pang claim sa pahinang ito, kasama ang eksaktong mga command at inaasahang output, ay nasa Patunayan Ito Mismo.

Hot-linked na render URL

Live sa lolly.tools. Bawat https://lolly.tools/tool/<tool-id>.<ext>?<inputs> URL ay talagang nagre-render, at kasama ang mga input sa URL na iyon. Ipinapaliwanag ng seksyon sa ibaba kung ano ang ibig sabihin nito para sa iyo, at puwedeng i-off ng isang operator ang feature na ito sa sarili nilang instance.

Ang app mismo ay nananatiling buong-buo sa iyong device. Hiwalay dito, puwedeng paganahin ng isang operator ang hot-link render URL - /tool/<tool-id>.<ext>?<inputs>

• para makita ang isang ibinahaging Lolly link bilang live na larawan sa isang

README, wiki, o dashboard. Ang pag-fetch ng isa ay humihiling sa server na i-render ang pampublikong data ng tool at catalogue gamit ang mga input na nakasulat sa URL.

• Walang account, walang cookie, walang state. Anonymous ang endpoint, at wala sa device mo ang nababasa. Ang mga dokumento, session, at upload mo ay hindi kailanman umaalis sa browser mo - hindi sila kailanman lalabas sa mga link na ito.
• Pero ang URL mismo ay naitatala. Ang query string ng isang URL ay bahagi ng request line, kaya lumalabas ito sa ordinaryong access log ng hosting platform sa parehong paraan gaya ng bawat hiniling na path. Kung ang mga input ng isang link ay naglalaman ng pangalan o email ng isang tao - isang name badge, isang email signature - nananatili ang tekstong iyon sa mga log na iyon, at wala kahit anong salita ng patakaran ang makakapagbago nito. Kaya mali ang hot-link URL na paglagyan ng personal na detalye: ilagay lang dito ang ilalagay mo sa isang pampublikong pahina.
• Pampubliko na ang mga input sa likas nitong pagkakabuo kahit papaano - anuman ang itinype ng may-akda ng link sa URL, mababasa ng sinumang mararating ng link. Huwag maglagay ng mga sekreto sa isang shared link. Nag-aalok ang Lolly ng link encryption para sa sensitibong content.
• Ang mga tugon ay naka-cache at may rate-limit gaya ng anumang pampublikong larawan, at minarkahang noindex para hindi i-index ng mga search engine ang mga render mo.

Nag-self-host ng Lolly at ayaw ng pampublikong render surface? I-set ang LOLLY_DISABLE_RENDER_GET=1 at ang bawat isa sa mga URL na ito ay magbabalik ng 404.

Ang MCP server (opsyonal, para sa mga AI agent)

Maaari ring marating ang Lolly ng isang AI agent sa pamamagitan ng Model Context Protocol - isang endpoint na pinapatakbo ng operator (may pinapatakbo ang lolly.tools; puwedeng mag-self-host ng sarili nila ang kahit sino, kabilang ang buong air-gapped). Ibinabahagi nito ang no-accounts na postura ng render path, kasama ng apat na tool na kinakailangang humawak ng file bytes:

• lolly_transform (nagpapatakbo ng on-device na utility sa server-side, sa ngalan ng tumatawag na agent), lolly_verify (sinusuri ang Content Credentials) at lolly_redact (nagtatakip ng mga rehiyon ng isang larawan o PDF) - lahat ng ito ay tumatanggap ng bytes ng file mula sa tumatawag. Pino-proseso ang mga ito in-process, sa memory, at ibinabalik ang resulta sa parehong tawag na iyon - hindi kailanman isinusulat ang file sa disk at hindi kailanman naka-store kapag natapos na ang request.
• Ang lolly_rebrand (nagre-renovate ng lumang slide deck patungo sa isang design system, sa buong plan, compile at inspect stages nito) ay tumatanggap ng bytes ng deck sa parehong paraan, at pino-proseso ang mga ito sa memory, para lang sa tawag na iyon - walang isinusulat sa disk o iniingatan pagkatapos maipadala ang response. Ang unang stage nito, capabilities, ay nagsasaad sa salita kung saan mapupunta ang bytes mo bago ka magpadala ng kahit ano: sa isang self-hosted na lokal na server, hindi kailanman umaalis sa makinang iyon ang deck; sa isang hosted na server, ang pagtawag sa lolly_rebrand ay nagpapadala roon ng deck, hanggang sa limitasyon ng laki at bilang ng slide na ibinibigay ng parehong stage.
• Ang mga image tool (lolly_look, lolly_sample_color at lolly_trace_edges) ay maaari ring tumanggap ng image file mula sa tumatawag, na hinahawakan sa parehong paraan: sa memory, para sa tawag na iyon lamang. Ang bawat iba pang tool ay gumagana mula sa mga parameter sa tawag: teksto, numero, kulay, URL, catalogue asset id, o isang dokumentong ibinibigay ng tumatawag.
• Ang access ay alinman sa isang shared token na inilalabas ng operator sa mga client na pinagkakatiwalaan nila, o stateless OAuth 2.1: mga short-lived na naka-sign na token na na-verify laban sa isang shared secret, walang naka-store sa server-side at ang token mismo ay hindi kailanman isinusulat sa isang log o isang render URL.

Content Credentials identity (isang sign-in na kailangan mong simulan mismo)

Kaya ng Lolly na maglagay ng cryptographic Content Credential sa mga export mo para may makapag-verify, offline, na hindi na-alter ang isang file mula nang umalis ito sa Lolly. Ganoon na iyon naka-on by default at fully local - ang signing key ay ginagawa sa device mo at ang pag-sign mismo ay nangyayari offline. Kung walang enrolment, ang key na iyon ay throwaway lang: isang bagong keypair na ginagawa para sa bawat export at isinasama dito. Kapag nag-enrol ka, ang key ay nagiging lasting at ginagawang non-extractable - kahit ang code mismo ng Lolly ay hindi ito mababasa, puwede lang itong hilingan na mag-sign. Sa alinmang paraan, hindi ito umaalis sa device mo. Sakop ng seksyong ito ang isang optional na hakbang dito: ang pag-enrol ng verified identity, para ang mga export mo ay magsabing "Verified - signed by \<your email\>" sa halip na anonymous key. Kung nilaktawan mo ang enrolment, wala sa seksyong ito ang aplikable sa iyo, at walang personal data na aalis sa device mo.

signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups24 KBI-check mo mismoKunin ang signed na file signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups25 KBI-check mo mismoKunin ang signed na file

Kung mag-enrol ka, narito nang eksakto ang mangyayari:

1. Pipili ka ng paraan ng sign-in - GitHub, Google, SUSE (id.suse.com), o isang emailed na link. Para sa tatlong OIDC provider, ire-redirect ka papunta sa sariling login page ng provider na iyon, na pinamamahalaan ng kanilang sariling patakaran sa privacy, hindi sa amin. Ang certificate service ng Lolly ay tumatanggap lamang pabalik ng isang verified na email address at ang pangalan ng provider. Para sa email link, ang address na tina-type mo ay ipinapasa sa Resend, isang transactional email API, para lang maihatid ang link na iyon.
2. May proteksiyon ang redirect ng isang short-lived na cookie. Ito ang nag-iisang cookie na inilalagay ng buong sistema ng Lolly: lolly_ca_state, HttpOnly, naka-scope sa /api/ca, mag-e-expire sa loob ng sampung minuto. Nagdadala ito ng random na value, hindi tracking identifier, at umiiral lang para pigilan ang pagpeke ng OAuth redirect. Nabubura ito sa sandaling matapos ang sign-in.
3. Ginagamit ang IP address mo, nang panandalian, para pigilan ang pang-aabuso sa mga sign-in endpoint (para hindi makapag-spam ng isang inbox o maubos ang email quota ang iisang script). Hina-hash muna ito ng Lolly bago gumawa ng isang short-lived na abuse-control bucket; hindi ipinapadala ang raw address sa store na iyon. Nag-e-expire ang bucket pagkatapos ng mga isang minuto at hindi ito ginagamit para sa tracking. Hiwalay ang ordinaryong hosting access log at inilalarawan ito sa ibaba.
4. Naglalabas ang certificate service ng isang short-lived na certificate (7, 30, 90, o 365 araw, ayon sa iyong pili, na naka-cap ng patakaran ng operator) na nagbibigkis sa iyong verified na email sa pampublikong kalahati ng keypair na nabuo sa iyong device. Ang pribadong kalahati ay hindi kailanman umaalis sa iyong browser.
5. Walang naitatala tungkol sa pagpapalabas. Ang certificate service ay walang pinapanatiling issuance log: hindi ang iyong email, hindi ang provider, hindi ang serial number, hindi ang timestamp. Walang database, walang log line, walang webhook. Ang iyong email address ay umiiral sa request nang sapat lang na panahon para maisulat ito sa certificate na natatanggap ng sarili mong device, at pagkatapos ay nawawala na ito sa amin nang lubusan.
6. Pagkatapos noon, offline na naman ang pag-sign sa buong lifetime ng certificate. Ang pag-export ng file ay hindi kailanman nakikipag-ugnayan sa certificate service - ang pag-enrol lang ang nakipag-ugnayan.

Ang tradeoff, sinabi nang tuwiran. Nag-log dati ang mas naunang bersyon ng serbisyong ito ng bawat pagpapalabas, para masubaybayan ang isang certificate na mali ang pagkalabas o na-compromise. Inalis namin ito, dahil ang log na iyon ang tanging lugar sa buong Lolly kung saan may personal na data na napunta sa isang server, at mas gugustuhin naming huwag itong hawakan kaysa hawakan ito nang maingat. Ang isinusuko namin ay ang server-side na traceability: kung inabuso ang isang certificate, hindi namin ito masusubaybayan kung sino ang nagkaroon nito. Short-lived ang mga certificate ayon sa disenyo - 7 hanggang 365 araw, ayon sa iyong pili, na naka-cap ng operator - at nag-e-expire nang mag-isa, na siyang mitigation na inaasahan namin sa halip. Ang mga self-hoster na ang sariling mga obligasyon ay nangangailangan ng audit log ay puwedeng magdagdag ng isa, at magiging controller ng data na iyon sa paggawa nito.

Ang browser extension

Ang browser extension na Lolly URL Screenshot ay hindi kumukolekta ng anumang personal na data para sa amin. Walang analytics, walang tracking at walang sariling server. Inilalarawan ng pahinang Browser Extension kung paano ito gumagana.

Ano ang ginagawa nito. Maaaring hilingan ito ng Lolly web app ng screenshot ng isang web page, o ng nilalaman ng isang page para magsimula ng design system mula sa isang website. Bawat request ay nagbubukas ng approval window sa extension na nagpapakita ng site na humihiling, kung screenshot o nilalaman ng page ang gusto nito, at ang address ng page. Pagkatapos mo lang pindutin ang Approve once bubuksan ng extension ang page na iyon sa isang pansamantalang background tab, kukunin ang screenshot o babasahin ang page, ibibigay ang resulta sa Lolly tab na humiling at isasara ang tab. Bawat request ay nangangailangan ng sarili nitong pag-apruba.

Data.

• Wala kaming kinokolekta. Sa Lolly page lang na humiling napupunta ang resulta, sa parehong browser. Hindi nag-iimbak ang extension ng nilalaman ng page at hindi ito nagdaragdag ng ibang tatanggap.
• Mga network request. Nilo-load ang page na inaprubahan mo gaya ng sa anumang tab, kasama ang anumang hinihiling ng page mismo. Ang pagbasa sa nilalaman ng page ay kumukuha rin ng mga stylesheet nito at ilang icon at logo image, mula sa loob ng page, at walang cookies na ipinapadala ng mga fetch na iyon sa ibang site. Walang ibang request na ginagawa ang extension, at wala ni isang napupunta sa Lolly server.
• Ang iyong browser session. Nilo-load ang page gamit ang iyong browser session, gaya ng kung ikaw mismo ang nagbukas nito, kaya ang page na naka-sign in ka ay maaaring maglagay ng pribadong impormasyon sa resulta.
• Ang mga address na inaprubahan mo ay ginagamit lang para i-load ang isang page na iyon para sa isang request na iyon. Hindi ito naka-log o ibinabahagi.

Mga Pahintulot.

• debugger - para kunin ang screenshot sa pamamagitan ng DevTools Protocol (ang parehong mekanismo na ginagamit ng Lolly desktop app).
• tabs - para buksan at isara ang pansamantalang tab, at para tiyakin na hindi lumipat ang Lolly page o ang target page mula nang aprubahan mo.
• scripting - para basahin ang nilalaman ng page sa pansamantalang tab, pagkatapos mong aprubahan ang request na iyon.
• storage - para itala ang mga id ng pansamantalang tab nito sa session storage, para masara pa rin ang mga ito kung ihinto ng browser ang extension habang may request. Walang nilalaman ng page na naka-store.
• *Opsyonal na site access (http:///, https:///) - hindi ibinibigay sa pag-install. Kapag pinindot mo ang Approve once*, humihingi ang extension sa Chrome ng access sa nag-iisang site sa request na iyon, at tinatanong ka ng Chrome sa unang beses para sa bawat site. Ang site na pinayagan mo noon ay nangangailangan pa rin ng bagong pag-apruba para sa bawat request.

Wala sa mga ito ang ginagamit para basahin, subaybayan, o ipadala ang iyong pag-browse lampas doon sa isang request na inaprubahan mo.

Mga infrastructure log

Tulad ng anumang website, ang mga server sa likod ng lolly.tools - at sa likod ng anumang Lolly deployment - ay gumagawa ng standard na web-server access log tuwing may request na sumasapit sa kanila: IP address, hiniling na path, timestamp, user agent. Iyon ay baseline na hosting behaviour, hindi isang bagay na idinagdag ng Lolly sa ibabaw, at hindi ito kailanman naglalaman ng nilalaman ng iyong mga dokumento, dahil hindi kailanman nakararating ang mga iyon sa isang server sa simula pa lang. Ang isang sinasadyang eksepsiyon ay isang file na tahasan mong ibinigay sa isang tawag ng MCP na lolly_transform, lolly_verify, lolly_redact, o lolly_rebrand, na pino-proseso sa memory at hindi kailanman isinusulat sa disk o sa isang log, tulad ng inilarawan sa itaas.

Walang isinusulat ang sariling code ng Lolly sa mga log na iyon. Nagla-log ang MCP server ng startup, configuration at rendering warning; wala itong sariling request log at hindi nito nilo-log ang mga token o address ng tumatawag. Nilo-log ng Penpot pass-through ang pangalan ng bawat command at ang response status ng Penpot, hindi kailanman ang mga header, token o ang file. Nilo-log ng certificate service ang mga startup setting at configuration warning nito, kasama ang dalawang tinanggalang linya sa pagkabigo: isang send-failure status code na walang recipient address, at isang nakapirming failure line na walang error text, stack trace o URL (ang error ng provider ay maaaring may dalang identity value o credential). Ang lahat ng iba pa sa log ay sa hosting platform, hindi sa amin.

Para sa lolly.tools, Vercel ang hosting at sinusunod ng access-log retention ang sariling mga platform default ng Vercel para sa plano namin. Hindi kami nag-configure ng log drain, walang pangmatagalang log export, at walang analytics o monitoring product sa ibabaw. Hindi kami nagpapanatili ng sarili namin na kopya ng mga log na ito, na nangangahulugan din na wala kaming paraan para hanapin ang mga ito para sa iyo - tingnan ang Ang iyong mga karapatan.

Mga legal na basehan, pagpapanatili at mga tatanggap

Halos walang kailangan ng legal na basehan dito, dahil halos walang pinoproseso. Para sa kompletuhin, narito ang buong listahan:

Mga Tatanggap. Ang mga kategorya ng tatanggap ay: ang aming hosting provider (Vercel Inc.); ang aming abuse-control store provider, na tumatanggap lamang ng panandalian at one-way na hinangong bucket key at hindi kailanman ng mismong IP address; at - kapag ginamit mo lamang ang opsyon na email sign-in - isang transactional email provider (Resend). Kung mag-sign in ka gamit ang GitHub, Google o SUSE (id.suse.com), direkta kang nakikipag-ugnayan sa provider na iyon sa ilalim ng sarili nilang privacy policy. Sinasabi nila sa amin ang isang na-verify na email address at wala nang iba. Hindi namin ibinabahagi ang personal na data sa kahit sino pa, at hindi kami nagbebenta ng data, nagpapatakbo ng advertising, o nagpo-profile ng mga user.

Mga paglilipat sa labas ng EEA. Ang Vercel at Resend ay mga kumpanya ng US. Ang function compute para sa lolly.tools ay naka-pin sa Frankfurt (fra1) region ng Vercel kaya naganap ang pagproseso sa EU, ngunit dahil sila ay mga provider na naka-base sa US, maaari pa rin nilang i-access ang data bilang mga processor mula sa US. Umaasa ang mga paglilipat na iyon sa Standard Contractual Clauses ng European Commission at/o sa EU-US Data Privacy Framework, gaya ng nakasaad sa data processing agreement ng bawat provider. Dahil napakalimitado ng personal na data na umaabot sa mga provider na ito - isang email address na ipinapasa para magpadala ng isang mensahe, ordinaryong access logs, at isang panandaliang hinangong abuse-control bucket - katumbas na maliit ang exposure.

Awtomatikong paggawa ng desisyon. Wala. Walang profiling at walang awtomatikong desisyon na gumagawa ng legal o katulad na makabuluhang epekto (Art. 22).

Privacy ng mga bata

Hindi kusang kinokolekta ng Lolly ang personal na impormasyon ng kahit sino, anuman ang edad, sa ordinaryong paggamit ng app - walang kokolektahin. Ang tanging pagkakataon na nangongolekta ng personal na impormasyon (isang email address) ay ang Content Credentials enrolment, na inilarawan sa itaas, na hindi nakatuon o nilaan para sa mga bata.

Ang iyong mga karapatan

Dahil halos lahat ng nagagalaw ng Lolly ay iniimbak lamang sa iyong sariling device, karamihan sa tinatawag ng batas sa proteksyon ng data na "ang iyong mga karapatan" - access, pagwawasto, pagbura, portability - ay mga bagay na kaya mo nang gawin mismo, agad, nang hindi humihingi ng pahintulot kaninuman: nasa storage ng iyong browser ang iyong data, sa isang anyo na maaari mong siyasatin, i-export (I-export ang data ko, sa itaas) o i-delete (sa pamamagitan ng pag-clear ng storage ng site sa iyong browser, gaya sa itaas).

Pormal, sa ilalim ng GDPR Articles 15-22 may karapatan kang i-access ang iyong personal na data, iwasto ito, burahin ito, paghigpitan o tutulan ang pagproseso nito (kabilang ang pagtutol sa anumang ibinabatay namin sa lehitimong interes), sa data portability at - kung nakabatay sa consent ang pagproseso - sa pagbawi ng consent na iyon anumang oras, nang hindi apektado ang legalidad ng nangyari bago mo ito binawi.

Narito ang tapat na posisyon sa paggamit ng mga ito laban sa amin. Dahil hindi na kami nagpapanatili ng issuance log, wala kaming hawak na personal na data tungkol sa iyo na maaari naming hanapin, iwasto, i-export o i-delete. Kung susulat ka at magtatanong kung ano ang mayroon kami tungkol sa iyo, ang tapat na sagot ay wala, at iyon ang aming sasabihin. Ang tanging kategoryang umiiral ay ang hosting access logs na naka-key sa isang IP address, hawak ng aming hosting provider sa ilalim ng kanilang mga default sa pagpapanatili. Wala kaming kakayahan para hanapin o piling burahin ang mga iyon, at ito ang sasabihin namin sa halip na magkunwari. Lahat ng talagang sa iyo ay nasa iyong device, kung saan maaari mo na itong basahin, i-export at sirain nang hindi humihingi ng pahintulot kaninuman.

May karapatan kang magreklamo. Kung sa palagay mo ay hindi namin tama ang pagtrato sa iyong data, maaari kang maghain ng reklamo sa isang data protection supervisory authority - sa EU, ang awtoridad sa bansang iyong tinitirhan, lugar ng trabaho o kung saan mo naniniwalang naganap ang paglabag (Art. 77). Ang aming lead supervisory authority ay ang Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) sa Ansbach, Germany. Hindi mo kailangang kontakin kami muna, bagaman gusto naming magkaroon ng pagkakataong ayusin ito.

Hindi kami nagbebenta ng data. Wala man lang kaming maibenta.

Mga pagbabago sa patakarang ito

Nagbabago ang petsa sa itaas tuwing nagbabago ang dokumentong ito. Ang isang pagbabago na nag-aalter sa kung ano ang umaalis sa iyong device o kung ano ang pinapanatili ay bibigyan ng sarili nitong linya dito, hindi isang tahimik na edit - kung gusto mong makita kung ano ang nagbago, magtanong (sa ibaba) o ikumpara laban sa pampublikong pinagmulan.

22 Oktubre 2026: itinama ang paglalarawan ng umiiral na behavior. Sakop na ngayon ng seksyon ng browser extension ang approval window para sa bawat request, ang site access na hinihingi nang isang site bawat beses at ang mga fetch ng stylesheet at icon sa pagbasa ng website. Itinama rin: ang mga row ng Send to Google Drive at Meeting Planner, ang tala tungkol sa SEAL (walang Lolly app ang nagla-lookup ng mga SEAL key sa DNS), ang default na antas ng usage telemetry ng organisation service, ang mga MCP image tool at ang application logging ng mga pampublikong serbisyo. Hindi nagbago ang software mismo.

Sino ang responsable, at paano kami maabot

Ang data controller para sa lolly.tools ay:

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

Nagtalaga ang SUSE ng isang Data Protection Officer, na maaabot sa privacy@suse.com. Gamitin ang address na iyon para sa anumang pormal na kahilingan sa ilalim ng "Ang iyong mga karapatan" sa itaas.

Para sa kahit anong tungkol sa Lolly mismo - kung paano ito gumagana, bakit ganito ang isang bagay o isang pagwawasto sa dokumentong ito - kontakin si Andy Fitzsimon, fitzy@suse.com.

Para sa isang self-hosted o enterprise na instance ng Lolly, kontakin sa halip ang sinumang nagpapatakbo nito: ang operator ang controller para sa kanilang sariling deployment. Walang hawak na data ang SUSE at ang Lolly open source project para sa mga deployment na hindi nila pinapatakbo.