Privacy Policy
The Flat Rock Events app is in a private beta phase. During beta, the platform infrastructure (the Firebase project, Cloud Functions, mobile and web codebases, deployment pipeline) is operated by Patrick Mikes (Serenica Digital) on behalf of the Client, the corporate event organizer using the platform.
The Client decides who is invited to events, what data is collected from attendees, what notifications are sent, and how the app is used at their events. Under GDPR and similar laws, the Client is the data controller for that personal data. Patrick Mikes provides the platform infrastructure as a data processor acting on the Client's instructions for those purposes.
For service-side telemetry that helps keep the platform working (crash reports sent to Sentry, system logs in Google Cloud), Patrick Mikes is an independent controller. These telemetry flows are described in section 7.5 and have personally identifying fields stripped client-side before transmission.
At public launch, the Client takes over the platform infrastructure itself and the processor relationship described above ends. You will be notified in-app before the transition takes effect. No new categories of data will be collected as a result of the transition, and no user consent will be re-collected — this is a change in the organization providing the platform, not a change in what is done with the data.
1. Who we are
This privacy policy covers the Flat Rock Events mobile app (iOS and Android) and its companion web admin portal.
During the beta phase, the data controller for your personal data (under GDPR Article 4(7) and equivalent laws) is the Client, the corporate event organizer that has invited you to participate. The Client decides who is invited to events, what data is collected from attendees, and how the platform is used at their events. The Client's identity is communicated to you when you receive an invitation; the Client is also identified in event-specific branding inside the app.
Patrick Mikes, an individual operating under the name Serenica Digital, located in the State of Michigan, United States ("we," "us," "our"), provides the platform infrastructure during beta as the Client's data processor (under GDPR Article 4(8)). Patrick Mikes is also an independent controller for service-side telemetry described in section 7.5.
For questions about this policy, how your data is handled, or to exercise any of the rights described in section 10, contact us at events-support@serenicadigital.dev. Requests we cannot fulfill on the Client's behalf will be forwarded to the Client and you will be notified.
For users in the European Economic Area, United Kingdom, or Switzerland, you also have the right to lodge a complaint with your national supervisory authority.
2. Scope
This policy applies to:
- The Flat Rock Events mobile application on iOS and Android.
- The companion web admin portal used by event organizers.
- Any data the platform collects when you use either of the above.
This policy does not cover:
- Sites, services, or apps operated by third parties that we link to (sponsor websites, speaker social profiles, etc.) — their own privacy policies apply.
- Data your employer, event organizer, or other third parties may collect about you outside the app (for example, a badge-scan system at a physical venue, or a registration form on a separate website).
The platform is designed for corporate events. Attendees, organizers, speakers, and internal team members all use the same mobile app with different permissions. Organizers additionally use a web admin portal.
3. What information we collect
We collect the minimum information needed to run an event, help you navigate it, and let the organizing team coordinate with you.
3.1 Account identifiers
When you create an account, we store:
- Your Firebase account identifier (a unique ID assigned by Firebase Authentication).
- Your email address (unless you signed in with Apple Sign-In and chose to hide it — in which case we receive Apple's relay email).
- Your first name, last name, and display name (as you entered them).
3.2 Contact information
If you provide them, we store:
- Phone number
- LinkedIn profile URL
- Personal or professional website URL
All of these are optional. You can leave them blank.
3.3 Profile content
If you choose to provide them:
- A profile photo
- A short bio
- Your job title
- Your organization or company
All optional.
3.4 Health-adjacent information for event accommodation
The data model includes two fields we treat as sensitive under GDPR Article 9 (special category data):
- Dietary restrictions — a list of dietary needs for catered meals (e.g. vegetarian, gluten-free, kosher, halal, nut allergy).
- Accessibility needs — a short free-text description of accommodations you need (e.g. wheelchair access, hearing loop, large-print materials).
When collected, these fields exist specifically so the organizing team can accommodate you at the event. They are visible only to you and to the event's organizers (see section 6).
During beta, the app does not collect this data from you directly. The structured fields above exist in the schema and the security rules tier them appropriately (only you and the event's organizers would be able to read them), but no in-app input UI writes to them today. If the organizing team needs your dietary or accessibility information during a beta event, they will collect it through their own channels outside the app (registration forms, email, or direct conversation), not through this app. The in-app input UI is deferred until after beta. When that UI is built, this section will be updated to reflect what the app actually collects, and an explicit consent surface will be added at that time per section 11.
3.5 Event participation data
As you use the app, we record:
- Which events you are a member of and with what role (invitee, companion, internal team, organizer).
- Which sessions have been made available to you (via the audience groups you belong to, or via direct assignment).
- Which travel arrangements (flights, lodging, transport) the organizer has linked to you.
- Any ratings, choices, or free-text responses you submit when answering an organizer-published survey.
- Private notes you type about individual sessions (only you can read these).
3.6 Notification engagement
When an organizer sends a notification, we record:
- Whether the notification was delivered to you.
- When (and whether) you have read it in the in-app inbox.
This is used to show you unread counts and to give organizers aggregate delivery statistics.
3.7 Device and technical data
For push notifications to work, we store:
- Firebase Cloud Messaging (FCM) device tokens, tagged by platform (iOS / Android) and the date the token was registered.
Each time the app starts it also records the app version and build number you are running, your platform (iOS / Android), and the time of that launch, so we can tell which installs still need an update.
If the mobile app or the admin web app crashes or throws an uncaught error, we send the stack trace, error message, and a small amount of device metadata (operating system or browser version, device model, app or build version) to our crash reporting provider, Sentry. We do this so we can find and fix bugs before they affect more users. Personally identifying fields (your name, email, phone number, profile content) are stripped from these reports before they leave your device. See section 7.5 for the full disclosure.
We do not collect, store, or transmit any of the following: advertising IDs (IDFA, AAID), device fingerprints, telemetry, analytics session data, or any other identifier not needed to deliver a push notification or fix a crash. See section 7 for our explicit non-use of third-party tracking and analytics SDKs.
3.8 Email delivery metadata
When we send you an email (invitation, notification, or event announcement), we record the delivery state (queued, sent, failed) and the timestamp, so organizers can confirm you received important messages and so we can troubleshoot delivery failures.
3.9 Internal notes about you
If you attend an event as an external guest of the organizing company, members of that company's internal team may record short administrative notes about you in a separate internal collection — for example, the name of a company you are associated with, or a tag used to group attendees for event operations. You cannot read these notes yourself. They are visible only to the organizing company's internal team, organizers, and admins.
We disclose this because the data exists and the law requires transparency about what is stored, even when access is restricted.
4. How we use your information
We use the data described in section 3 for the following bounded purposes:
| Purpose | Data used |
|---|---|
| Letting you sign in and stay signed in | 3.1, 3.7 |
| Showing you the event agenda and its navigation | 3.5 (membership, audience-group assignments) |
| Showing you the event map, your travel arrangements, and weather at the venue | 3.5 (travel) |
| Letting you browse speakers, sponsors, and other attendees | 3.1, 3.2, 3.3 (subject to your privacy settings, see section 5) |
| Letting you save private notes to individual sessions | 3.5 (notes) |
| Recording your survey responses for organizers | 3.5 (survey responses) |
| Delivering push notifications and emails about the event | 3.6, 3.7, 3.8 |
| Accommodating your dietary and accessibility needs at the event | 3.4 |
| Giving organizers the contact details they need to reach you about the event | 3.1, 3.2 |
| Giving internal team members context for event operations | 3.9 |
We do not use your data for:
- Advertising or marketing by us or any third party.
- Profiling for decisions that affect your legal rights.
- Automated decision-making.
- Selling to data brokers or any other third party.
- Training machine learning models.
5. Privacy controls in your hands
The platform is built with privacy as the default. When you first create an account, your information is visible only to you and to the event organizers who need it. You do not appear in the attendee directory until you explicitly choose to be listed, and even then only the specific fields you choose to share are visible to other attendees.
5.1 The master toggle
There is a single master setting: "Show me in the attendee directory." It is off by default. While it is off:
- Your profile does not appear in the directory.
- Other attendees cannot search for you or see your name in any directory list.
- Other attendees cannot view your profile.
5.2 Per-field visibility
If you turn the master toggle on, you then control — field by field — which details of your profile are visible to other attendees:
- Email address
- Phone number
- LinkedIn profile
- Website
- Bio
- Job title
- Organization
Each field is individually off by default and must be turned on explicitly.
Your name and profile photo are always visible in the directory if you have opted in — that's the minimum to be findable at all. If you want complete invisibility to other attendees, leave the master toggle off.
5.3 How changes take effect
When you turn a toggle on or off, the change takes effect immediately. A background process running on our servers synchronizes the change across the app.
The master toggle and per-field toggles exist as data fields in the app's database today and the server-side sync is in place. The mobile app's privacy settings screen that lets you actually flip the toggles is in development and is not yet shipping. Until it ships, the defaults above are enforced automatically (nothing is visible) but you will not see the UI described in this section. This policy will be updated to match the shipping app when the screen lands.
6. What your event organizer can see
This section is the single most important disclosure in this policy. Please read it carefully.
Event organizers and the organizing company's internal team have access to your full profile regardless of your privacy settings. The controls in section 5 affect what other attendees can see. They do not restrict what organizers see.
Specifically, organizers of events you are a member of can see:
- Your name, display name, and profile photo.
- Your email address.
- Your phone number (if you provided one).
- Your LinkedIn profile and website (if you provided them).
- Your job title and organization (if you provided them).
- Your bio (if you provided one).
- Your dietary restrictions and accessibility needs, if you have provided them. Implementation note: during beta, the app does not have an in-app input surface for these fields, so there is nothing for organizers to read here through the app today. See section 3.4. If the organizing team needs this information during a beta event, they will collect it from you outside the app.
- Your event participation data: memberships, the audience groups you belong to, your travel arrangements, and your survey responses (including any free-text answers you submit).
- Email delivery status for messages sent to you.
Organizers cannot see:
- Your private session notes — these are readable only by you.
- Data for events you are not a member of.
The organizing company's internal team (staff and employees) additionally may record notes about you — the "internal notes" described in section 3.9 — which you cannot read.
Plain-language summary: treat anything you put in your profile as visible to the people running the event you are attending. If you would not want the event organizer to see it, do not put it in the app.
Organizers also have the technical ability to set a profile photo on your behalf — for example, when you are a speaker at an event and the organizing company's marketing team already has a professional headshot for you. When this happens, the photo becomes your profile photo across the whole app and is visible on your profile everywhere.
7. Sharing with third parties
We share your data with the following third parties, and only for the purposes listed. During the beta phase, the Client is the data controller for your personal data and Patrick Mikes (Serenica Digital) is the data processor providing the platform infrastructure (see the beta notice at the top of this page). Patrick is also an independent controller for the service-side telemetry described in §7.5. The parties below are sub-processors of the Client, sub-processors of Patrick's telemetry processing, or independent controllers as noted.
7.1 Google Cloud / Firebase
The app runs on Google Cloud, using Firebase (Firebase Authentication, Firestore database, Firebase Cloud Messaging, Firebase Cloud Functions, Firebase Storage, and the Firebase "Trigger Email" extension). Google is our primary data processor.
- Data location: Firestore and Storage data are stored in Google's
us-east1region (United States). Firebase Authentication and Firebase Cloud Messaging use Google's global infrastructure. - Contractual basis: Google Cloud Terms of Service including the Data Processing Addendum.
- International transfers: For users in the EEA / UK / Switzerland, data is transferred to the United States under Google's Standard Contractual Clauses. The Client's GDPR international-transfer mechanism for the production destination must be confirmed at public launch.
7.2 SMTP email delivery
Email messages (invitations, notifications, confirmations) are delivered via an SMTP service. The service receives:
- Recipient email address
- Message subject and body
- Sender information
During beta, the platform uses Mailtrap's transactional sending service for real email
delivery from events.serenicadigital.dev. (In developer environments, a
separate Mailtrap sandbox inbox captures messages for testing without delivering them.)
At public launch, email delivery transitions to the Client's corporate mail
infrastructure; the specific provider will be named in this policy at that time.
7.3 Push notifications via Google Cloud Messaging
Push notifications are delivered through Firebase Cloud Messaging (FCM), operated by Google. FCM receives:
- Your device's FCM registration token (a long identifier that identifies the device, not you).
- The notification title, body, and optional deep link.
FCM does not receive your name, email, user ID, or any other personal identifier. The mapping between FCM tokens and users stays inside our Firebase project.
7.4 Sign-in providers
If you sign in with Google, Apple, or Microsoft (instead of creating a password), the relevant provider processes the authentication:
- Google Sign-In — Google receives the standard OAuth sign-in data and returns your email and basic profile. Subject to Google's privacy policy.
- Sign in with Apple — Apple receives the OAuth sign-in data. You can choose to hide your email address, in which case Apple provides us with a relay email. Subject to Apple's privacy policy.
- Microsoft Entra ID — Microsoft receives the OAuth sign-in data when you sign in with a work or school Microsoft account. Subject to Microsoft's privacy statement.
7.5 Crash reporting via Sentry
When the mobile app or admin web app crashes or throws an uncaught error, the
diagnostic information described in section 3.7 is sent to Sentry
(sentry.io), operated by Functional Software, Inc. Sentry is configured
to:
- Receive only stack traces, error messages, and basic device or browser metadata (OS or browser version, device model, build version)
- Receive your Firebase user ID (a pseudonymous identifier) so we can tell whether one user is hitting many errors versus many users hitting one error
- Not receive your name, email address, phone number, profile content, organization, bio, or any other directly identifying field. These are stripped from every report before transmission
The data is hosted in Sentry's United States region. Our contractual basis is Sentry's standard Data Processing Addendum.
You cannot opt out of crash reporting in-app. It is operationally necessary for a small team to maintain a working app for thousands of users. If you object to crash data being collected at all, the practical outcome is account deletion.
7.6 Apple WeatherKit and Apple MapKit
The mobile app shows weather forecasts at event venues and renders maps of event locations.
- WeatherKit — When you open the weather panel for an event, our Cloud Function fetches forecast data from Apple's WeatherKit REST API using the venue's coordinates. WeatherKit receives the latitude/longitude of the venue. It does not receive any information about you.
- Apple Maps (mobile) — Map tiles in the mobile app are rendered by Apple Maps via
react-native-mapson iOS. Apple receives the standard map tile requests (the area being viewed) but no user identifier. - MapKit JS (admin) — When event organizers pick a location in the admin portal, Apple's MapKit JS provides address autocomplete. MapKit JS receives the partial text the organizer types into the search box.
These flows are subject to Apple's privacy policy.
7.7 Microsoft 365 ecosystem (Client tenant)
The platform is integrated with the Client's Microsoft 365 tenant for organizer workflows. These integrations replicate event and attendee data into the Client's Microsoft tenant, where it is governed by the Client's Microsoft tenant agreements rather than this policy.
- SharePoint List sync — Event data (events, sessions, attendees, surveys, survey responses, plus a roster) is mirrored into six SharePoint lists in the Client's tenant via Microsoft Graph API. Mirrored data includes attendee names, email addresses, roles, and event participation. Organizers and other tenant users with appropriate SharePoint permissions can view this data.
- Per-event SharePoint hub pages — Each event auto-provisions a SharePoint page in the Client's tenant with embedded Power BI reports (URL-filtered to the event) and links to the SharePoint lists above.
- Power BI live survey dashboard — When you submit a survey response, it is written to a Power BI push dataset in the Client's tenant within seconds, where organizers can view live aggregate results during the event. Whether your individual response is identifiable to organizers depends on the per-survey anonymity setting the organizer chose at survey creation; anonymous surveys store responses against a synthetic identifier with no link back to your account.
- Microsoft Entra ID SSO — Organizers and internal team members can sign in via the Client's Microsoft Entra ID tenant (see §7.4). Attendees can also use Entra ID sign-in if their employer is part of the same tenant.
The Client controls retention, access permissions, and downstream use of all data inside their Microsoft tenant. If you have questions about how the Client uses data inside their tenant, contact the Client's organizer team via the contact in section 1.
7.8 BigQuery analytical mirror
Event data is exported from Firestore to a Google BigQuery dataset for analytical
reporting via the Firebase firestore-bigquery-export extension (one
install per collection, currently seven collections exported).
- Current routing: during beta, the BigQuery export from the production Firestore project routes to a separate Google Cloud project named
serenica-event-planner-dev(the staging project), in the datasetevent_planner_firestore_export(us-east1 region). This isolation is documented in our engineering ADRs as a dev/prod safety measure. Patrick Mikes is the data processor for this BigQuery instance during beta. - Production analytical mirror: a separate BigQuery instance owned by the Client is the long-term destination for cross-event analytics. The production-side setup is not finalized. When it activates, this policy will be updated to name the destination project.
7.9 App Review demo account
Apple App Store reviewers and similar app-distribution review processes require
functional demo credentials to evaluate the app. To support this, we maintain a
deterministic demo account (email contains the prefix apprev-) and a
scoped demo event that exists alongside production data. Reviewers use this account to
navigate a representative event during their review. The demo account and demo event
do not contain real attendee data, and the account is the only way for an outside
reviewer to access the platform without an organizer-issued invitation.
7.10 What we do not share, and do not use
The platform does not currently use:
- Any third-party analytics SDK (Firebase Analytics, Google Analytics for Firebase, Mixpanel, Amplitude, Segment, etc.)
- Any crash reporting other than Sentry, configured per section 7.5 (we do not use Crashlytics, Bugsnag, or similar)
- Any advertising network, advertising SDK, or marketing attribution service
- Any telemetry or usage-tracking library beyond what is described in section 7.5
We do not sell your personal information, and we do not share it for cross-context behavioral advertising. For users in California, this means we do not engage in "sale" or "sharing" as those terms are defined by the CCPA.
We do not share your data with any party beyond the ones listed above.
8. Where your data is stored
Your data is stored in Google Cloud's us-east1 region (United States) for
Firestore and Firebase Storage. Firebase Authentication data is stored in Google's
global authentication infrastructure. Push notification tokens are processed by Firebase
Cloud Messaging's global infrastructure.
The BigQuery analytical mirror (§7.8) is also located in us-east1 during
beta. Data replicated to the Client's Microsoft 365 tenant (§7.7) is stored in
whatever region the Client's Microsoft tenant is provisioned for; consult the Client's
organizer team for that region.
For users in the European Economic Area, the United Kingdom, or Switzerland: your data is transferred to the United States. We rely on Google Cloud's Standard Contractual Clauses as the transfer mechanism. Additional transfer mechanisms (binding corporate rules, sector-specific adequacy decisions) for both Google and Microsoft processors will be confirmed at public launch.
9. How long we keep your data
Retention windows are set per category:
| Category | Retention |
|---|---|
| Account data (profile, contact, privacy settings) | For as long as you have an account |
| Event participation (memberships, audience-group resolutions, travel, survey responses, notes) | For as long as you have an account, or for as long as the event exists — whichever is shorter |
| Email delivery records | Up to 90 days after the final delivery state is known |
| Notification receipts | Up to 180 days after the notification was sent |
Queued outbound emails (mail collection) | Up to 30 days after delivery |
| Invitation records (active and accepted) | Up to 90 days after the invitation is accepted by your first sign-in |
| Invitation records (revoked) | Up to 30 days after the status changes |
| Event content (sessions, speakers, sponsors, locations, groups, travel items) | For the lifetime of the event |
| Daily Firebase Auth metadata backups | 30 days, per the storage bucket lifecycle policy |
| Archived events | Retention window to be decided by the Client at public launch |
Several of these retention windows (notification receipts, email deliveries,
invitation records) are proposed defaults, not currently enforced.
The scheduled cleanup jobs that would enforce them are listed as engineering work to
be done. Until they ship, these records persist indefinitely in the database. The
30-day TTL for queued outbound emails (mail collection) and the 30-day
lifecycle policy on Auth metadata backups are live. This policy will be updated as
additional enforcement work lands.
When you delete your account (see section 10.1), most of your personal data is removed within a reasonable time frame. Some records are kept as described in the next section.
10. Your rights
You have the following rights over your personal data. Section 10.5 is the jurisdiction-specific summary for the EEA/UK and California.
10.1 Account deletion (right to erasure)
You can request the deletion of your account and all personal data associated with it. When this happens, the following will be erased:
- Your profile (public and private).
- Internal notes about you.
- Your event memberships and your inclusion in any event groups.
- Your private session notes.
- Your survey responses (including any ratings and free-text answers you submitted).
- Your notification read tracking.
- Your travel arrangements stored against your account.
- Your profile photo.
- Your authentication account (you will no longer be able to sign in).
A consequence to be aware of: because we delete your survey responses, the aggregate counts and average results shown to organizers will adjust downward when your account is deleted. This is the result we prefer over retaining anonymized records indefinitely.
What is not erased by account deletion:
- Content you authored on behalf of the event — for example, if you were an event organizer, the sessions and sponsors you created remain part of the event until the event itself is deleted. They are no longer attributed to you.
- Invitations you received are preserved as audit history (their status carries over from the moment of deletion). The invitation does not point back at your deleted profile beyond the email address that was used to invite you.
- OAuth grants you may have given on Google's, Apple's, or Microsoft's side when you signed in. You can revoke those separately through your Google, Apple, or Microsoft account settings. Microsoft Entra ID grants in particular may need to be revoked through your tenant administrator if you signed in with a work account.
- Data the Client has already replicated to their Microsoft 365 tenant (§7.7). The Client controls retention inside their tenant; contact the Client to request erasure of replicated copies if applicable.
In-app account deletion is available from the mobile app at Settings → Delete Account. A confirmation dialog describes exactly what is deleted; confirming triggers the cascade described above within a few seconds and signs you out. If you cannot reach the in-app button for any reason, email us at the contact address in section 1 and we will delete your account on your behalf within one month (GDPR Article 12(3)).
10.2 Access to your data (right to know / right of access)
You have the right to obtain a copy of the personal data we hold about you.
Self-service data export is not yet implemented. Until it ships, access requests must be submitted via the contact address in section 1. We aim to respond within one month. The export will include a copy of your profile, event participation, check-ins, feedback, notes, and notification receipts in a structured JSON format.
10.3 Correction (right to rectification)
You can correct your profile, contact information, and privacy settings yourself in the app at any time. Corrections take effect immediately. If a correction requires action we cannot take on your behalf through the app (for example, correcting a historical check-in record), submit the request via the contact address in section 1.
10.4 Objection and restriction
You can ask us to stop processing your data or restrict how we use it. Submit the request via the contact address in section 1. Note that certain processing is required for the app to function — if you object to all processing, the practical outcome is account deletion.
10.5 Jurisdiction-specific rights
European Economic Area, United Kingdom, and Switzerland (GDPR / UK GDPR): The Client is the data controller for your personal data during the beta phase. Patrick Mikes (Serenica Digital) is the data processor providing the platform infrastructure, and is an independent controller for the service-side telemetry described in §7.5. Lawful bases for processing are: (a) performance of a contract (Article 6(1)(b)) for account creation and event participation, (b) legitimate interest (Article 6(1)(f)) for organizer access to contact information, notification delivery, and crash reporting, and (c) explicit consent (Article 9(2)(a)) for the dietary and accessibility fields described in section 3.4. At public launch, the Client takes over the platform infrastructure itself and the processor relationship ends. You have the right to lodge a complaint with your national supervisory authority. Contact information for supervisory authorities is available on the European Data Protection Board's website.
California (CCPA / CPRA): California residents have the right to (a) know what categories of personal information we collect, (b) access their specific personal information, (c) request deletion, (d) correct inaccurate information, (e) limit the use of sensitive personal information, and (f) opt out of the sale or sharing of their personal information. We do not sell or share personal information as those terms are defined by the CCPA, so there is no opt-out mechanism to display — we simply do not do it. To exercise any other right, contact us at the address in section 1. We do not discriminate against users who exercise their rights.
Other jurisdictions: If you are located outside the EEA, UK, Switzerland, or California, you still have the rights described in sections 10.1–10.4 under this policy.
11. Sensitive (special category) information
Section 3.4 described two fields that we treat with extra care:
- Dietary restrictions (an array of dietary needs).
- Accessibility needs (a free-text description).
We collect these fields only if you choose to provide them. Their purpose is to let the organizing team accommodate you at a physical event: plan catering menus that meet your dietary needs, and ensure the venue and materials are accessible.
Under GDPR Article 9, these can qualify as "special category data" because dietary restrictions may reveal health conditions (e.g. celiac disease, diabetes) or religious beliefs, and accessibility needs are health-adjacent. Our lawful basis for processing them is your explicit consent under Article 9(2)(a).
How we limit access:
- These fields live in a separate private data store that is not readable by general attendees. Access is limited to you and to the organizers / internal team of events you are a member of, enforced by database-level access control (not just by the app UI).
- They are stored encrypted at rest by Firebase's default encryption.
- They are never included in the attendee directory, regardless of your privacy settings.
- They are never shared with third parties except insofar as the organizers need to communicate them to catering vendors or venue staff — which happens outside the app.
You can leave these fields blank, and you can clear them at any time by editing your profile.
The explicit-consent toggle is deferred along with the in-app input UI that would need it (see section 3.4). Because the app does not currently collect dietary or accessibility data from you directly during beta, there is no in-app surface where Article 9(2)(a) consent would need to be captured. When the in-app input UI is built post-beta, the explicit-consent toggle will be added at the same time, and this section will be updated. If the organizing team collects this information from you outside the app during a beta event, the legal basis for that collection lives in whatever process they use, not in this app.
12. Children's privacy
The platform is designed for adults attending professional and corporate events. It is not intended for and not directed at children under 16 (or under 13 in jurisdictions where the applicable age threshold is lower, such as the United States under COPPA). We do not knowingly collect personal information from children.
If you believe a child has created an account, contact us at the address in section 1 and we will delete the account.
13. Security
We use Firebase's managed security controls to protect your data:
- Database access is enforced by server-side security rules. The rules are verified by automated tests on every change.
- All data is encrypted in transit (HTTPS/TLS) and at rest by Firebase's default encryption.
- Authentication is handled by Firebase Authentication, which supports OAuth from Google, Apple, and Microsoft as well as email/password accounts.
- Cloud Functions that perform sensitive operations (invitation handling, cascade deletes, speaker photo uploads) verify the caller's identity and role before executing.
- Secrets such as SMTP credentials are stored in Google Cloud Secret Manager.
No system is perfectly secure. If you become aware of a vulnerability, please contact us at the address in section 1.
14. Changes to this policy
We may update this policy from time to time as the app evolves, as regulatory obligations change, or as we add or remove features. When we make a material change, we will:
- Update the "Last reviewed" date at the top.
- Notify you in the app, either through the in-app notification inbox or with a banner on next launch after the change.
Minor corrections (typo fixes, clarifications of existing behavior) may be made without notice.
You can always find the current version of this policy at this URL and inside the app under Settings → Privacy Policy once that screen is implemented.
15. Contact us
Questions about this policy, or requests to exercise any of the rights in section 10:
For security vulnerability reports, use the same email address and include "Security" in the subject line.