Rm8tes Privacy Policy

Last updated: 1 September 2026

Rm8tes is an app that helps renters in the UK protect their tenancy deposit: it captures move-in and move-out photo evidence, keeps a tenancy diary, and generates an evidence pack you can share with your landlord or a deposit scheme.

This policy explains what personal information Rm8tes collects, why, where it is stored, and the choices and rights you have. We have tried to write it in plain English. It does not limit our liability to you — that is set out in our Terms & Conditions, which forms part of your agreement with us.

Who is responsible for your data (the "data controller"): Roomates Ltd, trading as Rm8tes — a company registered in England and Wales, company number 16826260, registered office 35 Welbeck Avenue, Tunbridge Wells, England, TN4 9BD. Contact: rm8tes@gmail.com

In this policy, "Rm8tes", "we", and "us" all mean Roomates Ltd.

The short version

We collect only what the app needs to work: your account details, your profile, and the tenancy records and photos you choose to capture.
You can sign in with an email address and password, or with your Google or Apple account if you prefer. They tell us your email address and the name on your account, and little beyond that; we never see your password there, and they never see anything you capture in Rm8tes.
You can share a property with the people you live with. Everyone in that household can see its photos, checklists and diary — so only join a household you trust, and only capture what you are happy for your flatmates to see.
Your evidence — audit photos and diary entries alike — is fingerprinted and timestamped so it can be shown to be unaltered, and the fingerprint is published to the Bitcoin network once an hour. What gets published is a one-way code that reveals nothing about you, your home, or your photos — but it is permanent and we cannot withdraw it.
So that anyone can check that for themselves, we also publish the working behind it: each record’s fingerprint and the few neighbouring ones needed to tie it to the blockchain. Never your photos, entries, address or name — only arithmetic about them. A record’s file is withdrawn when the record is deleted; the batch summaries, which identify nobody, are permanent.
A diary entry can carry a photo, and both are fingerprinted the same way. Once an entry is recorded it is fixed: nobody can edit or delete it — not your flatmates, not us — though deleting your account still erases every entry you wrote.
Evidence records the flatmate who captured each photo, and who wrote each diary entry, as a code, never a name — different in every property, and locked with a secret key of your own that we destroy when you delete your account, so it cannot be used to link you across tenancies.
Your data is stored with our hosting provider, Supabase, in London, United Kingdom.
We do not sell your data or show ads, and the app contains no advertising or marketing technology.
We use two privacy-focused tools, both hosted in the EU: PostHog to see which features are used, and Sentry to receive crash reports. Neither ever receives your photos, diary entries, addresses, or anything else you capture as evidence. You can switch the usage analytics off at any time in Profile, and that device stops sending them.
Account emails (your sign-up confirmation and password resets) are delivered by Resend, which sends from Ireland but keeps its own record of those messages in the United States, under transfer safeguards approved for the UK. Those emails contain your email address and a one-time link — nothing else about you.
Sign-up, log-in, password-reset, and beta waitlist requests are screened for bots by Cloudflare Turnstile. In the app it runs invisibly — there is no puzzle or checkbox to complete.
Location is optional, used only at the moment you take an evidence photo, and only to stamp that photo.
Evidence packs (PDFs) are generated on your device and are only shared if and where you choose to share them.
You can delete your account in the app. If you are the only person left in your household that erases everything; if you still share it, the flat's records pass to your flatmates and the sealed evidence stays, because it is their proof too.

Information we collect

Account information

When you create an account with an email address and password, we collect your email address and a password. Passwords are handled by our authentication provider (Supabase) and stored only in hashed form — we never see or store your plain-text password. Your email address is used to sign you in, to send account emails (such as email confirmation and password-reset links), and is stored alongside your profile. Those emails are delivered by an email provider outside our systems — see "Account emails" below.

Instead of an email address and password, you can create your account and sign in with your Google account, or — on an iPhone — with Sign in with Apple. It is entirely optional, and everything else in Rm8tes works the same either way.

If you use one, your device shows you that provider's own sign-in sheet. We never see your Google or Apple password, and we never ask them for access to anything else you keep there: no Gmail, Drive, iCloud, contacts, calendar, or photo library. We ask only for the basic sign-in information described here.

