Privacy Policy

Draft — not in force. This document is a draft awaiting the owner's review.

Most privacy policies are written to make a large amount of data collection sound reasonable. This one is short because there is not much to describe.

Said plainly: we hold your email address, a name and picture-hash for your connections to recognise you by, a note of which two devices you use, who you are connected to, and whatever you shared for as long as it takes to deliver it — at most 30 days. That is close to all of it. Everything below is the detail.

Who we are. VACUUM is operated by [LEGAL ENTITY NAME], CNPJ [CNPJ], registered at [REGISTERED ADDRESS], Brazil. We are the controller of the personal data described here.

Contact. Privacy questions and data-rights requests: support@vacuum.social. Reporting abuse: abuse@vacuum.social.

---

1. What we store

Everything in this table is here because a specific thing VACUUM does would not work without it. That is the rule we hold ourselves to internally, and it is a hard rule: every stored field has to have a documented purpose, a documented lifetime, and documented deletion behaviour, or it does not get stored.

Your account

Your email address is never shown to another member, never used to put two members in touch, and never included in any response another member's app receives. Your connections see your display name and the avatar hash — never an address, never part of one, never even the domain.

We never fetch, cache or proxy your Gravatar image on our servers. If your app shows an avatar, your phone asked Gravatar for it.

Your devices

For each of your (at most two) devices we store an identifier, a label, and the date it was added. The label defaults to your device's model name — "iPhone 17 Pro" — and you can change it. It exists so you can tell your two devices apart when you sign one out.

That is the whole device record. There is no IP address, no user agent, no operating system version, no app version, no "last seen" timestamp, and no per-device counter of anything — all four are prohibited by name, not merely absent. Your device label is never shown to another member and is never an input to anything derived.

Signing in

When you request a sign-in link we store a hash of that link's token, which account it belongs to, and when it expires. The link itself lives for 15 minutes and is single-use. The row is deleted 24 hours after it expires.

Once you are signed in we store a hash of your session token, which device it belongs to, and when it expires. App sessions last 60 days; account-website sessions last 14 days.

Sessions carry no IP address, no user agent, and no "last seen" or login count — prohibited by name.

Your connections

When a connection ends, the row is deleted. We do not keep a history of who you used to be connected to. There is no such table, deliberately.

Who blocked whom never leaves our server for anyone except the person who did the blocking. The other person is never told, and cannot find out.

What you share

Media files are held on our servers only long enough to deliver them. Most are deleted within days, because most people open the app within days. The absolute ceiling is 30 days and it is not conditional on anything.

Notifications, if you turn them on

Every notification type is off until you turn it on. A fresh install has no notification record at all, and silence is the default state, not a setting you have to find.

If you turn them on we store your three on/off choices, your digest cadence if you chose digests, and a push token for the device so the platform can deliver the notification. The push token dies with the device — sign out, and it is gone in the same operation.

If you use digests, we store a single marker saying "this account has something pending in this category". Not a count. The digest never says "you have 7".

Your subscription

If you subscribe, we store your Paddle customer and subscription identifiers, which plan you are on, when your period ends, and whether you may post.

We store no card number, no card last four, no expiry date, no payment token, no billing address, no tax identifier, no invoice, and no transaction total. We never see them. Paddle does.

We do not even store your price. The account page reads the amount you are charged live from Paddle when you open it. There is no per-member price stored anywhere in our database — that is a hard schema rule, and it exists because a stored price is the grandfathered price the price-follows-costs covenant abolished.

We also keep a minimal record of the billing events Paddle sends us — the event's identifier, its type, and when it happened — so a duplicate or out-of-order message cannot corrupt your subscription state. The message body is not stored, because it carries billing and address data nothing we do needs. These records are deleted after 90 days.

Technical records

A few short-lived operational records exist so the service behaves correctly: a 24-hour record of requests your app already made (so a retry does not post twice), and internal instructions telling your devices to delete something. The delete instructions are kept 37 days — slightly longer than a moment lives — so a phone that was off for a month still gets the instruction when it comes back.

2. What we do not store

This list is as load-bearing as the one above, and every item on it is prohibited by name in our schema rules, not merely absent from today's build.

• No browsing or viewing history. We do not record what you looked at, when, or for how long.
• No view counts, no seen-by, no read receipts. The only way anyone learns you saw something is if you chose to say something. There is no passive signal, for anyone, including the person who posted.
• No counters of any kind — no post counts, no connection counts, no streaks, no scores, no engagement metrics, no per-person interaction history.
• No behavioural or profiling data. None. There is nothing to profile you with.
• No advertising identifiers, no attribution SDKs, no fingerprinting. Not now and not later; they are permanently excluded from the product.
• No location data. Photos and videos with location tags are rejected at upload — see §4.
• No emoji-usage data. Your most-used emoji are computed and kept on your phone. They are never sent to us.
• No message read state, no "typing", no last-active.
• No copy of your data for analytics, training, or research. There is no analytics pipeline, no data warehouse, and no machine learning on anything you share.

