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.

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.

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) 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.

18. 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.

18) Vulnerability Disclosure (VDP)

• See our Vulnerability Disclosure Policy (VDP) and security.txt
• Report potential issues to security@flightcrewview.com.
• Good-faith testing safe harbor, coordinated disclosure, no bounty at this time.

19) 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.

20) 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).

21) 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.

22) Roadmap / In Progress

• Fixed backup-retention cap and lifecycle rules.
• Documented RPO/RTO.
• 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

• Support: support@flightcrewview.com
  • faq: help.flightcrewview.com
• Security: security@flightcrewview.com
  • (VDP & security.txt)
• DPA / Enterprise: contact support or security to request our brief.

Change Log

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