CrewNexo Privacy Policy

Last updated: 26 October 2026 · Version: 1.4

CrewNexo helps airline crew manage their roster, share selected information with friends, and use crew conversations, meetups, jump seat requests and line offers. This policy covers the CrewNexo iOS and Android apps, including beta releases, the CrewNexo service and this privacy page. Available features depend on your app version and the features enabled for your account.

CrewNexo is independent of the airlines. Your use is voluntary; your employer does not operate CrewNexo or receive your private roster through an employer dashboard.

1. Who is responsible

The controller of your personal data is SilkIdea s.r.o., company number 07990073, registered office Kosova 1242/1c, Suchdol, 165 00 Praha 6, Czech Republic ("we", "us").

SilkIdea acts as the service provider and controller independently of your airline; an individual founder, director or developer is not named as a separate contracting provider by this policy. This does not change any responsibility imposed directly by law.

Registered in the Commercial Register maintained by the Municipal Court in Prague, Section C, File 311152.

For privacy questions, support, or a request to exercise your rights, write to crewnexo@silkidea.com. You can also write to our registered office.

2. Information on your device and roster imports

• Original roster PDFs are imported and parsed on your device. Roster import does not upload the original PDF file to CrewNexo. If you separately choose to attach a PDF or another document to a chat, that selected file is uploaded as chat content.
• Parsed roster data is uploaded automatically after onboarding and when your roster changes, separately from sharing with friends. Supported apps minimise the service-readable upload on the device: selected health/medical and works-council activity codes become the neutral ABS code with their station and times; qualification entries, parser messages and the corresponding sensitive-code legend entries are omitted; structured flight crew lists keep only the roster owner and ground participant-name lists are removed. Free-text activity information and remarks, flight remarks and day notes are omitted, apart from extracted FTL-extension codes needed for calculations. Duty markers are also reduced to those extension codes. The server applies an additional minimisation step to incoming roster data, including older clients. The service-readable copy still includes identity/staff number, duties, flights, times, stations, hotel details and retained structured fields needed by the service. Older clients can transmit more before server-side filtering. New imports do not by themselves rewrite every earlier stored revision or backup.
• Sensitive details and minimisation: the selected-code replacements and removal of the fields above reduce the service-readable information about health and works-council matters; they do not make your roster anonymous. Your full local roster and the separately sealed copy for your own devices remain distinct from this minimised copy. Imported formats and codes can change, and these measures are not a promise to recognise every possible sensitive statement in content you provide. Do not include unnecessary medical information, trade-union details or sensitive information about other people in chat, files or feedback. Accepting the EULA or reading this policy is not explicit consent to process special-category data.
• Synchronisation between your own devices: supported apps download roster revisions to other authorised devices on the same account. Alongside the minimised service-readable copy, they can upload a separately sealed full copy, including the original activity details and crew names, for those devices. The devices hold the keys for this extra copy and exchange them as encrypted key bundles relayed by the service; the service stores device public keys and key identifiers, not the unwrapped device-held roster key. This extra copy is not shared with friends and does not make the separate service-readable copy end-to-end encrypted. Losing all devices holding a key may make the sealed copy unreadable; importing the original roster again can restore it. The original PDF itself is not synchronised by this feature.
• Your airline password and sign-in sessions are used on your device to access the airline's own sign-in and roster services. A saved password is protected by iOS Keychain or encryption using Android Keystore. CrewNexo does not receive your airline password. The airline and its sign-in providers process your login under their own policies.
• Airline verification codes and clipboard: supported sign-in flows can help fill a one-time verification code into the airline or its identity provider’s page. If you use Open RSA app and return to CrewNexo, the app can read a code you copied to the clipboard during that short sign-in step and fill/submit it automatically. Manual entry/pasting remains available. The code is used on your device for that sign-in flow and is not sent to the CrewNexo backend. Clipboard access for this feature is limited to the requested verification flow; it is not background reading for analytics.
• Local roster history and country summaries: supported apps can keep the newest imported copy covering each month and remove superseded local files. This local cleanup does not itself erase earlier revisions already uploaded to CrewNexo or copies on another device. Days-by-country and shared-flight history are calculated from the roster available on the device; they are estimates of rostered activity, not live location tracking or proof of tax residence.
• QR invitations and camera access: supported apps use the camera with your permission, or an image you select, to read an invitation on the device. The decoded invitation and acceptance information can be sent to CrewNexo to establish the connection; this feature does not upload the camera feed to CrewNexo. On supported Android versions the QR model is bundled for offline scanning.
• Calendar exports are written to the calendar you choose. Your calendar provider may sync them under its own settings and policy. Deleting your CrewNexo account does not remove those exported entries.
• Photos, videos and Live Photos selected for chat: supported apps resize/re-encode pictures to remove embedded EXIF metadata, including GPS coordinates, and prepare videos and Live Photo clips without embedded location/device metadata. A Live Photo can include both a still picture and its short video, including sound where present. Anything visible or audible in the media remains available to recipients. Preparation can change quality, format or motion playback.
• Documents and other chat files are sent without cleaning their contents or embedded metadata. Their original text, author information, comments, revision history, location information or other personal data can therefore remain. The file name is also shared with recipients. Check a file before sending it, especially if it contains a roster or information about other people.
• A location sent in a message is an optional, one-time point: either a place you select or a device-location fix obtained with your operating-system permission. You can use an approximate location if your device permits it, choose a different point, or decline location permission. The chat payload can include latitude/longitude, accuracy, a place name and an address. It is sent to CrewNexo when you choose to send the message; opening the picker alone does not upload a location message to CrewNexo. This feature does not continuously update your location or request background location tracking.
• Local protection and downloaded copies: supported apps can hide conversations behind a local secret-chat code or app lock. The local code verifier remains on the device; we do not receive the code or its verifier. Optional Face ID, fingerprint or device-authentication checks are handled by the operating system; we do not receive biometric templates. Devices can cache decrypted media or temporary previews for playback, viewing or sharing. These copies rely on device/app protections; a preview, an export to another app or a saved copy is separate from the encrypted server object.
• Background uploads and saving media: where supported, an encrypted upload can continue through the operating system's background-transfer service after you leave the app; completing the chat message can wait for the app to resume. Supported versions offer separate choices to save received pictures or videos to Photos/the device gallery. These are off by default and exclude hidden chats; video saving applies to subsequently received videos from other people after you enable it. Turning the setting off or later hiding a conversation does not remove copies already saved. Your gallery or cloud-photo service handles those copies under its own settings, including any backup or synchronisation.
• Link previews and external sites may be fetched directly by your device. The destination can receive your IP address, the requested URL and ordinary connection information. Weather requests sent to our aviation weather service contain an airport code and connection information such as an IP address; they do not include your CrewNexo profile or full roster.

