[cloudhead]

As they pointed out, this requires me to trust Amazon. But since that's the case, what's the point of it being auditable? Amazon can easily drop the last N transactions on your ledger and tell you the digest you provided was "not found".

[cheeze]

Amazon could leak your secrets stored in Secrets Manager, or KMS.

ACM could leak your private keys.

EC2 hypervisor could have a 0day that allows China to steal all your data.

CloudTrail could drop audit logs.

At some point, you have to trust the company who's software you're using. Sure Amazon could easily drop the last N transactions, but what motivation do they have to do so? What behavior in the past makes you think this wuold happen?

[cloudhead]

Completely agree - what I'm wondering is why they are telling their customers that they can verify the data for themselves, when that is entirely pointless: "and using cryptography, you can easily verify that there have been no unintended modifications to your application’s data"

[Filligree]

How is it useless?

If the digest you provide is found, then you know the data hasn't been changed. Sure, that's the only bit of information you get, but in a lot of cases that's the only one you need.

It doesn't guarantee your data can't be changed, no. What guarantees that is your contact with Amazon.

[cloudhead]

Your other comment puts it nicely - "trust but verify" - I guess it's more about auditing yourself, than Amazon.

[CiPHPerCoder]

Maybe they just want to quell the blockchainia.

[jedberg]

They could, but why would they?

[cloudhead]

Indeed, they wouldn't - but the product offering sounds like they are telling customers that they can audit their data and that it is cryptographically verifiable - but why does the customer care about this, unless they don't trust amazon to preserve data integrity?

[Filligree]

"Trust, but verify."