Privacy Policy

We designed Detroit Meets with a privacy-first approach. In plain terms:

• We do not display advertisements or monetize user data in any form.
• We do not employ third-party analytics services, tracking pixels, or behavioral profiling tools.
• We do not sell, rent, or trade personal information. We disclose limited data only to service providers necessary to operate and secure the Service, as described in Section 9.
• We collect only the minimum information necessary to operate and secure the Service.

You may browse all publicly listed events, view event details, and access external map links without creating an account or providing personal information.

If you choose to submit a meet listing for review using the public submission form at /submit, you voluntarily provide: a meet title, venue description, optional notes, a social link or website, optional start and end dates and times, your name, and an email address or social handle so we can follow up. No account is required. Your name and contact details are stored in our database and are visible only to site administrators — they are never shown publicly on the Service. Submissions may be approved and published as a meet listing, rejected, or removed as spam at our discretion. See Section 7 for how we use your IP address for rate limiting on this endpoint.

You may check the review status of your submissions without signing in at /submit/status by entering the same contact detail you provided on the form and/or the anonymous sync ID stored in your browser or app (see Section 7). The lookup returns only submissions that match the values you enter. Anyone who knows your contact detail or sync ID could retrieve the same status information, so treat those values like lightweight credentials.

We do not set tracking cookies, deploy browser fingerprinting techniques, or build user profiles. We do, however, operate on standard hosting infrastructure that processes limited technical data to deliver pages and protect against abuse; see Sections 7 and 8 for specifics.

When you choose to open a venue location in a third-party maps application (such as Apple Maps, Google Maps, or Waze), you will be redirected to that provider's platform. We transmit only the venue name and street address necessary to display the location — no user identifiers or device information is included. Your use of those services is governed by their respective privacy policies.

Location-based discovery features (such as "Near me") are opt-in. In a regular web browser, selecting these features triggers your browser's standard geolocation prompt. Your approximate coordinates are used in-memory on your device to sort and filter meets by distance; they are not transmitted to our servers, stored, or shared. You can deny the prompt and continue using the rest of the Service.

Detroit Meets is available as a native iOS app on the Apple App Store. The app loads the same website you see in a browser inside an embedded web view pointed at our servers. Data collection and use for account holders, public visitors, sessions, and event content are the same as described elsewhere in this policy.

When you follow links that leave our site (for example, opening a map or an external ticketing page), those destinations open in the system browser or maps app where applicable; their privacy policies apply there.

Organizers uploading a cover image from within the iOS app may see an iOS permission prompt requesting access to your photo library. We only receive the image file you select for the upload; we do not access, enumerate, or retain any other photos.

If you use map discovery features such as Near me, the iOS app may request location access. Location is used to show nearby meets, sort by distance, and support location-based discovery features. You can deny location access and continue using the rest of the Service.

If you choose to enable notifications, the iOS app requests notification permission for three purposes:

• Meet reminders — reminder alerts you explicitly configure for saved meets are scheduled as on-device local notifications and fire without a network connection. The reminder fire-times themselves are also mirrored to our servers as part of saved-meet sync (see Section 7) so your reminders carry across devices, but the alert is still scheduled and shown locally by iOS.
• Featured post alerts (remote push) — when we publish a new featured blog post, we send a push notification directly to your device via Apple Push Notification service (APNs). To do this, the iOS system generates a device-specific APNs token that our app transmits to our servers, where it is stored alongside a randomly generated installation identifier (a UUID we create and keep in your device's local storage). We use this token only to deliver the featured-post alert and to deactivate the record if the token becomes invalid. We do not use it for advertising or share it with third parties other than Apple's APNs infrastructure, which routes the delivery. You can revoke notification permission at any time in iOS Settings, which prevents further pushes; you can also clear the app's local storage to remove the installation identifier.
• Saved-meet change alerts (remote push) — when an organizer materially changes a meet you have saved (for example, the date, time, location, or cancellation status), our server may send a push notification to the installations that have saved that meet, using the same APNs delivery and installation identifier described above. The change-alert lookup is keyed only by the anonymous installation identifier and the public meet ID; no account or personal information is required. You can disable change alerts by un-saving the meet, by revoking notification permission in iOS Settings, or by clearing the app's local storage.
• Meet submission status alerts — if you submit a meet for review using the public submission form and your browser or app has an anonymous installation identifier (see Section 7), our server writes a meet-submission status notification to your per-install inbox when your submission is approved (with a link to the published meet when applicable) or rejected. If you also use the native iOS app with notification permission granted and an APNs device token on file, we may additionally send a remote push with the same content. No account is required. You can prevent remote pushes by revoking notification permission in iOS Settings. Clearing local storage generates a new installation identifier on that device unless you link an existing sync ID manually (Section 7).
• Morning-of meet reminders with weather — when you choose the "Morning of (8:00 AM)" reminder preset for a saved meet, iOS fires the alert as an on-device local notification at 8:00 a.m. America/Detroit on the meet day. At schedule time, we make one server call to our weather proxy (which forwards the meet's public coordinates and the meet start time to Open-Meteo — see Section 9) and bake the resulting temperature and chance of rain into the notification body so the alert is informative even if your device is offline at fire time. We do not store the snapshotted forecast on our servers, and the proxy request contains no user identifier or device information.
• Live Activities for saved meets — for a saved meet that is starting soon, iOS may show a Live Activity on the Lock Screen and in the Dynamic Island with a countdown and (optionally) a live drive-time estimate. Two Apple Push Notification service token kinds are involved: (a) a single per-install "push-to-start" token that lets our server ask iOS to start an activity without the app being foregrounded, and (b) a short-lived per-activity "update" token used by our server to push phase changes (saved → upcoming → starting → live → ended) and ultimately end the activity. Both tokens are stored on our servers keyed only by the anonymous installation identifier and the public meet ID, deactivated when invalid or when the activity ends, and used solely for activity delivery. While an activity is active, the app may briefly use on-device location to refresh the drive-time estimate — see Section 9 for the bounded scope, the "When in use" permission model (we never request "Always"), and the optional one-per-minute drive-minutes echo to our server.
• Leave-by alerts (remote push) — when the server-side dispatcher determines that you should leave for a saved meet, it may send a brief APNs alert. There are two variants: an early heads-up roughly five minutes before the computed leave-by time, and a single urgent banner when the phase becomes "leave soon" or "leave now." These alerts can fire for any device that has saved a meet, granted notification permission, and has an APNs push token on file — a Live Activity does not need to be running. When drive-minutes echo data is available from an active Live Activity (see Section 9), the timing is traffic-aware; without it, the alert is timed relative to the meet's published start time. Alerts are best-effort, at most twice per meet per approaching window, and suppressed entirely once the app reports that you are likely en route (we record only a server-side timestamp, leaveByPushSuppressedAt, to remember the suppression). All alert rows are keyed only by the anonymous installation identifier and the public meet ID and use the same APNs delivery path described above.
• On-device traffic-aware "leave by" local notifications — in addition to the remote alerts above, the iOS app schedules its own local notifications for upcoming saved meets. A short background-refresh task (registered as com.detmeets.leaveByRefresh) wakes up periodically and uses MapKit to compute a traffic-aware ETA from your device to each saved venue, then pre-schedules one local notification per meet for the resulting leave-by time. Limits: only saved meets starting within the next three hours, never more than the soonest thirty-two meets, and only when notification permission is granted. Location runs strictly under the When in use authorization (we never request "Always") with a coarse (~100 m) accuracy hint. Your coordinates are used only on your device — they are not transmitted to our servers and are not stored after the refresh task completes. If a remote leave-by alert (above) has already been delivered for a meet, the local notification is skipped so you do not get duplicates.

iOS system surfaces (widgets, Spotlight, Siri). On iOS, the app also exposes your saved-meet data to system surfaces that read from a shared App Group container on your device:

• Home Screen and Lock Screen widgets — the "Next saved meet" widget reads from the App Group container so iOS can keep it refreshed without launching the app. Only the saved-meet snapshot fields already cached on your device are shown.
• Spotlight indexing — when you save a meet, the app submits a CSSearchableItem to iOS Core Spotlight containing the meet title, a short description, the venue, host or city keywords, and the cover image URL so the saved meet appears in iOS system search. Items are removed when you un-save the meet or clear the app's local storage. The index lives in iOS itself; we do not see your Spotlight queries.
• Siri and App Intents — App Intents such as "What's my next Detroit meet?", "Save this meet" (from a URL), and "Open the map" let Siri and Shortcuts read the same on-device App Group data or deep-link into the app via the detmeets:// URL scheme. Voice transcripts and recognition are handled by Apple under its own policy and are not transmitted to us.

Across all three surfaces, no new categories of data are sent to our servers — they are read-only views of the saved-meet snapshots already described in Section 7. Clearing the app's local storage removes them.

iOS Share Extension. The app installs a Share Extension so you can share a link from another app (typically Safari or Instagram) directly to the submit form. When you tap the Detroit Meets icon in the system share sheet, the extension extracts the shared URL and opens it inside an embedded Safari View Controller pointed at our submit page. Because it is a Safari View Controller, it inherits your Safari cookies for detmeets.com. In practice this only matters for organizers who happen to be signed in to the site in Safari; the share extension does not read your other cookies, browsing history, or any data outside that single request, and the host app does not see your Safari cookie jar. The extension does not transmit anything to our servers beyond the page-fetch described in the paste-a-link section of Section 9.

Downloading or updating the app from Apple's App Store (or participating in TestFlight) is subject to Apple's privacy policy and terms. Apple may process account and device information related to the store and platform independent of us.

Account creation is restricted to invited event organizers and site administrators. Public registration is not available. We do not ask for or use real email addresses, full legal names, phone numbers, or physical addresses for account holders.

When an organizer account is provisioned, the following data is stored in our database:

• Username — a chosen display identifier used for sign-in and visible to other staff members. This does not need to be a real name.
• Display name — optional human-readable label shown alongside the username.
• Synthetic email placeholder — our authentication library requires an email field. We generate a non-deliverable placeholder derived from the username (for example username@staff.local). We do not send email to this address and we do not treat it as a contact channel.
• Password — cryptographically hashed and salted before storage. We do not store, transmit, or have access to plaintext passwords at any time. A "must change password" flag is stored when an administrator creates or resets a password, and cleared the first time the user changes it themselves.
• Account permissions — a stored list of permission flags (for example, the ability to manage meets, manage staff accounts, review public meet submissions, or view the audit log) that governs what an account can do within the platform. A legacy role label ("administrator" or "organizer") is derived from these flags for compatibility with our authentication library and is not used for new authorization decisions.
• Internal staff notes — an optional short memo about a staff account, written by another staff member with permission to manage staff accounts. Internal notes are visible only inside the staff admin area and are never shown publicly.
• Moderation metadata — a boolean indicating whether the account is disabled, an optional short reason shown at sign-in if so, and an optional expiry for timed disables.
• Timestamps — account creation and last-update timestamps used for record-keeping.

No email verification is required and no additional personally identifiable information is necessary to create or use an organizer account.

Upon successful authentication, we generate a session record that contains: a cryptographic token, the IP address that initiated the sign-in, the browser user-agent string, creation and expiry timestamps, and (when applicable) an indicator that the session was created by an administrator impersonating the account. This information is used exclusively to maintain authenticated state, to populate the admin sessions view so that administrators can spot unfamiliar sign-ins, and to detect potentially unauthorized access.

If you sign in while using the iOS app, the same session cookie and server-side session record apply as when you sign in on the website; we do not collect additional categories of personal information solely because you used the app.

Sessions expire automatically after a defined period of inactivity. Site administrators may view active sessions for staff accounts (IP address, user-agent string, and expiry time as stored in each session record) and may revoke individual sessions or sign an account out everywhere.

Events published on the Service contain the following organizer-provided information: event title, optional description, venue name, street address, start and end dates and times, an optional cover image URL, optional latitude and longitude derived from the venue and address (for mapping and calendar accuracy), and optional external links (for example, a social media post or ticketing page). This content is provided voluntarily by organizers and is displayed publicly on the Service.

Cover images may be pasted as a link or uploaded through our admin tools. Uploaded files are sent to a third-party host (see Section 8); we store only the resulting image URL on our systems.

We also maintain a record of which staff accounts are associated with each event listing, as well as any public-facing host links (such as Instagram profiles or websites) that organizers elect to display.

We keep a minimum amount of ephemeral, non-marketing technical data needed to run and secure the Service:

• Client error reports — when the web application encounters an unrecoverable rendering error, the error boundary sends the error name, message, a short digest, a truncated stack trace, and the URL of the page where the error occurred to our server, which writes them to our hosting provider's logs. These reports do not include cookies, session identifiers, or account data.
• Address autocomplete rate limiting — the administrative address-suggestion endpoint uses the request IP address as an in-memory key to prevent abuse of the upstream OpenStreetMap service. Entries are held only for a short sliding time window and are not written to the database.
• Durable rate-limit buckets — for endpoints that need to share rate-limit counts across serverless function instances (such as the public meet submission, the paste-a-link prefill proxy, and saved-meet cloud-sync writes), we keep a small Postgres bucket table containing a namespace, a client key (typically the request IP address), a current token count, and a refill timestamp. Rows exist only for the duration of the active rate-limit window and are not associated with submission content, account data, or installation identifiers.
• Meet submission rate limiting — the public meet-submission endpoint uses the request IP address as a short-lived rate-limiting key to prevent automated or abusive submissions. The IP address is held only for the duration of the rate-limit window (in-memory and/or in the durable rate-limit bucket described above); it is not stored in the application database or associated with submission content.
• Meet submission records — when you submit a meet for review, the following information is written to our database: the meet title, venue description, optional notes, social link or website, optional start and end dates and times, your name, and your contact detail (email address or social handle). When anonymous cross-device sync is enabled and your browser or app has an installation identifier, we also store that identifier with the submission so we can write a status notification to your inbox (and, on iOS, optionally deliver a remote push) when your submission is reviewed. Submissions made without an installation identifier store no sync key beyond your voluntarily provided contact detail. Submission records are visible only to site administrators. Approved submissions may be published as public meet listings; submitter name and contact are never shown publicly. We retain submission records for moderation accountability and may delete them on request — see Section 12.
• Local preferences — the website may use your browser's local storage to remember lightweight UI preferences, such as whether you have dismissed a banner promoting a blog post. These entries stay on your device, contain no personal data, and are not transmitted to our servers.
• Appearance preferences (on-device only) — your theme choice (system / light / dark) and the optional "true black (OLED)" toggle are stored only in your device's local storage. They are not mirrored to our servers, used for analytics, or shared with third parties.
• Submit form drafts (on-device + optional cloud mirror) — to keep you from losing work when you switch apps or refresh the page, the public meet submission form auto-saves what you have typed (title, venue, notes, social link, your name, your contact detail, and the optional start/end dates and times) to your device's local storage every ~500 ms. The draft is cleared automatically when you successfully send the submission and can be cleared manually with the "Clear saved draft" button. When anonymous cross-device sync is enabled, the same draft is also mirrored to our servers as a single JSON blob attached to your anonymous installation identifier (column anon_user_pref.submit_draft_json) so the draft survives clearing local storage on one device, reinstalling the app, or moving to a new device when you link the same sync ID. Drafts are never shown publicly and are visible only to site administrators after the submission is sent (see "Meet submission records" above).
• Notification inbox (server-side, per install) — when our servers send you a remote push (featured-post alert, saved-meet change alert, meet-submission status alert, or status note), we also write one inbox row keyed to your anonymous installation identifier so the /inbox page (website or native app) can replay recent notifications. Each row stores the installation identifier, the notification kind (for example meet change, blog featured, meet-request status, or general meet status updates), an optional public meet ID, the on-screen title and body, an optional in-app deep link, the creation time, and a flag for when you read it. Inbox rows are pruned nightly after approximately 90 days and contain no account data, advertising identifiers, or contact details.
• Per-meet notification mute (server-side, per install) — if you tap "mute future alerts" on a row in the in-app inbox, we write a small mute row keyed by your anonymous installation identifier and the public meet ID (and a timestamp) so our server-side dispatcher stops sending remote pushes and inbox rows for that specific meet to that specific install. You can clear the mute from the inbox UI; the row contains no account data and is removed when you un-mute the meet or clear the app's local storage and the dispatcher cleans up orphaned mutes.
• Map tile cache budget (on-device only) — in Menu → Offline map cache you can choose how much storage the map worker is allowed to use for saved-meet tiles (currently 25, 50, or 100 MB). The chosen budget, the cached tile bytes themselves, and the count of tiles per saved meet stay on your device; nothing about the budget or the cache is reported to our servers.
• Saved meets (on-device + optional cloud mirror) — if you use the "save" feature, the list of meets you have saved is stored in your browser's local storage (and, in the iOS app, in an equivalent on-device store) so your saved list is available between sessions and works offline. No account is required to save meets. Anonymous cross-device sync is enabled by default in current Detroit Meets builds (site operators may disable it via configuration). When sync is on, your saved list is also mirrored to our servers, keyed only by an anonymous installation identifier (see "Anonymous installation identifier" below). The cloud mirror is used so that re-installing the app or moving to another device keeps your saved list, and so that we can send the optional saved-meet change alerts described in Section 3. The mirror contains: the public meet ID, the time you saved it, your reminder presets and fire-times for that meet, and a snapshot of public meet fields (title, venue, address, start/end times, description, cover image URL, coordinates). It does not contain account credentials, contacts, advertising identifiers, or device fingerprints.
• Offline meet cache (on-device) — to keep saved meets viewable with a weak or missing connection (for example, inside a parking structure), the app stores a snapshot of each saved meet on your device. That snapshot may include the meet title, venue name, street address, start/end times, description, cover image URL, and coordinates. All of this content is already public on the Service; storing a local copy simply avoids re-fetching it. Clearing the browser's storage (or the app's storage on iOS) removes the cache.
• Reminder configuration (on-device + optional cloud mirror) — if you schedule a reminder for a saved meet, the chosen preset (for example "1 hour before") and the fire time are stored alongside the saved-meet entry on your device. In the iOS app, that configuration is handed to iOS's local-notification scheduler so the alert can fire without a network connection. When the cross-device sync feature is enabled, the same reminder presets and fire-times are mirrored to our servers as part of the saved-meet entry described above so reminders persist across reinstalls or devices.
• UI preferences (on-device + optional cloud mirror) — your default maps app preference (Apple Maps, Google Maps, or Waze) and your haptics on/off setting are saved in local storage. When the cross-device sync feature is enabled, those two values are also mirrored to our servers keyed by the anonymous installation identifier so they follow your saved list across reinstalls. They are not used for advertising, profiling, or analytics.
• Anonymous installation identifier — the website and the iOS app each generate a random UUID we call an "installation identifier" the first time they need one, and store it locally (in your browser's local storage on the web, or in the app's local storage on iOS). Each browser profile and each app install receives its own identifier. The identifier is not derived from any device hardware identifier and is not linked to any account or contact information by default.
• Uses of the installation identifier — we use this identifier as the key for: (a) routing remote push alerts to an iOS device via APNs when one is registered, (b) mirroring your saved meets, reminders, and UI preferences to our servers when sync is enabled, (c) deciding which installs should receive saved-meet change alerts, (d) writing optional meet-submission status inbox rows, and (e) the optional public submission status lookup at /submit/status when you choose to enter your sync ID.
• Voluntary cross-device sync ID linking — you may link devices yourself by copying your sync ID from one browser or app and pasting it into Menu → Link sync ID on another (or by replacing the value in local storage). Doing so causes both devices to share the same server-side mirror keyed to that identifier. We do not automatically merge identifiers across devices and cannot tell that two identifiers belong to the same person unless you perform this step yourself.
• Clearing or replacing the installation identifier — clearing local storage (or reinstalling the app) generates a new identifier unless you link an existing one, which disconnects you from prior server-side records keyed to the old identifier on that device.

For internal accountability, we maintain an append-only log of administrative actions such as creating or modifying events and managing user accounts. Each log entry records the acting staff member's user identifier, the type of action performed, the affected resource, a timestamp, and structured details of the change (for example, which fields were edited and their before/after values for that action). Audit logs are accessible only to staff with the audit-log permission and are never disclosed externally.

Address autocomplete (OpenStreetMap Nominatim) — When an organizer enters a venue address in the administrative panel or a member of the public types an address into the meet submission form at /submit, we relay the search query to the OpenStreetMap Nominatim geocoding service to provide address suggestions. Only the text entered is transmitted; no cookies, authentication tokens, or device identifiers accompany the request.

When an organizer saves an event, our servers may also send the venue name and address to Nominatim once more to obtain coordinates we store alongside the listing. That enables accurate map pins in calendar exports; the same Nominatim usage policy applies.

Map basemap tiles (OpenStreetMap + CARTO) — The interactive map (`/map` and the home-page map widget) renders OpenStreetMap data styled by CARTO, served from *.basemaps.cartocdn.com. When you scroll or zoom, your browser fetches map tiles directly from CARTO; CARTO sees the standard request fields (your IP address and user agent) plus the tiles requested. We do not use Mapbox, Google Maps tiles, or any other tile provider in the production render path. Recent tiles may be cached locally by your browser to reduce repeated fetches; on the production website we also register a service worker that may cache recent map tiles and lightweight saved-meet manifest metadata on your device to improve offline map viewing. These caches are bounded and held only on your device; they contain no account or tracking data.

Cover image hosting (catbox.moe) — When an organizer uploads a cover image file (instead of pasting a URL), our server forwards the file to catbox.moe, a third-party file host, and stores a public direct link returned by that service. Do not upload images you consider sensitive; the hosted file is publicly retrievable by anyone with the link. catbox may log requests according to its own policies.

Upload availability depends on catbox.moe policy enforcement. Anonymous uploads from some networks may be blocked by catbox, and we may require authenticated forwarding from our server or disable uploads for abuse prevention and policy compliance. We do not control catbox moderation, anti-abuse systems, or retention decisions.

Calendar subscription feeds and saved-meet ICS export — We publish a standard iCalendar (ICS) URL listing the same public event information shown on the website. Subscribing imports that data into your calendar application; your provider's privacy policy governs how they process subscribed feeds.

In addition, the saved-meets view provides a "Download saved meets" button that generates a one-time ICS file containing the meets you have saved. Your browser sends the list of public meet IDs (the same identifiers shown in each meet's URL) to our server; the server fetches the public listing data for those meets and returns a standard ICS file. No installation identifier, account credential, or personal information is transmitted as part of this request; the server treats it identically to any other request for public meet details.

Push notifications (Apple Push Notification service) — When you grant notification permission on iOS, our app transmits your APNs device token and a locally generated installation identifier to our servers so we can deliver remote pushes in the categories described in Section 3: featured-post alerts, saved-meet change alerts, and meet submission status alerts. Live Activities for saved meets use two additional Apple-issued token kinds — a per-install push-to-start token (one per device, used to start an activity on the Lock Screen without the app being foregrounded) and a per-activity update token (used to push phase changes and to end the activity). All four token kinds are stored on our servers keyed only by the anonymous installation identifier (and, for activity update tokens, the public meet ID), routed through Apple's APNs infrastructure for delivery, and deactivated when they become invalid, when permission is revoked, or when an activity ends. Apple may process delivery metadata as described in Apple's privacy policy. We store tokens only for delivery purposes and use none of them for advertising or profiling.

Live Activity drive-time refresh (on-device location) — while an iOS Live Activity for a saved meet is active, the app may briefly use on-device location to refresh the live drive-time estimate shown in the activity. Location access is strictly bounded: only while at least one activity is active, under iOS's "When in use" permission model (we do not request "Always"), with a relaxed accuracy setting and distance filter to limit battery draw. Raw coordinates are not transmitted to our servers. At most once per minute, the app may echo the computed drive-minutes integer back to our server so the server-side phase-change dispatcher (saved → upcoming → starting → live) has an accurate ETA; the echo is keyed only by the anonymous installation identifier and the public meet ID, and is discarded when the activity ends.

Paste-a-link prefill (our /api/submit/from-url proxy) — when you tap "Fill from link" in the submit form, or when you share a link to the app from another iOS app via the system share sheet, our server fetches the public HTML of the URL you provided (capped at 256 KB for most sites; Instagram posts may fetch up to 512 KB, with a generic User-Agent and no cookies), parses Open Graph and Twitter Card metadata, and returns suggested values (title, venue guess, address guess, start-time guess, description) to pre-fill the form. For instagram.com post and reel links, we also download the first image on the post, mirror it for moderator review, and — when AI_GATEWAY_API_KEY is configured — send the caption and that image to the Vercel AI Gateway to extract dates, venue, and other fields printed on the flyer. We treat the Instagram account that published the post as the default host. From the third party's perspective, the request originates from our server's IP address, not yours. We do not retain the fetched HTML; only the parsed values land in your draft, and only the values you keep after review are stored when you submit. A short-lived rate-limiting bucket (see Section 7) prevents the proxy from being misused as an open URL fetcher.

Weather forecast (Open-Meteo) — Each meet detail page can show a small weather card. To build the card, our server proxies the meet's public latitude and longitude (the same coordinates already shown on the map for that meet) to Open-Meteo, a free public forecast API. The request contains only meet coordinates and a timestamp; no user identifier, IP address pass-through, or device information is sent. Open -Meteo's usage is governed by its own terms and privacy practices.

Hosting (Vercel) — The Service is deployed on the Vercel platform. All connections are encrypted via TLS/HTTPS. We do not enable Vercel Analytics, Web Analytics, Speed Insights, or any other optional telemetry products. We expose a public status page at /status and a JSON health endpoint at /api/health for uptime monitors. Both endpoints report only system-level signals: database round-trip latency, an Apple Push Notification service connectivity check, outbound reachability to the Open-Meteo weather API, the CARTO map-basemap CDN, and catbox.moe (our third-party cover-image host), plus last-success timestamps for three internal scheduled jobs (Live Activity maintenance and nightly data pruning). They contain no account data, installation identifiers, IP addresses, or any other personal information, and monitoring pings cause our server to issue outbound requests to those third parties solely as part of the health checks (already disclosed above for Open-Meteo, CARTO, and catbox). Like any host, Vercel may process limited technical data (for example, IP addresses and request metadata) to operate its network and protect against abuse, as described in Vercel's privacy policy.

Database (Neon) — Application data is stored in a managed PostgreSQL database hosted by Neon. Connections are encrypted in transit. Access is restricted to the application layer and authorized administrators. Neon may process limited operational metadata to run and secure the database as described in Neon's privacy policy.

The Service uses a single, strictly necessary session cookie to maintain organizer authentication. This cookie contains only a session identifier — it does not include advertising identifiers, cross-site tracking data, or any third-party payloads.

Public visitors who do not sign in receive no authentication cookies. The website may store small, non-tracking UI preferences in your browser's local storage as described in Section 7. We do not use local storage, session storage, or similar mechanisms to build profiles or track behavior across sites.

This does not include ordinary infrastructure/security request logs processed by our hosting and networking providers to deliver pages and protect against abuse.

The same session cookie applies when organizers authenticate in the iOS app's web view, scoped to our domain.

Pages on the Service include a standard Safari apple-itunes-app meta tag so iPhone Safari can show a Smart App Banner that offers to open or install our iOS app. The meta tag contains only our App Store ID and a public link back to our site. No personal data is transmitted to Apple by the tag itself; any interaction you have with the App Store or the installed app is governed by Apple's policies.

We implement reasonable technical and organizational measures to protect the information we hold from unauthorized access, alteration, disclosure, or destruction. These measures include encrypted connections (HTTPS/TLS), hashed credential storage, and role-based access controls. However, no method of electronic storage or transmission is completely secure, and we cannot guarantee absolute security.

Organizer account data is retained for as long as the account remains active. Site administrators can disable organizer access at any time (for example when an organizer leaves the team or violates policy), which prevents further sign-in and revokes active sessions.

If you are an organizer and wish to request deletion of your account data, contact us using the information in Section 16 below. We aim to process deletion requests manually within 30 days of receipt where feasible, and will permanently remove account records that are no longer required for security, fraud prevention, or legal compliance.

To protect account security, we may request reasonable identity verification before processing access, correction, or deletion requests.

Past event listings may be retained indefinitely as part of the site's public historical record, with the associated organizer attribution anonymized on request.

We process personal information only where we have a valid legal basis, including: (a) performance of a contract (for organizer authentication and account administration), (b) legitimate interests (operating, securing, and improving the Service), (c) compliance with legal obligations, and (d) consent where required by law.

Depending on your location, you may have rights to request access, correction, deletion, restriction, objection, or data portability, and to appeal a denied request where local law provides that right. To exercise these rights, contact us using Section 16 below. We will respond within the timeframe required by applicable law.

California residents (CCPA/CPRA) — we do not "sell" personal information and we do not "share" personal information for cross-context behavioral advertising, as those terms are defined under the California Consumer Privacy Act. We do not use targeted advertising, third-party analytics, or behavioral profiling on the Service, and there is no "Do Not Sell or Share My Personal Information" opt-out required because we do neither.

The Service is not directed at individuals under the age of 13. We do not knowingly collect personal information from children. If we become aware that we have inadvertently collected data from a child under 13, we will take prompt steps to delete such information.

We may update this Privacy Policy from time to time to reflect changes in our practices or applicable law. When we do, we will revise the "Effective" date at the top of this page. We encourage you to review this page periodically. Material changes will be communicated through a notice on the Service.

Most recent update (June 2, 2026): corrected the leave-by alerts disclosure to reflect that alerts can fire for any device with a saved meet and a push token, without requiring an active Live Activity — the prior wording implied they only fired when a Live Activity was running (Section 3); and disclosed the on-demand saved-meets ICS download in the saved-meets view, which posts only public meet IDs to the server and receives a standard ICS file in return (Section 9).

If you have questions, concerns, or requests regarding this Privacy Policy or our data practices, please contact us at alex@detmeets.com. For general questions, you can also reach us via Instagram at @alex.30mm.