3. Information we process and why

Plus purchase flow: where available, purchases use Apple's App Store or Google Play. The app sends a signed Apple transaction or a Google purchase token to CrewNexo for verification. To associate a purchase with your CrewNexo account, Apple receives your CrewNexo account UUID as an app-account token; Google receives a hash derived from that UUID as an obfuscated account identifier. These identifiers are not anonymous. The service processes renewal, cancellation, refund and revocation updates using the stores' APIs and notifications, including Google Cloud Pub/Sub delivery for Play updates. Google purchase tokens are encrypted at rest; transaction identifiers and operational status fields are not all encrypted. This flow does not collect your full payment-card number in CrewNexo.

Supporter badge: active Plus and your visibility setting can cause a supporter icon to appear beside your already-visible profile in friends, conversations, groups/meetups, offers and jump seat requests. The setting is on by default in supported versions and can be switched off in privacy preferences. The icon does not show an amount, transaction identifier or card details, and does not prove that someone paid a particular price rather than receiving a trial or other entitlement. In a supported crew list, the service can also return the badge for eligible CrewNexo users on the same flight segment, including people who are not your friends. Purchasing Plus does not expand access to other people's profiles or rosters.

Call-quality diagnostics: supported versions keep a small recent-call log on the device, including connection time/direction, connection-path type, duration and technical quality measures such as latency, jitter, buffer delay and bitrate. The quality log does not record the call audio or message contents. It is not automatically uploaded as routine analytics; you can choose to attach the available diagnostic text to feedback. Once sent, it is linked to that feedback and can be included in the operator's email digest. Device logs are bounded by the number of recent calls/samples, rather than the server's six-month call-record retention, and can remain until replaced or app data is removed.

Roster-download diagnostics: when you submit a problem report in supported versions, the latest available download trail is attached automatically; attaching it is not a separate opt-in. It contains technical steps, host names, masked URL paths, status/content types, timings and download/skip reasons. Apps remove credentials and direct identifiers, and the server applies additional scrubbing. This reduces exposure but does not guarantee anonymity: the trail is linked to your feedback and can still reveal technical or contextual information. It is encrypted at rest and available to authorised operators, not sent in the daily email digest. It has a separate 30-day retention period from submission; the feedback text and any call-quality log appended to that text have the feedback period below. A local trail or unsent report can remain on the device until replaced, sent or app data is removed.

First-party usage measurement: in supported versions from the consent-enabled release, measurement is off until you choose Allow measurement after an explanation. Don't allow, closing the question or later withdrawal does not restrict ordinary app functions or change their price. You can change your choice under Privacy → Help improve CrewNexo on this device. The choice applies to that installation, separately from accepting the EULA or other optional settings.

