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

There is no data protection officer.

2 · What data we process

As a host

• Your email address. So that we can send you the links to the event and the code for deleting the event, you can have the links sent to you again, and we can send you emails about your event. You can unsubscribe from them in any of these emails.
• Details about the occasion, which you enter yourselves: title, date, place, design, the event’s settings.
• The origin of your visit. Recorded when the album is created: the campaign details (‘utm_source’, ‘utm_medium’, ‘utm_campaign’, ‘utm_content’) of the page you create the album on; if it has none, the first of the same visit; if those are missing too and the cookie ‘migu_d’ is set (section 3), the first of the same device from the 7 days before. Plus the path of that page, the host of the website you came from if your browser sends it (never the full address), and the optional answer to ‘How did you hear about us?’. If ‘migu_d’ is set, its device identifier and its visit identifier; if you have not yet answered the question about the cookie, the identifier of the visit without a cookie (below); and whether the cookie was set, refused, unanswered or missing. Plus the version of the website under which the album was created and, if ‘migu_d’ is set, the identifier from ‘migu_xp’ (section 3). Purpose: to know how many people find us by which route, to link the album to the page views of the same browser, and to charge the first purchase at the offer of that version. Only we analyse these details, and we pass them to no third party; no third-party tracking runs on this website. They hang on the album and are deleted with it, the identifiers after twelve months at the latest.
• Payment details — see section 5.

As a guest

• The name you enter yourself. It appears next to your photos and comments, so that the others know who they are from.
• A password, if you set one. Optional. With it you get back in under your name on another device. Only a hash value is stored.
• An access code, if you or the hosts create one. Eight characters, valid for 30 minutes, usable once — with it you connect a further device to your name. Only a hash value is stored. The hosts can create such a code for you: whoever redeems it within those 30 minutes uploads under your name afterwards.
• Photos, videos, comments and reactions, which you upload or leave.
• Measurements for each upload. How long each step took from sending to display, how often a step was repeated, the measured transfer rate and which of our servers ran a step. Purpose: to improve uploads and their processing. Deleted twelve months after the upload, or earlier with the event.
• Which photos you have marked as a favourite. One entry per photo and guest, with the time. This list is seen by only the guest who created it. Without a name, the list stays on this device until you enter one. It is deleted with the event.
• Which photos you have opened in the large view (‘Viewed’). Counted per device and per photo, from about a second of viewing time; your own photos do not count. This stays inside this one event: the photo shows how many different guests have opened it, and the other guests of the same event can open that list. If you have entered a name, you appear in it under that name; if you have not, you appear only as a number (‘+ 3 more guests’) and cannot be told apart there.
• The count runs even when the display is switched off. The hosts can switch ‘Viewed’ off for their event; then nobody sees numbers or names. The count keeps running.
• Device type, model and operating system of your browser, as far as it gives them away — ‘Pixel 7 · Android 15’, for example. Purpose: to improve Migumento for the devices in use; it also appears next to you in the hosts’ guest list. If you use several devices under the same name, we bring them together in that list: the hosts then see how many devices belong to you, the details of the first one, and whether you have set a password. It is tied to the event and is deleted with it.
• Reports. If you report a photo, a video or a comment, we record: the reported content, the reason, your optional note, your guest entry with your name if you have entered one, and the time. Purpose: to review and remove impermissible content. Reports on photos and videos are seen by the host and the event’s moderators, reports on comments by the host.
• Who takes photos out in bulk. If you download a ZIP archive through the guest link or start an export to Google Drive or Google Photos, as a host too, we record: your name at that moment, the route (ZIP, Google Drive or Google Photos), what you took (the whole event, one album, your favourites or a selection), the number of photos and videos, for a ZIP the amount of data transferred, and the time. Purpose: to be able to trace who took an event’s photos out in bulk.
• Use of the event. We record the use: views and actions, app or browser, the time. With it the event, your guest entry if there is one, your browser’s identifier and your shortened IP address (below), and, if the cookie ‘migu_d’ is set (section 3), its device identifier and its visit identifier; if you have not yet answered the question about the cookie, the identifier of the visit without a cookie (below). After ‘Decline’, only the event. Purpose: to know which functions of an event are used, and how. Deleted after twelve months.
• Rating. If you give a rating after the event, including as the host, we record: the stars, the optional text, your guest entry or the fact that you are the host, the number of photos you have uploaded and opened in full view, app or browser, the language and the time. If you close the question, we record how often and when. Purpose: to improve Migumento and to show the average and the number of all ratings on the website, without names. Only we read the text. Deleted with the event.

