FlightCrewView

Flight Crew View Trust Center

Last updated: December 9, 2025

Flight Crew View (“FCV”) is built by a pilot, for crews, and is a product of Flight Crew Apps, LLC. We protect crew schedules, trip details, messages, and account data with modern security controls and a privacy-first approach.

Security Program Overview

Flight Crew View operates a security program designed to protect the confidentiality, integrity, and availability of customer data. Our approach is risk-based and tailored to a small SaaS platform that processes sensitive crew schedule, trip, and layover information. We design our controls with an understanding that time- and location-based data can present elevated personal safety, privacy, and employment-related risks.

Our security program is built around clear accountability, logical separation between tenants, least-privilege access to systems and data, encryption in transit and at rest, monitoring of systems and access, and documented procedures for incident response, onboarding, and offboarding. We aim to collect and retain only the data required to provide Flight Crew View’s features, and we restrict internal access to customer data to legitimate operational, support, or security purposes.

While Flight Crew View does not currently maintain a SOC 2 or ISO 27001 certification, we align our practices with widely accepted security principles reflected in those frameworks. We continuously review and improve our controls as our product, customer base, and regulatory expectations evolve.

Our pillars

  • Encryption everywhere (TLS in transit; provider-managed at rest)
  • No ads or data sales. We never sell your personal data or share your schedule with advertisers.
  • Least-privilege access to production with MFA
  • Per-airline isolation (no cross-tenant mixing)
  • Transparent practices (Trust Center, Privacy Policy, VDP)

Security Governance & Access Management

Security ownership

Security at Flight Crew View is owned by the company’s founder and principal engineer. Security responsibilities include application security, infrastructure protection, incident response, and oversight of internal access to user data. Our security program is designed to be appropriate for a small SaaS platform handling sensitive crew schedule and trip data, and is continuously refined as the product and customer base grow.

Team roles & production access

Flight Crew View intentionally operates with a small team. Access to production systems and user data is tightly restricted and granted only where necessary to perform specific job functions.

  • Access to production infrastructure and databases is limited to a minimal set of authorized roles.
  • Customer support access is read-only for user accounts, with the ability to adjust only a small number of support-related settings.
  • Contractors do not have standing access to production infrastructure or databases.

Where support or debugging requires access to real user data, access is granted on a temporary, ticket-specific basis, limited to the minimum data required, and revoked once the task is complete.

Least privilege & access reviews

We apply the principle of least privilege to all internal roles.

  • Access is provisioned based on job responsibilities and removed when no longer required.
  • Admin and support access is reviewed at least quarterly, and additionally upon role change or departure.
  • Privileged actions and access to sensitive systems are logged and reviewed during investigations and access reviews.

Onboarding & offboarding

Flight Crew View maintains written onboarding and offboarding procedures for roles that interact with internal systems or customer data. These procedures cover:

  • Account provisioning and permission assignment
  • Required training on data handling and confidentiality
  • Prompt access removal when a role changes or ends

Confidentiality & data handling obligations

All staff and contractors with access to user data are bound by confidentiality obligations, including contractual confidentiality terms and non-disclosure agreements where applicable. Internal access to user schedules and trip data is permitted solely for legitimate operational, support, or security purposes.

Safeguards against misuse

Using Flight Crew View to stalk, harass, intimidate, or improperly monitor individuals is strictly prohibited and violates our Terms of Service. We investigate reports of misuse and may take actions such as access revocation, account suspension, or other remedial measures where appropriate.

Crew schedule, trip, and layover data is treated as sensitive personal data, and access to it is restricted accordingly.

What we collect & why (high level)

  • Account info (name, email, photo, airline): create/manage your account, support.
  • Schedule & trip data: show schedules, layovers, alerts, stats.
    • We treat schedule, trip, and crew list data as sensitive personal data due to the detailed time/location patterns it reveals.
  • Device & diagnostics (app version, crash/error logs): keep the app stable.
  • Support messages: answer your questions and improve the product.

We do not sell personal data and we do not share schedules with advertisers. See the full Privacy Policy for details.