What the provider tells us. The sheet hands back a signed sign-in token, which our authentication provider (Supabase) checks and records against your account. It contains your email address and whether the provider treats it as verified, an identifier for your account with that provider, and — where the provider includes them — the name on your provider account and a link to your provider profile picture. We use the name for exactly one thing: to prefill the display-name box when you set up your Rm8tes profile, where you can change or clear it. We do not copy your provider profile picture into your profile, and none of this is used for advertising or passed on to anyone.

What the provider learns. Google or Apple necessarily learn that you have an account with Rm8tes and when you sign in to it, as they would for any app you use their sign-in with. For that they act as their own data controllers rather than our processors, under their own policies — Google's Privacy Policy and Apple's Privacy Policy. We send them nothing about you beyond what completing the sign-in requires: none of your photos, diary entries, tenancy records, or anything else you capture in the app ever reaches them.

If you use Apple's "Hide My Email", Apple gives us a relay address ending @privaterelay.appleid.com instead of your own, and forwards our account emails to you through it. That relay address is then the only address we hold. Because it matches nothing else, an account created that way is a separate account from any you already have with us under your real address — separate profile, separate household — and we have no way to merge the two.

If you use Google on an address you already have a Rm8tes password account under, Google reports that address as verified, so the two are treated as one: you sign in to the account you already had rather than creating a second one.

Your password, or the absence of one. An account created with Google or Apple has no Rm8tes password at all, so getting into it depends on your provider account — please keep that one secure. You can add a password whenever you like from the profile screen, after which either way of signing in works.

These sign-ins are screened for bots exactly as an email log-in is — see the next section. If you later delete your Rm8tes account, everything we hold goes with it, including the link to your Google or Apple account; the entry for Rm8tes in your Google or Apple account's own list of connected sign-ins belongs to them rather than to us, and you can remove it in their settings.

Bot protection (Cloudflare Turnstile)

To stop bots and scripts from mass-creating accounts, bombarding the sign-up, log-in, and password-reset screens — including when you sign in with Google or Apple — or flooding our beta waitlist, each of those requests is checked by Cloudflare Turnstile. In the app the check is invisible: there is no puzzle, checkbox, or image to solve, and you will not see it happen. On the "Join the beta" form on our website it normally stays out of the way in the same manner, but it may ask you to confirm you are human if it cannot reach a decision on its own.

To make that judgement, Turnstile processes a small set of technical signals about the request: your IP address, TLS fingerprint, User-Agent header, and the site key and origin the check was issued for. Cloudflare states that it cannot directly identify individuals from these signals, including IP addresses, and that their purpose "is not to identify, profile or target any individuals but solely to detect and block bots". Cloudflare acts as our processor when it screens a request on our behalf, and as an independent controller when it uses the same signals to improve its own bot-detection technology, which it does on the basis of its legitimate interests.

Turnstile never receives your photos, diary entries, tenancy records, landlord details, or anything else you capture in the app, and it does not receive the email address you type into the beta form. When our server confirms a check with Cloudflare it sends only the one-time token the check produced and the IP address the request came from; what comes back is a pass or a fail, not the signals behind it. Full detail of Cloudflare's handling is in Cloudflare's Turnstile Privacy Addendum.

Beta waitlist

If you submit your email address on our website's "Join the beta" form, we store only that email address, so we can send you a one-time link when the beta becomes available. It is kept in the same Supabase project and UK region as the rest of the data described in this policy, is not used for any other purpose, and is never shared, sold, or used for advertising. You can ask us to remove it at any time by emailing rm8tes@gmail.com. To stop the form being abused for spam, we also briefly record where a submission came from: the IP address for an IPv4 connection, or only the network prefix — not your full address — for an IPv6 one. It is stored apart from your email address and never linked to it, is used for nothing but limiting how many submissions one source can make in a short period, and is deleted automatically well inside 24 hours — usually within about two — by a clean-up that runs every fifteen minutes whether or not anyone uses the form. The form is also screened by Cloudflare Turnstile, as described above.

Profile information

You can choose to add profile details: display name, age, whether you are a student or intern, gender, profession, general location (as free text, e.g. a city), monthly room budget, a short bio, lifestyle tags, and a profile photo. Apart from a display name, all of these are optional. Gender includes a "prefer not to say" option.

Profile photo: if you add one, it is stored in a publicly accessible storage bucket, which means anyone who has the photo's web address can view it. Do not upload a profile photo you would not want to be publicly visible.

Property and tenancy information

When you log a property or tenancy, we store what you enter: the property address, your move-in date, your deposit amount, and your landlord's name and (optionally) email address. If you use the viewing checklist, we also store the addresses of properties you view and your checklist notes.

