Privacy notice

1 · Who is responsible

Responsible for processing your personal data within the meaning of the Swiss Data Protection Act (DSG) is:

Michael Bolliger
Earhart-Strasse 19
8152 Glattpark (Opfikon)
Switzerland
info@migumento.com

We’re a sole proprietorship and have no data protection officer. Every enquiry goes straight to the address above and is answered by the person named there.

2 · What data we process

As a host

• Your email address. So that we can send you the links to the event, and so that you can have them sent to you again. It’s the only thing we actively ask of you — there’s no account, no password and no profile.
• Details about the occasion that you enter yourselves: title, date, location, design, the event’s settings.
• Where your visit came from. Recorded once when the album is created, and never touched again after that: the campaign details from the link you came to us through (‘utm_source’, ‘utm_medium’, ‘utm_campaign’), the path of the page you were on (for example ‘/hochzeit’), and, if you came from another website, its host — so ‘www.google.com’ and never the full address. Plus the optional answer to ‘How did you hear about us?’ in the form; you may leave that blank. It serves one question only — how many people find us, and from where — never to recognise you again. What does not happen: no cookies, no IP address, no user agent, no profile across several visits. And if your browser sends ‘Do Not Track’ or ‘Global Privacy Control’, none of it is collected at all. The details hang on the album and are deleted with it.
• Payment details — see section 5.

As a guest

• The name you enter yourself. Anything you like. It stands with your photos and comments so that the others know who they are from.
• A password, if you set one. That’s optional — nobody has to. It gets you back in under your own name on a new phone, if you’ve lost the old one, say. We don’t store it in plain text, only a hash that the password can’t be worked back out of — we can’t read it either.
• An access code, if you or the hosts create one. Eight characters, valid for 30 minutes, usable once — you use it to connect a second device to your name, a tablet next to the phone, say. Here too we store only a hash, never the code itself. So that you can get back in without a password, the hosts can create such a code for you: whoever redeems it within those 30 minutes uploads under your name from then on.
• Photos, videos, comments and reactions that you upload or leave.
• Which photos you’ve marked as favourites. One entry per photo and guest, with the time. That list is seen only by the guest who created it — not the hosts, not the other guests. There’s no number on the photo, no leaderboard and no analysis of which photos were marked most often. You don’t need a name for it; without a name, though, the list stays on this one device until you enter one. It’s deleted with the event.
• Which photos you’ve opened in the large view (‘Viewed’). Counted per device and per photo, from about a second of viewing time — a quick swipe past doesn’t count, and your own photos never count. It stays within this one event: the photo says how many different guests have opened it, and the other guests at the same event can open that list. If you’ve entered a name, you stand in it under that name; if you haven’t, you appear only as a number (‘+ 3 more guests’) and can’t be told apart there. An event is a closed circle of people who know each other — which is why we think that’s defensible. If you’d rather not stand on that list, don’t enter a name.
• The counting happens even when the display is switched off. The hosts can turn ‘Viewed’ off for their event; then nobody sees numbers or names. The counting carries on anyway, so that the numbers are complete if it’s switched back on later.
• Device type, model and operating system of your browser, as far as it gives them away — e.g. ‘Pixel 7 · Android 15’. Many browsers (all of them on the iPhone) name no model; then there’s less there, or nothing. We use it to make Migumento better for the devices people actually use, and it stands next to you in the hosts’ guest list — for devices without a name it’s the only thing they can tell two devices apart by. If you use several devices under the same name — phone and tablet, or a new phone after losing one — we bring them together in that list: the hosts then see how many devices belong to you, the details of the first, and whether you’ve set a password — never the password itself. It’s tied to the event and is deleted with it.
• Without a password there’s no sign-in: we don’t identify whoever opens an event, and what marks the uploads as yours lives only in your browser’s storage and doesn’t leave your device. If you set a password or connect a device with an access code, that stops being true for that one device — which is exactly what the two are for.

When something breaks

• Error reports from your browser. If something goes wrong in the app — an upload hangs, part of the page doesn’t load, an error comes up — your browser sends us a short report about it. It contains: the error message together with the technical line it came from, the address of the page you were on (that is, the link to your event, which you opened yourself anyway), the version of our app, plus details about the surroundings — browser, operating system, screen size, connection quality, available memory — and the last few steps that led to the error. If an upload failed, the file name of the file in question is in there too, so that we and you know which item it was about.
• What is not in it: your name, your email address, your password, any photo or video content, or anything else we could recognise you as a person by. A report is created only when something goes wrong — on a page that works, nothing is sent. We don’t use it to count what you look at, and we don’t build profiles from it.
• What for, and how long. Solely to find errors and fix them — a wedding happens once, and we’d like to hear about a problem while it can still be fixed, rather than weeks later. Identical errors are grouped into one entry and deleted after 90 days. The reports sit on the same server as the event itself; once an hour a summary goes to us by email, and the links to your event are redacted in it.

Technical, on every request

• IP address and browser identification. They arise on every request to any website and, as with every web server, stand in our operating logs together with the address requested. We use them to fend off abuse (limiting the number of requests per sender) and to find faults. We don’t evaluate them for statistics, we don’t link them to anything above, and we don’t build profiles from them. In particular, ‘Viewed’ hangs not on the IP address but on the identifier your browser created for this one event.
• Data volumes transferred per event. We count how many bytes an event has caused in downloads and video playback. That’s a plain total per event — no IP, no device, no person — and it’s there so that we can weigh our prices against our actual costs.