When something breaks

• Error reports from your browser. If something goes wrong in the app, your browser sends us a 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), the version of our app, plus details about the environment — browser, operating system, screen size, connection quality, available storage — and the last steps that led to the error. For a failed upload the file name of the file concerned is in it too. If part of the page does not load, the address of the file that was missing is in it.
• What for, and for how long. Purpose: to find and fix errors. Identical errors are grouped into one entry and deleted after 90 days. The reports sit on the same server as the event itself.

With an account (optional)

An account is optional. Purpose: to find all your events in one place and on every device. For that we store:

• Your email address and the name you give in the account. The address is the key to the account; every sign-in code goes to it.
• A password, if you set one — as a hash value. Without a password you sign in with a six-digit code that is valid for ten minutes; of that too we store only a hash value.
• Your sessions: one identifier per signed-in device, when it was last used, the device’s IP address and browser identifier — so that under ‘Sessions’ you see where you are signed in, and can sign individual devices out. A session ends after a year without use, or when you end it.
• Which events belong to the account — as a host or as a guest under the name you go by there.
• A log of the sign-ins — when, from which IP address, with what result — so that we can spot misuse.

Signing in with Google. If you choose ‘Continue with Google’, Google passes us your account identifier (‘sub’), your email address and your name. We store the identifier so that we recognise you next time. What Google itself records about the sign-in is governed by Google’s own privacy policy.

Signing in with Apple. If you choose ‘Continue with Apple’, Apple passes us your account identifier (‘sub’), a verified email address and, the first time only, your name. If you choose ‘Hide My Email’ at Apple, the address is a relay address from Apple. We store the identifier so that we recognise you next time. Apple is independently responsible for the sign-in at Apple; what Apple records in the process is governed by Apple’s own privacy policy.

Protection against automated sign-ins. The sign-in page can embed a check from Cloudflare (‘Turnstile’) that tells a sign-in attempt by a person from one by a program. Cloudflare processes the IP address and technical characteristics of your browser for it — only during the check, and only on that page.

You delete an account yourself under ‘Sign-in → Delete account’. That removes the links to events and the sessions; events, photos and guest names stay with the event.

With the Android app (optional)

The app is optional. It shows the same website, and everything in this section applies there just the same. On top of that:

• The app installation. On first launch the app registers with us: with an identifier, a key of which we store only a hash value, the app’s version and the language you use it in. We also record when it last checked in with us. Purpose: to send notifications to this phone in your language, and only this phone may change their settings.
• Notifications, if you allow them. The identifier under which Firebase Cloud Messaging from Google reaches your phone (a Firebase installation ID or a registration token). Per event: which guest the phone belongs to there, whether it holds the Manage link, your switches under ‘Notifications’, up to when you have seen the photos, and when we sent which notification. For each send attempt we also record: the kind of notification, whether the phone counted as a guest or as the host at that moment, the language, the operating system, the channel the notification is shown on, and the number it states. We keep the outcome too: Firebase Cloud Messaging’s answer or our own reason when no answer came from there. If you tap a notification, the app reports that to us and we record the time. Purpose: to see whether the notifications arrive and are tapped. A notification contains the event’s title, a text with a number and the names of guests who uploaded, the link to the album, the identifier of the send attempt — where we were able to record it — and the address of a preview image you can see in the album. It reaches your phone through Firebase Cloud Messaging, on an iPhone then through the Apple Push Notification Service (section 6). If a switch is off, we do not send that kind of notification. In the phone’s settings you switch the display off for the whole app.
• Access to the phone’s photos and videos, if you allow it. The app reads the media library on the phone to show it for selection and to suggest photos taken during the event; for suggestions also when the app is not open. A photo or video leaves the phone only when you upload it. So that the app can mark photos and videos the album already has, and not suggest them, it first sends us their file size, capture time and file name. We answer which of them the event already holds, and we do not store these details.
• An install code, if you import events from the browser into the app. For this, the browser fetches one code per event that is valid for 24 hours and can be used once. The app uses it to open the event under your name. We store a hash value of the code and the code itself, encrypted: it can be collected for at most 15 minutes and is deleted after that.
• Scanning a QR code. The camera image is analysed on the phone by Google Play services. The app receives only the content of the code.
• Signing in in the app. Signing in with Google runs through Google Play services on the phone. Signing in with Apple and connecting a Google account for the export happen in the phone’s browser; we hand their result to the app with a ticket that is valid once and expires after five minutes.