Evidence and records you capture

Audit photos: move-in and move-out photos are taken with the camera (never selected from your photo library), and each is stored with the date and time it was taken and — if you allow location access — the GPS coordinates where it was taken. These photos are stored in a private storage bucket that only you and the other members of your household can open.
Damage checklist: the condition items you tick off and their severity.
Living diary: the dated entries you write (title, description, date) and, if you add one, a photo — taken with the camera at that moment, never chosen from your photo library, and stored with the time it was taken and any GPS coordinates in the same private bucket as your audit photos. Everyone in your household can read the diary and see its photos. Since 5 August 2026 an entry is written by our server and fixed the moment it is written, which is explained under "Keeping your evidence tamper-evident" below.

Evidence packs (PDFs)

When you generate a deposit evidence pack, the PDF is built on your device. It contains your display name, the property address, landlord details, deposit amount, the household's audit photos with their timestamps and location stamps, and the diary timeline with any photos attached to its entries. It also reproduces the integrity record described under "Keeping your evidence tamper-evident" below — which, for each photo and each diary entry, includes the capturer code of the household member who took or wrote it, but never their name, email address or account number. We do not upload or store the PDF. If you share it (for example by AirDrop, email, or a messaging app), it goes only to the destination you choose, through your device's share sheet.

Device permissions

Camera — to take your profile photo, to capture audit evidence, and to attach a photo to a diary entry. Optional; the app asks before first use.
Photo library — only so you can choose an existing photo as your profile photo. Evidence photos, in the audit and in the diary alike, can only be taken with the camera. We do not scan or upload your library.
Location (while using the app) — only at the moment you take an audit photo or a diary photo, to stamp it with GPS coordinates so it is stronger tenancy evidence. This is optional and best-effort: if you decline, or no fix is available, the photo is simply saved without coordinates. The app does not track your location in the background or at any other time.

Stored on your device only

Your light/dark theme preference and your sign-in session token are stored locally on your device. They are not used for tracking.

Usage analytics and crash reports

To understand which features are useful and to fix problems, we use two service providers:

PostHog (usage analytics). The app records when you complete key actions — creating an account, signing in with Google or Apple (which provider, and nothing from your provider account), finishing your profile, adding a property, taking move-in audit photos, using the viewing checklist, adding a diary entry, logging damage, generating an evidence pack, and opening the Know Your Rights section — along with basic technical information such as your device model, operating system version, and app version. Events are linked to a random account identifier, never to your email address. The content of what you enter or capture — photos, property addresses, diary text, checklist notes, landlord details — is never sent to PostHog. We do not use session recording. You can turn this off. Open Profile and tap USAGE ANALYTICS: that device stops sending events immediately, and the random identifier it had been using is deleted from it. You can turn it back on the same way, and you never have to give a reason for either. Crash reports are separate and are not affected.
Sentry (crash reporting). If the app crashes or encounters an error, a report is sent containing the technical details of the error (such as the stack trace) and the same basic device information, so we can find and fix the problem. If a sign-in with Google or Apple fails before it ever reaches us, we record that too — which provider it was and the reason it gave, never your email address, your name, or any token.

Both services act as our processors under data processing agreements, are configured to store data in the European Union (Frankfurt, Germany), and do not use your data for their own purposes or for advertising.

What we do not collect

We do not show ads and use no advertising or marketing SDKs. We do not collect your contacts, your browsing history, or your precise location outside of photo capture. We do not use your data to train AI models. The analytics and crash reports described above never include the content of your evidence or records.

Sharing a household with flatmates

A property in Rm8tes belongs to a household rather than to one person. You either create the flat yourself — which makes you its owner — or join an existing one with the short join code a current member gives you. That code is the key to everything described below, so treat it like a key: only pass it to people you actually live with, and only accept one from someone you trust.

While you are an active member of a household, you and every other member can see:

the property and tenancy details — the address, move-in date, deposit amount, and the landlord's name and email address;
every audit photo captured for that property by anyone, with its timestamp and any location stamp;
the damage checklist and the viewing checklist;
every entry in the living diary, and any photo attached to one. A shared diary is the point — the household needs one repair history — but it does mean your flatmates read what you write and see what you photograph. Nobody can delete an entry once it has been recorded, not even the person who wrote it, so a repair history cannot be quietly rewritten. (Entries written before 5 August 2026 pre-date that and can still be deleted by their author.)

