DRAFT — not legal advice, not reviewed by counsel, not in force.
Privacy
A draft describing the data rumo actually holds, written from the schema rather than from a template.
It has not been reviewed by counsel and it is not in force.
What this covers
rumo is a hyperlocal app.
A story is about a place — a building, a business, an organisation, an event — and it is written by the people it happens to, under their own names.
This page describes what rumo stores about a person who signs in, what it does with it, how long it keeps it, and how to get rid of it.
Two things are deliberately not folded together.
An account is a phone-verified person inside the app.
A waitlist email left on this website is a stranger who has not signed up for anything; it is held in a different table and joins nothing else.
Both are below.
What an account stores
This is the profile row, field by field, as it exists in the database.
Your phone number
Verified by one-time code, and the only identity rumo has.
One active account per number — that is the whole of the anti-impersonation control.
Email and social sign-in are convenience layers on top of the phone number, never a substitute for it.
Your real name, displayed
rumo has no anonymous mode and no handles.
Your name is shown on every update you write, inline, beside the time you wrote it.
This is not a setting and it cannot be turned off.
The reason is stated plainly rather than buried: in a building of three hundred households, a pseudonym does not hide you — it gives you a false picture of your own exposure, which is worse than no cover at all.
Your building, and the words for where in it you live
Every account belongs to exactly one community — a building, complex, campus, neighbourhood or office.
Optionally you may also store a short line for where inside it you are, in words: “Tower B”, “4th Cross”.
That line is shown beside your name when you have confirmed it.
It is text, not a coordinate.
Whether you said you are over 18
A single true or false, self-declared at signup.
There is no under-18 experience in rumo and no account for one.
A profile photo, if you add one
Optional.
Stored as a file path, and cleared when you delete your account.
What you write, and what is stored with it
An update is the thing you post: a body of text, the time the server recorded, and your account as its author.
Alongside it rumo keeps whether the update came from a voice recording, whether it has been edited, and whether it has been deleted.
An update may be edited for fifteen minutes after posting, after which it is immutable.
Edits are shown as edits; silent revision is not available to anybody, including rumo.
Media attached to an update — photographs, video, screenshots, documents and audio — is stored with its kind, its file, its length in seconds where that applies, its size in bytes, a SHA-256 digest of the file, whether it has cleared scanning, whether its location and device metadata were stripped, and the caption you wrote under it.
The digest exists because the scanner computes it anyway and because storage is a metered product that has to be countable. It is not a chain of proof and it is never presented as one.
Every upload is scanned against known-hash databases for child sexual abuse material and non-consensual intimate imagery before it is visible to anyone, and stripped of EXIF location and device metadata on ingest.
Receipts cannot be downloaded: there is no save-to-device action anywhere in rumo, because a copy on somebody’s camera roll survives deletion, takedown and account closure and has no route back.
A model listens to every published recording
This is a plain fact about how rumo works and it gets its own section rather than a clause inside a general moderation sentence.
Every voice recording that is published is read by a model, once, as a safety check. The call happens inside the same worker that already computes the file’s digest and strips its metadata on upload — it is not a separate service and there is no separate queue.
What goes in is the audio, the transcript your device produced, and your own display name as context.
What comes out is a list of names heard, with a timestamp for each one, and nothing else.
It exists for one reason: rumo refuses to be about private individuals, and a guard that only reads text cannot hear a name said out loud.
Roles are fine — “the secretary”, “the site engineer”.
Entity names are fine.
Your own name on your own update is fine.
A private individual’s proper name is flagged.
On a flag, the recording is held: it stays unplayable and one item is written for a human to look at.
It is never removed automatically.
The model writes nothing into any story — it does not transcribe, it does not summarise, and it does not speak. rumo has no synthetic voice.
A recording inside a story set to Just you is not read by this guard at all while the story stays that way.
If you later publish that story, the check runs across it before anything becomes visible, and you are shown what it found first.
Location
Precise coordinates are never shown to anyone. The centre point of a community and the point stored against a place are both withheld from every signed-in client by a column grant in the database — not by the app choosing not to display them.
There is nothing to leak through an API response, a URL or a payload, because the columns are not readable by the role the app connects as.
rumo never asks your device where it is.
Ordering by nearness is worked out on the server from your own building, so two neighbours can never be shown a different answer, and no sequence of requests can be used to triangulate where a place — or a person — actually is.
A place a contributor invents is pinned at their community’s centre point, never at the spot they were standing when they wrote about it.
Display precision is the named locality or the building, and a building appears only when the building is the subject.
A resident’s contribution is never drawn as a marker on a map.
Who can see what you write
| Audience | Who reads it |
|---|---|
| Just you | You, and nobody else. Excluded from every feed, every notification, and the calculation that decides how warm a story is. |
| Your Circle | The people in one building. Not indexed, not searchable, never surfaced by nearness. |
| Your community | Everyone signed in to rumo who can reach that community’s feed. |
Publishing a story that was Just you is one-way.
Not because reversing it would be hard, but because it would be a lie: content that has been read cannot be recalled from the people who read it. rumo will not offer a control that does not do what its name says.
Unpublished is not out of reach of legal process. A court order, a subpoena or a lawful government request can compel disclosure of a story only you have ever read.
Nothing on this page should be taken to mean otherwise.
Deleting your account, and what deletion reaches
Deletion is available from inside the app and runs as a single operation.
It does, in this order:
- tombstones every update you have written, which removes each one from display and recomputes the counts and the temperature of the stories it was in;
- drops the model-written headline of any story whose first update was yours — it falls back to the name of the place, permanently, and is never regenerated;
- clears a headline you typed yourself, on any story you started;
- replaces your display name with “Deleted account”, and clears your photo and your locality line;
- marks the profile deleted, which hides it from every client.
A single update can be deleted the same way, by its author, at any time.
What deletion does not reach, said rather than implied:
- A notification already delivered to somebody’s lock screen.
Unsent ones are dropped; a sent one is gone from rumo’s reach. - A link to a photograph issued in the minutes before you deleted it.
Media is served by short-lived signed links, and one already issued stays valid until it expires. - A screenshot somebody took.
No product control reaches that, and rumo will not claim one. - The retained copy described below, which rumo is required to keep for a period and which no client can read.
Nothing is hard-deleted. Content is tombstoned — removed from display, retained in a restricted store for the statutory period, then purged.
How long things are kept
| Data | Why | Kept for |
|---|---|---|
| Verified phone number | Identity; one account per person | Life of the account |
| IP address and timestamp, per contribution | Legal response, abuse investigation | 180 days, jurisdiction-dependent |
| Device identifier | Detecting evasion of a ban | Life of the account |
| Tombstoned content | Legal response | The statutory period, then purged |
| Moderation action log | Audit and transparency reporting | 3 years |
Two different 180-day clocks exist and they are not the same clock.
The one above runs from the moment something was contributed.
India’s intermediary rules require records of removed content and of a cancelled account to be kept for 180 days from deletion or cancellation.
Different triggers, so they are counted separately.
Access to identity-linked data is restricted by role and logged.
Engineering access to production identity data requires a logged, justified request.
Legal requests, and what you are told
Requests arrive in two shapes and rumo treats them differently.
A letter is not legal process. A complaint from a business that dislikes a story about it goes into the ordinary report queue and is decided on policy.
It is not obeyed, and there is no control anywhere in rumo that lets the subject of a story remove it.
Valid legal process is checked before anything is disclosed — that it is a subpoena, court order or warrant, from a court with jurisdiction, properly served, and within scope — and only the fields actually demanded are produced.
The account is never exported wholesale.
You are told before disclosure, by default. You are told what has been demanded and given a window — ten business days or the return date, whichever is sooner — so that you can move to quash.
The only exception is where a court order under confidentiality, or a valid non-disclosure provision, bars telling you, and that bar is recorded.
A preservation demand or notice of litigation suspends the purge above for the named records, so that a scheduled deletion cannot destroy something rumo has been told to keep.
Statutory windows, the named officer who answers for them, and how to appeal a decision are on the grievance page.
Copyright complaints have their own route, on the copyright page.
The waitlist on this website
If you leave an email address on the rumo home page, that address is stored on its own, with the word “site” to say where it came from and the time it arrived.
Nothing else.
There is no account attached to it, because nobody has an account yet.
It is used for one message: to tell you when your building can join.
Nobody can read the list back through the website — the form can add an address and cannot ask whether an address is already there, which is a deliberate property of how it is built rather than a promise about how it is used.
It is marketing data and it is kept apart from everything above.
If you would like it removed, write to hello@rumo.live.
Advertising, and what a paid notice can measure
rumo sells two clearly labelled paid notices.
A Large one takes a whole card in Home across all of rumo.
A Small one reveals inside a story, in one selected locality.
Both run for exactly 30 days at the fixed price of the country the advertising brand confirmed — ₹300 or ₹100 a day in India, $3 or $1 a day in the United States.
There is no auction, and nothing is targeted at a person.
What a paid notice records about a reader
Three things are counted, and only as totals: how many times a notice was displayed, how many times a Large notice was opened, and how many times its single action — a call, or a website — was used.
A raw event row carries its own identifier, the campaign and the exact creative version, the placement, which of the three kinds it was, the time the server assigned it, and the app version.
It does not carry your account, your profile, your device or your building.
Raw rows are deleted after seven days.
What remains is the daily aggregate: a date, a placement, a kind and a count.
What an advertiser is shown
Times displayed, times opened where the format can be opened at all, times acted on, the dates, and what was paid.
Never a name, a viewer list, an identifiable local cohort, or an export with a person in it.
A Small notice can be placed in a locality only when at least 50 eligible rumo members are counted there, and the advertiser sees that aggregate figure and nothing finer.
What rumo stores about an advertiser
An advertiser signs in with an email address and a one-time link. rumo stores the workspace, the brand name, its confirmed country, an optional website and phone number, the campaign words and picture, and the payment record.
Card details are never stored: Stripe processes the payment, and rumo keeps the amount, the currency, the state of the order and the receipt link Stripe returns.
The campaign picture is held in a private bucket and is read through short-lived signed links, never a public URL.
What is never sold
Advertisers may buy ad space.
They may never buy story placement, story ranking, removal, reputation management, dispute data or influence over what a record says.
Buying a notice changes nothing about where a story sits or how it is moderated.
Charging the subject of a story for influence over it is the one source of money that would end this product.
Contact
General: hello@rumo.live.
Grievances, and the statutory clocks that attach to them: the grievance page.
Copyright: the copyright page.
What is still owed
Every item below is a gap in this page, not a summary of one.
They are listed rather than implied so that nobody reads a placeholder as a commitment.
- The named grievance officer. An India-resident individual, published in-app and here, does not exist yet.
See the grievance page. - The legal entity. No company name, registered address, place of incorporation or data-controller identity appears anywhere on this page, because none has been settled.
- Where the data lives. The hosting region has not been stated here, and whether any cross-border transfer restriction applies to it is a counsel question.
- DPDP status and the itemised notice. India’s Digital Personal Data Protection Act commences in phases.
Which provisions bind rumo on the day it opens, and what an itemised notice must say about a model reading recorded speech as distinct from hashing an image, are both unconfirmed. - Notice languages. India’s Act requires the notice be available in English or any language in the Eighth Schedule.
This page exists in English only.
The scope of that requirement — whether it reaches the privacy policy and the grievance process, or only the consent notice — is unresolved. - Access, correction and nomination. Erasure is built.
The rights to obtain a copy and a summary of processing, to correct a record, and to nominate somebody to act after death have no implementation in rumo and no route on this page. - Breach notification. No incident process is written down.
One is required. - Age assurance. The 18+ floor is self-declared, and the check that refuses an account on a false answer is not built.
- US state privacy law. rumo is probably below every threshold at launch.
That is a working position, not a legal conclusion, and it has an expiry date. - The deletion walk. Every artifact in the internal deletion inventory has to be walked by a human against the running system once.
That has not happened. - Counsel. No lawyer in either country has read this page.