Community airport & hotel info

  • What it is: Crews can submit tips about airports and layover hotels (amenities, nearby food, shuttle/van info, etc.).
  • Visibility:
    • “Global” items (e.g., amenities, nearby restaurants) are visible to crew users across airlines.
    • Airline-specific items (e.g., negotiated discounts, van pickup procedures) are scoped to that airline’s users only.
    • Friends & Family can see a crew’s scheduled hotel information if shared by the crew. They cannot search the hotel/airport database. Search access is limited to verified airline-linked accounts (ABAC; enforced in the API).
  • Privacy & rules: Do not include personal data, room numbers, access codes, or information a hotel/airline considers confidential. We may edit or remove submissions that violate policy.
  • Moderation & takedown: Items can be reported in-app or via support/security email; urgent removals are prioritized. We log who added/edited an item (internal user ID + timestamp).
  • Use & retention: Content is used only to power FCV features; not sold or shared with advertisers. Items remain until edited/removed; attribution is not shown publicly. If you delete your account, we de-link your identity from past contributions; items may remain if still useful to other crews. Backups age out per our backup policy.
  • Accuracy note: Community info is for convenience only; verify operational details (e.g., transport timing) with hotel/airline ops.

Quick answers (for crews)

Who can see my schedule? Only you in the app, and those friends and family that you grant access to. Limited support access may occur for troubleshooting, under strict controls.

Can other people see my schedule? Flight Crew View includes an optional Friends feature that lets you share parts of your schedule with specific people you choose. Sharing is opt-in, and you can:

  • Remove friends or temporarily pause sharing at any time (for example during medical leave).
  • Choose to hide certain details from friends, such as layover hotels, totals, and crew lists.
    FCV never gives your schedule to other users or third parties unless you explicitly share it via Friends or similar features.

How are passwords handled? For Microsoft (Entra) SSO, you sign in on Microsoft’s pages. For all others, we use Firebase Authentication. We never see your passwords and they are never sent to our servers.

Do you store my Flica password?
If you choose to fetch your schedule by logging into Flica in the app, your credentials are stored only on your device in the secure keystore and sent over TLS to the airline site. Credentials are never sent to FCV servers. For ICS or device-calendar sync, no credentials are stored by FCV.

What if I change airlines or close my account? You can export and then close your account; we remove personal data from active systems per the Privacy Policy.

How do I report a security issue? Email security@flightcrewview.com. See our Vulnerability Disclosure Policy (VDP) and security.txt

Technical details (for airline IT & vendor risk)

1) Authentication (SSO & MFA)

  • SSO (preferred): Microsoft Entra OIDC (tenant-specific) with PKCE; MFA via Conditional Access.
    • SSO today uses OIDC; SAML can be evaluated on request.
  • FCV app sign-in (non-SSO): We use Firebase Authentication for email/password, Apple, and Google sign-in. FCV servers never handle or store app passwords; hashing, storage, and verification are handled by Firebase.
    • TOTP is available for non-SSO users.
  • Flica credentials (for schedule fetch, not FCV login): If a user chooses to fetch their schedule by logging into Flica/portal inside the app, those credentials are stored only on the device in the OS secure keystore (iOS Keychain / Android Keystore) and used to connect directly to the website over TLS. They are never sent to or stored on FCV servers and can be removed at any time in Settings. (Details in §10.)

2) Authorization & Tenant Isolation

  • Every authenticated request is authorized by tenant ID (tid) + user ID (oid) (and airline code).
  • No cross-tenant data mixing; per-airline logical isolation in code and data access patterns.

3) Hosting & Architecture

  • Production hosted on DigitalOcean (compute/managed db) with Cloudflare in front (CDN/WAF/DDoS).
  • Managed database, no direct DB exposure to the public internet.
  • Bastion-less access, admin consoles gated behind Cloudflare Zero Trust.
  • Cloudflare fronts all public endpoints (CDN/WAF/DDoS). Server and cloud firewalls restrict inbound traffic to required ports only; SSH is limited to a single VPN egress IP.

4) Encryption

  • TLS 1.2+ for data in transit.
  • Encryption at rest for databases, object storage, and backups via our cloud providers.

5) Network Security (public)

  • Cloudflare provides CDN, WAF, geo restrictions, and DDoS mitigation in front of our services.
  • Server and cloud firewalls restrict inbound traffic to required ports only, and request-level rate limiting is implemented at key endpoints.