Members also see a flatmates list showing each member's display name, profile photo, whether they are the owner, and the date they joined. Your email address and the rest of your profile are not shown to them.

So everything you capture in a shared flat is visible to the people you live with. Please do not photograph anything you would not want your flatmates to see, and remember the diary is shared even though you wrote the entry.

The owner of a household can remove a member, and any member can leave. In both cases the audit photos that person captured stay in the household's record: moving out does not rewrite what was documented while they lived there, and the remaining members still need it for their own deposit. Their account, profile and diary entries are theirs and go with them. The same applies if they delete their account outright — see "Deleting your account and data" below.

Keeping your evidence tamper-evident

Evidence is only worth having in a deposit dispute if it can be shown not to have been altered or back-dated afterwards — and that is as true of the note saying you reported the damp in March as it is of the photograph of it. Rm8tes does that in four steps. None of them involve sending your photos anywhere.

A fingerprint for every photo. When a photo reaches our server, the server records the moment it arrived and computes a fingerprint (a SHA-256 hash) of the whole record: the photo file, the property, the prompt it answers, the timestamps, any GPS coordinates, and a capturer code for the member who took it. A fingerprint is a short one-way code — nobody can work backwards from it to the photo or to anything else in the record.
A fingerprint for every diary entry. Since 5 August 2026 your diary works the same way. The app no longer writes entries itself: it asks our server to record one, and the server stamps it with its own clock — so an entry cannot be back-dated to before the fault was reported — and fingerprints the whole thing: the property, the title and description, the date you say it happened, the moment it was recorded, the capturer code of whoever wrote it, and, when a photo is attached, that photo's own fingerprint, computed by the server from the file it actually stored rather than from anything the app claimed about it. Entries written before that date carry no fingerprint and are ordinary notes.
A seal for each side of the audit. When your household finishes a move-in or move-out audit, it can seal it. A seal fixes that side of the audit as complete at a stated moment and records which member closed it. Sealing is one-way: a sealed side cannot be reopened, added to, or edited by anyone, including us. The diary stays open to new entries, because a tenancy keeps happening — but each entry is fixed on its own as soon as it is written.
An hourly anchor to the Bitcoin blockchain. Once an hour, the fingerprints of all new records across the whole service are combined into a single summary fingerprint, and that one value is published to the Bitcoin network using OpenTimestamps. When it appears in a Bitcoin block, that block's own timestamp proves every record in the batch already existed at that moment.

What "fixed" means for a diary entry. Once an entry has been recorded it cannot be edited or deleted — not by you, not by your flatmates, and not by us — and the photo attached to it cannot be replaced with different bytes. That is the point of it: an entry that could be withdrawn afterwards would prove nothing, and a flatmate's dispute resting on "we reported this in March" should not evaporate because whoever typed it had second thoughts. If an entry is wrong, write another one correcting it; the timeline shows both. This is a limit on rewriting a shared record, not on erasure — deleting your account still removes every entry you wrote, and every photo attached to one, as described under "Deleting your account and data" below.

The capturer code is not your name or your account number. It is a one-way code worked out from the property and the member together, so it does two things at once: within one property the same code across several photos and diary entries shows they all came from one person, while the same person documenting a different address produces an entirely unrelated code. It is different in every property, and cannot be used to link you across tenancies — not by us, not by a landlord, and not by anyone who collects evidence packs from several different homes.

The code is also locked with a secret key of your own. When you first document a property we generate a random key for your account, keep it where nothing outside our database can read it, and use it to work out your capturer codes. Without that key nobody can reproduce a code, work out whose it is, or test a guess against one — and the key is destroyed the moment you delete your account, along with everything else about you. So while your account exists we can tell whose code is whose; once it is gone, neither we nor anyone else can, ever, including for codes already published in the anchors described above. The trade-off is that you cannot single-handedly prove one of these codes is yours either: if you ever need to show that you personally took a photograph, ask us and we will confirm it for you while your account is open.

What goes onto the blockchain is a single 32-byte code and nothing else. It is not your photo, your address, your name, or your account identifier. It covers many different people's records at once, it cannot be reversed, and nobody reading the Bitcoin blockchain could tell it has anything to do with Rm8tes, with you, or with any property. We do not consider it to be personal data.

It is, however, permanent, public and worldwide. The Bitcoin blockchain is not ours; it cannot be edited or withdrawn by us or by anyone else, so an anchor stays there indefinitely. That permanence is exactly what makes it useful as proof, and it is why the anchor is designed to carry nothing that could identify you — so that there is nothing in it that would ever need withdrawing.

