Privacy Policy

Version 8 · Last updated October 16, 2026

Effective from November 16, 2026

0. In short

• Ruslan Zykun, a natural person in Leipzig, Germany, operates Relocat and is the controller for the data described here.
• Your documents, their names and their types are encrypted on your device before they reach us, and we cannot read them.
• Not everything is encrypted. Your email address, your device records, request logs, your onboarding profile and anything you publish on the Community Map are readable by us.
• We hold wrapped key material and backup blobs for you, sealed with keys we do not have.
• Features you switch on separately include crash reports, the AI assistant, the Community Map and sharing your progress with an advisor.
• Outside providers help us run the Service: Contabo GmbH for hosting, Contabo GmbH for object storage, Scaleway SAS for transactional email and Google for push notifications.
• We keep most data for as long as your account exists and delete it when you delete the account. Section 7 lists every exception.
• You can ask for access, correction, deletion, restriction and portability. You can also object to processing we base on our legitimate interests.
• You can complain to Sächsische Datenschutz- und Transparenzbeauftragte, Maternistraße 17, 01067 Dresden.
• Write to privacy@relocat.org about anything in this policy.

1. Who we are

Ruslan Zykun operates Relocat as a natural person in Leipzig, Germany. Ruslan Zykun is the controller for the processing described in this policy (Art. 4(7) GDPR).

We publish our postal address and the other identification details German law requires on the imprint page at https://relocat.org/imprint/.

You can reach us at privacy@relocat.org. We answer data protection questions at that address.

We are appointing a data protection officer. We will publish their contact details here and report them to the supervisory authority.

2. Scope, definitions, age

This policy covers the Relocat mobile app, the browser session app at /app/ and the guest page at /g/. It also covers the pages on our website and the API the app talks to. It does not cover services you connect yourself, such as an AI provider you choose.

Your vault is the encrypted store of your documents. It lives on your device and is copied to our servers as ciphertext. A device is one installation of the app that holds keys and is registered to your account. The Community Map is an optional feature that publishes a name, a city and an optional photo to other signed in members.

What is encrypted and what is not

Your document contents, their file names and their document types are encrypted on your device with keys we never receive. We store them as opaque blobs.

The following are not encrypted and are readable by us: your email address, your device records, request and security logs, sharing relationships and access records and your onboarding profile. So are your storage usage, your permission settings and everything you publish on the Community Map, including a photo.

Your private keys never leave your device in the clear. Wrapped copies of key material do reach our servers. They are sealed with keys derived on your device from your own secret, and we do not hold those keys.

Age

The Service is offered only to people aged 18 or over. It is not directed to children and we do not seek data about them. If we learn that a registered user is below that age, we delete the account and its data.

3. What we process and why

Each subsection below is one category of data. The table states the data, the purpose, the legal basis, the retention period and the recipients. The text around the table adds the detail the table cannot hold.

3.1 Account

We ask for an email address and nothing else about your person at registration. We store no name, no telephone number and no postal address for the account.

We store the one time codes we send to sign you in while they are valid, and delete them with the account.

Deleting your account deletes these records at once.

3.2 Devices, keys and backups

Your app signs every request it makes with a private key that stays on your device. We store the matching public key. The device identifier is derived from that public key rather than chosen by the app.

We also store wrapped key material for you. This includes your wrapped user root key and its salt, your wrapped sharing key, a wrapped one time prekey escrow blob and your signed prekeys. If you register a server side backup, we store the salt for the key derivation, the size, a verification tag and the encrypted backup blob. None of this is readable by us.

When you link a second device or transfer an account, a link payload and relay messages pass through our servers. Browser sessions are separate short lived records.

An assisted key recovery feature exists in the code and is not active in current releases. Switching it on would place an additional key share on our servers. We will update this policy before we switch it on.

3.3 Requests and security logs

Our legitimate interest is keeping the Service available and free of abuse (Recital 49 GDPR). An IP address in a server log is personal data, and we treat it as such.

We do not truncate or mask the IP address in these logs. An earlier version of this policy claimed truncation. That claim was wrong and we removed it.

