Privacy notice

Who is responsible for your data

The data controller is Hossein Bagherzadegan Talkhouncheh, a natural person in Berlin, Germany, trading in their own name under the business designation NextTrace. NextTrace is not a company and cannot be a controller: the responsibility is the named person’s. Full provider details are on the Impressum.

Contact for privacy questions: privacy@riluno.org.

No Data Protection Officer is appointed, and that is a position rather than an omission. § 38 Abs. 1 BDSG requires one where at least twenty people are regularly engaged in automated processing — Riluno has none — or where the processing requires a data protection impact assessment. Riluno does not yet run the recommendation feed that would trigger the second limb. When it does, that assessment is due, and an officer with it.

What Riluno collects today

This is a factual statement about the deployed build, not a forward promise.

Anyone can create an account. You do not need one to watch: an account exists so you can report content and manage your own data. Creating one means giving an email address and choosing a password, and confirming the address with a six-digit code we send to it.

An account does let you upload, from the website and from the Riluno app. Uploading is not publishing: what you send goes to a safety check and then to a moderator, and nothing you upload is visible to anyone until a moderator approves it. Publishing remains a capability an operator grants deliberately, and no account you create yourself carries it.

In the Riluno app you can sign in with Apple or with Google instead of a password. This website has no such button — here it is an email address and a password. When you use a provider in the app, it tells Riluno a stable identifier for you and, if you allow it, your email address. Riluno verifies what they send against the provider’s own signing keys and stores three things: which provider it was, that provider’s identifier for you, and the address — and the address only when the provider has confirmed it is yours, so that an unproven one can never be matched later as if it were proof. That is what lets the same sign-in find the same account next time. Riluno never receives your Apple or Google password, and the provider is told nothing about what you watch.

The first time you sign in with a provider there is no Riluno account yet, so the app asks the same two questions the sign-up form asks: your date of birth, and your agreement to the terms and the community guidelines. Both are asked once, to create the account. The date of birth is checked and thrown away — it is described under “Children” below. Your agreement is recorded, and is described in the list that follows. Signing in again later asks for neither.

Apple’s “Hide My Email” gives Riluno a relay address rather than your own. That works normally here and Riluno treats it like any other address; it is the only address Riluno will have for you.

If the address a provider gives already belongs to a Riluno account made with a password, Riluno asks for that password once before connecting the two. It does this so that losing control of an Apple or Google account does not by itself hand over a Riluno account.

This section is enforced rather than merely true. Riluno refuses to start with accounts enabled unless whoever enabled them confirms this notice was updated first, so it cannot quietly go out of date while accounts come online behind it.