That code is not the only thing we publish, though. Checking it needs the working that connects your record to it, and we publish that too — the subject of the next section.

Your evidence pack reproduces this chain in full — each record's fields, its fingerprint, the steps that combine it into the published summary, and the Bitcoin block it landed in — so a landlord, letting agent, deposit scheme or adjudicator can check the arithmetic for themselves without having to trust us or the app.

Publishing the proof

An anchor is only worth having if somebody can actually check it, and until August 2026 nobody outside your household could. Your evidence pack told its reader to obtain the timestamp proof from us and check it with standard tools — but that proof sat in a part of our database only your household could read, so the strongest claim in the pack was the one thing an adjudicator could not follow up. We now publish what that check needs, at rm8tes.com/verify.

It goes out as two separate files, and the split is deliberate:

The batch. For each hourly run: the summary fingerprint, the timestamp proof over it, and the Bitcoin block it reached. This is the anchor and its working. It covers many unrelated people’s records at once, names nobody, and holds nothing that could identify you — so, like the anchor itself, it is permanent and is never withdrawn.
The record. For each record: its own fingerprint, and the handful of neighbouring fingerprints needed to combine it into that batch. A fingerprint cannot be turned back into the photograph or entry it came from, and there is no name, address, account identifier or capturer code anywhere in the file. But it is worked out from one person’s record and we can link it back, so we treat it as yours: it is withdrawn when the record it covers is deleted.

That is the whole reason these are two files rather than one. Deleting a diary entry, or deleting your account, takes down the published file for every record that goes with it — usually within a few hours, and never longer than a day.

None of this publishes your evidence. Not the photograph, not the entry, not the address, not who you are. What is published is arithmetic about them.

Every anchored record in your evidence pack now carries a QR code beside it, pointing at that page with the record’s fingerprint already filled in. The fingerprint travels in the part of a web address that browsers never send to a server, so scanning a code does not tell us — or the company hosting the page — which record somebody checked, and leaves no trace of it in any log. The page then does the whole check inside the reader’s own browser, and reads the Bitcoin block from two independent public block explorers, so they do not have to take our word for any of it. Neither do you.

Information about other people

To describe your tenancy, you may enter another person's details — typically your landlord's name and email address. This information is stored only as part of your tenancy records and appears in evidence packs you generate; we do not use it for any other purpose and never contact your landlord ourselves. Please only enter information about others that is accurate and relevant to your tenancy.

You will also hold information about your flatmates, and they about you, for as long as you share a household — see "Sharing a household with flatmates" above.

How we use your information, and our legal bases

Under UK data protection law (UK GDPR), we need a legal basis for using your data:

To provide the service (performance of a contract): creating and operating your account — including signing you in, through Google or Apple if that is how you choose to do it, and sending the account emails needed to confirm your address, sign you in, and reset your password — storing your profile, tenancy records, photos, checklists, and diary; sharing a household's records with the other members of that household; keeping the tamper-evident record described above; and generating evidence packs.
With your consent: attaching GPS coordinates to the photos you capture, in the audit and in the diary alike (you can decline the location permission at any time in your device settings; existing photos keep the stamp they were saved with).
Legitimate interests: keeping the service secure (for example, authentication and access controls, rate limiting, and the Cloudflare Turnstile bot check that guards sign-up, log-in — including sign-in with Google or Apple — password reset, and the beta waitlist form); and understanding, through the limited usage analytics and crash reports described above, how the app's features are used and where it fails, so we can improve it. We have designed this to be minimal: feature-level events and technical crash data only, under a random identifier, never the content of your records. You can object to the usage analytics whenever you like by switching them off in Profile, as described above — no reason needed, and it takes effect on that device at once. This heading also covers keeping a household's sealed evidence intact after one of its members leaves or deletes their account, so that the people still living there can continue to rely on it — explained under "Deleting your account and data" — and keeping a recorded diary entry unalterable while its author is still a member, so that a shared repair history stays worth something to everybody in it.

We do not use your information for marketing, profiling, or automated decision-making.

Where your data is stored and who can access it

Your account, profile, and records are stored using Supabase, our backend and hosting provider, in their London (United Kingdom) region. Supabase processes data on our behalf under its data processing agreement and does not use your data for its own purposes. Access to your records is restricted so that only your signed-in account — and, for a shared property, the accounts of the other members of your household — can read or change them. Two things sit at publicly accessible addresses instead, both described above: profile photos, and the anchor proof files under “Publishing the proof”.