After permission, the app creates a fresh random installation/session identifier and can queue up to 2,000 new events offline. Measurement concerns named screens/controls, time on screens and transitions, platform, app version, language and event times rounded to a minute. It is designed to exclude roster/message/file contents, flight details, coordinates, names, emails and account identifiers. Batches use a separate analytics-consent credential, not the account sign-in token. We also record the explanation version/language, times of grant/acceptance/withdrawal and token-verification information to evidence and enforce the choice. Connection infrastructure sees the IP address; the service uses an IP-derived daily rate-limit hash for a short period. This is CrewNexo's own measurement service, not a third-party analytics SDK or cross-app advertising tracker. Raw events and identifiers are pseudonymous, not completely anonymous.

Withdrawal stops new collection and clears the local queue. Supported apps request deletion of raw events for that consent session and keep a pending request for retry when connectivity returns. Completion requires the service to receive and process the request; do not assume immediate deletion while offline. Deleting the account from that device invokes the same session process. A request cannot automatically identify sessions on your other devices by account email because those identifiers are not joined to the account; already produced daily totals and the limited evidence-of-choice record are separate. Contact us for assistance without sending credentials. Earlier beta versions used an on-by-default preference and an older deletion flow; that pre-enabled preference is not treated as affirmative consent for the new mechanism.

Marketplace plan checks: your roster-derived duty/rest/flight information and the proposed change can be used to filter line offers, show an indicative FTL check and check a pending arrangement again after a roster update. The detailed check shown is for your own side; other participants receive only the feature's limited eligibility/status information, not your full roster or numerical duty history. Checks can be incomplete beyond the available roster and can prevent an app action or cancel a pending in-app arrangement; they do not change the official roster or replace crew control's decision. Offers split into days or grouped as a block share related offer/response identifiers for that feature.

Optional place counts: if you opt in, roster-derived stays and your home-country/language settings contribute to counts visible to eligible users at an overlapping stay. Results are bands (such as “<5”), not a named list or a country/language combination identifying a person. Participation can be switched off independently of friend sharing. A small group or information known outside the app can still allow inferences; we do not promise that every count is anonymous.

Meetup and group tips: recommendations use fixed rules over your own roster-derived stay and off-duty intervals, events you are allowed to see, friends attending, previous participation, language/country and your feedback. This is profiling to suggest social activities, not a decision with legal or similarly significant effects. The app can calculate suggestions locally; online suggestions and push tips also use the roster-derived information already held by the service. These calculations do not give other users access to your roster or enable separate presence-sharing visibility. In-app tips remain separately controlled. General tip pushes are off by default in current supported versions and can be enabled in notification preferences; earlier versions may have different defaults. Personal invitations are a separate, individually switchable notification category and do not require general tip pushes to be on. You can manage in-app and push tips separately, adjust quiet hours and limits, and remove “not interested” feedback. You can also object by contacting us.

We receive information from you and your devices, from rosters you import, from users who invite you, communicate with you or report content, and from the beta distribution platforms.

We do not sell personal data, display third-party advertising, use advertising identifiers or track you across unrelated apps and websites. We can show CrewNexo's own optional Plus offers and reminders, using account age, entitlement state and local reminder controls rather than tracking you across other apps. Roster-based presence matching, event discovery and social tips use roster stations and dates, which can reveal where you are expected to be. They do not use a location pin you send in chat. Access to device location is limited to the optional one-time location-message feature described above; it is not used for advertising or continuous tracking.

4. Sharing and access

Friends: you approve the sharing scope and date range. A supported invitation can include the author's advance approval, so the recipient's acceptance can complete the connection without another author confirmation. Other invitation flows require both confirmation steps. Check the person and proposed scope before showing or forwarding an invitation. Remote invitations expire within three days in current supported versions; an in-person QR can have a shorter lifetime. Declining an invitation can temporarily suppress another request from the same sender. Ending friend sharing and deleting existing copies follow the rules below. A Plan view includes selected duty and flight information and night-stop stations; it excludes crew lists, hotel details and roster notes. Availability shows a reduced view. Friend only does not share your days. These limits concern what your friend receives, not what the server processes for your account.

Crew and events: flight participation, event audiences and the relevant feature rules determine who can find or interact with you. A verified CrewNexo user on the same flight segment can receive your sharing name, crew code, rostered role, avatar reference, enabled supporter badge, call availability and indicative latest FDP end times, including a separately labelled discretion estimate. This does not require friendship or a friend-plan sharing grant. The FDP values are derived from the roster you uploaded and may be missing or inaccurate; the crew-list response does not disclose your full roster. Apps may match these entries to crew names already held on the device. A crew chat can cover multiple segments flown by its creator that day, so authorised participants from any covered segment may share that conversation. Disabling friend sharing does not by itself remove you from conversations, requests or events you have joined. Do not post roster screenshots or information about colleagues unless you are entitled to share it. Recipients can save, screenshot or forward content; revoking access cannot recall copies they have already made.

