Privacy Policy

This policy explains what Irhium does with personal data: yours, if you have an account, and other people's, if you upload a photograph of them. It is written to be read rather than to be survived, and it says what the software actually does rather than what a service like this usually does.

Who we are

Irhium is operated by [LEGAL NAME], NIF [NIF], with its registered address at [ADDRESS], Spain. You can write to us at [CONTACT EMAIL]. We run the website at irhium.com and the service reached through it.

These details are published to meet article 10 of Spain's Ley 34/2002 on information society services (LSSI-CE). Data protection is governed by the EU General Data Protection Regulation (Regulation (EU) 2016/679) and Spain's Ley Orgánica 3/2018 (LOPDGDD).

Who is responsible for what

A wedding album has three sets of people in it: the couple who created it, the guests who joined and uploaded, and everybody who appears in a photograph. So it is worth being explicit about who is answerable for what, rather than leaving it implied.

Our position is that we are the data controller for everything described in this policy. We decide the things a controller decides: how long photographs live, that location is stripped, what a guest is asked for when they join, who can see whose uploads, and how the whole thing is secured. Those are not instructions we receive from a couple; they are decisions we made and that a couple cannot change.

A couple collecting photographs of their own wedding is, in our view, doing something personal and domestic, which the GDPR largely leaves alone. That exemption does not extend to us: recital 18 of the GDPR says in terms that it does not apply to a provider of the means for such personal processing. In other words, the couple can treat their album as a private family matter; we cannot.

Two situations sit differently, and we say so rather than hiding them. A wedding planner or another business running an album on a client's behalf is not doing anything domestic, and is a controller in their own right for the guest list and the seating plan they build. And for some of what we do — the seating planner in particular, where a couple decides what to record about their guests and we provide the tool — the honest description may be joint controllership rather than sole. We have taken the position above because it puts the obligations on the party that can actually meet them, and because asking every couple who spends twenty euros to sign a data processing agreement would be a fiction. This is the first question we have flagged for legal review.

What we hold, and why

Your account

Your first name, surname and email address; your password, kept only as a bcrypt hash that cannot be reversed; or, if you signed in with Google, the identifier Google gives us for your account and the date you linked it. Also the language you read the app in, when you last used it, which albums you belong to, whether you host or are a guest in each, and when you joined.

We do not verify email addresses, because we never send anything to them. An address here is a label and a way of recognising you when you come back, not a channel. The one exception is an address confirmed by Google when you sign in that way, which Google has checked on its own account.

The legal basis is the contract between us: you asked for an account so you could take part in an album, and we cannot provide one without these details (GDPR article 6(1)(b)).

Photographs and video

The file exactly as your phone sent it, at full resolution and never re-encoded; who uploaded it; the original filename; its type, size and dimensions; how long a video runs; a checksum used to recognise a re-sent upload; and the time the camera recorded, where the file says so. We generate a thumbnail and a larger preview for display, and a poster frame for video.

Location data is removed. When a file arrives we read its metadata, and if it carries GPS coordinates we strip every location tag with exiftool and write the cleaned file back over the stored one. So the copy we hold and the copy the couple eventually downloads both carry no coordinates. The capture time, the camera model and the orientation are kept, because they are what make an album sort correctly and come out the right way up. Stripping happens on a background queue moments after the upload lands, so there is a short window during which the original as sent is still in storage.

Nothing reads the content of a photograph. There is no face detection, no object recognition, no automatic tagging, and no model of any kind is trained on anything uploaded here.

The album itself

Its name, the wedding date, the venue if the couple typed one, the welcome and closing messages they wrote, the appearance of the printed code, the memorable link, and any name or logo shown to guests.

Payments

Payment is handled by Stripe on Stripe's own pages. Card details never reach this application — not the server, not the logs, not a crash report. We use Stripe's hosted checkout precisely so there is nowhere for them to arrive.

What we send to Stripe when somebody pays is: the amount, the currency, the album's name, our own reference numbers, and the payer's email address so that Stripe can send them a receipt. What we keep afterwards is: which album was paid for, who paid, the amount, the currency, Stripe's reference for the payment, and the date. Records of a payment are kept for as long as Spanish tax and accounting law requires them, which is longer than anything else in this policy.

Technical data

Our web server records requests in the ordinary way, including IP addresses, and your IP address is used while you are being served to limit how often the same connection can try to join an album — otherwise one bad actor could work through a wedding's join codes. We do not build a profile from any of it. There is no analytics package, no advertising network and no third-party script on any page; the fonts are served from our own server rather than from anybody's font CDN.

Guests, and the people in the photographs

This is the part of the service that deserves the most honesty, so here it is plainly.

A guest scans a code at a reception and uploads photographs. Those photographs contain other guests, waiting staff, children, and people who wandered through the shot. None of them has agreed to anything, and no realistic version of this product could ask them: there is no moment at a wedding at which a hundred and fifty people can meaningfully consent to a photo app.