Usage analytics are processed for us by PostHog and crash reports by Sentry, both in their European Union (Frankfurt, Germany) regions and only on our instructions, as described in "Usage analytics and crash reports" above.

The bot checks described in "Bot protection" above are run by Cloudflare, on the global network it uses to deliver Turnstile — which means the technical signals for a given check may be handled outside the UK, including in the United States. The signals stay with Cloudflare; none of your account details or records are sent to it, and it has no access to anything stored in Supabase.

Account emails

Account emails — your sign-up confirmation and password-reset links — are triggered by Supabase's authentication service and delivered by Resend, our email provider, acting as our processor under a data processing agreement.

To send you a message, Resend receives your email address and the message itself, which contains a one-time confirmation or reset link and nothing else about you. It keeps a record of the messages it has sent, so that we can tell whether an email arrived and diagnose it if it did not. Resend never receives your photos, diary entries, tenancy details, landlord details, or anything else you capture in the app. These emails are service messages, not marketing, and we do not use open- or click-tracking in them.

Resend sends our mail from servers in Ireland, but stores its own records of sent messages in the United States. That transfer is covered by the safeguards described in the next section.

If you sign in with Google or Apple, that exchange is different in kind from everything above: you are choosing to authenticate with a company you already have an account with, and they act as their own controller for what they learn from it rather than as a processor for us. What passes in each direction is set out under "Signing in with Google or Apple". Nothing you keep in Rm8tes is part of it, and if you never use those buttons neither company hears about you from us at all.

Beyond that, we do not share your personal information with anyone else. We do not sell it, rent it, or share it with advertisers or data brokers. We would disclose information only if genuinely required by law, or as part of a transfer of the service itself (in which case this policy would continue to apply and you would be notified).

Anything you export yourself — such as sharing an evidence pack PDF — is under your control and goes only to the recipients you choose.

International data transfers

Everything you create in the app — your account, profile, tenancy records, photos, checklists, and diary — is stored in the United Kingdom. Usage analytics and crash reports are processed in the European Union (Frankfurt, Germany), which the UK government recognises as providing an adequate level of data protection, so no additional safeguards are needed for them.

Two things do leave the UK and the EU. The first is the account-email pipeline described above: Resend sends our mail from Ireland but stores its record of those messages — your email address and the message itself — in the United States. We rely on two safeguards for that transfer, both of which UK law recognises:

Resend is certified under the EU–US Data Privacy Framework and its UK Extension, the mechanism the UK government has approved for transfers of personal data to certified organisations in the United States; and
our data processing agreement with Resend includes the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, which continues to protect the transfer independently of that certification.

The second is the Turnstile bot check. Cloudflare, Inc. is based in the United States and runs Turnstile across its global network, so the technical signals for a check — your IP address, TLS fingerprint, User-Agent header, and the site key it was issued for — may be processed there or in another country. That transfer rests on the same two safeguards: Cloudflare is certified under the EU–US Data Privacy Framework and its UK Extension, and its data processing agreement incorporates the EU Standard Contractual Clauses with the UK International Data Transfer Addendum. Nothing you create in the app is included in this — only the signals from the request being checked.

A third leaves only if you choose it: signing in with Google or Apple. Google LLC and Apple Inc. are both based in the United States and run their sign-in services worldwide, so the sign-in itself — which happens between your device and them, and carries nothing you have stored in Rm8tes — may be handled there or elsewhere. Because they are their own controllers for it rather than our processors, the safeguards that apply are theirs and are described in the policies linked under "Signing in with Google or Apple" above; ours is simply the decision to offer the buttons, which you are free not to press.

One further thing leaves the UK, and it carries no personal data at all: the hourly anchor described under "Keeping your evidence tamper-evident". The single summary fingerprint it publishes goes to the Bitcoin network, which is worldwide and public. It is a one-way code covering many people's records at once and holds nothing that identifies you, your home, or your photos — but unlike the transfers above it is permanent, and neither we nor anyone else can withdraw it.