6) Access Control (Internal)

  • Administrative and support consoles are not publicly reachable; they sit behind Cloudflare Zero Trust with SSO and least-privilege access. Admin access requires MFA; privileged actions are logged and reviewed.
  • Access is audited; contractors operate under NDA and limited scopes.
  • We review all admin roles and production access at least quarterly, and immediately revoke access on role change or departure
  • As of December, 2025, production access is limited to 2 engineers and 1 support staff. Most support access is read-only and scoped to the minimum needed to troubleshoot a specific ticket.

7) Application Security

  • Separate dev vs. prod environments.
  • Automated dependency scanning and update PRs for PHP and mobile app dependencies via GitHub Dependabot; high/critical advisories are prioritized and resolved before release.
  • Secrets stored as environment secrets/managed config (no client hard-coding).
  • All client > API calls require authenticated sessions.

8) Logging & Monitoring

  • We monitor application and API health with structured logs plus Sentry and Firebase Crashlytics. Error reports contain only what we need to diagnose issues (e.g., stack trace, timestamp, app/server release, environment, and limited metadata). We scrub sensitive fields (passwords, tokens, cookies, airline credentials) before anything is sent, and we do not capture full request bodies.
  • Vendor tools (Sentry/Crashlytics) receive only the pseudonymous internal ID; neither vendor can identify a user from it. We correlate incidents on our side with server logs, Entra sign-in logs (SSO), or Firebase Auth logs (non-SSO).

9) Availability, Backups & Disaster Recovery

  • Backups
    • Backups are used only for disaster recovery, not analytics.
    • Production data is backed up daily, with at least 180 days of retention and longer-term monthly backups in line with our Privacy Policy.
    • Backups are encrypted and stored both with our primary cloud provider and off-site in AWS us-west-1.
    • We test full restores at least twice per year to a non-production environment.
    • On restore, previously processed deletion requests are re-applied as soon as practicable.
  • RTO / RPO
    • Recovery Time Objective (RTO):
      For a catastrophic failure of our primary cloud provider (e.g., complete loss of our DigitalOcean account), our goal is to restore core services (database and file storage) from off-site backups within 24 hours.
    • Recovery Point Objective (RPO):
      We take daily, encrypted backups of our production database and file storage. In a worst-case disaster, we may need to restore from the last daily backup, resulting in up to 24 hours of potential data loss.
    • These are planning objectives, not contractual SLAs.
  • High Availability & Redundancy
    • Our managed database uses replication and automatic failover to minimize downtime and data loss during common infrastructure failures (e.g., a single node/droplet failure). In these cases, our operational target is RTO under 30 minutes and RPO near zero.
    • The application runs on multiple stateless servers behind a load balancer. Each server can handle full production load, and replacement servers can be brought online from a hardened image in a short period of time.
    • This architecture is designed to keep the service available during typical infrastructure issues, while the RTO/RPO values above cover rare, provider-wide incidents.

10) Schedule Sources & Credential Handling

Preferred path: We are moving toward SSO/API, ICS import, and device-calendar sync as airlines modernize access.

How users bring schedules into FCV today (user-chosen):
• Airline portal login (Flica/portal): Some crews choose to sign in to their airline portal inside the app to fetch their schedule. In this flow, credentials are used on the device and stored only in the device’s secure keystore (iOS Keychain / Android Keystore). They are not stored on FCV servers and are sent only to the airline’s site over TLS. You can remove them at any time in Settings.
• ICS file import: Users export an .ics file from their airline system and import it into FCV. No credentials are stored by FCV.
• Device calendar sync (e.g., company app > device calendar > FCV): FCV reads events from the device calendar the user has already synced. No airline credentials are stored by FCV.

Respect for network controls: If access moves inside an intranet/VPN, we do not attempt to bypass those controls. We guide users to ICS import or device-calendar sync, and we prefer SSO/API where available.

11) Data Retention & Deletion

  • Operational logs: 180 days online, may be archived thereafter.
  • Account & flight logs: retained while the account is active; removed from active systems within 30 days of request or account deletion.

Backups may still contain historic data until they age out; see Privacy Policy for the full language.

12) Third-Party Services (Sub-processors)

12.A) Core infrastructure & security

DigitalOcean

  • Purpose: App hosting & managed DB
  • Data: Account profile, schedule data, app API traffic
  • Notes: Network & service logs processed to operate/secure infra. DB not publicly exposed.

