Live data from Hacker News

In S3 simplicity is table stakes

allthingsdistributed.com

141–142 of 142 posts

Re: In S3 simplicity is table stakes

#141
post #124

Earlier quoted context omitted.

Not sure what you’re getting at. An S3 bucket out-of-the-box is secure and can’t leak/be accessed publicly. There’s legitimate use cases for making a bucket public. What are you advocating for?

A good security model doesn't let stupid people do stupid things with warnings. Stupid people ignore warnings. A good model protects stupid people from themselves. A password model that says "you MUST have a strong password" protects stupid people from their own stupidity. A model that says you can use bad passwords if you click through warnings is a shite model. Stupid people ignore warnings. Seriously.

So a good operating system doesn't let you install apps except from the app store?

Re: In S3 simplicity is table stakes

#142

Earlier quoted context omitted.

Object integrity isn’t part of the S3 SLA. I assume that is mostly because object integrity is something AWS can’t know about per se. You could unknowingly upload a corrupted file, for example. By the time you discover that, there may not be a clear record of operations on that object. (Yes, you can record S3 data plane events but that’s not the point.) Only the customer would know if their data is intact, and only t…

S3 supports checksumming, you just need to provide a hash in a header when you upload an object.

Yes but my point stands. If AWS added S3 data integrity to the SLA then it’s now made that commitment contractually. If you add checksum data the checksums would (logically) be required and also be in scope of the SLA. If there was a mismatch between them and the file functioned it would be impossible to sanely adjudicate who is responsible for the discrepancy, or what the nature of that discrepancy might be if no other copies of the file exist.

AWS probably doesn’t want those risks and ambiguities.

Post reply on HN