The proof files described under "Publishing the proof" are stored alongside everything else in the United Kingdom, but they are meant to be read by anyone, anywhere, so they are delivered through Cloudflare’s content delivery network. That means copies are cached on servers close to whoever is reading — which may be outside the UK. It is the same company and the same safeguards as the Turnstile bot check above: Cloudflare is certified under the EU–US Data Privacy Framework and its UK Extension, and its data processing agreement incorporates the EU Standard Contractual Clauses with the UK International Data Transfer Addendum. What is cached is only ever a fingerprint and its neighbours; when a proof file is withdrawn, it is removed from those caches too.

If you would like more detail about these safeguards, or a copy of the relevant contractual terms, email us at rm8tes@gmail.com.

How long we keep your information

We keep your information for as long as your account exists, so that your evidence remains available for the length of your tenancy and any deposit dispute. When your account is deleted, or you ask us to erase your data, we delete your records from our live systems without undue delay.

There is one exception, and it exists because Rm8tes records are shared. Audit photos and audit seals captured inside a household that other people still belong to are kept for as long as that household's record lasts, even after the person who captured them deletes their account — they are the remaining members' evidence as much as theirs. What survives is the record and the photo file, carrying a capturer code that is specific to that one property and, once the key behind it has been destroyed with the account, no longer resolves to anybody. This is set out in full under "Deleting your account and data" below.

A diary entry, once recorded, cannot be deleted from inside the app by anyone — but that is a limit on rewriting a shared record rather than on erasure. Deleting your account still removes every entry you wrote and every photo attached to one, in every household you belonged to. What is left behind is the fingerprint already published in an hourly anchor, which is a one-way code covering many unrelated people's records and identifies nothing and nobody.

Copies of your data may survive for a short while in backups we keep so that the service can be recovered after a failure. We do not use those backups for anything else, and we cannot pick a single person's data out of one — instead, your data disappears from them as older backups are replaced by newer ones, which takes no more than 30 days. In the unlikely event that we ever had to restore the service from a backup taken before your deletion, we would re-apply your deletion straight afterwards.

Our email provider's record of the account emails we have sent you is deleted after 30 days, and everything held there would be deleted within 90 days if we stopped using the service.

Beta waitlist emails are kept until we send the beta invite or you ask us to remove them. The separate spam-prevention record described under "Beta waitlist" — the source address a submission came from, never linked to the address you submitted — is deleted automatically well inside 24 hours, by a scheduled clean-up that runs every fifteen minutes regardless of whether the form is being used.

We keep nothing at all from the Turnstile bot checks — we never hold the signals, only the account or waitlist entry the check let through. Cloudflare keeps the signals it processed under its own policy, linked above.

Crash reports are deleted by Sentry automatically after 90 days. Usage analytics events are kept under their random identifier so we can see longer-term trends; when we erase your data on request, this includes the analytics events linked to your account's identifier.

Your rights

Under UK GDPR you have the right to:

Access the personal data we hold about you, and receive a copy;
Rectify inaccurate data (most profile and tenancy details can be edited directly in the app; a recorded diary entry is the exception — write a further entry correcting it, or contact us);
Erase your data ("right to be forgotten") — subject to one limit where your evidence is shared with flatmates, explained under "Deleting your account and data", and to what an hourly anchor has already fixed, explained under "Publishing the proof";
Restrict or object to our processing of your data — for the usage analytics you can do this yourself, immediately, in Profile, without contacting us;
Data portability — receive data you provided in a machine-readable format;
Withdraw consent at any time where we rely on it (for example, by turning off the location permission).

To exercise any of these rights, contact us at rm8tes@gmail.com. We will respond within one month.

If you are unhappy with how we handle your data, you can complain to the UK Information Commissioner's Office (ICO) at ico.org.uk, though we would appreciate the chance to help first.

Deleting your account and data

You can delete your account from the profile screen in the app, and rm8tes.com/delete-account gives the steps, along with an email route if you can no longer sign in. It happens immediately, it cannot be undone, and we have no way to recover a deleted account for you afterwards. Because it is permanent, generate and save any PDF evidence pack you might still need — for a deposit dispute, for example — before you delete. Anything you exported beforehand is outside our systems and is unaffected.

Always erased: your login credentials — including the link to your Google or Apple account, if that is how you signed in — your profile and profile photo, your diary entries and every photo attached to one, your household memberships, and your usage analytics. Diary entries go even where your flatmates remain: they are your account of your tenancy, so they leave with you, which is worth knowing if the household is relying on a repair history you wrote.

If nobody else is left in your household — you rent alone, or every flatmate has already gone — that is the whole story. The property, the tenancy, the checklists, every audit photo and every stored photo file go with it.