Cloudflare

  • Purpose: CDN, WAF/DDoS, DNS
  • Data: Encrypted traffic metadata (IP, headers, request timing), no app secrets
  • Notes: Global edge; used for performance and attack protection.

AWS

  • Purpose: Encrypted backup storage (DR only)
  • Data: Encrypted backup archives + storage metadata
  • Notes: Backups are at-rest encrypted and transferred over TLS; not used for routine processing.

12.B) Identity & authentication

Firebase Authentication / Identity Platform (Google)

  • Purpose: User auth (email/password, Apple, Google) & token issuance
  • Data: Email (for email sign-in), display name (if provided), photo (if provided), Firebase UID, auth tokens
  • Notes: Passwords are hashed & stored by Firebase. We also support OIDC SSO (see below).

Customer-controlled IdP (not our sub-processor):
When an airline enables Microsoft Entra (Azure AD) OIDC, the airline is the IdP/controller. We receive ID tokens/claims to authenticate the user; we do not control the airline’s IdP.

12.C) Analytics & error monitoring

Traceability (no PII in vendors): we tag incidents with an internal user ID in our logs for correlation; vendor tools get only pseudonymous IDs.

Firebase Analytics

  • Purpose: In-app analytics (stability/usage)
  • Data: Pseudonymous device/app data (e.g., model, OS, app version, events)
  • Notes: Used to improve reliability/UX; not used for ads.

Google Analytics (website)

  • Purpose: Website analytics
  • Data: Page views, device/browser metadata, IP (by Google)
  • Notes: Site only; not for in-app ads/retargeting.

Firebase Crashlytics

  • Purpose: Mobile crash reporting
  • Data: Stack traces, app version/OS, pseudonymous internal user ID, limited tags
  • Notes: No passwords/tokens. We avoid PII and scrub sensitive fields.

Sentry

  • Purpose: Server/API error monitoring
  • Data: Stack traces, request metadata (method/path/status), timestamps, limited tags, internal user ID
  • Notes: Sensitive fields (passwords, tokens, cookies, airline creds) are scrubbed before send. Typical retention ~90 days.

12.D) Support & internal operations

Freshdesk

  • Purpose: Customer support desk
  • Data: Emails/support content you send us; ticket metadata
  • Notes: We limit PII and delete/redact when no longer needed.

ClickUp

  • Purpose: PM / issue tracking
  • Data: Task descriptions, attachments, ops notes
  • Notes: We avoid customer PII; if included for troubleshooting, it’s removed/redacted on close.

Slack

  • Purpose: Internal communications
  • Data: Internal messages/files/metadata
  • Notes: We avoid customer PII in chat; any temporary snippets are removed when not needed.

Google Workspace

  • Purpose: Company email & docs
  • Data: Email content/attachments you send us
  • Notes: Used for business comms (support, security).

12.E) Developer tooling (no customer data stored)

Github

  • Purpose: Source control & CI/CD
  • Data: Repo metadata, build logs
  • Notes: We do not store customer data in repos/issues/build logs. GitHub Dependabot and security alerts are used to monitor and update third-party dependencies (no customer data is involved).

12.F In-app messaging (Crew Chat) and notifications

Stream (getstream.io)

  • Purpose: Real-time chat backend
  • Data: Message content you send in Crew Chat; your display name and profile photo for in-app display
  • Notes: Acts as our processor to deliver chat. No advertising/tracking on our behalf.

Firebase Cloud Messaging (FCM)

  • Purpose: Push notification delivery
  • Data: Device push token, delivery metadata (e.g., timestamps), and limited notification/data payloads (e.g., title/body or IDs for chat/ops alerts)
  • Notes: Used to deliver app notifications only. No passwords/tokens. FCM stores undelivered messages briefly until delivered or TTL expiry.

12.G) Payments & app stores

Apple App Store

  • Purpose: In-app purchases/subscriptions
  • Data: Transaction metadata handled by Apple
  • Notes: We don’t see/store card numbers. See Apple privacy policy.

Google Play Store

  • Purpose: In-app purchases/subscriptions
  • Data: Transaction metadata handled by Google
  • Notes: We don’t see/store card numbers. See Google privacy policy.

12.H) External aviation & weather data (non-personal)