Technical, on every request

• IP address and browser identifier. They arise with every request to a website and sit together with the requested address in our operational logs. Purpose: to fend off misuse (limiting the requests per sender) and to find faults.
• A page view, counted by the server. What is recorded: the page requested, as its German base address (‘/hochzeit’, say) — an album link never appears in this count, an album counts only as album, manage or upload access; the language and the price region of the address; the campaign details from the link; the identifier an advertising platform attaches to its own link; the short key from one of our own links; and, if you came from another website, its host — so ‘www.google.com’ and never the full address. Purpose: to know which pages are opened how often and by which route. If the cookie ‘migu_d’ is set (section 3), its device identifier and its visit identifier are in the line; if you have not yet answered the question about the cookie, the identifier of the visit without a cookie (below). The line also records whether the cookie was set, refused or unanswered, and which version of the website was delivered; if ‘migu_d’ is set, also the identifier from ‘migu_xp’ (section 3). If you create a demo, a line with the same details is recorded for it. From your device only the language you chose, ‘migu_d’ and ‘migu_xp’ (section 3) are read.
• Use of the website. We record the use of the website: views and actions, the time. With it the page as its German base address, the language and the price region of the address, your browser’s identifier and your shortened IP address (below), and, if the cookie ‘migu_d’ is set (section 3), its device identifier and its visit identifier; if you have not yet answered the question about the cookie, the identifier of the visit without a cookie (below). Plus the version of the website that was delivered and, if ‘migu_d’ is set, the identifier from ‘migu_xp’ (section 3). After ‘Decline’, the same without your browser’s identifier, the IP address and the device and visit identifiers. Purpose: to know which parts of these pages are used, and how. Deleted after twelve months.
• One identifier per day. So that several pages of one visit do not count as several visitors, our server computes a checksum from your IP address, your browser’s identifier and your language setting. A secret value goes into that calculation which is generated afresh for each day and deleted after two days. Only the checksum is stored for this. Your browser’s identifier additionally answers whether the request came from an automated program. After ‘Decline’ (section 3) that checksum is not computed.
• Browser identifier and shortened IP address with the page view. The line of a page view and of a demo also holds your browser’s identifier and your IP address without its last part: for IPv4 without the last of the four numbers, for IPv6 only the first three blocks. Purpose: to recognise our own requests by rules we set and mark them as internal, and to recognise requests by automated programs. We delete both twelve months after the page view from the line.
• A visit without a cookie. If you are in the EU, the EEA, the United Kingdom or no country can be assigned, and you have not yet answered the question about the cookie ‘migu_d’ (section 3), our server groups your page views into one visit. For that it computes a checksum from your IP address, your browser’s identifier, the characteristic of your encrypted connection that our network provider forms (‘JA4’) and your language setting. The secret value of the day from the previous point goes into the calculation; it is deleted after two days. What is stored is the checksum, a random visit identifier and the start and the last request of the visit. A visit ends after 30 minutes without a request or 24 hours after it began. Purpose: to link the page views of one visit to one another and to an album created during that visit. After ‘Decline’, none of it is computed.
• Campaign details in links. If you arrive through a link with campaign details (‘utm_source’, ‘utm_medium’, ‘utm_campaign’, ‘utm_content’) and you have not yet answered the question about the cookie ‘migu_d’ or have declined it, our server attaches these details to the links of the page that lead on within Migumento. If the cookie is set, the page removes the campaign details, the identifier of an advertising platform and our short key from the address bar as soon as the page view is counted.

3 · What stays on your device, and the cookies

Locally on your device, without being sent to a server: which albums have had new photos since your last visit, your colour and display settings, and uploads still waiting in the queue. On your device there is also a copy of your favourites (section 2).

Cookies for this one event. Five, set by your browser, valid for at most a year. The server reads them to deliver the first page in the state they describe:

