This is a boggling level of disdain for customer security - even putting aside the insanely low levels of data security, it's mind boggling that the website remained up for months after the disclosure, and that even after being taken down the vulnerability remained open.
This is a boggling level of disdain for customer security
To be fair, this usually doesn't start as a boggling level of disdain. It usually starts out as 100% ignorance. It's how the people and the group respond to the negative feedback from experts and from reality, which brings in the disdain, even spiraling to boggling levels.
There are two deep lessons herein, rooted in game theory.
This is an "I have no idea what the hell I'm doing" level of incompetence.
Isn't it accepted security knowledge, that about 99% of everybody is at a "should not be doing it myself" level of security/crypto incompetence? I'm not saying that the example isn't particularly bad. It is.
Requiring competence would appear to be the wrong way to do it, here.
Given that the password hasn't changed, I'd assume that there are exactly 0 sysadmins or software engineers working at this insurance company. A web app was poorly hacked together a few years ago, and just ticks-over in the background. Nobody in the org knows about the exploit (and it's possible they don't have the capacity to understand the exploit).
There's a serious problem with human beings. A very loud, emotionally charged warning used to work perfectly for us. "SABERTOOTH TIGER!" is obvious and it's useful for the warning to be delivered with such emotional force.
However, there's a problem when the severe danger is disguised by layers of abstraction and complexity and obscured by time. Even emotionally neutral warnings will trigger our psychological attack defenses in these cases.
Note, I'm not saying op did anything wrong. What I am saying, is that delivering negative feedback about anything complex is itself a complex operation!
A security membrane which needs this kind of feedback to work correctly should be viewed as having a serious design flaw.
In case you ever decide to return to AWS, its Cost Explorer is far from perfect but it can show you where your expenses are coming from, especially if your costs are pennies. In the last re:invent they even released daily granularity when grouping by resources (https://aws.amazon.com/blogs/aws-cloud-financial-management/...).
Thanks for the feedback! I don't think it's nitpicking, you're right that it's misleadingly phrased - in fact, the only S3 costs I observed weren't storage at all, but rather the API calls.
I'm not sure how this could be removed - the fundamentals behind it are basic building blocks of S3.
Maybe raising the cost of transient storage? e.g. If you have to pay for a minimum of a day's storage - but even if that was the case this would still be cost-effective, and at any rate it seems very unnatural for AWS to charge on such granularity.
+ I would guess that S3 is orders of magnitude more profitable for AWS than cross-AZ charges, so I'm not sure they'd consider it a loss-leader.
It would be fairly easy to change the pricing policy. GCP did something similar for cross-region https://cloud.google.com/storage/pricing-announce#network. This is pretty severe because it seems to affect all reads. However I can imagine an alternate implementation where the source AZ is tracked when data is written and egress fees are charged when the data is read (as if the data was always stored in the source AZ). This could even be done more complexly such as only charging the first time data is read in another AZ. Once you read once it is free as-if it is now cached in that new AZ forever. Another option would just be raising the minimum storage duration so that it basically costs all or most of what the data transfer would.
It would definitely piss a lot of people off as it is adding to their bill, but it could likely be done in a way that makes exploiting this for just data transfer not worth it without adding huge costs to most "real" use cases.
Yeah, I see what you mean - that'd indeed render this method ineffective. Like you said I'm sure this would bother a lot of customers, but it's not a completely unrealistic overhaul of S3 pricing.
That being said, that'd be sort of "mean" of AWS to do - the data is already replicated across AZs whether you pay for it or not because of how S3 works.
But in the context of data transfer costs, this would actually increase the costs, because there's a small surcharge for Intelligent Tiering - and the only relevant storage class for sidestepping data transfer costs is standard storage (because it's the only one with free download), so Intelligent Tiering won't provide value.
I understand the sentiment behind your frustration - but it's worth noting that these support tickets are usually answered really quickly.
Specifically as it relates to Lambdas there's solid rationale behind these limits, but I agree that in many other cases the limits seem arbitrary and annoying.
As another comment explains - the vast majority of drivers are not compiled as part of a standard Linux distribution.
If you're asking why so many drivers are included in Linux's mainline repository and not maintained off-tree - the major advantage of being upstreamed is that changes to the kernel have to take your driver into account as well. e.g. anyone who changes any APIs will have to update your driver as well.
Moreover, being upstreamed certifies that your driver has gone through a non-trivial review process to be merged into the mainline and is an indication of quality/stability.
Great post!