Server-to-server feeds that do not receive your personal data:

  • FlightAware (Firehose): real-time flight/airport data to enrich flight status. (Inbound only)
  • FAA (e.g., SWIM/SWIFT): ground delay programs, ground stops, EDCTs, ops notices.
  • NOAA: METAR/TAF weather observations/forecasts (public domain).
  • Vaisala Xweather: radar tiles/conditions/forecast. We proxy where feasible; if a tile is loaded directly from Xweather’s CDN, Xweather may see your IP/User-Agent solely to deliver that asset.

12.I) Notes on retention, regions, and transfers

  • Retention: Error telemetry is retained for a limited period (target ~180 days) and aged out. Backups follow our Backups & DR policy.
  • Regions: Our production deployment is currently US-based; some vendors operate globally (e.g., CDN edges).
  • EU/UK: We sign DPAs with sub-processors and rely on EU SCCs and the UK Addendum/IDTA where applicable.

12.J) Minimizing data in third-party tools

We configure vendors to avoid sensitive data:

  • Scrub passwords, tokens, cookies, and airline credentials from logs and error reports.
  • Use pseudonymous IDs (no real names/emails) in Crashlytics/Sentry.
  • Keep support/project tools free of customer data where possible; redact when used for troubleshooting.

13) Aviation & Weather Sources (informational use)

We display aviation and weather information from sources such as FAA SWIFT, FlightAware, NOAA, and Xweather to help crews stay informed. This content is informational only and not for operational decision-making; crews should verify with ATC and their airline’s dispatch/operations. See our Terms and Conditions for details.

14) Compliance & Transfers

  • We do not currently hold SOC 2/ISO certifications; we follow many aligned best practices and are maturing controls.
  • We can sign a DPA for enterprise onboarding.
  • For EU/UK users, we rely on SCCs or equivalent safeguards with vendors where applicable.
  • Independent security assessment / pentest available on request during enterprise onboarding.

15) Incident Response

  • We detect, triage, and remediate issues; we keep backups to restore service.
  • If a breach affects users, we notify impacted parties and, where required, regulators within applicable timelines.
  • We notify affected users via in-app and email; enterprise contacts receive an incident summary at their designated address.

16) Sensitive Events (Accident/Incident) Handling

When a serious aviation event is credibly reported, Flight Crew View activates a respectful, privacy-preserving response designed to reduce harm and misinformation.

  • What triggers action
    • We act only on credible reports (official airline/authority statements or well-substantiated news). A designated owner reviews and authorizes any changes.
  • What may temporarily change in the app
    • We use a tiered approach, narrowing scope as facts are confirmed:
      • Precautionary: Before the airline is publicly confirmed, temporarily hide all crew lists or friend schedules app-wide.
      • Airline-scoped: When the airline is confirmed, hide crew list and friend visibility for the affected airline.
      • Flight-scoped: When the flight number is confirmed, hide the crew list for the specific flight (and all inbound/outbound) and all friend schedules at that airline to avoid “confirmation by omission.”
      • Individual: After the crew is publicly released, restore all features system-wide, but remove the involved crew from crew lists on the remainder of their schedule.
    • We post brief, respectful notices in-app when appropriate.
    • These measures are temporary and do not delete friendships or user accounts; normal visibility is restored for non-affected users as official information is published.
    • Friend/Family access will be disabled depending on tier. The app checks in with the FCV backend to update the schedule each time a friend/family opens the app. The server will clear the schedule if that crew is included within the scope.
  • What we don’t do
    • We don’t confirm identities. Names are not disclosed by FCV.
    • We don’t act on rumor or speculation. We only make changes after credible, verifiable sources.
    • We don’t provide backdoor or real-time access to user data.
  • About timing & freshness:
    • Breaking events are chaotic. FCV isn’t an official source, and some views can be stale. There can be a delay between an event, official confirmation, and our awareness. As soon as we have credible confirmation, we apply our tiered restrictions and post an in-app notice reminding crews that app information may be incomplete and to avoid drawing conclusions or making public statements based on what they see in the app.

Audit & review

All actions are logged. We conduct a post-incident review to improve safeguards and data freshness.

If you have questions about this process, contact security@flightcrewview.com

17) Disclosures & law enforcement

We only disclose data under a valid legal basis (see our Privacy Policy “Requests from an employing airline / legal requests”). Overbroad or informal requests are declined. We do not provide bulk schedule exports or monitoring feeds to employers or employee groups/unions for generalized employee surveillance, monitoring, or union-related targeting.