3 · What stays on your device, and the two cookies

Most of what Migumento remembers sits locally on your device and is never sent to a server: the identifier your browser recognises your own uploads by, which albums have new photos since your last visit, your colour and display settings, and uploads still waiting in the queue.

One exception, since ‘Viewed’ came along: which individual photos you’ve opened is sent to the server — see section 2. ‘Which albums are new to me’, by contrast, stays purely local; that’s a different thing and doesn’t leave your device.

Your favourites are on the server too, and deliberately so: for the list to be the same on all your devices, and for you to be able to download exactly those photos, the server has to know which ones they are. Even so, only the person who created it can read it. There’s a copy on your device as well, so that the stars are there from the first moment instead of appearing afterwards.

Two small cookies do travel along with every request, because the server needs them to draw the first page correctly instead of correcting it again straight away:

• which view you last had open in this event;
• whether this device holds the Manage link — so that the Manage view is there immediately and doesn’t appear only afterwards.

Both apply to this one event only, contain no identifier for you and serve no analysis. They aren’t tracking cookies, they come from nobody but us, and that’s why there’s no cookie banner here. You get rid of them and everything else by clearing the website data in your browser.

4 · Location data in your photos

A camera writes invisible extra details into every photo — the time, the camera model, and on many phones the coordinates of the place it was taken. We do not remove those details: they are part of the shot, and anyone who downloads their event later should get back exactly the file that was taken — with the real time and everything that belongs to it.

But that also means: anyone who has access to an event and downloads an original can read from it where the photo was taken. If you don’t want that, switch location recording off in your camera app before you take photos. On the website itself no location is ever shown and no map is drawn.

With videos this holds for the original only. The version that plays in the app is one we re-encode ourselves — and in the process the device’s extra details fall away, the coordinates included. So anyone who only watches a video sees no location; anyone who downloads the original does.

5 · Payments

Payment goes through Stripe. Card numbers, TWINT details and everything comparable are collected and processed by Stripe directly — we never see them and we store them nowhere. All that comes back to us is: that a payment succeeded, for what amount, and a reference number.

The provider is Stripe Payments Europe Ltd., Ireland, for European payments, with Stripe, Inc. (USA) as its parent company. Their privacy notice: stripe.com/privacy.

If your billing address is outside Switzerland, Stripe is the merchant of record for the purchase (Link, LLC) and is independently responsible for that payment — it collects your billing details for itself, issues the receipt and needs them for its own tax obligations.

6 · Who else processes the data

As few as possible, and all of them as processors — they may process the data only for us, not for their own purposes.

One exception: with a billing address outside Switzerland, Stripe is not a processor for the payment itself but, as the merchant of record, independently responsible (see section 5).

Where data reaches the USA in the process, we rely on the European Commission’s standard contractual clauses and the Federal Council’s adequacy decision on the Swiss-U.S. Data Privacy Framework. We don’t sell data and we don’t pass it on to anyone who isn’t listed here — unless the law obliges us to.

7 · What we don’t do

• No advertising, no ad networks, no reselling of data.
• No analytics software, no tracking pixels, no Google Analytics — Migumento loads no third-party script at all.
• No third-party cookies and no advertising or tracking cookie — only the two functional ones from section 3.
• No face recognition, no automatic recognition of people, no automated individual decision-making.
• We don’t look at your photos — unless you ask us for help or a report forces us to.

8 · How long we keep things

• The event and everything in it: as long as it exists. Once the access period has run out (see Terms and Conditions), the event is locked, but not deleted automatically — so that nobody loses their photos for having missed a date. It’s deleted when you delete it, or when you ask us to.
• Demo events: automatically and completely after 48 hours.
• Failed uploads: after 7 days.
• The host’s email address: as long as the event exists.
• Operating logs: short-lived. They’re overwritten by rotation and aren’t archived or evaluated anywhere.
• Payment records: ten years, because the law requires it (Art. 958f OR, the Swiss Code of Obligations).

9 · Your rights

You have the right of access to the data we process about you, the right to have wrong details corrected, to deletion, to being given your data in a common format, and to object to processing. An email to info@migumento.com is enough — we need no form and no reason for it.

If you can be seen in a photo at an event and would rather not be, write to us as well. You need neither the link to the event nor the host’s consent for that.

You can also complain to the Federal Data Protection and Information Commissioner (EDÖB / FDPIC) in Bern.

10 · Security

Everything runs over encrypted connections (TLS) and nothing else. An event is reachable through a long link that can’t be guessed; anyone who doesn’t have it doesn’t get in. Original files are handed out only through short-lived, individually signed links. The Manage link and the guest link are separate — one can be shared without giving the other away.

But that also means: whoever has the link is in. Don’t pass the Manage link on.

We review our code continuously — automated and AI-assisted — and every change goes through a fixed run of tests and checks before it is published. That is care, not a guarantee: absolute security doesn’t exist on the internet, and so we don’t promise it either. What that means for liability is in section 12 of the Terms and Conditions.

11 · Changes

We adapt this notice when something about the product changes. The version published here is the one that applies; the date below says when it was last changed.