Your account: the email address you sign in with, a hashed password — never the password itself, and it cannot be recovered from what is stored — the roles the account holds, and two Riluno-generated identifiers for it. The identifiers are random, so they say nothing about when you joined or how many people are here.
A provider sign-in, if you use one: the provider you chose (Apple or Google), the identifier that provider uses for you, and the email address it confirmed is yours. Nothing else the provider offers is kept — no name, no profile picture — and the identifier is provider-scoped, so it is meaningless anywhere else. Where Apple gives a relay address instead of your own, that relay address is what is stored.
The name a passkey shows on your own device: when you sign in, the answer Riluno sends back carries the address you sign in with, so that the app or the browser can list your passkey under your email rather than under an internal account id in the chooser you pick from. Nothing new is collected here: it is your own address going back to you, on a request where you have just proved the account is yours, and the label it sets is written into your own device’s credential manager and nowhere else. An account Riluno cannot name is sent no name at all rather than an empty one.
That you accepted the terms: when an account is created by signing in with Apple or Google, Riluno records which version of the terms and which version of the community guidelines you agreed to, the moment you did, and that it happened at sign-up rather than later. The versions are the dates those published texts carry, so a record can be checked against the page’s own history. It is evidence of an agreement, not a setting: a row is written once and never edited, and agreeing to a later version adds a row rather than replacing one. It is deleted with your account. The password sign-up form does not yet write this record.
Your date of birth: not kept at all. Both doors — the sign-up form and a first provider sign-in — ask for it, and it is read once to work out whether you are 16. No record carries it and nothing logs it. See “Children” below.
A pending sign-up: while you are confirming your address, Riluno holds a hash of the six-digit code, not the code, for fifteen minutes. It is discarded once used, once expired, or after five wrong attempts — and it does not survive a restart of the service, in which case you would ask for a new code.
Email we send you: a confirmation code when you sign up. If someone tries to register an address that already has an account, Riluno writes to that address to say so — that message goes to the account holder, and it is how you would find out. Sending is handled by the processor named below, which receives your address in order to deliver the message.
Uploaded media: any confirmed account can upload video, from the website and from the Riluno app. The file goes directly to Riluno’s object storage — described under “Who else sees your data” below — and Riluno holds the caption and topic you typed alongside it. Uploading is not publishing: what you send is checked and then waits for a moderator, and it is visible to nobody until one approves it. In the app, choosing a video uses your phone’s own picker, which hands Riluno the single video you select and nothing else — Riluno asks for no access to your photo library and cannot see the rest of it.
Who you have chosen not to see: when a signed-in viewer blocks a creator or a channel, Riluno records three things against that account — what kind of thing it was, which one, and the moment it happened. No reason, and nothing about what prompted it. The record is written when you block and removed when you lift the block; blocking the same thing again is the same block and does not move the time, because when you decided is the part that is evidence. Riluno applies your blocks to every session and every playback request you make, so the decision outlives the phone it was made on instead of being lost to a reinstall or missing on a second device. It is in the data export you can ask for, and it is deleted with your account. On the phone this still works differently. The Riluno app keeps its blocked list in the device’s own secure storage and sends it with each request; it does not use the account-level list at all. That device list is what lets you block while watching without an account, which is how most people watch.
Who you follow: the same three things in the same shape — what kind of thing you followed, which one, and the moment — recorded against your account when you follow and removed when you stop. It does one job: it pre-fills a viewing session with work from the creators and channels you chose. No feed is built from it, and there is no route anywhere that lists who follows somebody — a follow is private to the person who made it, so it appears in their own listing and their own export and in nobody else’s. What a creator can see is a count of the accounts following one of their own channels, on their own page and never publicly, and that count is left out entirely below ten rather than shown as a small number: a creator watching a count of three move would learn which individual had arrived. Your follows are in your data export, and deleted with your account — and because the records go, you stop being counted in anyone’s follower count. The Riluno app has no follow in it yet, on the phone or anywhere else; this describes what the service records for a client that offers one.
Analytics and tracking: none. Riluno loads no third-party script, sets no advertising identifier, and uses no cookie for tracking. This describes the service as deployed today. Advertising and a paid subscription are planned — both are described under “Advertising and subscription” below, and neither is in effect yet. This line will change in the same release that introduces them, not afterwards.
Riluno application logs: Riluno records a line for every failed request — its method, path, HTTP status, response time, a caller address, and a correlation id. Successful requests are recorded only at debug level, which the deployed service does not emit, and health checks are not recorded at all. Riluno also logs a refused sign-in, an internal error, a recovered panic, and a moderation-provider fault. The correlation id is generated unless you supply a valid X-Request-ID header, in which case yours is used. Query strings, request bodies, credentials, and session tokens are never logged.
About that caller address: it is your IP address, as our content-delivery network passes it on. Riluno reads it so that limits on abuse — too many sign-in attempts, too many reports — apply to the person sending them rather than to everyone at once. It appears in the failure log lines above and is kept only as long as those logs are (see “How long it is kept”).
If you report a video or a comment without an account: Riluno does not store your IP address with the report. To stop the same person filing the same report repeatedly, it stores a one-way code computed from your address and the date, with a secret key that is replaced whenever the service restarts, so the code cannot be turned back into your address and cannot be matched across days. It also keeps daily totals of reports with no personal data in them. If you report while signed in, the report is linked to your account instead.
Hosting platform logs: our hosting provider records ordinary web request logs, which include your IP address. These are the provider’s logs, not Riluno’s, and they exist for every visit to this page.

What Riluno will collect when the product operates

Stated as intent, and not yet in effect. Each item below depends on a decision that has not been made, and the notice must be updated to describe the chosen answer before any of it happens.

Two entries were removed from this list because they are no longer forward-looking: uploaded media with its caption and topic, and the safety-review result recorded for it, are both collected today and are described in the section above. A notice that files live collection under “one day” is inaccurate in the direction that matters.

Session records, so a session can be ended immediately when you sign out. Ending every session for a restricted account is intended but not yet built.
Measurement data: none. Riluno measures nothing about you — no analytics, no events, no identifiers. Any future measurement is governed by a plan (ADR-010) that is still proposed rather than adopted, and which requires every event to be justified, minimised and given a retention decision before it may be collected. If that plan is adopted, this notice changes first.

