The strongest privacy guarantee livedesign can offer is that you do not have to trust it blindly. The entire codebase is public and MIT-licensed, so every claim on these pages, where designs are stored, what telemetry records, how share passwords work, is something you can verify in the source yourself.
A public, MIT-licensed codebase
livedesign is open source under the MIT license. That is permissive on purpose: anyone may read, fork, modify, or embed it, for any purpose.
- Free for everyone. There is no paid tier and no plan to introduce one. Every feature ships to every user.
- No license checks. Nothing in the core editor calls home to verify a licence or gate a feature.
- Optional, not required, outside services. Sign-in is optional. With it unconfigured, the app runs in pure-guest mode and works fully without any account system. Email is the same: it stays off until a deployment adds its key. Image search (Openverse) needs no key and is on everywhere; it runs from the browser, and only when someone searches.
Because the code is visible to the world, you can audit precisely how your data is handled rather than relying on a privacy policy alone.
No secrets in the source
A public repository has one hard rule: no secret ever lives in the source code. No API keys, no tokens, no passwords, no signing keys, in code, in examples, in tests, or in history.
Every secret a deployment needs is supplied at runtime through environment variables or the hosting dashboard, never committed. Only values explicitly marked as publishable (such as a public API base URL) are ever included in what ships to the browser. This is what makes a public codebase safe to publish in the first place.
Audit it
Read the code to satisfy yourself about how livedesign treats your data: follow how a design is saved, how access is checked, or what an analytics event contains, all in the open.
Found a problem?
Open code also means anyone can look for weaknesses, and we want to hear about them. If you find a security vulnerability, please report it privately through GitHub rather than in a public issue: Reporting a Vulnerability explains how, what is in scope, and our safe-harbour promise. The same policy is linked from /security and from the site's /.well-known/security.txt.
Was this article helpful?