• which view you last had open in this event;
• whether this device holds the Manage link;
• your display settings, and how far you have seen this event’s photos;
• how many photos you have marked as a favourite — a number, not a list;
• a checksum (SHA-256) of the identifier your browser created for this event. With it the server recognises your own uploads and does not show them to you as new.

Cookies for the whole website. If you choose a language or a price region, two cookies hold that choice for a year. A third remembers for this visit that you dismissed the note about a different price region.

With an account (section 2) further ones come along. They apply to the whole website, for as long as you are signed in:

• a cookie that identifies you as signed in and finds the matching session on your next visit — it ends after a year without use, or when you sign out;
• a second one that only records that you are signed in and keeps your initials ready for the symbol in the top right;
• if you sign in with Google or Apple, one more that secures that one sign-in procedure against tampering and expires by itself after ten minutes, whether you complete the sign-in or not.

You get rid of them and everything else by signing out or by deleting the website data in your browser.

In the Android app these cookies and everything above sit in the app’s storage instead of the browser. In addition the app stores on the phone the list of your events with their access grants, the installation’s identifier with its key, which photos and videos from the media library it has uploaded, and which suggestions you swiped away. Those two lists stay on the phone. You get rid of all of it by uninstalling the app or by deleting its data in the Android settings.

One cookie that recognises this browser: ‘migu_d’. Set by our server when it delivers a page of Migumento. Valid for 400 days from the last request. Content: a random device identifier, a random visit identifier, the start and the last request of the visit, and whether you have consented. A visit ends after 30 minutes without a request or 24 hours after it began. Purpose: to link the page views of one browser to one another across several days and from the website into an album, and a new album to the visit it was created from (section 2). Its identifiers go to nobody.

Where it is set without asking: in Switzerland and in every country outside the EU, the EEA and the United Kingdom. What counts is the country our network provider assigns to your connection. In the EU, in the EEA, in the United Kingdom and when no country can be assigned, it is set only with your consent; without it nothing is set there and an existing cookie is not read. Until you have answered, ‘A visit without a cookie’ (section 2) applies there.

Your choice: Stop recognising this browser — the cookie is replaced by one that for 400 days records only your refusal. Allow recognition — that is your consent, where one is needed. You can change the choice at any time.

A cookie that decides which version of the website you see: ‘migu_xp’. Set by our server when it delivers a page of Migumento, in every country. Valid for 400 days. Content: a random identifier and, after a visit via an advertisement from Google, a note of it. Purpose: that this browser sees the same version of the website and the same prices on every request. Its identifier goes to nobody.

Every other cookie in this list is needed by the service you asked for.

One further cookie we set exclusively behind the sign-in to our internal administration. Content: the statement that this device’s visits do not go into our numbers. Duration: one year.

Not from us: the check from Cloudflare (‘Turnstile’) on the two sign-in fields can set a cookie. Purpose: to tell a human from a program. Provider: section 6. In our assessment it is strictly necessary for the procedure you asked for and therefore not subject to consent.

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.

Anyone who has access to an event and downloads an original can read from it where the photo was taken.

Through the Android app photos and videos arrive with these details, the coordinates included. If you select them in a browser on Android, Android removes the coordinates before the upload; in the app too, if it has no access to the media library.

The host can have these details removed for other guests. If the host switches ‘Include metadata’ off under ‘Download originals’, then on download and on export by guests we remove from other guests’ photos and videos the coordinates, device details such as the serial number, stored names, texts and embedded preview images. Every guest gets their own photos and videos unchanged, and so does everything obtained through the Manage link.

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.

5 · Payments

Payment goes through Stripe. Card numbers, TWINT details and everything comparable are collected and processed by Stripe directly. 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

We use all of them as processors; they process the data only for us.

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 pass data 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.

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. The export exists for hosts and for guests; each person connects their own Google account and exports only into it. 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. 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. Purpose: a second export recognises by it what has already been transferred.

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

The copies then sit in your account, under your own agreement with Google. Google is not our processor for these copies. 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 each connection we ask for exactly one permission for your photos and videos — the one for the destination you chose: for Google Drive only access to the files and folders our own application created there (drive.file). 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. If you want to use both destinations, you connect twice, and we then hold both permissions. In addition, signing in releases your account address to us (openid, email).

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 a new sign-in; the email address of the connected account, so that you can see which account is being exported to; 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.