Our web server access log rotates sooner than the ceiling in the table. Application logs sit in the system journal under a size cap.

Before you agree to anything, the app asks our server whether registration is open and whether the server is healthy. Those two requests reach us with your IP address and user agent.

We never log the contents of your documents. We hold no key that would let us read them.

3.4 Vault content

The encrypted metadata holds the file name and the document type. The size does not travel inside it. It travels beside it as a coarse size bucket that we can read.

We cannot read the contents of your documents or their names. We hold no decryption key for them, so we cannot produce them to anyone who asks.

We do see the operational fields listed in the table. They let us route, sync and account for your data without reading it.

When you delete something, a tombstone records the deletion so your other devices learn of it. Tombstones carry an entity identifier and a type, and they are deleted with your account.

The app can scan a document with your camera. The scanner is a Google Play services module that runs on your device. The scan goes into your encrypted vault. What that module reports to Google is governed by Google's own terms.

3.5 Sharing and guest links

We see who shared with whom. Both sides of a share are accounts with email addresses, so a sharing relationship is not anonymous to us.

We also see when a share or a guest link was opened. The access record has a country field that we do not populate. It is always stored as a placeholder value.

A daily task deletes access records automatically after 90 days. They are also deleted when the grant or the guest link they belong to is deleted.

If you open a guest link you may not be a Relocat user. A short notice on the guest page explains what we log about that visit and why (Art. 14 GDPR).

3.6 Onboarding profile

This profile is stored in plain form. We can read it.

The date of birth is optional. Where you give us a field that the Service does not need, we process it on your consent (Art. 6(1)(a) GDPR). You can withdraw that consent.

3.7 Push notifications

The app registers a token with Google Firebase Cloud Messaging and sends that token to us. Obtaining the token makes your device and app installation known to Google. Every push we send passes through Google.

Google keeps installation identifiers until we call its deletion interface and for a further 180 days after that.

We record whether a notification was delivered, read and dismissed. We send no promotional push messages. If we ever wanted to, we would ask for your consent first.

Where the law requires your permission before an application may store or read information on your device, we rely on the notification permission you grant your operating system (§ 25 TDDDG).

An operator can address a broadcast to a group, for example by role or by journey state. The description of that group is stored with the notification.

3.8 Crash reports

You choose whether the app sends crash reports. When you set the app up, it asks you once whether to send them. "Not now" leaves the question open. In Settings then Privacy you pick one of three options: send automatically, ask each time, or don't send. Nothing is sent unless you choose "Send automatically". That choice takes effect the next time you open the app. Switching away from it takes effect at once. Until you choose, the app behaves as if you had chosen "Ask each time". In this version, "Ask each time" sends nothing. After the app closes unexpectedly it may ask whether you want to turn on automatic sending. It asks at most twice, never twice for the same app version, and not after every crash. Each time you pick "Ask each time" in Settings after having chosen something else, it may ask up to twice more. Version 1.0.26 offered a single on/off switch instead; a choice made there carries over (on becomes "Send automatically", off becomes "Don't send"). Versions before 1.0.26 started crash reporting on by default and send reports until you switch it off; if you still run one of those, check Settings then Privacy. Once you update, that pre-set "on" is not treated as your choice and does not carry over; you are treated as not having chosen yet. An "off" you set yourself in those versions is kept as "Don't send".

A crash event carries the device model and a model identifier for it, and the device's hardware architecture; the operating system name and version; the app version and build; the error type and the stack trace, including the stack traces of the app's other threads at the moment it happened; technical identifiers for the app's code libraries, used only to decode the stack trace, with any file name in them reduced to its base name; a short technical label for where it happened — an error reference code, the startup step reached, and, if the app had frozen, which operation stalled, for how long, and whether it recovered; and report bookkeeping: a random report id, a severity level, the platform, the SDK name and version, the app's release and build (the same version and build named above, repeated for our bookkeeping), the environment it ran in, and a count of reports the app discarded before sending. It also carries the time it happened. It carries no identifier for you or your device, no locale or timezone, no breadcrumbs or activity trail, and no document names, no file paths and no document content.

