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 appears 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 appear 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 be 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 appears 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. If part of the page doesn’t load, the address of the file that was missing is in there — otherwise we would only know that something is missing, and not what.
• 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, appear 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 (Stripe)) 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 you instruct an export into your own Google account yourselves (section 7), or the law obliges us to.

Google isn’t in the table for exactly that reason: in an export Google isn’t working for us but for you, in your own account and under your own agreement with Google. What happens there is in the next section.

7 · Export into your own Google account

Migumento can copy an event’s photos and videos into your own Google Drive or into your own Google Photos. That happens only if you connect a Google account yourselves and start the export. Without that step nothing goes to Google — there is no automatic export, no scheduled export and no export after the fact, and guests don’t get one at all. When you connect, we send you on to Google; Google sees your IP address in the process, as it does on any visit to a website.

What we transfer: the photos and videos you selected for this export, their file names and the time each one was taken. Along with those goes the name of the event and of the album — in Google Drive as the names of the folders the files sit in, in Google Photos as text on every photo, so that you can find them again there. To every file in Google Drive we also attach a technical identifier for that photo or video; and if you ask for the export to Google Drive as a single archive (ZIP), that archive carries the identifier of the export. That is how a second export recognises what is already up there, instead of uploading everything a second time. Those are strings of characters with no meaning outside our service, and Google only ever gives them to our own application — in your Google Drive there is nothing of them to see.

An original goes across exactly as it was taken — with all the invisible extra details the camera wrote into it, from section 4, the coordinates of where it was taken included. We don’t remove them for an export, just as we don’t remove them for a download. Only if you pick the smaller version of a photo or the converted version of a video for an export to Google Drive does the newly computed file go across instead, and that one no longer carries those details. To Google Photos it is always the originals that go.

We do not transfer guest names, comments, favourites or email addresses. What lands in your Google account is the photos and videos themselves, not the record of who uploaded, favourited, commented on or viewed them.

The copies then sit in your account, under your own agreement with Google. We are only the route, not the recipient; for these copies Google is not our processor, and that is why it isn’t in the table in section 6. What Google does with the data in your account is governed by Google’s own privacy notice: policies.google.com/privacy.

We can put things into your Google account, but we can’t read what is in it. For your photos and videos we ask for exactly two permissions, and both are as narrow as Google offers them: for Google Drive only access to the files and folders our own application created there (drive.file) — anything that was already in your Google Drive stays invisible to us. For Google Photos only adding (photoslibrary.appendonly): we can put photos and videos there and create an album for them, but we can’t search your library, can’t look at it and can’t delete anything from it. In addition, signing in releases your account address to us (openid, email). We don’t ask for anything more.

Of the connection itself we store only what an export needs: an access grant you give us at Google, which we keep only in encrypted form so that an export can run without you signing in again every time; the email address of the connected account, so that you can see which account is being exported to — many people have more than one, and exporting into the wrong one could not be undone; which permissions you granted us; and the identifier of the folder and of the albums we created, so that a second export carries on using the same ones instead of creating twins. No password, and no access to Gmail, contacts or calendar.

You can disconnect at any time. The event’s Manage view has a ‘Disconnect’. Two things happen when you use it, and the two are not equally reliable. We delete our record in every case — after that we have neither that access nor the address of your Google account, and an export that is running is stopped. And we ask Google to revoke the permission — that is a request to Google, and normally Google carries it out. If it doesn’t reach Google, or Google turns it down, the permission can still be standing in your Google account even though nothing of it is left with us. We can’t go back and revoke it later: the access that would do it was deleted along with the record. Either way, what you see with us says ‘Google account disconnected’ — that display describes our record, not your Google account.

You can check the permission and take it away yourselves at any time, independently of us and without us doing anything: in your Google account under ‘Security’, at the third-party apps with account access: myaccount.google.com. That page says what we are still allowed to do in your account, and that is where you take it away. That place is yours, and it is the only one that gives you the answer for certain.

If the event is deleted, our record goes with it; we don’t ask Google in that case — so here the route through your own Google account counts all the more. If you withdraw the permission at Google directly, our access becomes invalid straight away; the record with your account address stays on in that case, though, so that we can even tell you which connection no longer holds — it goes with ‘Disconnect’, or with the event. Whatever has already been exported stays in your account — it’s yours, both of you, and we can’t get at it afterwards.

8 · 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.

9 · How long we keep things

• The event and everything in it: as long as the access period runs (see Terms and conditions). After that the event is locked, and from that point we may delete it at any time. We give no undertaking to keep anything beyond the access period. As a rule we keep a locked event for longer, so that you can reopen it — but you cannot rely on that. Before then, it is deleted when you delete it, or when you ask us to.
• Never-used events: an event that is still completely untouched 12 months after it was created is deleted automatically. Untouched means: no photo or video ever uploaded, no guest ever entered their name, the email address never confirmed, nothing paid, no table card created. There is nothing in such an event that anyone could lose. As soon as even one of those things has happened, the first point applies unchanged.
• Demo events: automatically and completely after 48 hours.
• Failed uploads: after 7 days.
• The host’s email address: as long as the event exists.
• The connection to a Google account: until you disconnect it, and at most as long as the event exists — after that the whole record of it is gone, the access and the account address (see section 7).
• 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).

10 · 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.

11 · Security

Everything runs over encrypted connections (TLS), without exception. 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.

12 · 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.