FlightAware Leaks Customer Data (Name, Email Addresses and Passwords)

Original Article ↗ Hacker News Discussion ↗

Breach scope and technical details

  • Notification emails state that passwords and extensive profile data were exposed, including addresses, phone numbers, IPs, last 4 of credit cards, aircraft ownership, pilot status, and activity history.
  • One former employee says passwords were stored salted and hashed in the database, but the wording of the email (“passwords” without “hashed”) plus mention of credit card digits raises concern that more than just the user table may have been exposed.
  • Some speculate about possible issues with Apache/Rivet/Tcl and logging or variable leakage, but this remains unclear.
  • Several commenters interpret the description as effectively a full account database dump.

Company response and communication

  • Many users only learned of the breach via forced password-reset prompts on login; email notifications are arriving in a slow “drip” over days or weeks.
  • No prominent notice on the main website or blog is reported; information appears mainly in email and a Discourse thread.
  • The three-week delay in user notification is heavily criticized, especially in light of GDPR expectations.
  • Wording around law-enforcement involvement is called ambiguous.

User impact and reactions

  • Some users with ADS‑B receivers feel betrayed because the service was a hobby, not a “big tech” platform, yet now resembles the same data-hoarding pattern.
  • Several report not having received email despite seeing password-reset prompts.
  • A few used throwaway credentials and feel relatively unconcerned; others plan to stop using FlightAware or piaware.

Regulation, liability, and incentives

  • Strong calls for harsher penalties: substantial per-account fines, GDPR-style enforcement, and even criminal liability for severe negligence.
  • Counterpoints note difficulty proving individual harm and causality, and warn that automatic jail time could deter people from building services at all.
  • Discussion compares treatment of financial data (credit cards, with strong industry rules) vs. weak protection of general personal data.

Account hygiene and email practices

  • Many advocate using unique email aliases per service (own domain, plus-addressing, catch-all), both for attribution and damage containment.
  • Others note practical issues: some sites reject “+” addresses, or backend systems mishandle them.
  • There is debate over how much plus-addressing actually helps when attackers or companies can strip tags.
  • Some recommend fake names and birthdates for non-critical services, recorded in password managers; others find this cumbersome or historically didn’t have managers.

FlightAware technology stack and ownership context

  • Commenters reference a recent blog on migrating away from a long-lived Tcl/Rivet stack dating back to ~2005, suggesting legacy complexity and “footguns.”
  • Ownership under a large aerospace/defense conglomerate is discussed; some argue such parents often pay little attention to consumer-facing subsidiaries or public crisis communication.

iOS app support controversy

  • Separate but related frustration: the iOS app dropped support for iOS 15 with a full-screen block rather than simply ceasing updates.
  • Some see this as uniquely user-hostile; others argue that supporting very old OS/device combinations and legacy web views does carry real cost and that iOS users mostly stay on recent versions anyway.

Working at a breached company

  • One perspective: joining post-breach can mean improved focus on security, pentesting, and tech debt.
  • Another: breaches are stressful for staff, can expose internal HR data, and may make the workplace less pleasant long-term.