While "Send automatically" is chosen, the app also sends a record of each app session to the same monitoring server: one when you open the app, and a new one each time you return to it after it has been in the background for more than 30 seconds. That record holds a random session id, the start time, the time of its last update, how the session ended, how many errors it saw, how long it ran, the app version and the environment. The crash reporter attaches a random per-installation identifier to that record on the way to us; the relay removes it and does not keep it, so the record our monitoring server holds carries no identifier for you or your device.

Crash events go to a relay we run and from there to a monitoring server we run. Both are operated by us, so no separate analytics company receives them. The relay counts submissions per IP address to stop flooding, and it drops any field not listed above before a report reaches our monitoring server. The relay also keeps a daily count, per app version, of app sessions started by apps with "Send automatically" chosen. The count holds no identifier, IP address or link to any device or account, and we use it only to see how widely crash reporting is switched on.

An earlier version of this policy said that current releases transmit no crash reports. It also said that the local diagnostics log stays on your device only. Both statements were wrong when they were published. Version 7 then described a single on/off switch and a crash event that carries your locale, the runtime version, hardware details and breadcrumbs. That is what releases before 1.0.27 sent. The app no longer puts those fields into the reports it builds itself. Where the crash reporter's operating-system layer still attaches them to a report of a freeze or a native crash, and in anything an older release still sends, the relay has dropped them since 25 September 2026 before the report reaches our monitoring server. This section replaces all of those statements.

3.9 AI assistant

If you connect an assistant over the Model Context Protocol, we log which tool was invoked, when, which data category it touched and what the result was. We store a signed receipt for each approval you grant. Neither record holds file contents or file names.

The provider you connect receives only the metadata categories you approved. You choose that provider and direct what it receives. Your agreement with it governs what it then does. You can revoke its access at any time. Every revocation is recorded.

We keep receipts for 13 months because we must be able to demonstrate the consent you gave (Art. 7(1) GDPR). If you ask us to delete your activity log while keeping your account, the receipts keep running down that same 13 month clock. Deleting your account deletes both at once.

Two features in the code would let our server read a working set of your document types and expiry dates under a grant you give. Neither is active in current releases. We will update this policy before we switch either on.

3.10 Privacy permissions

Your privacy switches are stored as a matrix of permissions on our servers. Each cell pairs a class of party with a category of data.

Every decision and every change is written to a hash chained log that we cannot rewrite. Our legitimate interest is being able to show, later, what was allowed and when.

In releases published from the effective date of this policy the onboarding privacy step presents these permissions switched off. Earlier releases presented them switched on and wrote them when you tapped Continue. You can change any of them in Settings then Privacy. Turning one off stops the processing it allowed.

Community sharing is one of those permissions. The feature that would use it is not active in current releases. If we switch it on, it will create one record per event linked to your account. We will update this policy before that happens.

3.11 Community Map

Your display name, your city and your photo are stored in plain form so that other signed in members can see them. They are not part of your vault and no zero knowledge guarantee covers them.

The city comes from a list you pick from. The Community Map never uses your device location. When you open the city picker, the app fetches country and city lists from us. That tells us which country you are browsing before any profile exists.

A city appears on the map only once at least five members have chosen it.

Your profile is deleted immediately and permanently when you leave the map or delete your account. A ledger of your city changes is kept for seven days so that we can enforce a daily change limit.

Moderation records cannot rest on your consent, because a suspended member would withdraw it. We keep them on our legitimate interest in running a map that is safe to use. A suspension record names the moderator who acted, carries their note and records who lifted it. Suspension records and reports are kept for as long as your account exists and are deleted with it. Every moderation action is also written to an operator side log that names the acting moderator.

A photo you add is stored unencrypted and reviewed by a moderator before anyone else can see it. Software produces advisory scores that a person reads. No decision about a photo is automated. A photo that is not approved, or that you replace or remove, is deleted at that moment.