Why Riluno may process it, and on what legal basis

Riluno processes personal data for seventeen purposes. Each was read out of what the software actually does rather than described in the abstract, and each rests on one of four bases in Article 6(1). There is no consent anywhere in this list, and that is deliberate: Riluno runs no analytics, sets no advertising identifier, loads no third-party script, and uses no tracking cookie. The only cookie is the session cookie, which is strictly necessary for a service you asked for and is therefore exempt under § 25 Abs. 2 Nr. 2 TDDDG. A consent banner here would be theatre.

Serving a viewing session and delivering the media — Art. 6(1)(f), legitimate interests. Watching needs no account and no identification; the route that serves a session requires no credential.
Creating and holding your account — which includes the provider identity you sign in with and the record of the terms you accepted in order to have the account at all — confirming your address, accepting your upload, comments you write, and changing your own password — Art. 6(1)(b), performance of the contract you entered when you asked for an account.
Remembering who you have blocked and who you follow — Art. 6(1)(b), and a block also Art. 6(1)(f). Both are choices you asked Riluno to keep for you, which is the account you entered into. A block rests on legitimate interests as well: a viewer being able to make somebody go away and have it stay gone is Riluno’s own interest in a service people can stand to use, and it is what both app stores require of it.
Telling an address holder that someone tried to register it — Art. 6(1)(f). The message goes only to the address itself, so the person who holds it learns of an attempt on it.
Checking you are at least 16 — Art. 6(1)(c), read with Art. 8 GDPR.
Scanning an upload before anyone sees it, human review and the recorded approval, and acting on reports — Art. 6(1)(c) and 6(1)(f). The DSA requires a notice-and-action mechanism and requires decisions to be attributable; the safety check is also Riluno’s own interest in not publishing prohibited material.
Deleting your account and exporting your data — Art. 6(1)(c). These are Articles 17 and 20 being performed.
Application logs — Art. 6(1)(f), to keep the service working and to investigate faults.

Every purpose resting on legitimate interests carries a written balancing test. The full purpose-by-purpose mapping, including those tests, is held as an internal record under Article 30 and is available to a supervisory authority on request.

Special categories of data (Article 9)

Riluno never asks for a special category of data. But video of people inevitably reveals some — health, ethnicity, religious dress, sexual orientation, political opinion — and a short-video service cannot honestly claim Article 9 is out of scope.

Riluno’s position is that it does not process special categories as such: it stores video without inferring anything from it, runs no biometric identification, performs no face recognition, and has no recommendation model deriving traits from what you watch or upload. That is a statement about how the system is built, and it is checkable against the rest of this notice.

This position is provisional and under legal review. The case law is not settled, and the reading above is stated here so that it can be challenged rather than left unwritten. It is not offered as a settled legal conclusion.

It also does not cover somebody who appears in a video without having chosen to. Riluno’s community guidelines require an uploader to have the agreement of identifiable people in what they post, and enforcement and appeals explains how anyone — including someone who never used Riluno — asks for such a video to be taken down.

One purpose can be stated with confidence because it is built into the product: uploaded media is scanned for prohibited content before it can be published. Riluno cannot publish media that has not passed that check.

Decisions made automatically

Media is scanned automatically before it can be published. The scan cannot decide anything on its own, in either direction, and that is the whole of the answer to Article 22.

The logic is a classifier that scores media against a published policy and a set of thresholds. If it finds nothing, the video still goes to a person, and only that person can publish it — a creator cannot publish their own upload. If it finds something it considers prohibited, the video also goes to that person, carrying what the scan concluded, and the refusal only stands once they confirm it. Where no scanner is configured at all, everything reaches the same person.

So there is no path on which software alone decides that something you made will not be seen. Every refusal is made by a human being, and every publication is approved by one. This is enforced in the software rather than promised here: the policy engine has no way to return a refusal at all, and refusing is a separate action available only to a signed-in reviewer.

This paragraph described the opposite arrangement until 20 August 2026, and it was accurate at the time: a confident classifier hit refused publication outright, with nobody in the loop. It is recorded rather than overwritten because a privacy notice that silently improves its own history is not a record of anything.