So we do not claim consent as the legal basis for this, because we do not have it. We rely on legitimate interests (GDPR article 6(1)(f)): the interest of a couple and their guests in collecting and sharing photographs of a private event that those people chose to attend. In weighing that against the rights of somebody who appears in a photograph, these are the facts that matter, and they are facts about how the software is built rather than promises:

• The album is private. Nothing in it is public, indexed, or reachable without being admitted to that specific album, and no file is ever linked to directly from storage — every image is served through the app after a permission check.
• By default a guest sees only their own uploads. Everybody seeing everybody's photographs is a switch the couple has to turn on.
• Photographs are deleted 30 days after the wedding. This is not a service you can appear in indefinitely.
• Location is removed, so a photograph does not carry the place it was taken.
• Nothing analyses the image. Nobody is identified, tagged, matched or profiled.
• Nothing is ever sold, shared for advertising, or used to train anything.

If you are in a photograph and you would rather not be, you can object under article 21 of the GDPR, and you do not have to give a reason for a photograph. Write to us at [CONTACT EMAIL] and we will remove it. Two practical notes, because vague promises are worse than awkward facts. First, we cannot search for a face — there is no such capability here — so we need enough to find the photograph: whose wedding, roughly when, and what it shows. Second, the quickest route is often the couple, who can delete anything in their own album immediately, and the person who uploaded it, who can delete their own uploads at any time.

A photograph can incidentally reveal something the GDPR treats as sensitive — a religious ceremony, a wheelchair, a person's ethnicity. We do not seek that data, do not use it and do not derive anything from it. If it worries you, the paragraph above is the remedy and we would rather you used it.

Children

Children are at weddings, so children are in wedding photographs. Everything in the section above applies to them with more force, and a parent or guardian can exercise every right in this policy on a child's behalf — including asking us to remove a photograph, which we will do without asking why.

Accounts are a different matter. Irhium is not meant for children and is not directed at them. In Spain a person must be at least 14 to consent to an information society service on their own account (article 7 LOPDGDD). If you are younger than that, a parent or guardian has to act for you. If we learn that an account belongs to a child under 14 without that, we will delete it.

The seating planner also lets a couple record that a guest is a child, and their age. That is data about a child entered by an adult who is not their parent, which is one more reason the section below exists.

The seating planner

Paid albums include a seating planner, and it holds a different kind of personal data from the rest of the service: not photographs, but a description of a social world. It deserves its own section rather than a line in a list.

To plan the tables, the couple types in their guest list. For each guest that can include: their name; whether they have replied to the invitation; the groups they belong to, which are labels the couple invents and nests — Groom's side → University → Dorm floor 3; whether they are a child, elderly, or a guest of honour; whether they have mobility needs; their age; the language they speak; and who invited them, for a plus-one. Households can carry a free-text note. And the couple can add rules: these two must sit together, these two must not sit together, keep these two at opposite ends of the room.

Read that back and what it describes is who knows whom, who cannot bear whom, and who needs a chair near a door. It is personal data about people who are not our users, who did not provide it, and who have generally never heard of us. Some of it is sensitive: a note that somebody has mobility needs may amount to data about their health, and rules about who must be kept apart can reveal a family estrangement.

What we do with it: we run it through an optimiser that works out which household sits at which table and in which seat, and we keep every version of the plan so a couple can go back to one they have already announced. Nothing else. It is never used for any other purpose, never shown to anybody outside the album, and never sold or shared.

Who can see it: only the host of that album. The seating pages are closed to guests entirely — a guest of a wedding cannot see the guest list, the groups or the rules, and neither can anybody else.

Our position on responsibility here is the one set out earlier, and this is where it is most arguable: the couple decides what to record about their guests, and we provide the tool and the algorithm. If you are on somebody's guest list and want to know what is recorded about you, or want it corrected or removed, you can ask us at [CONTACT EMAIL] and we will act on it — but the couple is likely to be both faster and better informed, and we will usually tell them you have asked.

One thing to note about timing: the 30-day deletion covers photographs and video, not the seating plan. Seating data lives until the album is deleted, which the couple can do at any time.

How long we keep things

Photographs and video

Deleted 30 days after the wedding day, on both the free and the paid plan. The count runs from the date of the wedding rather than from when the album was created, because photographs keep arriving for a week afterwards and couples are usually away for the fortnight after that. If the wedding date moves, the deadline moves with it. A scheduled job does the deleting every morning, and it removes the original and every derived image from storage, not just the database row.

This is a deliberate limit rather than an accident of housekeeping, and it is the strongest privacy statement this service makes: a stranger's photograph of you at a party in June is gone in July, whether or not anybody remembers to ask.

What survives that deletion

The album record itself — its name, date and the list of who took part — is kept, so that a guest who scans the code months later reads an explanation rather than meeting an error. The seating plan is kept. Accounts are kept. We would rather say this plainly than let "everything is deleted after 30 days" stand as a half-truth.

Everything else

• Your account: until you ask us to delete it. There is no self-service button for this yet; write to [CONTACT EMAIL] and we will do it.
• An album and its seating plan: until the couple deletes it, or asks us to.
• Payment records: for as long as Spanish tax and accounting law requires, which is measured in years and overrides a deletion request for those specific records.
• Server logs: a short period, in the ordinary course of running a server.