A record of each decision about a photo you submitted is kept while your community profile exists. It is deleted when you leave the map or delete your account. It holds the outcome, the reason shown to you, the advisory scores and a digest of the image, never the image itself.

An upload that cannot be processed as an image is refused automatically, as is an upload that starts and never completes. These are technical checks, not decisions about you or about the picture.

Photos held as evidence

If a photo raises a suspicion of a serious criminal offence, we place it in quarantine and prepare a report. The Digital Services Act requires a hosting provider that becomes aware of such information to inform the authorities promptly (Art. 18 DSA). Our legal basis for keeping the image at that point is our legal obligation. It overrides your erasure request for as long as the obligation lasts (Art. 6(1)(c) and Art. 17(3)(b) GDPR).

The report goes to the law enforcement or judicial authorities of the Member State concerned. In Germany the receiving body is the Bundeskriminalamt. We hold such an image only to hand it over, and for no other purpose.

Every hold carries a review date, set 30 days after it is opened. Extending it needs a recorded reason. An overdue hold is flagged to us until it is closed or extended. When the hold is closed, the photo is deleted.

A record that the hold existed is kept after the photo is gone. It holds the dates the hold was opened and closed, the stated ground and the reasons for any extension. It also holds the moderators' notes, any advisory scores and a digest of the photo. We keep that record for three years after the hold is closed. Where a criminal complaint was made about the image, we may keep it for as long as that offence can still be prosecuted. We keep such a record only where the law allows a private controller to record a suspected offence.

When your account is deleted, we remove the links from that record to your account. The record still holds a digest of the image and the moderators' notes. That is why it remains personal data about a person who can be identified with the original file. We do not describe it as anonymous.

If we restrict or remove something you published, we must give you a statement of reasons. It must explain the measure, the facts behind it, the ground for it and how to challenge it (Art. 17 DSA).

3.12 Advisors and the PRO program

If you accept an advisor, we store a consent record for that one relationship. It holds when you granted, declined or revoked, and when the advisor last looked at what you shared. An advisor sees only what you approved, and only while your consent stands.

We store the invitation tree, which records who invited whom, and the history of any bonus attached to it. A person who registers as a PRO also gets a profile with a display name, a professional title, a company name and public contact details. They also get a log of status changes. Endorsements between a PRO and a client are stored with their attachments.

Consent records, profiles and endorsements are deleted when the account they belong to is deleted. There is no earlier purge.

Revenue, commission, payout and bonus rows are treated differently. We keep them after an account is deleted, with the references to that account removed. We keep them for as long as we need to account for a payment that was made. No money moves in the open test.

Where an advisor undertakes to place you in employment, German law makes the placement records business records. Those records must be kept for three years after the placement activity ends (§ 298(2) SGB III). Where that applies, the statutory period replaces the retention above. Placement data may be passed on only with your consent in the individual case (§ 298(1) SGB III).

3.13 Storage accounting

We compute your usage from the sizes of what you upload. We do not read what you uploaded to do it.

3.14 Trust and security events

Our legitimate interest is protecting your account and the Service. Trust events are written once and are never edited. They are deleted with your account.

3.15 Support and staff surfaces

We run no helpdesk today, and no support tool of ours can see your account.

We do process data about the people who operate Relocat. Staff accounts, their two factor secrets and their sign in attempts are stored for the admin, moderator, partner and editor panels. Every change to a system setting is written to an audit log that cannot be deleted. Moderator actions on the Community Map are logged with the moderator's identity.

Those records are about our staff, not about you. They appear here so that the picture is complete.

Our server also carries modules for features that no released app can reach. They hold no data about you while they stay unreachable. We will update this policy before we make any of them available.

4. Legal bases in one list