Crew-list calls: calling permissions include role-based exceptions on a shared flight. Around the flight day, a captain can call that flight's crew and a purser can call its cabin crew and captain without friendship. The “nobody” setting normally prevents these calls, but a captain on the same flight can override it during the last three hours before departure; user blocking still prevents contact. Other crew-to-captain and friend/chat rules also depend on the app's current calling setting and shared-flight window. A crew-list call need not create a message in a chat. These are CrewNexo communication rules, not airline operational authority.

Ground activities and simulator participants: supported apps send short tags derived from participant names, the activity date and station, alongside the activity code/time/place. The service uses the uploaded roster and these tags to match eligible users to the same activity, including matching across participating airlines. The tags can collide and can be interpreted with contextual information; they are not anonymised names or a guarantee of membership. The app can match service profiles to names already held locally. Supported build-68 minimisation removes structured participant-name lists before the service-readable upload; older clients can still send these names before server-side removal. Import/version limitations and the remaining structured information are explained in section 2.

A ground chat can add eligible verified users automatically, including later roster uploaders, without a friend invitation. Its participants can see the relevant profiles, supporter badge and communication options and may have access to the conversation history. Roster changes do not necessarily remove existing members. You can leave a conversation and manage the ground-chat setting, which is on by default where available. Turning it off prevents new eligibility/listing but must not be understood as erasing already delivered content or automatically ending every existing membership. Direct messages between matched participants do not require friendship; calls use normal calling permissions, without the captain/purser flight exceptions. Selected health, absence, representation and other sensitive activity codes are excluded from this matching. The selected-code replacements in the service-readable copy and the separate full sealed copy are explained in section 2.

Inactive conversations: marking a chat inactive changes your own list, suppresses its message pushes and excludes it from your unread badge in supported versions. Other participants retain access; incoming messages do not by themselves reactivate it. Sending your own message or choosing to activate it can do so. This setting, hiding, muting, leaving and erasure are different operations.

Hidden or “secret” chats: hiding changes your own view, not the other participants' access. It does not delete the conversation, change the retention clock or add end-to-end encryption. The service still processes the content and your hidden flag. A compatible app applies its local unlock controls; an older app can omit a hidden chat from its list without providing the same local protection, and authenticated access to its contents can still be possible. Hiding is not a replacement for protecting your account and devices.

Media and location recipients: authorised conversation members receive the content you send, including file names, associated previews, Live Photo clips and location coordinates. Older apps may show a Live Photo as a still image, replace a video/file with an update notice, or show a location as text with a Google Maps link containing its coordinates. A fallback is not anonymisation and does not withhold the location from that recipient. Copies, forwarded links and exported files cannot be recalled by hiding a chat or changing a notification setting.

Groups, meetups and invitations: visibility follows the audience selected for the event. Where supported, station-based groups can be discovered from your current roster-derived stay or a stay starting within the next seven days; a timed meetup uses the expected stay at the event time. This does not make your full roster visible. A group member creating a related meetup can invite selected existing members even if their roster station differs; source-group identifiers and invitation/participation records link those features. Ending, cancelling, removing an event from lists and erasing data are separate operations.

Blocking and reporting: where available, you can block a person or report a person or message. Blocking ends existing friend sharing and restricts contact, invitations and calls; it does not recall copies already received or remove all content from shared conversations. Unblocking does not automatically restore sharing. A block is not automatically an abuse report. Report details are available to authorised operators for review and handling.

Automatic content checks: public-facing profile/event text can be checked against word rules. Group and meetup titles and descriptions can also be scored by a model running on SilkIdea's shared coolAltitude moderation infrastructure on the same hosting server. This path sends the submitted title/description for classification; it is not general inspection of private chat messages or the separately sealed roster. A check can reject text, flag it for operator review or, after a delayed check, restrict an event's visibility to its creator until corrected. Results and moderation state can be stored with the event. The model can make mistakes; contact us to request human review or contest a restriction.

Information about colleagues: a roster or a message supplied by another user can contain information about you even if you do not use CrewNexo. We do not assume that the uploader can consent on your behalf. The source can be that user's roster, airline-issued document or communication. Contact us for information, objection or erasure; other people's rights and any applicable legal exception are considered when responding.

Service access: authorised people operating CrewNexo may access data where necessary for support, maintenance, security, content-report review or legal obligations. We may disclose necessary information to professional advisers or competent authorities where legally required or necessary to establish, exercise or defend legal claims.

5. Providers, locations and security

Our application server and database are hosted by Hetzner Online GmbH in Germany. Encrypted chat media and files, including previews and Live Photo clips where supported, are stored in Hetzner Object Storage in Falkenstein, Germany. Restricted recovery copies may also be held by the operator in the EU. Verification, support and feedback-digest email use the SilkIdea mail service hosted through onice.io; email also passes through your own mail provider.

