Beisl Privacy Policy

Effective date: 12 May 2026
Last updated: 22 October 2026

This Privacy Policy describes how Timmo Caspar Achsel (“Beisl”, “we”, “us”, or “our”), as the operator of the Beisl mobile application and the website at beisl.pub (together, the “Service”), collects, uses, shares, and protects personal data.

We are the data controller for the personal data processed through the Service within the meaning of the EU General Data Protection Regulation 2016/679 (“GDPR”), the UK GDPR, and equivalent laws.

1. Who we are and how to reach us

Controller:
Timmo Caspar Achsel
Stockholm, Sweden
Email: hello@beisl.pub

Beisl is currently operated as a sole proprietorship. If you have questions, want to exercise a privacy right, or wish to lodge a complaint with us before approaching a supervisory authority, please email us at the address above. We aim to respond to verifiable requests within 30 days.

We have not appointed a Data Protection Officer because we are not legally required to do so, but the email above reaches the person responsible for privacy at Beisl.

2. Scope of this Policy

This Policy applies to:

• the Beisl iOS app (bundle identifier pub.beisl.app) distributed through the Apple App Store;
• the Beisl Android app (package name pub.beisl.app) distributed through Google Play; and
• the Beisl website at beisl.pub, including invite landing pages, the Apple App Site Association file used for universal links, the Digital Asset Links file (/.well-known/assetlinks.json) used for Android App Links, and any associated subdomains we operate (e.g. api.beisl.pub).

This Policy does not apply to third-party services that you reach from links inside the Service (for example, directions to a bar in Apple Maps or in your Android phone's maps app, or another user's external website). Their privacy policies govern your use of those services.

3. Summary at a glance

The summary is provided for convenience. The detailed sections below are legally controlling.

4. Personal data we collect

4.1 Data you provide directly

When you sign in to Beisl using Sign in with Apple, Apple sends us a signed identity token from which we extract a stable, opaque user identifier (the “Apple sub”). The Apple sub is unique to your Apple ID and to the Beisl Services ID; it cannot be linked back to your Apple ID by us. Apple may also include an email address in that token (your real address, or a relay address of the form <random>@privaterelay.appleid.com). We do not store the email address. It is read once, in memory, only to validate the token; we then discard it.

When you sign in to the Android app using Sign in with Google, Google sends us a signed ID token. We check that Google signed it and that it was issued for Beisl, and extract the stable identifier Google assigns to your Google Account (the “Google sub”). The token may also contain your email address, your name, and a link to your Google profile picture. We store only the Google sub. We do not store your email address, name, or picture, and we do not write the token or its contents to our logs.

An account created with Sign in with Apple and an account created with Sign in with Google are separate Beisl accounts. We do not link them, even if they belong to the same person.

After signing in for the first time, you choose:

• a handle — a unique short username, displayed as @yourhandle, that other people use to find and add you.

The handle is the only thing the iOS app requires to finish creating your account. We never ask you for your real name. Your account also carries a display name — a free-text name shown to your friends and crew. The iOS app does not ask you for it: it is seeded from your handle, and setting or changing it is entirely optional. The Android app asks you to choose one alongside your handle when you sign up; it can be any name of up to 40 characters, and it does not have to be your real name.

Your handle is permanent once you have chosen it. It is how other people find you, so it cannot be changed in the app afterwards; if you made a mistake when choosing it, email us and we can correct it. Your display name stays yours to change at any time from the Profile screen.

When you create or interact with content in the app, you may also provide:

• bar entries (a venue name, optional area label, an optional latitude/longitude, and a colour hue);
• ratings and notes about a bar (eight scores from 1–5 covering atmosphere, music, selection, quality, price, staff, toilets, and “linger”; an optional drink-kind text; an optional free-text note up to 1,000 characters). A rating doubles as your visit record — there is no separate “check-in”, so a bar counts as visited once you have rated it;
• crawls (a name, planned date and time, mode of transport, and an ordered list of stops);
• try-lists and bar lists (custom personal lists of bars; bar lists with multiple lists are a Premium feature);
• friend relationships (you choose whom to invite, accept, or block);
• moderation reports (a target type, target ID, and a free-text reason capped at 500 characters); and
• a logbook caption (a short text persisted with a completed crawl, sometimes called the “verdict”).

4.2 Data collected automatically

When you use the Service we automatically collect:

• a persistent user record identifier generated by us (a UUID stored on our server and tied to your Apple sub or Google sub);
• session tokens (JSON Web Tokens issued by us, stored in your device's iOS Keychain or, in the Android app, in app storage encrypted with AES-256 under a key held in the Android Keystore);
• APNs device tokens issued to your iPhone by Apple's Push Notification service so we can deliver notifications to you, together with the APNs environment (sandbox or prod), the language the app is set to (so that notifications arrive in it), and the date the token was registered or revoked;
• Firebase Cloud Messaging (FCM) registration tokens issued to the Android app by Google so we can deliver notifications to it, together with the platform (Android), whether the app is a development or a release build, and the date the token was registered or revoked. To issue the token, Google's Firebase Cloud Messaging library in the app creates a Firebase installation identifier for the app and registers it with Google. The notifications we send through FCM carry only a notification type and internal identifiers (for example, which crawl or bar a notification is about); the text you see — names, bar names, crawl names — does not pass through Google but is put together by the app on your phone;
• Live Activity tokens (iOS only) issued per active crawl so we can update your iOS Live Activity / Dynamic Island banner;
• a record of your premium subscription status (the product identifier and an expiry timestamp), kept in sync with Apple's StoreKit or Google Play Billing;
• the App Store Server Notifications that Apple sends us about your subscription (we keep the signed JWS message we receive from Apple as an audit record of the transaction);
• for Premium bought through Google Play: the purchase token Google issues for your subscription, which we bind to your account; the order IDs of its payments; and the subscription record that Google's Play Developer API returns when we ask it about that token, which we keep as an audit record of the transaction, labelled with the subscription's state or with the kind of notice that prompted us to ask. Besides the subscription's state, plan, and dates, that record can include the country or region you were billed in, the price and any offer applied, the identifier of your Beisl account (which the app passes to Google Play when you buy, so that the purchase can be tied to your account), and — if you cancel and answer Google's cancellation survey — your answer, including any text you type into it. Google also sends us Real-time Developer Notifications when something about a purchase changes; they carry the purchase token and the kind of change, and we use them only as a prompt to ask the Play Developer API again;
• crawl event records (arrived, left, rated, deviated, completed, reminded, position, member_joined, heading) generated as you participate in a crawl;
• the app version and build your account was used with (app build history), recorded at most once an hour per build so we can plan app updates; kept for 90 days after last use and deleted with your account (Sections 5 and 9). Only an app that reports its build to our server is recorded: the iOS app does, and the Android app currently does not; and
• standard server log information for each request to our API: a request identifier, the requesting user identifier (when authenticated), the HTTP method and path, the response status, error messages, the IP address the request came from, the app version and build number your device reports, and a high-resolution timestamp. For a limited period, while we confirm how older versions of the app identify themselves to our server, the log also records your device's operating-system version, taken from the app's network user agent. The Android app identifies itself only by its version number in its network user agent, which our logs do not record. These logs are written to standard output on our servers and rotated by the host operating system. They are not exported to a third-party log aggregator.

We do not collect:

• your real name, postal address, or phone number;
• your email address (Apple's and Google's identity tokens may contain it, but we discard it as described above);
• contacts from your address book;
• photographs, video, audio, microphone input, motion or fitness data, or HealthKit data;
• a device advertising identifier (Apple's IDFA or Android's advertising ID), and we do not use Apple's App Tracking Transparency framework because we do not track you across apps or websites;
• any biometric, government-issued, financial, employment, or health information; or
• anything from a “Sensitive Personal Information” category under California or EU law.

4.3 Location data

Location is the most privacy-significant category we handle. It deserves a careful description.

Location in the iOS app, outside a crawl. When you grant the iOS When In Use location permission, the app reads your location to about a kilometre — more precisely only during a crawl, as described below. It uses that reading on your phone to put the bars nearest to you first, and it sends it, straight from your phone, to Apple Maps (Section 6.2): as the area to search in when you look for a bar or a place, and to show the name of the city you are in. Outside a crawl it does not send your location to our server. The requests to Apple Maps carry nothing that identifies your Beisl account.

Location in the Android app, outside a crawl. The Android app asks for Android's location permission, which you grant “While using the app”, with precise or only approximate location — Android lets you choose. When you look for bars near you, search for a place, or open a map, the app takes a single, lower-accuracy reading from Google Play services on your phone. It does not send that reading to our server. It does send it, straight from your phone, to the public map and search services described in Section 6.2: as the area to look for bars in, or as a bias so that search results near you come first. The requests carry nothing that identifies your Beisl account, but those services do receive your phone's IP address with them.

Precise “Always” location during an active crawl. When you start or join a crawl, we ask for the iOS Always location permission. (The Android app never asks for Android's background-location permission, “Allow all the time”; it needs precise location to check you in, and asks you to allow it if you have granted only approximate location.) We then run two location-based services on your device, only while a crawl is in the active state and you are a member of it:

1. Geofencing. On iOS, the app registers a circular geofence of 100 metres around the stops of the crawl (iOS limits how many an app can watch at once, so on a long crawl it watches the stops around where you are). When you cross into one, the app takes precise readings for 30 seconds (10 seconds when you travel by taxi); if one of them puts you more than 30 metres from the bar, it drops the arrival, so walking past does not count. If you are still there, it asks whether you made it — in the app, or as a notification while the app is in the background — and writes an arrived crawl event once you confirm. Once you have been outside the 100-metre ring for the same 30 seconds (10 by taxi), it writes a left event. The geofence runs locally on your device using Apple's CoreLocation region monitoring, which iOS can wake the app for while the app is in the background.
   
   On Android, the app does not use Android's geofencing service. It works out its distance to each stop itself, on your phone, from location readings supplied by Google Play services' fused location provider: a reading about every 10 seconds while the app is open (or while it is confirming an arrival), and about every 30 seconds while it runs in the background. It registers an arrival once you have stayed within about 60 metres of a stop for 30 seconds (10 seconds when you travel by taxi) — a margin that widens when a reading is imprecise — and a departure once you are more than about 100 metres away.
2. Live position broadcast. While a crawl you are in is active and you have Share my live location switched on for that crawl, the app sends your latitude, longitude, and horizontal accuracy to our server every 30 seconds while you are using the app and every 60 seconds while it runs in the background, or whenever you have moved more than 50 metres, with a minimum 5-second floor between transmissions. If your phone has not moved more than about 30 metres for three minutes while the app is running in the background, transmission slows further: instead of a reading every 60 seconds it sends about one confirmation every 5 minutes, until you move more than about 50 metres, which resumes the normal schedule immediately. Your friends keep seeing your dot on the map throughout, and once the reading behind it is more than about a minute and a half old it is marked with how long ago it was confirmed. The Android app sends the same data on the same schedule, with one difference in when it slows down: it switches to the five-minute confirmations once you have been checked in at a stop, with the app in the background and nothing changing, for two minutes. These points are written to a crawl_events row of kind position. They reach two audiences:

• The other members of your crawl. The points are streamed live to them over a server-sent events connection so they can see the crew's positions on the active-crawl map. This is what the switch is for.
• Your friends, on the friends map — but only if you have also left Visible on the friends map on for that crawl. That map shows friends who are out tonight: your position, the bar you last checked into, and how far through your crawl you are. It never shows your planned route to someone who is not on the crawl.

Share my live location governs both. With it off, no position is sent at all — not to your crew, not to the friends map, and nothing is written to our server.

What sharing off does not hide is the bar you checked into. Beisl shows two different things about you, and they have two different switches:

• Your live position — a moving dot, updated continuously from your phone's GPS. Governed by Share my live location.
• The bar you last checked into — a single place you published deliberately, by tapping "I'm here" (or confirming an arrival). Governed by Visible on the friends map.

So with sharing off but friends-map visibility on, your friends see that you are out and which bar you last checked into — not where you are now, and not where you go next until you check in again. To show your friends nothing at all, switch Visible on the friends map off; that is what that switch is for, and it works independently of the other one.

The bar you checked into does not stay there all night. It ages, in two steps, measured from the moment you checked in:

• For the first 30 minutes your friends see it as where you are — “At Ginsberg”.
• From 30 minutes to two hours it dims and reads in the past tense — “Last seen at Ginsberg · 45 min ago”. It says you were there, not that you are.
• Two hours after the check-in it is gone. You disappear from the friends map entirely until you check in somewhere again (or switch live sharing back on). Checking in somewhere new starts the clock over at that bar.

That bound exists because a check-in is a statement about a moment, and it stops being true when you walk out. It applies to what your friends can see; your own crawl history is unaffected. If you are still broadcasting your live position, the two-hour rule does not remove you — your live dot is its own thing, and it expires on its own schedule (about two minutes, or up to about seven while you are standing still; see Retention of live position points).

Background position broadcasting. Position broadcasting continues while the Beisl app is in the background and while your screen is locked. That is deliberate: a crawl is mostly spent walking between bars with the phone in a pocket, and a foreground-only broadcast made your dot disappear from your crew's map exactly when they needed it. Three things about how we run it:

• It is visible. While background broadcasting is active, iOS shows its system background-location indicator (the coloured status-bar pill). Beisl deliberately leaves that indicator switched on rather than suppressing it, so you can always tell at a glance that the app is transmitting.
  
  On Android, the app keeps receiving location readings with the screen off through a foreground service, and Android requires such a service to show a notification: Beisl's ongoing “Active crawl” notification stays in your notification shade for as long as a crawl is active on your phone. The service runs for the whole crawl, because arrival detection needs it, whether or not you are sharing your position; what Share my live location decides is whether those readings are sent to our server.
• It is bounded to an active crawl and to your consent. The app asks iOS for background location only while a crawl is active and you have Share my live location on — not merely because some part of the app wants a location reading. It disarms when the crawl ends (immediately, not when you dismiss the end-of-crawl summary), when you leave the crawl, and when you switch sharing off. Outside those conditions the app requests no background location updates at all, and the system indicator is the honest signal of that: if it is showing, we are transmitting. On Android, the foreground service can be started only while the app is open on your screen and only for an active crawl, and it stops when the crawl ends, when you leave it, and when you sign out.
• It is throttled, and it does not pretend. While you are broadcasting, the app runs at roughly 10-metre GPS accuracy rather than best-available — in the background and in the foreground alike — which is where the battery saving comes from; a brief best-accuracy window runs only while the app is confirming an arrival at a stop. Your position expires on our server after about two minutes, so a timer wakes roughly every 20 seconds and re-sends your most recent reading if the regular interval described above has already passed — a check every 20 seconds, not a transmission every 20 seconds. That keeps the gap between transmissions under about 50 seconds while you are using the app, and under about 80 seconds while it runs in the background, even while nothing new is being measured. It re-sends only while that reading is less than 45 seconds old: if your phone genuinely stops producing readings, your dot goes dark rather than being kept alive artificially at a place you may have left. The Android app uses the same 20-second check and the same 45-second limit.
  
  Standing still in the background is the one deliberate exception to that pace. Once your phone has reported the same place for three minutes, the app stops repeating it every 80 seconds and sends about one confirmation every 5 minutes instead; our server keeps each of those confirmations for correspondingly longer, so the gap between them stays covered and your dot does not blink out (see Retention of live position points). The GPS itself does not switch off — the app keeps reading your position, which is how it notices the moment you move — it simply stops sending a reading that says what the last one said. Moving resumes the normal schedule immediately.
  
  The Android app goes one step further while you are checked in at a stop and standing still (see Live position broadcast above), on phones with a motion sensor that can tell it when you start walking: it stops taking location readings altogether, and re-sends the position it last had about every 5 minutes. It starts reading your location again as soon as your phone's motion sensor signals that you have started walking, when you open the app, or when a check it makes about every 10 minutes finds that you have moved; the motion signal is used on your phone only and is not sent to us.

How to stop location sharing. There are two routes, and the in-app one is the one we recommend.

1. In the app, per crawl (recommended). Open the active crawl, open the ⋯ menu, and switch Share my live location off. Four things happen: the app stops transmitting immediately on your device, without waiting for our server to confirm; as soon as the instruction reaches us, our server refuses any further position you send for that crawl; the position points we still hold for that crawl are deleted. Your live dot is gone from both audiences; your friends still see the bar you last checked into — for up to two hours after that check-in, dimmed to “last seen” after the first 30 minutes, and then not at all. Switching Visible on the friends map off removes it immediately rather than waiting for that. Both switches behave the same way when we cannot be reached. The change takes effect on your device straight away — transmission stops, or you leave the friends map — without waiting for our server; the instruction is stored on the device, survives closing the app, and is sent to us as soon as you are back online, however long that takes. Neither switch turns itself back on because a request to us failed. The one thing that discards a pending instruction is signing out of Beisl on that device before it has been sent: your device's pending changes are cleared with the rest of your session, because we will not replay one account's instruction under another account's sign-in. Signing out also stops all transmission, and the points we already hold stop being shown to anyone after two minutes — up to about seven for points sent while you were standing still — and are deleted automatically (see Retention of live position points below), so nothing keeps being shared either way. Arrival detection keeps working, and you can switch sharing back on in the same place.
2. In your phone's settings, for the whole app. Revoke the app's Location permission — on iOS in Settings → Privacy & Security → Location Services → Beisl; on Android in Beisl's app settings, under Permissions → Location. This route is all-or-nothing: it also disables the arrival detection described above, so the app will no longer notice when you reach a stop.

Retention of live position points. A background job on our server runs every 30 seconds and deletes every position event older than 120 seconds. The worst-case lifespan of a single position point on our server is therefore approximately two and a half minutes. The confirmations your phone sends while it reports you have not moved are the one exception: they arrive only about every 5 minutes (see It is throttled, and it does not pretend above), so a two-minute window would leave your dot missing from your crew's map between them. Those points are kept for up to 7 minutes instead — approximately seven and a half in the worst case, counting the same 30-second prune interval. Nothing else about them differs: they are the same kind of row, they carry nothing extra, and the first reading after you move again is an ordinary one on the ordinary window. The prune is automatic in both cases. In addition, switching Share my live location off for a crawl (see above) deletes your remaining position points for that crawl immediately.

How long a check-in stays visible to your friends. Separately from the live position above: the bar you checked into is shown to your friends for 30 minutes as where you are, then in the past tense until two hours after the check-in, after which you are no longer on the friends map at all. This is a visibility bound rather than a deletion: the check-in itself stays in your own crawl history and in the crawl's timeline for the members of that crawl, exactly as it did before — what expires is what your friends can see on the map.

No background location outside an active crawl. When no crawl is active, we do not run background location updates and we do not register geofences. The app declares the iOS location background mode in Info.plist and enables background location updates, but only for the duration of an active crawl in which you are sharing your position; the moment that ends, the app disables background location updates again. Arrival detection itself relies on CoreLocation region monitoring, which requires the iOS Always permission and works independently of background broadcasting — so revoking sharing in the app does not stop arrivals, and declining the Always permission does not stop sharing while you are using the app. The Android app holds no background-location permission at all: it receives location readings with the screen off only through the foreground service described above, during an active crawl.

Nearby bars during a crawl. On a spontaneous night out (one you start without planned stops), the iOS app looks up the bars around you when you open the list of bars to check in to or look for where to go next, and again as you walk, so that it can suggest checking in at the bar you are actually in. Each lookup sends your position at that moment, and anything you typed, to our server, which uses it only to answer that request — it puts the Beisl bars nearest to you first, does not store your position, and does not write it to its logs — and, straight from your phone, to Apple Maps, which lists the nightlife venues nearest to you. While the app is in the background it repeats these lookups only if you are sharing your live location.

To list the bars you might be checking in to, the Android app asks the Overpass service (Section 6.2) for the bars within 600 metres of where you are — when a spontaneous night out (one you start without planned stops) begins, and when you open the list of bars to check in to or to add as a stop. During a spontaneous night out it repeats that lookup as you walk, also while the app is in the background, so that its check-in suggestions match the bar you are actually in. These lookups carry your precise position at that moment, go from your phone directly to that service, and happen whether or not you are sharing your live location.

Walking directions during a crawl (iOS). The iOS app shows the walking route from where you are to your next stop, on the crawl map and in the mini-player's turn-by-turn directions. It asks Apple Maps for that route, straight from your phone, so each request carries your position and the location of the next stop; the route is requested again as you move.

Bar coordinates. When you create a new bar entry, the latitude and longitude you supply (typically picked from Apple Maps on iOS, or from OpenStreetMap data on Android) are stored as part of the bar record so it can be shown on a map and used for proximity searches. Bar coordinates are not personal data on their own, but a bar you created remains attributed to you (subject to anonymisation on account deletion — see Section 9).

4.4 Data we receive from third parties

• Apple sends us your Apple sub, and may send us your email address (which we discard), through the Sign in with Apple flow.
• Apple's StoreKit sends us signed transaction information when you start, renew, refund, or cancel a Premium subscription, both when your device submits the receipt and when Apple's App Store Server Notifications service posts a webhook to our /v1/premium/notifications endpoint. So that a purchase reaches the right account, the app attaches your Beisl user identifier to it when you buy (Apple's app account token); Apple keeps it with the transaction and sends it back to us with it.
• Google sends us your Google sub, and may send us your email address, name, and profile-picture link (which we discard), through the Sign in with Google flow.
• Google Play tells us about a Premium subscription bought on Android through the Google Play Developer API, which we ask when the app reports a purchase and whenever Google's Real-time Developer Notifications, delivered through Google Cloud Pub/Sub to our /v1/premium/play/notifications endpoint, tell us that the purchase has changed (Section 4.2). For the same reason as on iOS, the app attaches your Beisl user identifier to the purchase when you buy (Google Play's obfuscated account ID); Google keeps it with the purchase and returns it to us.
• Other Beisl users can attach you to a crawl by inviting you (using your user identifier), or send you a friend request, in which case our server stores the relationship between your account and theirs.

We do not buy personal data from data brokers, and we do not enrich your profile from advertising networks, social-media graphs, public records, or generative-AI providers.

5. How we use personal data, and the legal bases we rely on

We only process personal data for the purposes listed below. For users in the European Economic Area, the United Kingdom, and Switzerland, the table identifies the legal basis under Article 6(1) of the GDPR.

We do not use your data for advertising, profiling that produces legal effects on you, or automated decision-making within the meaning of Article 22 of the GDPR.

6. How we share personal data

We share personal data only with the categories of recipient described below, and only to the extent necessary for the purposes in Section 5.

6.1 Other Beisl users

The whole point of Beisl is to share a night out with the people you invite. Specifically:

• Anyone who looks you up in the friends search can see your handle, display name, and an indication of whether you are currently in an active crawl.
• Your friends can additionally see, on your friend profile, the bars you have visited (count and list) and your bar ratings and notes — but only while the “Share ratings” switch in your Profile is on. It is on by default, so your ratings are visible to your friends unless you turn it off, which you can do at any time.
• When you share a bar list with a friend (a Premium feature), they see the list's name, its bars and your handle and display name. A copy becomes their own list, as it was when you sent it; a list you build together is visible to everyone on it, including who has been invited and which member added each bar, until you remove them or they leave.
• The members of a crawl you are in can see your handle and display name, your current stop, your arrival and departure events, and the drink kind you logged, for as long as that crawl exists in their app. While the crawl is active and you have "Share my live location" on, they can also see your live position on the map — including while the app is in the background and your screen is locked. If you share one of your nights as an image, it names the friends who were out with you and counts everyone else; you choose whether and where to post it. A friend who shares a night you were both on may name you on that image by your display name; people who aren't their friends are only counted.
• People you have been out with can see Crew Highlights derived from the nights you were on together — never from nights they were not on. Only people you are friends with, and have been out with at least twice, may name you there (for example as their “partner in crime”); everyone else only ever counts you toward totals. Your ratings feed them only if you have “Share ratings” on, and blocking someone removes you from each other's highlights. If you share a Crew Highlight as an image, it shows the friends it names; you choose whether and where to post it.
• A person who holds a friend-invite link generated by you can call our public preview endpoint and see the inviter's handle and display name. They cannot see your user identifier from this endpoint.

If you block another user, the app stops showing them your activity and stops showing you theirs.

6.2 Service providers (data processors)

We use the following third parties to operate the Service. Each of them processes personal data on our instructions and is bound by a written contract (a Data Processing Agreement, or equivalent terms in their standard developer or hosting agreement) that meets the requirements of Article 28 of the GDPR.

• Apple Inc. (One Apple Park Way, Cupertino, CA 95014, USA) — provides Sign in with Apple identity verification, the Apple Push Notification service, the StoreKit in-app purchase platform, App Store Server Notifications, the iOS operating system, and distribution through the App Store. Apple's privacy policy is available at https://www.apple.com/legal/privacy/.
• Google LLC (1600 Amphitheatre Parkway, Mountain View, CA 94043, USA) — provides Sign in with Google identity verification in the Android app; Firebase Cloud Messaging, through which we deliver notifications to the Android app (Section 4.2 describes what those messages carry); the Google Play Developer API and Google Cloud Pub/Sub, through which Google Play tells us the state of a Premium subscription bought there (Real-time Developer Notifications); Google Play services on your phone, which supply the Android app's location readings and present the Sign in with Google and Google Play purchase screens; the Android operating system services the app relies on; and distribution through Google Play. For Google Play purchases, Google acts as merchant of record, as described below. Google's privacy policy is available at https://policies.google.com/privacy.
• Hetzner Online GmbH (Industriestr. 25, 91710 Gunzenhausen, Germany) — provides the virtual machine on which our API, database, and web server run. All Beisl databases and application servers are physically located in Germany. Hetzner's data-protection information is available at https://www.hetzner.com/legal/privacy-policy/.
• Brevo (Sendinblue SAS) (106 boulevard Haussmann, 75008 Paris, France) — transactional-email relay. Every moderation report you file is stored in our database, and our backend also emails it to our admin address through Brevo. That email contains the handle, display name, and user identifier of the person who filed the report, the reported bar or user, the reason given, and the time it was filed. Brevo is established in France and processes data within the EEA. Brevo's privacy policy is available at https://www.brevo.com/legal/privacypolicy/.

When you buy Premium on Android, Google acts as merchant of record: Google Play takes the payment and processes your payment details under its own terms and its privacy policy (https://policies.google.com/privacy). We never receive your card or payment details; we receive only what the Google Play Developer API returns about your subscription. To keep your Premium status in sync with Google Play, we keep against your account the purchase token Google issues for your subscription, the order IDs of its payments, the state of the subscription (for example active, in a grace period, cancelled or expired) and its dates, together with the subscription record Google returns as an audit copy of the transaction (Section 4.2 lists what that record can contain). These are deleted when you delete your account (Section 9).

Apple Maps (iOS app). The iOS app draws its maps, searches for places, turns a position into an address or a city name, and works out walking directions with Apple's MapKit. Your phone sends those requests to Apple directly: they do not pass through our server and carry nothing that identifies your Beisl account, but they do carry what each one needs — the part of the map you view, what you search for, and, where a request is about where you are, your position. Apple handles them under its own terms and its privacy policy (https://www.apple.com/legal/privacy/).

Map and place-search services (Android app). The Android app draws its maps and looks up places using public services built on OpenStreetMap data. Your phone contacts them directly: the requests do not pass through our server and carry nothing that identifies your Beisl account, though each service receives your phone's IP address with every request. We use these services without an account or API key; they are not our processors, and they handle requests under their own terms and privacy policies.

• OpenFreeMap (tiles.openfreemap.org) — supplies the map styles, fonts, and map tiles, and so receives the parts of the map you view.
• Photon, a search service run by komoot (photon.komoot.io) — answers the search boxes as you type: it receives what you type and, when the app has your location or you are looking at a map, that position as a bias for the results.
• Nominatim, the OpenStreetMap Foundation's geocoder (nominatim.openstreetmap.org) — receives what you search for when you press search, with an area reaching one degree of latitude and longitude on each side of your location (or of the city you chose to search in) as a bias, and the coordinates of a single point when the app looks up its address — for example the pin you place for a new bar.
• Overpass API (overpass.kumi.systems, with overpass-api.de as a fallback) — receives a position and a radius when the app looks for bars nearby: around you when you ask it to find bars near you, and during a crawl as described in Section 4.3 under Nearby bars during a crawl.

We do not use any third-party advertising network, attribution provider (AppsFlyer, Adjust, Branch, Singular, Kochava, etc.), analytics SDK (Firebase, Mixpanel, Amplitude, Segment, PostHog, etc.), or crash-reporting SDK (Sentry, Crashlytics, Bugsnag, etc.) inside the Service. The Android app contains Google's Firebase Cloud Messaging library only to receive notifications; it contains no Firebase Analytics or Crashlytics.

6.3 Legal disclosures

We may disclose personal data when we believe in good faith that disclosure is necessary to:

• comply with a court order, subpoena, search warrant, or other lawful request from a competent authority;
• enforce our Terms of Service or investigate suspected violations;
• protect the rights, property, or safety of Beisl, our users, or the public, including action against fraud, abuse, or imminent harm; or
• effect a corporate transaction such as a merger, acquisition, financing, reorganisation, bankruptcy, or sale of all or part of our assets, in which case the recipient will be bound to honour this Policy or give you notice and a meaningful choice.

If we receive a request from a government or law-enforcement body, we will challenge requests we consider overbroad, and we will tell you about the request unless we are legally prohibited from doing so.

6.4 No sale or sharing for cross-context behavioural advertising

We do not sell your personal data, and we do not share it for cross-context behavioural advertising, within the meaning of the California Consumer Privacy Act (as amended by the California Privacy Rights Act), the Colorado Privacy Act, the Virginia Consumer Data Protection Act, or any similar U.S. state law. We have not done so in the previous twelve months.

7. International data transfers

Our servers and database are located in Germany. Most of your data therefore stays inside the European Economic Area.

A subset of processing necessarily involves transfers outside the EEA:

• Apple Inc. (USA). Sign in with Apple identity tokens are signed by servers located in the United States, Apple Push Notification service messages are routed through Apple's global infrastructure, and StoreKit transaction verification involves Apple's servers. Apple is, at the time of writing, certified under the EU–U.S. Data Privacy Framework, which the European Commission has recognised as providing an adequate level of protection (Commission Implementing Decision (EU) 2023/1795). Where the Data Privacy Framework does not apply, we and Apple rely on the European Commission's Standard Contractual Clauses (Decision 2021/914) as a transfer safeguard.
• Google LLC (USA). Google LLC is established in the United States, and Sign in with Google, Firebase Cloud Messaging, the Google Play Developer API, and Google Cloud Pub/Sub involve its servers, which may be located outside the EEA. Google LLC participates in the EU–U.S. Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795), and Google's data processing terms incorporate the European Commission's Standard Contractual Clauses (Decision 2021/914) as a transfer safeguard. When you buy Premium on Android, Google processes your payment as merchant of record under its own terms.
• Map services. Apple Maps and the public services the Android app contacts directly (Section 6.2) receive those requests from your phone, not from us, and process them under their own terms and privacy policies; we have no say in where they process them.
• Brevo (Sendinblue SAS, France). Brevo is established in the EEA, so its use does not in itself involve a transfer of personal data outside the EEA. If Brevo subprocesses any portion of the processing to a non-EEA recipient, we and Brevo rely on the European Commission's Standard Contractual Clauses (Decision 2021/914) and Brevo's published transfer safeguards.

You can request a copy of the safeguards we rely on by emailing hello@beisl.pub.

8. Security

Sensible security is non-negotiable for an app that touches your real-time location. We implement and maintain technical and organisational measures appropriate to the risks of the processing, including:

• TLS 1.2 / 1.3 (with certificates issued by Let's Encrypt and renewed automatically) for every connection between the Beisl app, the Beisl website, and our API;
• session tokens stored in the iOS Keychain with the kSecAttrAccessibleAfterFirstUnlock accessibility class, so they require the device to be unlocked at least once after boot before they can be read, and in the Android app in storage encrypted with AES-256 under a key held in the Android Keystore;
• an Android app that excludes everything it stores from Android's cloud backup and from device-to-device transfer, so neither your session nor anything else the app keeps is copied off your phone that way;
• requests from the Android app to third-party map and search services that never carry your Beisl session token;
• isolated Docker networks for inter-service traffic on our server;
• a hardened, distroless container image for the API binary;
• principle-of-least-privilege database roles;
• bcrypt-equivalent hashing or signed envelopes for any secret material we hold (we do not store passwords, since authentication is delegated to Apple or Google);
• rate limiting and authentication on every non-public endpoint;
• automatic deletion of live position points within ~2 minutes, or ~7.5 minutes for stationary-confirmation points (see Section 4.3);
• no inclusion of personal data in URLs or query strings beyond opaque identifiers; and
• a strict change-management process whereby every backend change is reviewed and tested in CI before deployment.

No system is perfectly secure. If we become aware of a security incident affecting your personal data that meets the threshold for notification under Article 33 GDPR, we will notify the competent supervisory authority within 72 hours. If the incident is likely to result in a high risk to your rights and freedoms, we will also notify you under Article 34 GDPR using the contact information available to us, which in the absence of an email address will be a notice inside the app.

9. How long we keep your data

We keep personal data only for as long as we need it for the purposes set out in this Policy.

When you delete your account (see Section 10), your record is soft-deleted: the deleted_at field is set, your handle is cleared so it can be reused, and your Apple sub or Google sub is removed so that you can sign up again. Records that depend on you are then handled as follows:

• Your device tokens (APNs and FCM), Live Activity tokens, ratings, try-list entries, the bar lists you own (and their entries, unless a list is handed over as described below), friendship rows, crawl-member rows, app-build history, premium transaction records (App Store and Google Play), and Google Play purchase tokens are hard-deleted by explicit scoped DELETE statements executed in a single transaction. (Your account row itself is not row-deleted but tombstoned — deleted_at is set and your handle cleared, as noted above — so these deletions run directly rather than through a foreign-key cascade.)
• Your memberships of shared lists and any pending list invitations you sent or received are hard-deleted, and your name is removed from the bars you added to other people's lists (the bars stay on those lists). A list you sent as a copy stays with the friend who accepted it, without your name on it. A shared list you own is not deleted with your account if friends are on it: it passes to the member who joined it first, so their list survives.
• Bars you created, crawls you owned, and moderation reports you filed are anonymised: the creator, owner, or reporter field is rewritten to a sentinel “deleted user” identifier — so the venue and shared crawl history other people have built on survive, and any open moderation case remains actionable, without being traceable back to you.
• We keep no purchase records after erasure. We are not the merchant of record for Premium: Apple sells it through the App Store and Google through Google Play, and each keeps its own records of your purchases under its own terms and privacy policy. Our copies are deleted with your account, as described above, and age out of our backups like everything else.

Where data must be retained for backup or legal reasons after account deletion, it is no longer used for any other purpose and is securely deleted at the end of the retention period.

10. Your privacy rights

Subject to applicable law, you have the following rights with respect to your personal data:

• Access. You can ask us for a copy of the personal data we hold about you. Most of it is already visible to you in the app: open Profile, your friend profile, the rating sheet for any bar you have rated, and the crawls list. If you would like a structured export beyond what the app shows, email us and we will provide one within 30 days.
• Rectification. You can update your display name at any time from the Profile screen. Your handle cannot be changed in the app once you have chosen it (Section 4.1); if it is wrong, email us and we can correct it. For anything else, email us.
• Erasure (“right to be forgotten”). You can delete your entire account at any time from inside the app: Profile → Account → Delete Account on iOS, or Profile → Delete account on Android. Deletion takes effect within seconds; the consequences are described in Section 9. You can also email us if you prefer.
• Restriction. You can ask us to restrict processing in the limited cases set out in Article 18 GDPR.
• Portability. You can ask us to provide the personal data that you provided to us in a structured, commonly used, machine-readable format.
• Objection. You can object to processing carried out on the basis of our legitimate interests on grounds relating to your particular situation. If you object, we will stop unless we can demonstrate compelling legitimate grounds that override your interests, rights, and freedoms.
• Withdrawal of consent. Where we rely on consent (for example, for the iOS Always location permission or the Android location permission, for live position broadcast inside a crawl, or for push notifications), you can withdraw consent at any time. For live position broadcasting there are two independent routes: in the app, per crawl, by switching Share my live location off in the crawl's ⋯ menu — this stops transmission immediately and leaves arrival detection working — or in your phone's settings, by revoking the app's Location permission (on iOS in Settings → Privacy & Security; on Android in Beisl's app settings, under Permissions), which stops sharing for every crawl but is all-or-nothing and also disables arrival detection at your stops. Other permissions (notifications, and on iOS Always location) are withdrawn in your phone's settings. Withdrawing consent does not affect the lawfulness of processing that took place before you withdrew it.
• Complaint to a supervisory authority. If you live in the EEA, the United Kingdom, or Switzerland, you have the right to lodge a complaint with your local data protection authority. As Beisl is operated from Sweden, our lead supervisory authority is the Integritetsskyddsmyndigheten (IMY), Drottninggatan 29, plan 5, 104 20 Stockholm, imy@imy.se. If you live in another EEA country, you may also lodge your complaint with the supervisory authority of your habitual residence or place of work.

To exercise any of these rights, email hello@beisl.pub from the email address associated with your Apple ID or Google Account, or include enough information for us to confirm that you are the account holder (typically your handle and the approximate date you signed up). We do not charge a fee unless your request is manifestly unfounded or excessive.

10.1 Additional rights for California residents

If you are a California resident, the California Consumer Privacy Act, as amended by the California Privacy Rights Act (“CCPA”), gives you the rights described above and the following additional rights:

• the right to know the categories and specific pieces of personal information we have collected about you;
• the right to know the categories of sources from which we collected your personal information, the business or commercial purposes for collecting it, and the categories of third parties with whom we shared it;
• the right to delete personal information we have collected from you;
• the right to correct inaccurate personal information;
• the right to opt out of the sale or sharing of personal information; and
• the right to limit the use or disclosure of sensitive personal information.

We do not sell or share personal information within the meaning of the CCPA, and we do not collect or use sensitive personal information beyond what is strictly necessary to provide the Service. We will not discriminate against you for exercising any of your CCPA rights.

The categories of personal information we have collected in the previous twelve months, mapped to the categories listed in Cal. Civ. Code § 1798.140, are: identifiers (Apple sub or Google sub, our user UUID, device tokens, Google Play purchase tokens, IP addresses), customer-record information (handle, display name), commercial information (Premium subscription status), geolocation data (the live position points described in Section 4.3, retained for ~2 minutes, or up to ~7.5 minutes for stationary-confirmation points), internet or other electronic-network activity information (server logs, crawl events), and inferences are not drawn.

10.2 Additional rights for residents of other U.S. states

If you live in Colorado, Connecticut, Virginia, Utah, Texas, Oregon, Montana, or any other U.S. state with a comprehensive consumer-privacy statute in force, you have rights substantially equivalent to those listed above. To exercise them, email hello@beisl.pub. If we deny your request, you may appeal by replying to our denial; if your appeal is denied you may contact your state Attorney General.

11. Children

Beisl is intended for adults. The Service is built around the social experience of going to bars, and Premium content includes bar-related features. You must be at least the legal drinking age in your jurisdiction (and in any case at least 18 years old) to create an account. We do not knowingly collect personal data from anyone under 18.

If you believe a person under 18 has provided personal data to us, please contact us at hello@beisl.pub and we will delete the account.

In the App Store, Beisl is rated 17+ to reflect this restriction.

12. Changes to this Policy

We may update this Policy from time to time to reflect changes in the Service, in our practices, or in applicable law. When we do, we will:

• update the “Last updated” date at the top of this document;
• post the revised Policy at the same URL where you found this one; and
• if the changes are material — for example, if we add a new category of recipient, a new processing purpose, or a new legal basis — we will give you prominent notice inside the app and, where required by law, ask for your renewed consent before the change takes effect.

Past versions of this Policy are available on request.

13. Definitions and references

• “Beisl app” — the iOS application distributed through the Apple App Store under the bundle identifier pub.beisl.app, and the Android application distributed through Google Play under the package name pub.beisl.app.
• “Apple sub” — the value of the sub claim in an identity token issued by Apple's Sign in with Apple service. It is unique to a given Apple ID and to a given relying party (here, Beisl); it cannot be used to look up the underlying Apple ID.
• “Google sub” — the value of the sub claim in an ID token issued by Google's Sign in with Google service: Google's stable identifier for your Google Account.
• “Crawl” — a planned sequence of bar visits scheduled in the app, with optional friends.
• “Crew” — the set of users who are members of a particular crawl.
• “Geofence” — a virtual circular boundary around a geographic point. In the iOS app it is monitored by iOS so the operating system can wake the app when the device crosses it; the Android app checks it itself, on your phone, against its location readings.
• “Live position event” — a row in the crawl_events table of kind position, containing a latitude, a longitude, a timestamp, and the user identifier of the device that produced it.
• “Premium” — the auto-renewing subscription tier of Beisl, provided through Apple's StoreKit on iOS (product identifiers pub.beisl.app.premium.annual.v2 and pub.beisl.app.premium.monthly.v2) and through Google Play Billing on Android (the subscription premium, with the base plans monthly and annual).

This Policy was prepared in English. In case of discrepancy with any translation, the English version controls.

© 2026 Timmo Caspar Achsel. All rights reserved.