One thing genuinely is decided without a person, and it is not a judgement about you: an upload is refused immediately if the file is too large, too long, or not a video format Riluno accepts. That is a check on the file, not on what it contains or on who sent it, and the answer is the same whoever uploads it.

If your upload is refused and you want it looked at again, write to privacy@riluno.org. A person has already seen it by then; this is the route to a second person.

Whether you have to give us anything

To watch, nothing. No account, no email address, no name. That is the product’s central claim and it is enforced by the software rather than promised here: the route that serves a session requires no credential at all.

To create an account you must give an email address and choose a password, and you must confirm the address with a code sent to it. The address is required because it is how you sign in and how Riluno reaches you about your own account; declining it means you cannot have an account, which costs you the ability to report content and to manage your own data through the site.

In the app you can create the account with Apple or Google instead. That asks for no password, but it does require the same two things every new account requires: a date of birth, which is checked and not kept, and your agreement to the terms and the community guidelines, which is recorded. Declining either means no account is created.

To upload, you additionally need a creator capability that an operator grants; the video and the caption you write are then required, because they are the thing being published.

This section previously said that nothing here asks for personal data and that there is no account to create. Both had stopped being true, and the same page said so two sections higher.

People who appear in someone else’s video

When uploads exist, Riluno will hold video that contains people who never used it and never agreed to anything. They have the same rights as everyone else here, and reaching them individually is usually impossible, which the GDPR anticipates.

You do not need an account, and you do not have to identify yourself. Every video has a report control that is available without signing in, and “someone in this video did not agree to be in it” is one of the reasons you can give. A report opens a case for a human reviewer in the same queue as everything else, and it survives a restart — it is not held in memory and forgotten. You can also write to privacy@riluno.org if you would rather not use the form or want a reply.

Riluno cannot tell you who uploaded a video, and will not, because that is someone else’s personal data. What it can do is take the video down.

What Riluno does not do is contact you when your face appears in somebody else’s upload. It has no way to: it does not run face recognition and does not intend to, since building the ability to find you in other people’s videos would be far more invasive than the problem it solves. Article 14(5)(b) covers this — telling everyone who appears in a video would be impossible or disproportionate — and this notice being public is the substitute the GDPR asks for in that case.

Who else sees your data

DigitalOcean hosts Riluno’s web and API services in Frankfurt, terminates TLS for this site, and holds platform request logs that include your IP address. That is true of your visit to this page right now. DigitalOcean also provides the object storage and content-delivery network that serve Riluno’s media files, so a request for a video reaches DigitalOcean directly rather than through Riluno.

Cloudflare operates DNS for riluno.org and runs the mail forwarding for addresses at this domain. Cloudflare answers the lookup that finds this site, and it handles email you send us. It does not sit in front of the site’s traffic: page requests go to DigitalOcean, not through Cloudflare.

Cloudflare forwards rather than stores: mail sent to an address at this domain is delivered onward to a Google (Gmail) mailbox, which is where it is actually read and kept. So if you write to us — including to exercise a data-protection right — your message and your address are held by Google in the United States. This is said plainly because a notice that named only the forwarder would describe the pipe and not the destination, and the destination is the part that holds your message.

Better Stack receives Riluno’s application logs so faults can be diagnosed, carrying the caller address described above, which is your IP address. They are sent to an ingest endpoint in the EU, over an encrypted connection, and Riluno refuses to send them unencrypted.

Postmark — contracting entity AC PM LLC, part of the ActiveCampaign group — sends email on Riluno’s behalf from this domain. It carries the address of anyone it writes to. Today that is sign-up confirmation codes, and the notice sent to an address someone else tried to register. Riluno turns off open tracking, so no per-recipient pixel is embedded to record whether you opened one. The legal counterparty is named here rather than the product brand, because “Postmark” is a brand and an accurate record has to name the company you would actually be dealing with.

Beyond those five there is no analytics vendor, no advertising network, no media provider, and no content-moderation provider. An advertising network is planned and is not connected yet; when it is, it will be named here, in this list, before it receives anything.

Advertising and subscription

Stated as intent. Neither is in effect. Riluno shows no advertising today and sells nothing today. This section is published ahead of the change so that the notice does not arrive after the collection does.

When advertising is introduced, it will appear only on the screen where you choose a session and on the screen that ends it— never during a video. That is a product boundary, not a courtesy: a session that can be interrupted is not a session that ends when you said it would.