• Contract (Art. 6(1)(b) GDPR): your account, your devices and key material, your vault, your onboarding profile, your permission matrix, storage accounting, invitations and service notifications. Without these we cannot deliver the Service you registered for.
• Legitimate interests (Art. 6(1)(f) GDPR): request and security logs, share and guest access records, trust and security events, Community Map moderation records, and the flood protection on the crash relay. Our interests are security, abuse prevention, incident response and a map that is safe to use. We weighed them against your rights, kept these records to what the purpose needs and set the periods in section 7.
• Consent (Art. 6(1)(a) GDPR): crash reports, the AI assistant, the Community Map and its photo, sharing your progress with an advisor, and any optional profile field you choose to give. You can withdraw consent at any time. Withdrawal is as easy as giving it and stops future processing without affecting what was lawful before (Art. 7(3) GDPR).
• Legal obligation (Art. 6(1)(c) GDPR): keeping a quarantined photo to report it to the authorities (Art. 18 DSA), producing an item to an authority that orders its surrender (§ 95 StPO), and keeping placement records where an advisor brokers employment (§ 298(2) SGB III).

Providing your email address is a contractual requirement. Without it we cannot create an account. Everything under consent above is genuinely optional, and refusing it costs you nothing but that feature.

5. Recipients and processors

We use these processors to run the Service:

• Contabo GmbH, hosting. Every plaintext operational record described in section 3 sits on servers this provider operates for us.
• Contabo GmbH, object storage. Vault ciphertext, backup blobs and Community Map photos are stored there. Vault content is opaque to them. A Community Map photo is not. It is stored in plain form.
• Scaleway SAS, transactional email. It receives your email address and the content of the message to deliver it for us.
• Google, push notifications through Firebase Cloud Messaging. It receives your registration token and the notification we send.

Each of these acts only on our instructions. Art. 28 GDPR requires a written processing agreement with each of them.

Our crash relay and our monitoring server are operated by us, so they are not separate processors. Both run on servers of the hosting provider named above.

These further recipients are not processors:

• The AI provider you connect. It receives only the metadata categories you approved, and you decide what those are.
• An advisor you approved in the partner program. They see the progress data your consent covers.
• Law enforcement and judicial authorities. They receive data when we report a suspected offence that threatens life or safety (Art. 18 DSA). They also receive data when an authority lawfully orders us to produce something we hold (§ 95 StPO). We cannot produce vault content, because we cannot decrypt it.

We do not sell your data. We show no advertising. We use no third party analytics on any of our surfaces.

6. International transfers

Contabo GmbH holds vault ciphertext, backup blobs and Community Map photos in the European Union.

Hosting and transactional email are provided in the European Union. Vault content does not leave the European Union.

Push registration tokens reach Google in the United States. We rely on the European Commission's adequacy decision for the EU US Data Privacy Framework for that transfer, so far as it covers that recipient (Art. 45 GDPR). If you are in Switzerland, this is the transfer you should know about (Art. 19(4) FADP).

7. Retention overview

Where a table row says "while your account exists", there is no automatic purge before that point. Deleting your account is what ends the retention.

8. Your rights

You have these rights over the personal data we hold about you:

• Access (Art. 15 GDPR): a copy of the data we hold about you.
• Rectification (Art. 16 GDPR): correction of data that is wrong.
• Erasure (Art. 17 GDPR): deletion of your account and its data.
• Restriction (Art. 18 GDPR): a pause on processing in the cases the article lists.
• Portability (Art. 20 GDPR): the data you gave us, in a machine readable form.
• Objection (Art. 21 GDPR): see the box below.
• Withdrawal of consent (Art. 7(3) GDPR): at any time, as easily as you gave it, without effect on what was lawful before.

Write to privacy@relocat.org to exercise any of them. We answer within one month of receiving your request. If a request is complex, or if you send several, we may take up to two further months. In that case we will tell you within the first month that we are extending, and why (Art. 12(3) GDPR).

We have no self service export today. We answer a portability request by hand and send you what we hold.

Deleting your account is available in the app. The delete account page explains both routes and what survives deletion.

Your right to object

You have the right to object at any time to processing we base on our legitimate interests (Art. 21(1) GDPR). That covers our request and security logs, our share and guest access records, our trust and security events, and our Community Map moderation records.

We are required to bring this right to your attention clearly and separately from everything else. That is why it has its own box (Art. 21(4) GDPR).