One honest footnote about IP addresses. Like any service on the internet, our servers see the IP address your request arrives from — that is how the internet works. We use it for one thing: rate limiting, so somebody cannot hammer the sign-in endpoint. It is held in memory for the length of a rate-limiting window and then it is gone. It is never written to a database row and never written to a log. Our own engineering rules forbid giving a network identifier a persistent home.

And one about logs. Our operational logging records counts, timings and outcome classes — never an account identifier, never an email address, never a token, never content.

3. Where the 30 days is, and is not, absolute

At 30 days a moment is deleted from our servers and from every device that holds it. That is unconditional: it does not depend on whether anyone saw it, whether you are still subscribed, or whether anyone objects.

Two honest limits:

1. A phone that never opens the app cannot delete anything. Expired files sit in that app's private storage on that device until the next time it opens, at which point they are deleted immediately. We do not claim instant global deletion, because we cannot perform it.
2. Server deletion has a little slack. Our storage provider processes expiry deletions typically within about a day of the expiry mark. We say "30 days" and mean it as a promise, not as a stopwatch reading.

Deleting a moment yourself removes it from our servers immediately and instructs every device holding it to delete it at its next sync. There is no restore.

Disconnecting from or blocking someone deletes everything already shared between the two of you, immediately, in both directions — moments, media, and every reply thread between you. Not "stops sharing". Deletes.

Threads die with their moment. There is no transcript, no export, and no message history as a feature. When the moment goes, the conversation goes.

4. The one thing that touches your content

Nothing in VACUUM looks at what you shared, with exactly two exceptions, both at the moment of upload, both mechanical, and both described here rather than buried.

Only one component in the entire system is permitted to touch media at all. Every other part of the service handles your photos and videos as opaque bytes it never opens.

(a) Format and metadata checking

When you upload, we read the file's headers only — enough to establish that it is actually the format it claims to be, that it is within our size and length limits, and that it carries no embedded metadata. No pixels are decoded. No frames are decoded. No audio is decoded. Nothing is kept beyond pass or fail.

This is also how we keep location data out of the product. A photo carrying any EXIF or XMP metadata block, or a video carrying any metadata box, is rejected — not stripped, rejected. Location and device tags never enter the service at all.

(b) Known abuse material matching

Every upload must pass a check against lists of known child sexual abuse material and known harmful abusive material before it can publish — the check is built into the upload pipeline itself, and a moment that has not passed it never publishes. The matching runs through the Arachnid Shield service operated by the Canadian Centre for Child Protection. We are completing our registration with that provider; until it is active, the pipeline simply refuses to publish anything — it fails closed, never open. A match blocks the moment from ever being published.

What that is, precisely:

• It is a match against a list of known material. It is not analysis of your photo, it does not describe or classify what your photo contains, and it produces no opinion about you.
• For photos, we send a mathematical fingerprint rather than the image itself, wherever that is technically possible.
• For video, the file is submitted to the provider for matching, because fingerprint-only matching is not available for video.
• If the provider cannot be reached, we do not publish the moment. We retry. We never publish something unmatched. There is no override, no operator bypass, and no configuration switch that turns this off.

There is no other scanning of any kind. No nudity detector, no NSFW classifier, no image recognition, no machine learning on your content, ever. Report-based human review covers everything else. This is not a current limitation we might revisit — it is a fixed rule of the product.

If a moment is rejected — whether by the format check or by a match — you see the same neutral message either way, with no reason given. That is deliberate: telling you which check failed would turn our upload endpoint into a tool for testing material against the abuse-material list.

When a match blocks a moment, we keep a record of the match itself — which moment and item it was, what the provider returned, when, and whose account uploaded it. Not the media, not the caption, not who it would have gone to.

5. Reports

If someone you shared a moment with reports it, that moment — the item they selected plus the other items in the same moment, for context — is re-uploaded from their phone to a separate, isolated store, along with who posted it, who reported it, and when. Nothing else: no history, no other moments, no account data beyond those two identifiers.

Two consequences worth knowing:

• This is the one circumstance in which someone outside your connections can see your content. The person reporting is told this plainly before they submit.
• Because the evidence comes from their device, a report works even after the original has already been deleted from our servers.

One person reviews reports. Access to that queue is restricted and audited, and the queue shows only the reported moment and the identifiers above — never your other moments, never your account.

Reported material is held longer than 30 days, because evidence cannot delete itself mid-review and because illegal material may carry legal preservation duties. That exemption is bounded. Evidence retention is never indefinite, the end date is stored per item, and deletion at that date is automatic and requires no one to remember.

6. Who else handles your data

We use four outside providers. Here is each one, what it touches, and where it is.

Cloudflare — everything technical

Our API, our database and our media storage all run on Cloudflare (Workers, D1 and R2), and this website is served by Cloudflare Pages. In practice: your photos, your videos, and every database row described in §1 sit on Cloudflare infrastructure, and Cloudflare processes every request you make to us.

Media buckets are private. There is no public bucket, no public object, and no URL that works without a short-lived signed link issued to your signed-in device.