Advertising means a third party processes personal data, so it needs your consent, and consent means a real choice. Riluno will ask before the advertising code loads at all — not after it has already run. Declining is a supported answer: you will still get the app, with non-personalised advertising or none. There will be no “consent-or-leave” wall, and withdrawing consent later will be as easy as giving it.

Nobody under 16 will be shown personalised advertising. Under Article 8 GDPR, sixteen is the age at which a person can consent to this on their own behalf in Germany, and Riluno will not ask a child for a consent they cannot give.

A paid subscription will switch advertising off. Whether an account has paid is decided by Riluno’s server after asking Apple or Google — the app on your device never decides it, and no advertising identifier is used to determine it. Payment itself is handled entirely by the App Store or Google Play: Riluno never sees your card, and receives only the confirmation that a subscription is active and when it expires.

Of those five, Better Stack is established in the European Union (Prague, Czech Republic), so the logs it receives involve no transfer out of the EU at all. The other four — DigitalOcean, Cloudflare, AC PM LLC, and Google — are United States companies, so sending them data is a transfer to a third country and needs a lawful basis for that transfer.

Google is not in the same position as the other three, and saying so matters more than tidiness. DigitalOcean, Cloudflare and AC PM LLC each provide a data-processing agreement written for exactly this purpose. The mailbox does not: it is an ordinary consumer Google account, used under consumer terms, with no processing agreement, no documented instructions, and no audit right running to Riluno. That is a real gap rather than an oversight, and it is recorded here rather than left out because a notice that lists only the comfortable processors is not a notice. It is accepted deliberately while Riluno has no accounts and no users, and it has to be closed before it does.

The transfer basis is the EU-U.S. Data Privacy Framework, for all three. Each was checked against the register the U.S. Department of Commerce maintains — not against the company’s own marketing page, which is not evidence of anything — on 20 August 2026:

DigitalOcean, LLC — participant 5296, EU-U.S. DPF Active, certified since 6 February 2017, next certification due 3 March 2027.
Cloudflare, Inc. — participant 5666, EU-U.S. DPF Active, certified since 9 November 2016, next certification due 23 September 2026.
AC PM LLC — covered by ActiveCampaign, LLC, participant 4495, EU-U.S. DPF Active, certified since 19 September 2016, next certification due 12 September 2026. AC PM LLC does not hold its own certification; it is named on ActiveCampaign’s as a covered entity, which is what brings it inside the framework. That distinction is recorded because “Postmark is DPF-certified” would be true only in the loose sense, and the entity Riluno actually contracts with is the one that has to be covered.

A certification is renewed annually and organisations do fall off the list, so this is a fact with a date on it rather than a standing claim. Two of the three fall due within weeks of that check. If any of them lapses, the transfer does not become unlawful automatically: each of the three also offers Standard Contractual Clauses in its data-processing agreement, and those are what the transfer would rest on instead. What would then be missing is a transfer impact assessment for each, which has not been done, so a lapse is a thing to act on rather than a thing already covered.

Who scans an upload, and what they receive

Before anyone can see an uploaded video, Riluno checks it for prohibited content, and that check uses third-party artificial-intelligence providers. This section names them, because they receive material you uploaded.

Riluno extracts still frames from the video and sends those frames — not the whole file, and no account identifier — for classification to Google (Gemini, generativelanguage.googleapis.com), Anthropic (Claude, api.anthropic.com) and OpenAI (api.openai.com). They are used in that order: the second is asked only if the first cannot answer.

The frames come from a pinned copy of the media, never from the key you uploaded to, so what is examined is exactly what would be published and cannot be swapped afterwards.

These are processors in the United States, so this is a transfer outside the EU. Each publishes a data-processing agreement incorporating the European Commission’s Standard Contractual Clauses, and those are what the transfer rests on. A transfer impact assessment for these three has not been completed — that is stated as an outstanding item rather than implied to be covered.

The scan cannot publish anything and cannot refuse anything on its own. It produces an assessment; a person decides. That is also the whole of the answer to Article 22, and it is described under “Decisions made automatically” above.

Where your data is processed

Riluno’s application and API run in Frankfurt, Germany, inside the EU. Our hosting provider is headquartered outside the EEA and its staff may access systems from outside it.

That access rests on the same basis as everything else sent to DigitalOcean: its EU-U.S. Data Privacy Framework certification, checked against the Department of Commerce register on 20 August 2026 and recorded above, with the Standard Contractual Clauses in its data-processing agreement behind it. The data does not move — it stays on machines in Frankfurt — but people outside the EEA can reach it, and under the GDPR that is a transfer just the same.