If you object, we stop that processing unless we can show compelling legitimate grounds that override your interests, or unless we need the data to establish, exercise or defend legal claims. Write to privacy@relocat.org.

Complaints

You can complain to a supervisory authority (Art. 77 GDPR). The authority competent for us is Sächsische Datenschutz- und Transparenzbeauftragte, Maternistraße 17, 01067 Dresden.

That authority takes a complaint through its online form or by post. It does not accept a complaint under Art. 77 by email alone, because it needs your full name and postal address. You may also complain to the authority where you live or where you work.

9. Automated decisions

We take no decisions about you based solely on automated processing that produces legal effects or similarly significant effects (Art. 22 GDPR).

In the Community Map, software produces advisory scores that sort a moderation queue and draw a hint for the moderator. A score can never approve or reject a photo. A person makes every decision, and that person can and does overrule the score. Suspending a profile is always a decision by a moderator.

Some refusals are purely technical. The following are refused automatically: an upload in the wrong format, an oversized image, a corrupt file, a file that does not match what your app declared, and an upload that never completes. A signature that does not verify is refused automatically. These refusals decide nothing about you, and you can retry them.

10. Security and breaches

Your document contents, their names and their types are encrypted on your device before they reach us. We hold no key for them. This is the single most important security measure in the Service. It is why a compromise of our servers would not expose your documents.

We protect the rest with signed requests, rate limits, lockouts after repeated failures, hardened server configuration and separate panels for staff (Art. 32 GDPR).

If a breach of personal data occurs, we notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. We do not do this if the breach is unlikely to result in a risk to your rights and freedoms (Art. 33 GDPR).

We tell you directly when a breach is likely to result in a high risk to you (Art. 34(1) GDPR). We do not have to tell you individually where the affected data were encrypted so that they are unintelligible to anyone who obtained them (Art. 34(3)(a) GDPR). For vault content that exemption normally applies. For the plaintext categories in section 3 it does not.

11. Users outside the European Union

The Service is offered in English, worldwide, from Germany. This policy applies to everyone who uses it.

United Kingdom. We do not offer the Service to people in the United Kingdom, and our store listing excludes it. We have therefore not designated a representative under Art. 27 UK GDPR.

Switzerland. Your data is processed in the European Union, except for the push token described in section 6, which reaches Google in the United States. We have not appointed a Swiss representative, because we do not consider the conditions of Art. 14 FADP to be met at our current scale.

Brazil. The LGPD may apply to us because we offer the Service to people in Brazil. We have not named an encarregado, because Resolution CD/ANPD No. 2/2022 exempts small processing agents from that duty. That exemption applies as long as they publish a channel for data subjects. Our channel is privacy@relocat.org.

United States. We believe the Service does not meet the applicability thresholds of the California, Virginia, Colorado, Connecticut or Texas consumer privacy statutes. That is because it is free of charge, we have no revenue and we do not sell or share personal information. We will reassess that as the Service grows.

Canada. PIPEDA may apply to us where a real and substantial connection to Canada exists. We answer requests from users in Canada on the same terms as everyone else in section 8.

12. Changes to this policy

We change this policy when our practices change or the law requires it. Every version carries a version number and a date at the top of this page. Section 14 records what changed.

For a material change we tell you in the app and by email at least 30 days before the new version takes effect. A material change is one that affects you. That means a new purpose, a new category of data, a new recipient, a longer retention period or a change to your rights.

We give you information about a new purpose before the processing for that purpose begins (Art. 13(3) GDPR).

We do not treat your continued use of the Service as your acceptance of a new version.

13. Contact

For anything in this policy, including a request under section 8, write to privacy@relocat.org.

Our identification details are on the imprint page at https://relocat.org/imprint/.

For a report about content published on the Community Map, write to privacy@relocat.org.

14. Version and change log