Resend — the sign-in emails

Sign-in links and account emails are sent through Resend. Three things about that which we would rather you heard from us:

1. Resend processes and stores its data in the United States, regardless of which sending region is selected. There is no EU or Brazilian data residency option that would change this.
2. Resend keeps a copy of the emails we send you for 30 days — including the sign-in link itself — visible in its dashboard. We do not keep a log of the emails we send you. Our email provider does, for 30 days. It would be easy to write "we hold no communications log" and stop there; that would be technically true and misleading, so we are telling you where the record actually lives.
3. Resend is not a single company in this chain. Its own published subprocessor list named 22 US entities as of July 2026, including hosting and sending infrastructure, a data warehouse, analytics products, and AI processors. Your email address and the metadata of our messages to you travel through that chain.

For members in the EEA, the UK or Switzerland, transfers to Resend rely on the EU Standard Contractual Clauses in Resend's data processing agreement, not on data residency.

Paddle — the payment

Paddle is the legal seller of the subscription and handles the entire payment: card details, billing address, tax identifiers, invoices and receipts. We never receive your card data. We hold only Paddle's identifiers for you and whether you may post. Paddle's own privacy notice governs what it does with the rest.

Canadian Centre for Child Protection — the abuse-material check

Described in §4. For photos, what is transmitted is a mathematical fingerprint wherever technically possible. For video, the file itself is submitted for matching, through a signed link that works once and expires in ten minutes.

Where your data physically lives

We do not offer a data-residency guarantee, and we are not going to imply one. Media and database records live on Cloudflare's global infrastructure without a jurisdiction restriction; email processing happens in the United States. If your country's law requires your data to stay inside it, VACUUM is not the right service for you.

7. Cookies and tracking

The public pages of vacuum.social set no cookies, run no analytics, and make no third-party requests. No tracking pixels, no fonts loaded from someone else's server, no tag manager, no consent banner — because there is nothing to consent to. The invite page in particular carries no analytics, no fingerprinting, no behavioural tracking and no attribution SDK.

The signed-in account area sets exactly one cookie, which holds your session so the page knows it is you. It is strictly necessary, HTTP-only, secure, and expires with the session. It is not used for tracking, because there is nothing here to track you across.

The apps contain no analytics SDK and no advertising SDK, and attribution SDKs are permanently excluded from the product by design, not by current preference.

8. Your rights

Under Brazil's LGPD (Lei 13.709/2018, Art. 18) you have the right to ask us to: confirm whether we process your data; give you access to it; correct incomplete or outdated data; anonymise, block or delete unnecessary or excessive data; port your data to another provider; delete data processed with your consent; tell you who we have shared it with; tell you what happens if you refuse consent; and withdraw consent.

If you are in the EEA or the UK, we honour the equivalent GDPR rights — access, rectification, erasure, restriction, portability, objection, and the right to complain to your local supervisory authority. Invite-only does not mean Brazil-only, and we would rather state these rights than argue about applicability.

How to exercise them. Email support@vacuum.social from the address on your account. We will respond within 15 days, which is the LGPD's deadline for access requests.

Some practical honesty about what those rights get you here:

• Access and portability: what we hold is listed in §1. It is a small amount of data and we can send it to you.
• Correction: your display name is editable in the app.
• Deletion: see §9 — and read it, because the current answer is not a button.
• Objection and restriction: you can stop using the service at any time, and everything you shared expires on its own within 30 days regardless.
• What we cannot do: recover, restore or produce content that has already expired. It is gone, including for us. A data request cannot resurrect it.

9. Deleting your account

Right now, account deletion is by request, not by button.

Email support@vacuum.social from your account's address and we will delete your account, its data, and everything listed in §1 that belongs to it. That is your LGPD Art. 18 right and we honour it on request.

We would rather tell you that plainly than ship a page implying a self-serve control that does not exist yet. A self-serve deletion control is planned.

Two things that happen regardless of whether you ever ask:

• Everything you shared expires within 30 days of posting it, on its own.
• Signing out of a device deletes that device's copies of everything.

One exception, stated because omitting it would be dishonest: if an account is banned for a serious violation, we retain a record of that account indefinitely, so the ban can be enforced. That record exists only to keep a banned account banned.

10. Legal bases

Where the LGPD or GDPR requires us to name a basis for processing:

• Performing our contract with you — your account, your connections, delivering moments, running your subscription. Most of §1 sits here.
• Complying with legal obligations — abuse-material matching, evidence handling and enforcement records.
• Legitimate interests — keeping the service secure and available: rate limiting, fraud and abuse prevention.
• Your consent — notifications, which are off until you turn them on and which you can turn off at any time.

11. Children

VACUUM is not for children. You must be at least 18 to have an account, and we do not knowingly collect data from anyone younger. If you believe a child has an account, email support@vacuum.social and we will delete it.

12. Changes to this policy

If we change this policy materially, we will say so on this page and email account holders. We will not quietly widen what we collect: adding a new category of stored data would require changing the product rules that this policy describes, which is a deliberate act, not a policy edit.

---