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

iOS ecosystem has always been like this since Apple supports phones for a long time.

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.

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.

Also stop complaining, it’s a free app, get a new phone already.

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.

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

The blog mentions recently moving away from TCL. Could it have been related to that?

Do you have an idea why the emails arrive as a drip, spread over days?

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.

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.

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.

They seem to use some email delivery service that can't handle sending an email to all users within an hour.

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

EDIT: Someone suggests stored passwords were hashed [1]. Hope they're right.

[1] https://news.ycombinator.com/item?id=41278855

> Please note that this notification was not delayed as a result of a law enforcement investigation.

Was there a law enforcement investigation or wasn't there? The sentence can either mean:

a) A law enforcement investigation happened, but it didn't delay the notification

b) It may or may not have been delayed, but a law enforcement investigation played no causal role in a delay - whether it had happened or not

c) A law enforcement investigation happened, and it delayed the notification, but not in the legal sense of a "late notification"

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

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.

This sounds like a slightly painful process, but I bet it saves a lot of lives. Amazing.

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)

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

Yes, perhaps you'll learn something. But you won't want to stick around there long afterwards.

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.

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.

And many mail hosting services let you assign a catch-all, which allows you to simply use [email protected] to get the same result.

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

Okay. So now you, individually, may be able to attribute some sort of responsibility in some sort of civil action.

Penalties that companies care about aren’t going to be built around some very non-standard individual’s ability to maybe, sometimes, attribute blame.

Plus, the real damaging stuff wont have anything to do with your email addresses.

Who decides what a "severe" outcome is? The companies themselves? Why don't we hold them to a higher standard?

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.

That's what imposing a 'severe' outcome would mean. You're using circular logic to be against a statement of facts.

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?

It isn't - it's the company's responsibility to pass the cost to the customer.

a) everyone is impacted by climate change, not just the customers who gave their data

b) climate change has very real consequences for people

Weird.

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.

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.

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.

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.

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.

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

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