• Version 8 (October 2026): Section 3.8 is corrected to what the app sends and to the three choices in Settings then Privacy: nothing is sent unless you choose "Send automatically"; the question asked at setup and the question asked after a crash are described; and the list of fields is the one the relay lets through, which no longer includes your locale, the runtime version, hardware details or breadcrumbs. Section 3.8 now also discloses the app session records (one per app start and per return from the background) that the same monitoring server receives while "Send automatically" is chosen; they were sent before but were not described. The crash retention is now stated as no longer than 90 days. Section 0 names each provider with its role instead of counting them, because one company can provide two of the services; the providers themselves are unchanged. Section 5 is reworded without a change of substance. Section 7's crash row now covers the app session records. Nothing else changes. An earlier text named Netcup GmbH as the hosting provider. That was wrong: the Service has always been hosted by Contabo GmbH. The name was corrected on 12 October 2026.
• Version 7 (September 2026): Rewritten against the code. Section 1 names the operator and points to the imprint for the address, and says that a data protection officer is being appointed. Section 3 replaces the old collection list with one table per category covering data, purpose, legal basis, retention and recipients, and adds the categories the earlier versions never mentioned: wrapped key material and server side backups, the onboarding profile, push notifications through Google Firebase, crash reports, the privacy permission matrix and its log, the invitation tree and the partner program, storage accounting, trust and security events, and staff surfaces. The false statement that current releases transmit no crash reports is removed and replaced by a description of what a crash event contains and how long it is kept. The storage processor and its region are corrected: earlier versions named the wrong provider and the wrong location. Google, the hosting provider, the email provider and law enforcement authorities are named as recipients, and the claim that no other third parties receive data is removed. Section 6 states the transfer of the push token to the United States and the basis for it. The request log retention is corrected downward and the access record country field is disclosed as unpopulated. Section 8 gives the right to object its own box, names the supervisory authority and states the one month response window and its extension. Section 11 addresses users outside the European Union. The evidence hold record now has a stated period of three years instead of no fixed limit, and is no longer described as unlinked from any person.
• Version 6 (September 2026): Sections 5 and 10 now say that a Community Map photo is held by the storage processor in plain form — only vault content is encrypted. Section 11 says where the photo is held; that a record of each photo decision is kept while your community profile exists; that the record of an evidence hold — but not the photo — is kept without a fixed time limit and is no longer linked to you once your account is deleted; that a hold carries a 30-day review date; and which technical checks refuse an upload automatically. The photo is now listed among the data outside end-to-end encryption, and Section 6's exception names the hold record. The "last updated" date at the top of this page, which had not moved since the first version, is corrected.
• Version 5 (September 2026): Section 11 describes optional photos on the Community Map: a photo you add is stored unencrypted on Relocat servers and reviewed by a moderator before anyone else can see it; software produces advisory scores that a person reads, and no decision is automated. A photo that is not approved, or that you replace or remove, is deleted at that moment. A photo held as evidence of suspected illegal content is kept until the incident is closed, even after your account is deleted — the one exception to the Community Map profile's otherwise-immediate deletion (Section 6). Listed the optional photo in Section 2 (what we collect).
• Version 4 (August 2026): Added Section 11 describing the optional Community Map: the display name and city you provide for it are stored in plain form, are shown to signed-in Relocat users, are not part of your encrypted vault, may be hidden by a moderator if reported, and are deleted immediately when you leave the map. No device location is used. Section 11 also states that a moderator's decision to hide a profile, and any reports you file about others, are kept until your account is deleted. Listed the Community Map in Section 2 (what we collect), Section 4 (consent) and Section 6 (retention).
• Version 3 (July 2026): Disclosed the transactional email delivery sub-processor; removed an inaccurate IP-truncation claim (request logs are retained as described in Section 6); share and guest link access records are now deleted automatically after 90 days; added an automated decision-making statement (GDPR Art. 22); aligned the rights-response window with the statutory one month.
• Version 2 (July 2026): Disclosed the optional AI-assistant activity log and signed consent receipts (13-month retention), community signals, and the current no-crash-reporting status; distinguished user-directed AI recipients from our sub-processors; moved operator identification to the Imprint page; aligned log-retention wording at 90 days everywhere.
• Version 1 (April 2026): Initial policy.