You can disconnect at any time. In the export, the Google Drive page and the Google Photos page each have a ‘Disconnect’, for guests and hosts alike; it disconnects only the person’s own connection. We delete our record in every case — after that we have neither that access nor the address of your Google account, and your running export 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.

You can check the permission and take it away yourselves at any time in your Google account under ‘Security’, at the third-party apps with account access: myaccount.google.com.

If the event is deleted, our record goes with it; we don’t ask Google in that case. 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 until you choose ‘Disconnect’ or the event is deleted. Whatever has already been exported stays in your account.

8 · What we do not do

• No automated individual decisions.

9 · How long we keep things

• The event and its contents: for as long as the access window runs (see Terms and conditions). After that the event is locked, and from that point on we can delete it at any time. As a rule we keep a locked event for longer, so that you can open it again. It is deleted sooner if you delete it yourselves or ask us to. If you delete an event with photos or videos yourselves, it is no longer reachable at once and is deleted for good seven days later; until then it is used only to restore it.
• Events that were never used: an event that is still completely untouched 12 months after it was created we delete automatically. Untouched means: never a photo or video uploaded, never a name entered by a guest, the email address never confirmed, nothing paid, no table card created. As soon as even one of those has happened, the first point applies.
• Demo events: automatically and completely after 48 hours.
• Failed uploads: after 30 days.
• Files of deleted photos and videos: permanently deleted within 30 days of the deletion, from the backup copies too. Until then they are used only to restore them. For this we keep, for each deletion, a record for 45 days: the identifiers of the photo or video, the album, the event and the guest, the storage paths of the files, and the time and cause of the deletion. After that the record is deleted.
• The host’s email address: for as long as the event exists.
• Connection to a Google account: until you disconnect it, at most for as long as the event exists — after that the whole entry for it is gone, access and account address (see section 7).
• Reports: for as long as the event exists. If the host clears the reports on an item, they are deleted.
• Record of bulk downloads and exports: for as long as the event exists. If a guest is removed, their name stays in it.
• App installation and notifications: This phone’s entry for an event (section 2) never outlives the event and never outlives the installation. It is deleted, for instance, when you turn off every switch under ‘Notifications’, when you remove the event from the app’s list, or when the guest link is reissued and the entry belonged to a guest or to an older Manage link. If you remove the last event, the app deletes its installation with us and its Firebase installation ID at Google; Google then removes that ID from its backups too within 180 days. We delete the installation when it has not checked in with us for 270 days, for instance after uninstalling. The next point applies to the entry for a send attempt.
• Entry for a send attempt: 270 days from the attempt, then deleted. It refers to the event, to the installation and to this phone’s entry for this event; when one of those is deleted, we remove only the reference to it.
• Notifications that do not reach the phone: at most 24 hours at Firebase Cloud Messaging.
• Counted page views: indefinitely.
• Browser identifier and shortened IP address from a page view (section 2): twelve months after the page view.
• The secret value for the daily checksum from section 2: two days.
• Device identifier and visit identifier from ‘migu_d’ (section 3): twelve months — in a page view’s line from the page view, on an album from creation. The cookie itself: 400 days after the last request, or until you delete it in your browser.
• The identifier from ‘migu_xp’ (section 3): twelve months — in a page view’s line from the page view, on an album from creation. The cookie itself: 400 days after the first request, or until you delete it in your browser.
• Checksum of a visit without a cookie (section 2): deleted at the latest two days after the last request. Its visit identifier in the line of a page view and on an album: twelve months, like the identifiers from ‘migu_d’.
• The identifier an advertising platform attached to its link: twelve months. Purpose: to be able to report to the platform which advertisement led to an album. Deleted twelve months after the page view.
• Operational logs: until rotation overwrites them.
• Backup copies of the database: at most 16 months, then deleted. They are used only to restore data.
• Payment records: ten years (Art. 958f OR).

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.

If you can be seen in a photo at an event and would rather not be, write to us as well.

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

11 · Security

Everything between your device and us 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 individually signed links that stop working after 24 hours. The Manage link and the guest link are separate. Whoever has a link is in.

There is no absolute security on the internet. 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.