How long it is kept

Article 13(2)(a) asks either for a period or for the criteria used to set one. Riluno does not yet publish approved numbers, so the criteria are stated instead.

Data is kept only as long as the purpose it was collected for still needs it, and is deleted after that.
Request logs are kept for as long as they are useful for diagnosing a fault or investigating abuse, which is a matter of days rather than months.
Anything tied to an account is kept for the life of that account and deleted when the account is.
Safety-review evidence may be kept on a different clock, because a record of why something was refused can be required after the content itself is gone.

The periods those criteria produce:

Request and server logs, including any caller address: 7 days, extended to at most 30 days for a specific security incident that has been written down. Keeping them longer without a reason to is not defensible, and “in case it is useful later” is not a reason.
Session records: the life of the session, then 30 days, so abuse can still be investigated shortly after the fact.
Account data: the life of the account, then 30 days. The grace period exists so an accidental deletion can be undone; after it, there is no purpose left.
Uploaded media: deleted with the account, on the same 30-day grace.
Your recorded acceptance of the terms: deleted with the account, on the same 30-day grace. Keeping it afterwards as proof of what a former member agreed to would need its own legal basis and its own retention period, and neither has been decided — so it goes. Where a dispute is still open, the account itself is held, and the acceptance is held with it.
Who you blocked, and who you follow: for as long as the choice stands. Lifting a block or unfollowing removes the record then and there rather than marking it undone. Whatever still stands is deleted with the account, on the same 30-day grace.
Safety-review evidence: 6 months, extended to at most 3 years where it relates to a specific unresolved claim or a report made to law enforcement. The three-year figure is not arbitrary — it is the ordinary limitation period for civil claims under § 195 BGB, which is how long someone has to bring a case about a moderation decision.

Each period is published with the reason for it. A retention period without a rationale cannot be defended whatever the number is, and a reader is entitled to see why their data is kept as long as it is.

Your rights

Under the GDPR you have the right of access, rectification, erasure, restriction, portability, and objection, and the right to complain to a supervisory authority.

Every one of those rights is exercised by writing to privacy@riluno.org, including deletion. The one-month deadline in Article 12(3) applies from the day you write.

Deletion additionally has a built path: the deletion request page records a request and deactivates your account straight away: your sessions end and your videos and channels are no longer shown. Nothing is erased for 30 days (never more than one calendar month), and signing in before then cancels the deletion. If you do not, an automated workflow then carries it out, removing your account and your uploaded media including the provider’s copies. Backup copies cannot be selectively edited, so they are not used in normal operation and expire on the backup schedule instead.

This paragraph has been wrong in both directions and the history is instructive: it first described deletion as a right with a built path while nothing executed one, and was then corrected to say no automated process existed. The cascade exists now. See also how Riluno handles your GDPR rights.

Children

Riluno is for people aged 16 and over. Germany did not lower the age at which a person can consent to an online service on their own, so under Article 8 of the GDPR it stays at 16 here. Below that age, consent has to come from whoever holds parental responsibility.

Riluno’s answer to that is not to build a parental-consent system but to not process children’s data at all: both ways of creating an account — the sign-up form and a first sign-in with Apple or Google in the app — ask for a date of birth, accounts below 16 are not created, and an account reported as belonging to someone under 16 will be closed. Choosing the higher age makes the question disappear rather than answering it, which is the honest reason for the choice.

The date of birth is not stored. It is used once, at sign-up, to work out whether you are 16, and then discarded — no account record carries it and nothing logs it. That is true of the app as well as this website: when you sign in with Apple or Google for the first time, the app sends a date of birth with that sign-in, and the server does exactly the same thing with it — one comparison against today’s date, then gone. It is the same check for both doors, not a copy of it. Keeping it would mean holding a more sensitive piece of data than the question needed, which is what data minimisation under Article 5(1)(c) forbids. The honest consequence: this records that you stated an age, and is not evidence of your actual one.

You will not be asked for an identity document or a face scan to prove your age. Riluno is not required to demand one, and collecting an identity document from every person in order to check a birth year would take far more personal data than the check is worth.

Changes

In effect since 3 September 2026. Last updated 24 September 2026. Material changes are published here before they take effect, and a previous version of this notice is available on request from privacy@riluno.org.