Apple Push Notification service (APNs) and Google Firebase Cloud Messaging (FCM) deliver notifications. Notification payloads can contain a conversation title, sender information and a short message preview. APNs also carries duty information for iOS Live Activities and VoIP call notifications; call notifications can include caller information and a call identifier. Android incoming-call notifications use FCM. These providers therefore process more than a device token. For a hidden conversation, supported settings send only a neutral “CrewNexo / New message” notification without a sender name, message text, picture or conversation identifier, or suppress that push entirely. Hidden conversations are excluded from the unread badge by default; you can include them. A separate option makes message pushes neutral for all conversations, but does not automatically anonymise every other type of alert. Notification providers still receive routing information, a device token, delivery timing and any badge count. These settings do not retract notifications already delivered. Use your app, notification and lock-screen settings to control what is shown on your device.

Purchases and stores: Apple and Google process store accounts, payments and purchase history under their own store terms and privacy policies. CrewNexo exchanges the purchase/account identifiers and verification information described above with them; Apple server notifications and Google Play API/Pub/Sub messages update your entitlement. Entitlement changes can also trigger a silent APNs/FCM notification so your devices refresh their state. This version uses direct store integration and does not add a separate subscription-management service such as RevenueCat. See the Apple Privacy Policy and Google Privacy Policy.

Voice calling and Cloudflare: supported voice calls use the microphone with your device permission. WebRTC audio is encrypted between the participating devices (DTLS-SRTP), whether the connection is direct or relayed. CrewNexo handles call signalling and metadata and does not record call audio. A direct connection can reveal your IP address to the other participant. Cloudflare, Inc. provides STUN connection assistance and, when needed and configured, Realtime TURN relay as a processor for connection/relay data. Its infrastructure processes IP addresses, ports and session timing and forwards encrypted audio packets; it cannot read the WebRTC audio content. See Cloudflare's TURN privacy explanation and Data Processing Addendum. The phone's operating system may keep its own call history under your device settings.

Maps: map display, place searches, address lookup and map previews can involve your device's map provider, including Apple Maps on iOS. The provider can receive the map area or coordinates, search terms and connection information such as your IP address. Opening a shared point in Apple Maps or Google Maps also sends the chosen coordinates to that provider; a location fallback in an older app includes a Google Maps URL. These providers process those requests under their own policies. See Apple Maps & Privacy and the Google Privacy Policy. CrewNexo does not run these external map services.

Apple, Google, Cloudflare and their service providers may process data outside the European Economic Area, including in the United States. Their published transfer arrangements include EU standard contractual clauses and, for eligible Google transfers, the EU–US Data Privacy Framework. Details and ways to obtain information about the safeguards are in the Apple Privacy Policy, Firebase privacy information and Firebase data processing terms. Contact us for information about transfers concerning your CrewNexo data. Cloudflare publishes standard contractual clauses and safeguards for restricted transfers in its Data Processing Addendum. Hosting the main database in Germany does not mean all processing stays in the EU.

Traffic between the apps and CrewNexo uses HTTPS/TLS. Stored message text is encrypted on the server with a separate key for each conversation. Chat photos, videos, Live Photo components, documents and their previews are encrypted on your device before upload using AES-256-GCM; larger supported formats use authenticated chunks. The object store holds encrypted files. Location-message fields are encrypted at rest on the CrewNexo server. File names are encrypted at rest; file types, sizes, dimensions/duration, identifiers and upload state can remain readable operational metadata.

Parsed roster content and stored details derived from it for flight/ground-activity participation and stays are encrypted at rest using AES-256-GCM. Matching flights, places and duty days uses keyed lookup fingerprints rather than storing those lookup values as plain text in the matching indexes. Selected account/profile fields, including names, email addresses, date of birth and profile pictures, are also encrypted at rest.

Encryption does not cover every database field. Some identifiers and operational metadata, such as account IDs, roster date ranges, staff numbers, crew codes and account preferences, remain readable in the database. The service decrypts server-protected content when needed to provide the features you use. The separately sealed roster copy for your own devices uses the different device-key arrangement explained in section 2; it does not make the service-readable roster or chat inaccessible to the service.

These protections are not irreversible anonymisation. Rosters remain linked to your account, and the service can process their contents. Removing other people's crew-list entries before storage reduces the information we retain about them, but does not make your own roster anonymous.

Chat is not end-to-end encrypted: the CrewNexo service holds or can retrieve the keys needed to deliver stored messages, location content, media and files. Encryption does not prevent authorised service access. Access controls and restricted operational access provide additional protection.

6. Legal bases and required information