How erasure interacts with all of this

If you ask us to erase photographs that are already scheduled for deletion, we do it when you ask rather than making you wait out the window. A request does not join a queue behind the calendar.

Some deletion you can do yourself, faster than we can: a guest can delete their own uploads at any time, and the couple can delete anything in their album.

When a couple deletes their album, every photograph in it goes, including photographs uploaded by guests. Immediately, irreversibly, and without warning the guests first. There is no recycle bin and no recovery. If you have uploaded something to somebody's album that you want to keep, keep your own copy — you are relying on their decision, not ours.

Who else touches this data

We use as few outside services as we can, and every one of them is here because the software genuinely needs it:

• Amazon Web Services (EC2) — the server the application runs on, in the London region. The database, which holds accounts, albums and seating data, is on that machine and nowhere else.
• Cloudflare (R2) — object storage for photographs and video, in a bucket with a European location and no public access at all. Cloudflare also sits in front of the site providing TLS and protection against attack, so traffic passes through it.
• Stripe — payments. Stripe receives what is described under "Payments" above and nothing else. We receive no card details from them.
• Google — only if you choose "continue with Google". Google tells us your account identifier, your email address, your name and whether it has verified the address. We tell Google nothing about your wedding.

There is no email provider, because there is no email. Nothing in this application sends a message of any kind. Where a service like this would normally list a mailing provider, there is nothing to list.

Where the data goes

Photographs and video are stored in Europe. The server that runs the application, and the database on it, are in London, in the United Kingdom — which is outside the European Economic Area. Transfers there rely on the European Commission's adequacy decision for the United Kingdom, which is the mechanism the law provides for exactly this situation. Stripe, Cloudflare and Google are international companies whose group structures involve transfers outside the EEA under the safeguards each of them publishes. The precise legal footing of each of these transfers is the second thing we have flagged for legal review.

Wedding planners

Some couples arrive through a wedding planner, who receives a share of what that couple pays. Because a planner's name and logo can appear on the pages guests see, it is worth being exact about what that does and does not mean.

A planner cannot see the album. Not the photographs, not who uploaded what, not the guest list, not the seating plan. The referral arrangement grants no access of any kind to a couple's data. The only ways a planner sees an album are the ordinary ones: the couple makes them the host, or invites them as a guest, in which case they see exactly what a host or a guest sees and nothing more.

What a planner does get: their name and logo displayed on the guest-facing pages of albums they referred, and a statement of what they have earned, which necessarily identifies which of the couples they referred have paid and when.

When you follow a planner's link we store a cookie for 60 days so that the referral can be credited if you sign up later. It holds the planner's code and nothing about you.

Cookies

There are no advertising or analytics cookies on this site, and no third-party tracker of any kind. What exists:

• A session cookie, which is how the app knows you are signed in.
• A security token, which stops another site submitting forms as you.
• A "remember me" cookie, so a guest is not signed out of their own wedding photographs a week later.
• A referral cookie, set only if you arrive through a wedding planner's link, described in the section above.

The first three are strictly necessary to provide the service you asked for. The referral cookie is not: it exists so that a planner can be paid. Under article 22.2 of the LSSI it is therefore in a different category, and how consent for it should be obtained is the third thing we have flagged for legal review.

Security

The measures worth naming, because they are the ones doing the work:

• Nothing in storage is ever linked to directly. Every photograph is served through the application, behind a permission check, so an album cannot be enumerated by guessing URLs.
• Media addresses use random identifiers rather than sequential numbers, so nobody can walk through an album by counting.
• Passwords are stored only as bcrypt hashes.
• The whole site is served over HTTPS.
• The storage bucket has public access switched off, and the credential that reaches it is scoped to that one bucket.
• Payment notifications from Stripe are cryptographically signed and rejected if the signature does not verify.

No system is perfect, and this one is early. If you find a way to reach data you should not, please write to [CONTACT EMAIL] and we will treat it as urgent.

Automated decisions

The seating planner is an optimiser: it decides which household sits at which table. That is an automated decision about a person, so we mention it. It has no legal effect and no comparable significance — the worst it can do is seat you with your cousins — and the couple can override any part of it. Nothing else in the service makes an automated decision about anybody.

Your rights

You can ask us for a copy of the personal data we hold about you, to have it corrected, to have it deleted, to restrict what we do with it, to receive it in a portable form, and to object to processing based on legitimate interests — which includes appearing in somebody's photograph.

Write to [CONTACT EMAIL]. We will answer within one month. We may need to check that you are who you say you are, particularly where somebody asks about a photograph or about a name on a guest list, because the alternative is handing one guest's data to another.

If you are not satisfied with how we have handled it, you can complain to the Spanish data protection authority: Agencia Española de Protección de Datos, C/ Jorge Juan 6, 28001 Madrid, www.aepd.es. You do not have to come to us first, though we would rather you did.

Changes

If this policy changes we will update the date at the top of the page, and where the change is significant we will say so in the app. There is no mailing list to be told through.