← NascentBloom

Trust Centre

Last updated: October 2026

Compliance Programme

An overview of security controls in place.

Reader privacy

Access security

Data protection

Vendor and subprocessor management

Vulnerability management

What we will commit to in writing

Your content is yoursNot sold, not shared with another publisher, and not used to train anything of ours.
Deletion on requestArticle by article from your own dashboard, or the whole account on request.
You hear about an incident from usIf something affecting your data goes wrong we tell you — promptly, and with what we actually know rather than a holding statement.
Found a problem? Tell us, safelyWrite to [email protected] with “security” in the subject. We acknowledge within 3 working days, and say whether we can reproduce it within 10. We will not pursue anyone, or ask anyone else to, over good-faith research that stops at the point of proof and leaves other people's data alone — nobody should have to weigh legal risk against telling us about our own bug.

Contact and grievances

Under the DPDP Act a person must be able to reach someone who can actually answer a question about their data. That is the founder, at [email protected].

ReadersIf you scanned a code and want something you typed removed, write to the address above with the publication and roughly when. We hold no account for you, so tell us enough to find it. Question text expires on its own after 180 days regardless.
PublishersDelete an article or the whole account from your dashboard at any time, without asking us. For anything else, the same address reaches a person rather than a queue.
Response timeWe answer within 7 days. If you are not satisfied, the DPDP Act gives you the right to complain to the Data Protection Board of India.

Categories

Explore our security controls by category.

Reader privacy Access security Data protection Vendor and subprocessor management Vulnerability management

Reader privacy

The strongest position on this page is structural: there is no reader identity to protect, because none is ever created.

No reader accounts existA reader scans a code and reads. No sign-up, no login, no email, no profile — the capability is absent from the product, not switched off.
A visit is a random key, not a personEach page render mints a fresh random key so one visit’s actions can be counted together. It identifies a visit, never a reader, and is not reused.
No IP address in the analyticsThe events table has no address column. Nothing a publisher sees in Analytics traces to a network address.
Network addresses are never storedA one-way daily HMAC of the address is stored, never the address itself. The same value counts visitors to our own pages, and neither is joined to reading behaviour.
Children’s pages record nothing at allMarked by the publisher, the page logs nothing, offers no text boxes, and erases anything already collected. DPDP s.9 forbids monitoring children; this leaves nothing to monitor.
Data minimisation by designNo reader identity is created, nothing in Analytics ties to a person, addresses are hashed rather than stored, and free text expires on a clock.
Reader feedback carries no identifierA private note to the publisher stores the article, the publisher, the text and the time. Nothing about who wrote it.
Notice at the point of collectionEvery reader page links to what it records, reachable before anything is typed into it.

Access security

Who can get into a publisher's account, and what becomes of the credentials that let them.

Separate credentialled account per publisherEach publisher authenticates to their own account; there are no shared logins.
Passwords hashed, never storedPBKDF2-HMAC-SHA256 with a per-account salt and a recorded iteration count. Nobody holding the database can read a password.
Session tokens signed and hardenedHMAC-SHA256 signed cookies set HttpOnly, Secure and SameSite, so they are unreadable to page scripts and travel only over HTTPS.
Administrative access restrictedOperational diagnostic views sit behind a separate administrative key. With that key unset, they do not resolve at all.
Email verification on account creationA publisher account must confirm its address before it is usable.

Data protection

What becomes of publisher content and reader text while it is stored, and when it is asked to leave. Under the DPDP Act you are the Data Fiduciary and we are your Data Processor.

Customer data segregated by accountPublisher-facing reads bind your account identifier as a condition. No code path returns one publisher’s data to another.
Encrypted in transitAll traffic is served over HTTPS.
Encrypted at restProvided by our managed database and object storage providers as standard.
Injection-resistant data accessQuery values are always bound, never pasted into SQL text, which closes injection off as a class rather than case by case.
Erasure on request, and when the purpose is servedDeleting an article removes its experiences, entities and cached answers in the same operation. The whole account goes the same way, from the dashboard or on request.
Reader text ages out automaticallyQuestion text is redacted after 180 days while the event row survives, so counts and funnels are untouched. Cached answers and reader notes are removed outright.

Vendor and subprocessor management

Everyone else who touches your content, named rather than described vaguely.

Subprocessor inventory maintainedEvery third party that touches your content is recorded, with what reaches it. The list is sent on request and before any change to it.

Vulnerability management

How a flaw gets found, and what happens in the time between finding it and fixing it.

Automated vulnerability scanningDependency advisories and static analysis run on every change and again every Monday. A run that finds something fails the build rather than filing a notice.
Automated dependency patchingRoutine version bumps arrive as one grouped change each week. Security advisories arrive on their own, immediately, never bundled with housekeeping.
Documented vulnerability management policyWritten, and specific about timing: critical findings fixed or mitigated within 72 hours, high within 14 days, counted from when we learn of them.
Published vulnerability disclosure channelA stated address, a commitment on how fast we answer, and safe harbour in writing for research done in good faith. The terms are below.