• Providing the service — GDPR Article 6(1)(b): account access, roster processing and synchronisation, sharing you request, conversations, media/file delivery, a one-time location message you choose to send, your hidden-chat and notification settings, device-to-device roster/key synchronisation, regional feature checks, purchase verification and Plus entitlement/restoration, your supporter-badge setting, voice-call setup and history, contact blocking, events, offers and related notifications. Without the information required for a particular feature, we cannot provide that feature. You do not have to use the social features.
• Your consent — Article 6(1)(a): optional usage measurement in the consent-enabled releases, optional participation in place counts and optional profile fields/disclosure where consent is requested. These are separate choices; no payment or general acceptance of the EULA substitutes for them. Withdraw measurement on the device or change the relevant profile/count control; contact us for help. Withdrawal does not affect processing lawfully performed before it. This ordinary consent paragraph is not a substitute for an additional Article 9 condition for special-category roster data.
• Legitimate interests — Article 6(1)(f): securing the service, preventing abuse and purchase reuse, handling reports, content checks and support (including airline-support requests and in-app feedback), administering the beta, diagnosing faults and recommending relevant groups/meetups using the information described above. Our interests are a safe, functioning service, responding to requests, improving CrewNexo and helping crew find relevant social activities without disclosing their roster to other users. Tip profiling is optional and can be switched off. You can object on grounds relating to your situation.
• Evidence of choices and restricted retention — Article 6(1)(c)/(f), where applicable: retain the minimum proof needed to demonstrate an analytics choice and withdrawal, comply with accountability obligations and resolve a particular dispute. This does not authorise new analytics after withdrawal. For roster-derived profile/FDP/ground visibility involving other people, our interest is enabling relevant crew contact while restricting disclosure to the matching context. We do not treat an uploader's choice as everyone's consent; applicable necessity, balancing and objection requirements remain.
• Contract evidence — Article 6(1)(b)/(f), as applicable: the minimum record of accepting the EULA supports concluding/administering the agreement and our legitimate interest in demonstrating the agreed terms and handling contractual claims. It is not consent to analytics or every use of personal data.
• Legal obligations — Article 6(1)(c): where we must respond to a valid legal requirement, fulfil data-protection obligations or retain particular transaction records required by applicable accounting/tax law. This does not make every purchase token a mandatory accounting record.

CrewNexo does not make solely automated decisions that produce legal or similarly significant effects on you. Matching or eligibility suggestions do not constitute an airline's approval of a roster change or jump seat.

7. Beta testing data

For TestFlight, Apple automatically provides us with crash and usage information and may provide your tester name, invitation email, device and operating-system details, installation information and feedback. Feedback can include screenshots you choose to send. We use this information to administer testing, investigate issues and improve CrewNexo. See TestFlight & Privacy for Apple's collection and retention, including which information is collected automatically.

If you test through Google Play, Google processes your testing participation and may make crash, diagnostic and feedback information available to us according to your Google settings and its Privacy Policy. The use of FCM for Android notifications is separate from advertising or cross-app tracking.

Avoid including passwords, full rosters or unnecessary information about other people in screenshots or feedback.

8. Retention and deletion

