Comment by hguhghuff | Hacker News Reader

Comment by hguhghuff | Hacker News Reader

Parent Full thread

Amazon does not delete your account as far as I know until some extreme has been reached.

You guys need to understand the scale of distrust this issue raises.

If you want to fix it, give up on putting lawyers and spin doctors up front.

Instead, give this disastrous issue the response it deserves and get the CEO and Chairman of google to make s loud, clear and focused apology and say loudly that we do not delete your entire computer systems over account payment issues until defcon 3 is reached.

Why the F would I build my SAAS business on google cloud without that message being yelled repeatedly and loudly and clear from the top level of the company, as much so Google understands it as the market understands it.

And by the way, I pay ALL my cloud accounts on credit card. I note carefully that at google this means I have a higher chance of having my entire computer systems deleted than if I use some other payment mechanism. Your policy here appears to me to be using systems deletion add leverage to get me off credit card payment. All of which says to me that google still just doesn’t get it.

Amazon locked out a seller's account because they changed their Kindle's profile name to "Daddy" (in Chinese). Amazon asked for the seller's ID with that new name, and no amount of support escalation was enough to fix it[0]. It took an absurd amount of bad PR for them to come out and fix it.

Google is bad, but Amazon is really just as bad. They both have absurd policies with no recourse, that work in the 80% case and fail very badly in the 20% left.

[0] https://www.reddit.com/r/amazon/comments/5gvgdl/using_a_amaz...

Amazon Web Services is essentially unrelated as a business from Amazon.com. This is even less relevant than someone trying to compare the policies of some random end-user service like Google Photos with Google Cloud Platform. I personally had serious issues (not account suspension problems, but an inability to get things like basic tax paperwork to correct addresses) with Amazon Flexible Payments (which was part of some seemingly unrelated-to-everyone division), but I count absolutely none of them against AWS (which wasn't involved in running the service).

I once signed up for AWS, they couldn't verify the card on initial signup and the entire account got blocked, including a login to a seller account that was doing 6 figures/month.

Amazon has a big issue in that all their services are linked to a single Amazon account, and if that account is blocked you can be prevented from accessing entirely unrelated services. In that case, maybe it was ok to suspend a brand new AWS account until accounts could be verified, but the linked accounts that were also blocked should have been looked at manually because of their volume.

Yep I’ve also had absurd cross Amazon-AWS payment issues they were unable to fix for months. Their ultimate solution “uhhh make a new account.”

> Google is bad, but Amazon is really just as bad.

I think the main problem is that fraud is real problem and if you don't want your account to ever be considered fraudulent, then you should take ample steps to make sure that it is not.

There are countless stories of people being careless with their keys causing tons of crypto-mining servers to launch.

There is no win for cloud providers here. Either you get PR smashed for charging careless customers, pay tons of money to wave off their mistake, or get ridiculed for trying to block customers whom you think have been hacked.

Or just throttle the account and contact the customer by phone and help them resolve the issue.

If you can’t provide that level of support you don’t deserve my business.

I received this a few months ago on a demo account I was setting up. Here's the mail. (It was my personal account and cc not my corporate one) - I don't even have a fax machine.

---------

Greetings from Amazon Web Services,

We were unable to validate important details about your Amazon Web Services (AWS) Account. Your AWS account has been suspended. While your account is suspended, you will not be able to log in to the AWS portal or access AWS resources.

If you do not respond to us within 3 days of this email (by Saturday, April 28, 2018), your AWS Account, and any data will be terminated.

At your earliest convenience, please send us a copy of a current bill (utility bill, phone bill or similar), showing your name and address. Please provide for both the credit card holder and account holder if different.

IMPORTANT: When you send us your information, please include your email address, so we are able to process your fax as soon as possible. We can be reached via secure fax line at +1-206-922-5831 and 866-437-9072.

Once you have sent the requested documents via fax, please contact us at aws-verification@amazon.com and include the following details:

- The billing address and phone number of the credit card on the AWS account - The billing phone number of the credit card on the AWS account - Business name and phone number (if applicable) - The URL for your website (if applicable) - A contact phone number where you can be reached should we need additional information - Potential business/personal expectations for using Amazon Web Services

If you have any additional information you feel will expedite this process, please feel free to include that as well.

We apologize for any inconvenience this may have caused you and appreciate your patience with our security measures.

Thank you for your immediate attention to this matter.

Sincerely,

Amazon Web Services Team

That's an equivalently bad e-mail from AWS, but it's a single datum, out of context.

Actually, you did provide some context, which is that it was a "demo" account on a personal credit card. This, at the very least, implies much less spending than in the blog post that kicked this all off.

More importantly, what's missing is the human/support response and attitude from AWS, which is the OC's primary concern.

Anecdotally, from the comments I've seen on HN, AWS customers (at least beyond a certain size) seem generally pleased with the availability of human judgment during support issues, especially so when paying for that support.

As stated in the original medium post, the issue was they only had one credit card on file and no contact at the company. If they had either a second credit card or moved to offline billing or had a contact with a phone number (all free steps), they would not have been suspended.

Maybe the language in setting all those up should be very upfront with the benefits they provide. Or even proactive emails and large dialogs about doing that. Perhaps it should be like those sites heavily suggesting 2FA if you've been a customer long enough. If there is a concern about noise, maybe the messaging for that should pop up in the GUI in a non-ignoreable way and start on accounts with a sizable spend or have existed for some time with activity.

I'm pretty sure that's undisputed, but it also doesn't address the concern of what happens once a customer finds themselves in that situation, whatever the reason.

Furthermore, this response could be construed as reinforcing the OC's precise concern regarding Google's attitude:

> that you are probably wrong.

I hope we can convince you all that that is no longer our attitude, but I know that only time will tell.

As I mentioned above, in this case, WE were absolutely wrong, and the blog post details all the ways we're fixing it.

I suspect that part of what has people worried and continuing to complain about Google's attitude and "tone-deafness" is that your responses, which are seen as being representative of GCP, based on your revealing your affiliation, suggest you're not quite absorbing the meaning of the actual concern/complaint.

You did admit error and apologize in the blog post (perhaps not explicitly or early enough in the text for some people, but that's a separate issue), and you specified how you were going to fix it. It may take time for the reputational effects of those fixes to permeate.

That's not the issue.

The issue is that, here, you have, effectively, said, "but the customer could have..".

Even the implication that the customer might share in the blame, no matter how objectively true it may be, takes credibility away from the sincerity of an apology and can easily be seen as evidence of the persistence of same, old attitude. Given that the statement happened after the apology, further time is unlikely to make a difference.

Shoot, ok, let me try again.

1) This was, in NO WAY, the customer's fault. At all. Not even a little bit. They did stuff that was totally normal for a customer to do.

To remedy us not accidentally flagging totally normal stuff as fraud again, we talked about 7 steps we were taking (that was the first 7 steps in the blog).

2) IF, and only IF, you'd like to take ADDITIONAL steps to avoid us accidentally flagging you, we also offered three steps (at the end of the article). However, these were totally optional.

