Title is incomplete/almost misleading: much more data than name, email, passwords is leaked:
Depending on the information you provided, the information may also have included your full name, billing address, shipping address, IP address, social media accounts, telephone numbers, year of birth, last four digits of your credit card number, information about aircraft owned, industry, title, pilot status (yes/no), and your account activity (such as flights viewed and comments posted).
Sounded to me like most/everything associated with the profile is affected. Fortunately I didn’t use my account for anything that I can remember, and it used throwaway email and password.
FlightAware’s iOS app also just stopped supporting iOS 15 and, instead of just letting the old app continue to work, they did it with a full-screen modal telling iOS 15 users to fuck off and buy a new phone, preventing us from using the app that worked last week. Every other app on my phone gracefully continues to work on my old device except this one. This is absolutely bonkers and not the way any legitimate app does backwards compatibility. The developers over there are pretty clearly clowns that don’t know what they are doing.
Or they are shocked. Most companies I’ve been at, iOS version support is N-1. After that, we wouldn’t lock you out unless there was technical reason but no testing or support was done.
iOS ecosystem has always been like this since Apple supports phones for a long time.
Yea, I have no problem with them no longer issuing updates supporting iOS 15. It’s an old OS on an old device, and I get it: devs gotta move on. But don’t deliberately cause existing apps to stop working. No other app on my device behaves this way, and this is almost unheard of in the iOS ecosystem. This is where they went overboard. I looked and I’m surprised I couldn’t find an AppStore guideline prohibiting this.
My guess is technical reason drove decision not “Lolz, no more iOS 15”. Looking at our telemetry data, less then 1% of devices that run our B2B app are iOS 15 or older. If we ran into iOS 15 issue, we would lock them out as well.
It amazes me the money that brick and mortar businesses would spend to increase customers by a tenth of a percent, yet online businesses have no problem simply deciding that 1% of their clients are disposable. They would rather develop some new shiny feature that won't bring any new clients, than continue supporting a device that was sold new three years ago.
To be fair, you’re using a 8-year old device that has been unsupported by Apple for 2. I’m sure some websites already aren’t working for you and I’d expect a “web service” app wrapper to have similar limitations. To support your device, they probably would have to keep a legacy version of their web apps around, so it does not come free.
For a free app, supporting a device for 7 years is already a long time. With iOS 18 around the corner, it makes every day more sense to cut you off.
Don't look at it as "not supporting an 8-year-old device" which can't get the update; look at it through the lens of "not supporting an OS which had its initial release just under 3 years ago and is still receiving support itself."
There are plenty of reasons (of varying reasonableness) to avoid an update; people on an OS version this new shouldn't be getting this kind of harsh treatment.
If you have app features that rely on a new iOS feature, you could just put those behind a feature flag.
If your core API changes substantially over time meaning that out-of-date versions of your app quickly stop working without updates, it's better for the user if you use something like Swagger to auto-generate the API stubs; it makes it much easier to support your app in the long term, even for users on what would otherwise be unsupported platforms.
If you're dropping support because supporting an older OS creates irreparable security issues, well, I guess in this case they might actually be ok with that.
iOS ecosystem generally doesn't work like that. Most people upgrade to latest when latest.1 comes out so around December. Those on latest - 1 will remain until they become latest - 2 next September and by then, they will very likely upgrade to latest because they buy a new phone. See this blog article by Telmetry Deck about iOS 17 adoption: https://telemetrydeck.com/blog/ios-market-share-13-23/
Since Apple controls phone updates and phone support is long, unlike Android, most companies only do latest - 1 except around September when they will do latest - 2. However, most don't cut people off, you are just unsupported land and they will if older iOS versions give them any trouble.
There is nothing fair about this since the OS/device would continue to work just fine, and for many more years, unless the user hostile decision to block was made
Apps stop issuing updates for my old device all the time. I understand why and I live with it. What they don’t do is remotely disable their apps, forcing me to stop using them. That’s totally unacceptable, even for a free app. Especially for a free app! They spent developer effort to deliberately do it.
I don’t think you understand what it takes to support “unsupported devices”. I already explained that it does take effort, so without that screen you’d have a broken app.
Also stop complaining, it’s a free app, get a new phone already.
It takes zero effort to keep an existing app running that's already installed on a user's old phone. You simply do nothing! Don't issue updates or go out of your way to remotely disable users, and instead focus on shiny new phones. If the app hits a server API, you just make sure that API version doesn't get touched (you are versioning your APIs right?). It's not rocket science.
Sorry, everyone has one HN soapbox, and you happen to have run into mine. Software developers need to stop being so hostile to users with devices they deem "old and icky". This includes OS vendors, too by the way, I'm not leaving them out. Supporting only N-1 is a user-hostile policy, and it's driven primarily out of developer laziness rather than business need. Remotely disabling any version is absolutely appalling, and I hope that practice doesn't catch on.
I got news for you, they invented something called websites and all they do is remotely disable what appears in your browser. Next thing you know, they place them in webviews and show "Your browser is not supported because it's running on a 8-year-old device."
I don't know how else to tell you that they did not break something that works, but simply stopped serving an old web view because supporting it DOES NOT come for free. Do you still ship IE6 views for the lone monthly viewer too?
I can confirm the veracity of the email. I got it myself. Note that they say they leaked passwords. They didn't mention whether they were hashed or not, and if so whether with salt or not. I couldn't find a blog post either. The notification email took more than 3 weeks, not impressed.
As someone who used to work there, the passwords were definitely stored salted and hashed in the database.
The email mostly makes it sound like what’s in the user account table, though last 4 of credit card I didn’t think was in it. And mentioning passwords, not salted/hashed passwords, makes me think it was more.
I’m wondering if this is an Apache or Apache Rivet issue that possibly intercepted everything you sent to the server, which could then be your actual password if you logged in during the timeframe or even credit card if you bought something.
Also Rivet was full of footguns. IIRC, variables would exist for the life of the Apache child, so you had to clear them out or the next request had access to them, so if someone deleted or didn’t run the huge “delete all variables we probably set” proc, and someone was able to get an “info var” output, they’d see everything set in the previous request or further back if nothing overrode it. Like user info, which was just stored in a big global “user” array
I don't think there's anything about tcl that is inherently insecure, but it indicates that the code might be quite old and from a time where many vulnerabilities and ways to avoid them were not well understood.
Tcl and Rivet to me says the code is from the 1990s or 2000s. Does FlightAware go back that far? Otherwise I am surprised at those choices for anything newer.
2005. There was still code and pages dating back to then running and being used. But over the years, more and more was built on top of it rather than a different stack.
Frontend code would vary with whatever flavor a developer liked at the time, but the backend was still always going through Rivet/TCL.
ICs would complain about it but the founders cashed out to the tune of 9 figures in the end, so it worked out for them.
I’ll agree that TCL isn’t inherently insecure, but you aren’t getting any libraries or frameworks with it either to make your life easier or safer.
The website still looks like the TCL monster it has always been, so I doubt it. But I have no intimate knowledge of the inner workings there soon after the Raytheon buyout.
Oh it is owned by Raytheon a huge listed company. That makes it more surprising that the communication is so bad. I'd expect a public company with market cap of $150b to have its act together regarding crisis communication.
It's part of Collins Aerospace which was bought by United Technologies which merged with Raytheon. Having been part of a merger with RTX, generally your IT systems change and that's about it. Most of management stays and as long as your group is hitting numbers, no one from RTX gives a shit what's going on. My guess if you called up RTX CEO and asked him for a comment about FlightAware, he's not aware he evens owns the site.
Also, Raytheon doesn't ever talk to the public. Most of the work is classified so yea, crisis communication involving the general public, internally, they are clueless.
It's terrible for end users, bit to be fair here a domain that sends little mail suddenly sending a lot looks like spam. Ciscos sender base for example graphs long term volume per domain as a key indicator, and their data feeds into several mail services. You're much more likely to at least get the email this way.
I can't confirm that's the reason, but I don't see why they would drip send it otherwise. Also the reply-to email is bounces+MYEMAILADDRESS@bounces.flightaware.com (@ replaced by =)
8 months ago, Flight aware wrote a blog post about moving their entire tech stack from TCL. The post is called "Managing a Technical Transformation (Part 1)". I couldn't find Part 2.
Nowhere in the article says 'hashed' passwords, so I presume plaintext (!!!) passwords were leaked.
That's 100x worse than all the other data combined for two reasons: it can be devastating for users, and it's easily preventable (by not storing them in plaintext in the first place).
Specifically, they say that if (they think) you’re breaking a rule. When you get to a phase of flight that you have the bandwidth to do so, they’ll give you a phone number to call after you’ve landed. From there you might just get chewed out by a grumpy controller, or they might set the gears in motion for some sort of formal discipline.
ATC here. It's not always because someone is grumpy or for formal discipline.
I only gave a Brasher Warning one time, only because my trainer told me to. I suppose it depends on the culture/facility, but where I learned it, they had more of the attitude that it was to have an informal conversation to find out what happened and what the pilot and/or controller can do differently next time.
After my supervisor talked with the pilot and listened to the tapes, we discovered that my control instruction was ambiguous and that I should be more clear next time (and the pilot should follow the minimum altitudes on the approach plate).
I landed at a class C (KAVL) without switching to tower from approach. I don't think they were training controllers that day but the same two controllers were on both freqs... rolled off and sent my call "off at echo" and got a nice "traffic calling approach say again".
Didn't get the dreaded number to call on the air since they knew the school... filed a NASA report and nothing else came of it. mistakes happen.
Related, on a check ride with the chief instructor while a controller was training he absolutely chewed the controller out on the air for giving me an immediate turn instruction at ~350' AGL. I don't think that was called for and it made me feel horrible and made the rest of the flight awkward. But from that day on I was much more comfortable with a simple "unable" when I got weird requests.
A good point indeed! There are certainly grumpy controllers and a time for discipline, but there is a strong culture around continuous improvement and safety throughout aviation. A phone number from a controller is not nearly as adversarial as, say, getting pulled over by highway patrol, even though in a lot of ways the two events are analogous.
> After my supervisor talked with the pilot and listened to the tapes, we discovered that my control instruction was ambiguous and that I should be more clear next time
This sounds like a slightly painful process, but I bet it saves a lot of lives. Amazing.
And the reason they have to say it nowadays is due to a court case where a pilot found out he was being investigated for a deviation that allegedly happened many months ago. It was ruled that without a timely warning no sanctions can be taken. So it’s a little bit like the “Miranda rights” of aviation - at least you know you might be in trouble and have time to prepare.
I have the FlightAware free account, but on occasion I’ve bought the Ad removal IAP, via Apple. What personal/billing information beyond my email address do they actually have from me?
The author of the article seems to be confused about the GDPR notification requirements. In the event of a personal data breach, the controller is required to notify the supervisory authority without undue delay, and where feasible, no later than 72 hours after becoming aware of the breach—not the users themselves. However, when it comes to informing end users, the GDPR requires that they be notified without undue delay if the breach is likely to result in a high risk to their rights and freedoms. It’s mind-boggling that FlightAware took three weeks to inform users, which raises concerns about their handling of the situation. It’s also suspicious that they haven’t clarified whether they are aware if the exposed data was actually copied by bad actors—one should assume it was.
Yes, i don’t understand why anyone would ever enter real personal details into any website unless it was absolutely required for correct functionality of the website. Is it older people having a more overall general trust of institutions? or is it all ages that do this?
The problem is if you forget the fake details you can't recover the account. I was born around 1900 for my old yahoo groups email, but I forgot when exactly and so I got emails for a group I no longer cared about until (not sure what died, yahoo groups or the list)
I didn't hear of a password manager for another decade. Even if I had I'm now depending on it evisting (as opposed to lost in a disc crash or something)
If I think the fake details will be used for account recovery, and I actually care about the account, I store them in my password manager. (custom fields or notes in Bitearden).
Why not? It’s honestly a pain entering fake data and then realizing it won’t work on the next page. Easier to let the browser autofill it.
I junk-fill some signup forms and use Hide my Email for others, but it’s never less work than just using real data (well, with few exceptions like WiFi registration pages that I encountered before and don’t require data validation)
>Is it older people having a more overall general trust of institutions? or is it all ages that do this?
If I had to guess, probably a combination of baby boomers (really old people) and Gen XZers (really young people).
Those of us who grew up with the internet (me, millenials) got drilled in to never ever fucking never share our real name or street address. That 18/F/CA in the chatroom? That's a middle age GIRL (Guy In Real Life).
It's a bit disappointing how there's a total blackout from the company. Nothing on their website/blog/social media. Even the notification emails are arriving stagged over a period of 3 or more days.
As someone who worked in a company during breaches, I'd say if the company is willing to not getting another breach it's a unique learning experience. You'll see company standards stricten, more pentests and perhaps at least for 6 months more emphasis put on product security than time to market. A good time to also suggest tech debt to be fixed related to security.
It's never fun learning that your HR records are among the data being sold on the dark web. Depending on your business you might also have a target on your back afterwards - we had to implement "no company branded t-shirt" rules when leaving the office after an employee got accosted by an irritate customer. We also lost the relaxed policy we had on visitors.
Yes, perhaps you'll learn something. But you won't want to stick around there long afterwards.
I have an ADS-B receiver. It's a hobby. I didn't get any notification yet.
Looks like I let my guard down with Flightware. Again, it's a hobby -- supposed to be a joy. I wrote some code to use TTS to play the departure, aircraft, and flight info so I can sit on my deck and enjoy as flights passed by.
Flightware has my exact location. Of course, so does Google via my phone. But this isn't supposed to be Google. It's a hobby.
And now my hobby is part of the sh*t world of Google and every other data hoarding sociopath enterprise.
I'll stop using piaware.
EDIT:
Logged in to Flightaware.com and got this:
Reset Your Password
Due to a data security incident that potentially involves your personal information and out of an abundance of caution, we are requiring you to reset your password. Additional information was sent to you via email. Please enter your FlightAware username or e-mail address below to reset your password:
Until there are significant financial damages associated with each of these breaches, companies just won't invest enough to secure the information. These sorts of breaches should be existential to the company- they should never happen. And yet because the penalties are almost nothing, companies just are not incentivized to secure the data appropriately.
If a breach meant the firing of the CEO and the CTO and the board, then you'd know that companies would spend a lot more on security and privacy.
I’m completely sympathetic to that view. However, until such data breaches regularly lead to severe outcomes for subjects whose data was leaked, and those outcomes can be causally linked to the breaches in an indisputable manner, I’m afraid that we won’t see any such penalties.
>However, until such data breaches regularly lead to severe outcomes for subjects whose data was leaked, and those outcomes can be causally linked to the breaches in an indisputable manner
Which means nothing gets done because it's pretty hard to prove where any one misusing your information got it from. My identity was stolen after breach but when I took it up with entity that lost my information, they were like "Prove it" which of course I couldn't because people who did it to me were never caught.
I own my email domain, and I register for each service with a different address. For example, flightaware-20240817@mydomain.net. This way, I know where my email addresses leak from.
With some email services including Gmail and Protonmail you can add +whatever to your username part of the email address to get the same result. My name+flightaware@gmail.com for example…
And many mail hosting services let you assign a catch-all, which allows you to simply use anything@mydomain.com to get the same result.
Because they assume you've set name+spam@gmail.com to be filtered directly to spam, and they can easily evade those filters by removing the ±spam part.
Big companies do this. I have signed up for things using a +filter email address, only to receive the emails from that company that is signed up to get at my plane address, without the +filter part.
Even if you can enter it, various backends in the same company might not handle it correctly and you enter up with an half-working account that their customer support (if they even have that...) cannot solve. Been there, tried that...
Personally I have - as the separator (not on gmail or similar). If you have to give you email on the phone it can cause lengthy discussions why their company name appears in my email address..
Don't know. Last time I experienced problems was when entering a family members gmail address with a plus sign to share my newspaper subscription. They could not use it and I could not remove it... That was about 5 years ago. Have been burned too often, don't try it anymore.
what's important in "anything", if you can, is name, company, and some pseudorandom chars. Because company@example.com or name+company@example.com is easy enough to guess, but pseudorand_name_company_kroj38@example.com isn't plausibly going to get guessed at.
I do the same but some service provider forbid you to put the name of the company in the mail. That's among those stupid security rules (one of the most stupid is MS Xbox service preventing you to have letter from your email in your password. So if you are using a@xxxxx.com and your password generator use a, it will get rejected….
They didn't spam me, they tried to sign up with a bunch of credit services. Yes, X lost my data, it's getting proof that X data loss where was scammers acquired my data from.
I was merely pointing out the reality of the situation. Significant penalties generally only come about as a result of prominent cases of substantial harm being inflicted in a way where the causality is not in doubt. People like us here holding companies to higher standards by itself doesn't have that effect. I'm not saying that we shouldn't hold them to higher standards — I certainly do — just that realistically much more will have to happen.
It's similar with climate change. It's just a fact of the matter that people at scale only react as actual consequences become palpable.
I'm not saying your observation is inaccurate, but as a society we _let_ these companies continue to do whatever they want without consequence.
1% of users in a data leak having their identities stolen or 1% of the cities in the world becoming uninhabitable due to heat isn't enough to demand action, what about 10%? Is 25% where we draw the line?
> justify inaction with their impact on climate change.
but this is the correct justification. If the customer is the one buying these products that cause climate impact, why is it the sole responsibility of the company to pay the cost of rectification?
In such situations, where externality is problematic, it is up to the gov't to push regulations to prevent it. A carbon capture tax, for example, is one such way.
> Why don't we hold them to a higher standard?
why should companies be held to a higher standard than a person?
Is almost like publicly accessible information like email, phone, address, and, honestly, ss# at this point shouldn't be used for anything serious that doesn't require some sort of authentication beyond itself.
Credential stuffing isn't the only threat. Leaked emails and phone numbers become spam and phishing targets and phishing can get a lot more convincing when they also have your home address and other details.
With GDPR, simply leaking personal data is enough to earn you penalties. If your security is insufficient that someone can take this much personal data (and based on some of the other comments here it was a lot of personal data), then you have not upheld your responsibility according to GDPR.
So I disagree, we don't need to wait until the data breaches lead to any particular outcomes, we need laws that make it clear that data breaches alone constitute damages to the people whose data was released. More people should be protected by GDPR-style laws, and more companies need to recognise that data security is something they need to take deeply seriously.
That's not how it works. I think you are mixing up damages to be awarded by courts to an individual data subject (right to compensation, Article 82) with penalties (Article 83-84) - the latter having a special meaning, in practice covering the administrative fines by authorities (DPAs).
There was a case by the ECJ (C 300/21) saying that for damages to be awarded to the individual, they have to prove the material or non-material damages involved.
Regardless, any data protection authority can and do fine companies for breaches such as this one and also for late filing, and while DPAs also have to take into account the damages caused to data subjects when deciding the amount of fine, that's not a standard that has to be proven for each data subject separately and is therefore not as strict as the right to compensation. FlightAware definitely should be fined... Like Booking, NTT or Twitter or banks for breach obligations, for more than €400k. But it's still strange that very few US companies were fined so far in relation to no or late breach notifications - not that they were not fined heavily for failure to comply with other obligations. https://www.enforcementtracker.com/
IANAL. Damages are relevant in-so-far as a relevant law addresses or requires them. Nothing stops a law from assuming damages under some circumstances.
My private details leaking is damage, that's the point here. If I trust you with my confidential details (which can be anything from my bank details to my email address), and your data security protocols mean that my data gets stolen, then I have suffered damages, and GDPR comes into play.
GDPR enforcement is severely lacking, even in "business as usual" matters like nonconsensual data collection/processing, let alone data breach handling.
GDPR has been with us since 2018, and it if was the deterrent that everyone claimed it to be, we wouldn't be having this discussion today.
If breaches were automatic jail time, no one in their right mind would want these jobs. One same reaction would be to stop collecting personal data, but a lot of Internet businesses would have a hard time adjusting to that.
A more practical policy proposal would criminalize extreme negligence while focusing on financial penalties for lesser beaches. Possibly the young missing vs current policies is that the duty to protect user data should probably increase with the amount of data collected - the juicier target you make your company, the more the penalty needs to hurt. This could mean companies taking a hard look e.g. at whether they really need your address and phone number because every extra bit of hacked information should cost them more.
> a lot of Internet businesses would have a hard time adjusting to that.
Why? The majority of situations where you need an account can be replaced with pseudonymous info.
Netflix needs an account and some payment data (which can itself be a pseudonymous card number with no identifying info attached), but it doesn't need to know my name or anything else.
I can see that the whole advertising/data broker/"growth & engagement" crowd would end up begging on the streets, but I'm not sure many actually valuable businesses would be affected all that much.
Imagine if software engineers had to have a license, and they stood to lose their license in cases of malpractice.
When your license is your bread & butter and you cannot work without it, losing it is devastating—and much more devastating than losing a particular position at some company (so even if you are required to implement an insecure solution, you would have no problems telling respective manager to shove it, respectfully).
Surely a mealy-mouthed email without a formal apology or admission of culpability will be the order the day - perhaps with a $2 Amazon voucher for those willing to click a box and agree to not sue for damages or engage in public disparagement.
What I find surprising more that the usual lack of accountability in these cases is how little its impact tends to be felt on Wall Street. A slight dip in the share price maybe for a week or so, but then it's back to business as usual.
I do think it would incentivize new security products/libraries/services focused on helping companies fulfill their security requirements instead of rolling their own crappy solutions.
If a startup cannot secure their customer’s data effectively, I don’t want their product to exist. If that means fewer startups get products off the ground, I fail to see that as a bad thing if a lack of security was the reason.
Slowing the industry down after a decade of breach after breach after breach seems like a reasonable and possible necessary intervention.
Good model is credit card numbers because they really cannot leak and if they leak, people are prosecuted.
Thus there is basically nobody doing credit card processing and the companies that DO that are unreasonably big and basically a monopoly. (Everyone always complains about PayPal...)
My side projects will never leak passwords. How is that not security 101? You do not need to "invest" in this, every single engineer needs to have this level of working knowledge. Not having this in place should absolutely mean not being allowed to run a business online.
What if someone gets into your app logic and make a POST trigger that gets the passwords out.
What if you log all POST requests for debugging purposes and forget to sanitize the logs.
What if you have XSS in your web app that sends the password to a third party.
What if your mobile phone app has a dependency that includes a keylogger.
The likelihood of this increases the more layers you have in your organization (for example, the log pipeline team assumes the logs are already sanitized; the login form team assumes the log team is sanitizing them; it all goes through some A/B testing team that just dumps all data to "data lake" somewhere unsafe; the FE team puts in random node.js dependencies as it's "just a frontend"; etc).
Passwords can leak from more places than just from the DB...
Getting into the app's running process is an effective way to exfiltrate everything, and likely they'd have a lot more to worry about there. I don't however think that piggybacking on a live app does not give you the size of these leaks. I mean, does every user of a service access the service in these periods?
More likely they steal the app's credentials (db, cloud provider, etc) and then go to town on data at rest.
You're right on logs and things like fullstory, but no one on any team should assume things are sanitized. You do your job independently. If you're an infra, devops, sre, does it make sense to say I thought they had it handled? Was that what you marketed on your resume?
Not saying there aren't complexities involved, but in many of these cases I see a lot of low hanging fruit, likely due to moving too quickly. We really need to own up to the fact that we've grown too comfortable with not giving any thought to other people's data. Why is it that there are the PCI audits when you handle card data, but not when you handle PII? Because card fraud hits the banks and they don't want to pay for any of that. So an entire industry was spawned, it's not perfect, but it helps a lot. You do not see a lot of credit card leaks.
How can you be so sure? Never is a strong word unless you never use passwords in your side projects. And this here wasn't a side project. It's easier if only one person controls a code base than with complexity.
I'm starting to think there should be some statutory minimum like 10€ per account that will be automatic minimum fine. Then depending on type of information it scales up from there.