• Account, profile, uploaded roster history and account settings: kept while your account exists, unless you remove or correct particular information earlier. A new roster does not erase your old revisions. Account deletion removes the account, profile, devices, roster revisions and sharing connections from the live database when the deletion request succeeds.
• Direct chats and friend groups — normal storage: each message, including its location payload and associated media/file objects/previews, is removed by scheduled cleanup six calendar months after sending. Photos, videos, both Live Photo components and documents are included. The conversation/membership/settings may remain; attachment records are addressed separately.
• Other event chats — normal storage: flight, ground-activity, meetup and other event messages/location/media are removed six calendar months after the event ends, using its start if no end is recorded. A message in a long-running event can remain longer than six months from sending. Unsent uploads are removed after one day at the next successful cleanup. Account deletion does not restart these periods.
• Hiding, inactivity and deletion controls: hiding, locking, muting or marking a conversation inactive does not erase it or change its storage rule. Successful message deletion clears text and location and removes associated media; a deletion marker may remain for synchronisation until the message row is removed. Event cancellation/removal from lists is separate from erasure; participation/moderation records follow their own criteria.
• Attachment database records: after successful deletion of a file object, the current cleanup flow clears its stored decryption key, encrypted file name, dimensions and duration. Remaining upload/deletion records are removed at the next successful scheduled cleanup after they have been marked deleted for one day. This brief interval supports upload accounting and synchronisation; it is not an indefinite attachment archive. Temporary storage failures can delay object removal and are retried; restricted backups follow their separate rules below.
• Sealed roster and key-exchange records: kept with your account and roster history; account deletion removes the server-held sealed copies, device public-key registrations and wrapped key bundles from the live database. Revoking a device clears its roster public key and wrapped bundles addressed to or sent from it. It cannot erase a key or PDF already copied to a device or an independent export. If you change accounts on a device, original local PDFs may be set aside for the previous account and reappear if that account returns; signing out is not a promise to erase every original PDF.
• In-app feedback: database submissions are removed by scheduled cleanup twelve calendar months after submission. Account deletion removes the account link, but does not automatically erase the message text; it may still identify you. Email digests already sent can contain your work email and message. Operator-mailbox copies must be managed separately and removed when no longer needed within the same twelve-month period, unless particular correspondence must be kept for a legal obligation or claim. Contact us for earlier erasure.
• Roster-download diagnostic trails: the separate encrypted diagnostic field is cleared by scheduled cleanup 30 days after feedback submission. Deleting an account removes the account link, but does not immediately erase this diagnostic field. Call-quality text appended to the feedback body follows the twelve-calendar-month feedback period instead.
• Usage measurement and consent evidence: raw events are removed by scheduled cleanup after a 30-day threshold following aggregation, using daily cleanup boundaries. Batch records and IP-derived rate-limit hashes use a one-day threshold. A valid session-withdrawal request removes that session's raw events/batches earlier, once processed. The separate evidence record (including session identifiers, explanation version/language and grant/acceptance/withdrawal times) is currently removed after a 365-day threshold measured from withdrawal, or otherwise from the last accepted batch, or acceptance if no batch exists. It has no account/email join. Daily totals without installation identifiers currently have no fixed automatic expiry; low-count totals require protection and contextual assessment and must not automatically be assumed anonymous. Local queues and pending withdrawal credentials are separate device data.
• Ground-activity matching: derived ground details/tags follow the account and relevant roster revisions, not merely the six-month chat-content clock. Account/roster deletion and actual relation constraints determine their removal. Disabling ground chats is not a request to erase the underlying uploaded roster.
• Email delivery suppression: email-derived hashes, reasons and dates can remain independently of account deletion to avoid repeated undeliverable/unwanted delivery. The current table has no automatic expiry; retain a record only while necessary for that suppression purpose or a specific legal need, review it and contact us for correction/removal where appropriate.
• Store-country records: held with the device/account record and updated when a supported app reports a change; deleting the account removes them from the live database.
• EULA acceptance evidence: we keep the document/version and text hash, acceptance method, interface language, platform/app version, client-operation identifier, client/server times and account link to demonstrate the agreement and handle contractual questions or claims. Account deletion removes the account link. At the next successful scheduled cleanup, the service records when it first finds the acceptance detached from the deleted account; automatic deletion follows once 36 calendar months have elapsed from that recorded date. This is not a new period for your roster, chats or analytics events. The remaining receipt can still be personal data; unlinking is not a guarantee of anonymity. Earlier erasure or restriction can apply where required by law. Released EULA texts are archived by their hash so the agreed wording can be retrieved; the archived legal text itself does not contain your acceptance record.
• Purchases and Plus: the current purchase-verification implementation has no blanket automatic deletion period for purchase rows. We keep the information needed to validate a current subscription or one-time entitlement, recognise renewals/refunds and restorations, prevent purchase reuse, resolve a particular dispute and meet applicable legal record-keeping requirements. Different purposes can require different fields and periods; unnecessary information must be deleted or de-identified when those purposes end. Account deletion removes the live account link and account-linked retry/request records, but does not automatically remove the store transaction identifier, token or purchase status record. Those remaining identifiers can still be personal data; unlinking is not anonymisation. Contact us for erasure of data no longer needed. Store-held payment/purchase records follow the store's own retention and your applicable rights there.
• Plus reminders and badge preference: held with your account settings until changed or the account is deleted; local prompt counters and cached purchase/diagnostic state are separate device data. Turning off the supporter badge stops future display through the service after synchronisation, but cannot recall screenshots or stale offline copies.
• Hidden/inactive-chat flags and preferences: held with your membership/account settings until changed, the membership is removed or the account is deleted. The local code/verifier and device unlock choices are separate device data.
• User blocks: kept until you unblock the person or either account is deleted. Unblocking does not delete a separate report.
• User reports: kept while being reviewed, then removed from the live database by scheduled cleanup twelve calendar months after they are marked handled. Account deletion removes the link to a deleted reporter or reported profile, but does not automatically erase the report's reason or context, which can still identify people. Reports of particular messages remain linked to those messages and are removed when the message is removed; they do not have the separate twelve-month user-report clock.
• Airline-support requests: the request record, including your contact email, is removed from the live database by scheduled cleanup twelve calendar months after submission, or earlier when it is no longer needed after support is added and applicants are informed. These requests can exist without an account, so deleting an account does not automatically identify and remove a separate request. Contact us to withdraw it. Operator-mailbox copies are managed manually and must also be removed when no longer needed, within the same twelve-month period, unless particular correspondence must be retained for a legal obligation or claim.
• Call metadata: call records are removed by scheduled cleanup six calendar months after the call was initiated, or earlier when either participant's account is deleted. A call-history entry posted in a conversation follows that conversation's message-retention rules. Temporary offers, answers and network candidates are cleared when the call ends or expires; stale network candidates are also subject to short setup cleanup. Audio is not retained. VoIP push tokens remain until replaced, removed or the linked device/account is deleted.
• Tip preferences and feedback: kept while your account exists, unless you change or remove them earlier. Records used to limit and avoid repeating sent tips are removed by scheduled cleanup after thirty days.
• Other event, request, offer and confirmation records: the chat-content cleanup does not automatically delete these records. We retain them while needed to operate the feature, show participation or agreement history, resolve a report or dispute, or establish, exercise or defend legal claims. We delete or de-identify information once those purposes no longer require it; some account-linked records are removed by account deletion.
• Security records, technical logs and verification/support correspondence: kept only while needed to check verification, diagnose the issue, prevent abuse or resolve the relevant report, request or legal claim. The service does not apply one automatic deletion period to all of these records. Routine rate-limit records use short cleanup windows, normally about one day.
• Beta feedback and diagnostics we retain: kept while needed to investigate the reported issue and validate the fix or administer your participation, then deleted or de-identified unless a legal obligation or claim requires retention. Apple's and Google's own retention is described in their policies.
• Backups: the configured database backup process creates restricted server exports, encrypts them for recovery and uploads them to a separate Hetzner Object Storage bucket. Successful upload removes the corresponding plaintext dump; a pending/failed export can remain in restricted server storage. The remote rotation keeps seven daily copies and three monthly copies; encrypted local copies have a three-day cleanup threshold. Rotation is by stored copies; interrupted schedules can leave copies older than the usual daily/monthly cycle. Separate recovery exports are managed manually and kept only while necessary. The recovery private key is held separately by the operator; this does not make live service data inaccessible to CrewNexo. Restricted copies can contain deleted data until rotation/removal; on restoration, applicable erasures and withdrawals must be reapplied before restored data is put back into ordinary use.
• Offline copies of friends' plans: removed at the next successful sync after access ends, or when the app next checks a cached copy older than 31 days. Revocation cannot instantly erase an offline device or independent screenshots and exports.