Hope that helps.

> 2) IF, and only IF, you'd like to take ADDITIONAL steps to avoid us accidentally flagging you, we also offered three steps (at the end of the article). However, these were totally optional.

Getting warmer.. but:

Even here, you're saying that the customer has (or could have) some role in preventing your error (accidental flagging). This is merely an issue with the wording (here, not necessarily in the OP blog).

The "protect your account" wording of the blog post itself seems good, as do the specific reasons for each additional step.

My only suggestions would be to add the concept of urgency in reachability to the phone number, as time sensitivity seems to be important to many (but not all) customers, and to substitute something for "don't miss important alerts" (which, again, could be read to imply blaming the customer) that has a more positive wording, that expresses that all the relevant parties would then be empowered to have visibility into those alerts (rather than avoiding the transgression of missing them).

See also https://news.ycombinator.com/item?id=17567900 (which I have no idea as to the veracity of but figured I'd call your attention to)

> Hope that helps.

It does (at least IMO), and I hope you take my feedback in the contstructive spirit in which it is intended. (I don't personally have a strong opinion either way, as I lack enough direct experience).

One problem I have had with dealing with Google (not for this particular service) is that they set up mechanisms where adding a "backup" creates a new single point of failure rather than adding redundancy. If you can't access one particular backup method of verification, your primary and other backup are of no use. It's a trap! And quite Kafkaesque.

While this might not strictly apply to some other particular situation, my experience would lead me not to ever trust Google when they say "do this seemingly logical thing because it will make you safer".

I know, I guess the funny part is the opposite was true with this account on AWS. The GCP issue (as detailed in the original medium post) was a lot of spending on what appeared to be a new account (again, this was OUR mistake). The reason the AWS one frustrated me so much was there was effectively ZERO spend.

In our case, we're adding a second human in the loop (we already had one) to double check this. Customers can also add their own human to reach out to by connecting to a sales person (it's free and extremely low pressure!)

You work at google; surely you should google how to fax something without a fax machine? Or were you just unwilling to trust those services? (which is understandable, you're sending pretty personal data).

And in general, I find it difficult to buy your "I don't own a fax machine argument". I don't own a photocopier, but that's a small blocker, no?

I'll be honest, that comment was snark. I apologize.

Reply on news.ycombinator.com