If you still share the household with someone, we cannot simply erase the shared record, because it is also their evidence for their own deposit. In that case:

The property, tenancy, viewing checklist and damage checklist pass to whichever flatmate has been in the household longest. These records describe the flat rather than you, and the people still living there would lose their whole tenancy history if they went with you. Your identity is not attached to them — they simply become that flatmate's records to manage.
The audit photos you captured, and any audit you sealed, stay in the household's record — both the entries and the photo files themselves, which your remaining flatmates keep the access to that they already had. They are sealed, fingerprinted and anchored as described above: crediting them to somebody else would make the record untrue, and deleting them would destroy proof your flatmates are relying on.
Because those photos stay, their published proof files stay too — they are what lets your former flatmates show the photos have not been altered since. The proof files for everything that does leave with you, diary entries above all, are withdrawn. A proof file holds a fingerprint and its neighbours, and nothing else: no name, no address, no account identifier.
Those records keep the capturer code worked out when you captured them, because it is inside a fingerprint that has already been published and cannot be changed after the fact. It continues to appear in evidence packs your former flatmates generate. But it is only ever a code: it holds no name, no email address and no account number, and it is specific to that one property. The secret key it was locked with is destroyed when your account is — so from that moment nobody, ourselves included, can turn it back into a person, match it against you, or test whether a particular account produced it. Nobody can use it to find you, to contact you, or to connect you to any other home you have rented.

We believe this is the right balance between your right to erasure and other people's need to keep evidence they depend on, and UK data protection law permits personal data to be retained where it is necessary for the establishment, exercise or defence of legal claims. If you disagree, or your situation is not the ordinary one, email us at rm8tes@gmail.com — we will look at it properly and reply within one month.

The other thing in-app deletion does not reach is our email provider's record of any account emails already sent to you, which expires on its own within 30 days; ask us if you would like it removed sooner. (The Turnstile bot checks are never linked to your account in the first place, so there is nothing there to delete.)

If you signed in with Google or Apple, deleting your Rm8tes account removes the connection from our side, and we hold nothing about you afterwards. What we cannot reach is the record on their side that you once used their sign-in here: Rm8tes may still be listed among the apps you have signed in to with that account, and removing it is done in their settings — on Apple, under your Apple Account's "Sign in with Apple" list; on Google, under your Google Account's third-party connections.

If you would rather we handled the erasure, or you can no longer sign in to your account, email us at rm8tes@gmail.com from the address you signed up with and we will complete it and confirm within one month (usually much sooner).

Security

All communication between the app and our servers is encrypted in transit (HTTPS/TLS), and data is encrypted at rest by our hosting provider. Access to your records is enforced at the database level (row-level security), so your evidence, diary, and tenancy details are readable only by your own signed-in account and by the flatmates who share your household. The proof files described under “Publishing the proof” are the deliberate exception, and they are on the other side of that boundary by design: what they contain is fingerprints worked out from your records, never the records themselves. Passwords are stored only as secure hashes. If you sign in with Google or Apple instead, it is the security of that account that stands between anyone else and your evidence, so it is worth having two-step verification switched on there. No system is perfectly secure, but if we become aware of a breach affecting your personal data we will notify you and the ICO as required by law.

Children

Rm8tes is intended for renters aged 16 and over and is not directed at children. We do not knowingly collect data from anyone under 16; if you believe a child has created an account, contact us and we will delete it.

Links to other services

The app's "Know Your Rights" section links to external websites such as GOV.UK, Shelter, and Citizens Advice. Opening a link takes you out of the app; those sites have their own privacy policies, and we are not responsible for their practices.

The verification page at rm8tes.com/verify is different, because it contacts other people’s servers by itself rather than waiting for you to click. To read the Bitcoin block a record was fixed in, it asks blockstream.info and mempool.space — two independent public block explorers — from the browser of whoever is looking. It asks each of them for a block number and nothing else, and never sends them a fingerprint or anything about you or your records; but as with any web request, the person’s own IP address and browser details are visible to those two companies, who are not our processors and have their own policies. That is a deliberate design choice rather than an oversight: the point of the page is that the deciding fact comes from somewhere with no relationship to Rm8tes, and a check we performed for you privately would prove much less.

Changes to this policy

If we change this policy — for example because the app gains new features — we will update this page and change the date at the top. For significant changes we will let you know in the app before they take effect.

Contact

Questions, requests, or complaints about privacy: rm8tes@gmail.com

← Back to home