Deleting your account does not automatically delete messages, location messages, media or files already sent to other members: they remain subject to the chat periods above. The service removes the link to your deleted profile and no longer supplies your profile name as the author; the content may still identify you. Ask us if particular content also needs erasure. Local PDFs, calendar exports and copies held by recipients are separate from your server account. Removing the app alone does not delete your account.

9. Your choices and rights

Use More › Account › Delete account in the app and confirm the deletion, or email crewnexo@silkidea.com to request deletion without the app. You can contact us even if you no longer have access to your original work email or your beta account did not have a verified email. Include your account email or another account identifier if you know it; do not send passwords or roster PDFs. We may need proportionate information to verify that the account is yours. Verified deletion requests are carried out without undue delay, subject to the retention and legal exceptions described above. See Delete your account for the steps and the effect on your data.

You can also stop friend sharing, change optional profile visibility, leave supported conversations, manage inactive/hidden settings and ground-chat eligibility, manage blocks, report abuse, change who may call you, turn off tips or usage measurement and control notifications, location permission or microphone access in the app or device settings. Revoking location permission stops future device-location access; it does not erase a point you already sent. Turning off push tips does not automatically turn off in-app suggestions; each has its own control.

You can manage renewal or cancel a subscription in the store where you bought it. Deleting your CrewNexo account or uninstalling the app does not by itself cancel store billing. You can ask us to delete personal data even if a subscription or purchase issue remains; cancellation, refunds and erasure are separate processes. See the End User License Agreement for the purchase terms.

Under the GDPR, where applicable, you can request access to your data, correction, erasure, restriction of processing and a portable copy of data you provided. You can withdraw consent and object to processing based on legitimate interests. These rights are subject to the conditions and exceptions in the GDPR, including other people's rights. We normally respond within one month; if a lawful extension is needed, we will explain it within that month.

You may complain to the Czech supervisory authority, Úřad pro ochranu osobních údajů, through uoou.gov.cz, or to the supervisory authority where you habitually live, work or believe a violation occurred.

10. Children and changes

CrewNexo is intended for adult airline crew, aged 18 or over, and is not directed at children. The distribution store's content rating is separate from this intended audience. If you believe a child has provided personal data, contact us.

We will update this page and its effective date when the policy changes. We will bring material changes to users' attention through the app or an appropriate direct notice. Where a new use requires consent, we will request it before that use begins.

For the licence and conditions of use, see the End User License Agreement. Publishing that agreement does not by itself replace any agreement you previously accepted.