18) Logbook API & Third-Party Logbook Tools

  • FCV offers a Logbook API that lets pilots connect third-party logbook apps to their own FCV account.
  • Access is logbook-only: it is for importing, normalizing, and exporting a pilot’s own flight history. It is not for flight planning, dispatch, weather/NOTAM briefings, or any other operational decision-making.
  • Third-party apps must use our OAuth-style flow (no password or passkey capture) and can only access flights for the FCV account that authorized them.
  • Pilots can revoke a logbook app’s access at any time from within FCV, which invalidates its tokens.
  • Commercial logbook partners must comply with our Logbook API Access Policy (security controls, branding/non-affiliation, pricing transparency, and operational-use prohibition). We may suspend or revoke access if they don’t comply.
  • See our Logbook API Access Policy (tap here) for details.

19) Schedule Sharing (“Friends”) Feature

  • The Friends feature is an optional, user-controlled sharing mechanism between individual FCV users.
    • A user must explicitly add a friend before any schedule information is shared. There is no automatic sharing with other users or airlines.
  • Users can:
    • Temporarily suspend sharing (e.g., during medical leave or other periods when they do not want their schedule visible), and
    • Configure sharing to exclude specific fields, such as layover hotels, totals, and crew lists.
  • Airline staff and third parties do not gain any additional access through Friends; it is solely peer-to-peer sharing between end users, governed by the user’s own choices.
  • These controls are enforced by the FCV backend; revoking or pausing sharing takes effect on the server, not just in the UI.
  • Using Flight Crew View to stalk, harass, or intimidate anyone is strictly prohibited and may result in account suspension and cooperation with appropriate authorities.

20) Vulnerability Disclosure (VDP)

21) For Airline IT: SSO Onboarding

  • Protocol: Microsoft Entra OIDC (tenant-specific).
  • You provide: tenantId, clientId (and secret if confidential client); allow redirect https://<your-prod-auth-domain>/__/auth/handler.
  • We configure: issuer https://login.microsoftonline.com/<tenantId>/v2.0, scopes openid profile email offline_access.
  • Claims: We request email (or preferred_username) plus basic profile claims. We can adapt to your tenant’s claim availability.
  • Conditional Access (BYOD ask): Require MFA for our enterprise app; do not require compliant device / approved client.
  • Test setup: 1–2 test users (non-admin), app assignment, and tenant-wide admin consent (if applicable).
  • Lead time: typically < 1 business day once IDs are provided.
  • Timeline for SSO enablement: ≤ 1 business day after we receive the above, ending with a browser/app smoke test (sign-in succeeds and maps to the right tenant in FCV).
  • Deliverable: Users can sign in to FCV with your Entra ID. No schedule data connection is implied by SSO alone.
  • Rollback: Remove app assignment or revoke consent at any time.

22) For Airline IT: Data / Schedule Ingestion Onboarding

SSO authenticates the user; schedule data requires one of the following (chosen with the airline/user):

  • ICS import (user-exported from Flica): 1-3 days once the format is confirmed.
  • Device calendar sync (e.g., airline app > device calendar > FCV): 2-4 weeks for QA and user guidance.
  • API / direct integration: typically 2–4 weeks (depends on API docs, environments, scopes, and test data).

23) Customer Responsibilities (BYOD)

  • End users: Keep OS/app updated; enable device lock; report lost devices promptly.
  • Airlines: Enforce MFA via Conditional Access for the FCV enterprise app.
  • If a device is lost, Log Out All Devices from Settings > Flight Crew View account; we also revoke push tokens on logout/reinstall.

24) Roadmap / In Progress

  • Fixed backup-retention cap and lifecycle rules.
  • Key-rotation cadence and change tracking.
  • Status page (public uptime/incidents) under consideration.
  • Origin allowlisting to Cloudflare IP ranges and Authenticated Origin Pulls (mTLS); automated IP sync against Cloudflare’s published lists.

23) Contacts

Change Log

2025-12-09: Added Security Program Overview and Security Governance & Access Management sections.

2025-11-26: Added information about VDP, “Friends” schedule sharing, FCV Logbook API, Accident/Incident Handling, and how we handle Community airport & hotel info.

2025-11-22: Initial public version

Copyright © 2014-2025 Flight Crew Apps, LLC. All rights reserved.