Improving our account management policies to better support customers
cloudplatform.googleblog.com
cloudplatform.googleblog.com
What they are really trying to say is “Google Cloud is now less likely to delete your entire business computing systems over some minor credit card issues.” For this reason, this press release will not get the attention that google wants it to.
Note however that google has included human reviewers in the process and googles humsn reviewers are notorious for being ruthless.
It’s googles attitude to customers that is the ingrained and deep problem. Google has built into its DNA from the beginning that it does not want to be in contact with you, that you cannot get emergency attention, and that you are probably wrong.
My trust level for Google: ZERO. I can't risk my business on that level of stupidity.
- Provide a valid phone number where we can reach you in the event of suspicious activity on your account.
- Provide one or more billing admins to your account.
- Provide a secondary payment method in case there are problems charging your primary method.
- Contact our sales team to see if you qualify for invoice billing instead of relying on credit cards.
To be clear, if you do the last one (which you easily qualify for), you are under contract with us. In that case, the phrase "there was literally nothing stopping Google from insta-banning an account in the future in the middle of a Nike event" would be completely incorrect.
I've been locked out at times from my seller account because they wanted to verify a 10 euro purchase on a related account, and blocked the account for fraud until I faxed over a bank statement. A different time, I signed up for AWS, they couldn't charge the card for some reason, and so the account got blocked for fraud and I couldn't log into the seller account.
Of all the tech companies I've interacted with I've never dealt with one that has come off as uniquely elitist and tone-deaf as Google.
Steve Yegge (former Googler) makes some very good points on this.
https://medium.com/@steve.yegge/why-i-left-google-to-join-gr...
Tl;Dr We screwed up. We're sorry.
Disclosure: I work at Google on Google Cloud.
This post has 7 comments and 11 points after an hour. Compare that to the post that led to this outcome. If your trying to reassure the market that you don’t delete a companies entire back end infrastructure then yes this meets some internal management butt covering goal, but does not tell the market definitively that google cloud no longer deletes your entire computer systems.
Disclosure: I work at Google on Google Cloud.
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.
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 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.
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.
If you can’t provide that level of support you don’t deserve my business.
---------
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
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?
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.
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".
Furthermore, this response could be construed as reinforcing the OC's precise concern regarding Google's attitude:
> that you are probably wrong.
As I mentioned above, in this case, WE were absolutely wrong, and the blog post details all the ways we're fixing it.
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.
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.
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).
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!)
> Established GCP customers...
> Online customers with established payment history...
What exactly qualifies as being "established"? In the first example, additional stipulations around billing arrangements are imposed, but in the latter it remains unclear.
> ...review for flagged fraud accounts...
> ...event that fraud or account compromise activity is detected...
You gotta stop using the f-bomb like that. This piece is supposed to be a follow on to a story of a customer who apparently was conducting completely non-fraudulent activity within their account. Your copy should, like your culture, assume "innocent until proven guilty". Saying something is "flagged for fraud" in a PR piece breaks that rule.
> We will provide ways for customers to pre-verify their accounts with us if they desire...
Sounds very passive-aggressively optional. Nor does it tell me what I actually gain here, or even a hint of what might be involved for verification or how potentially simple or easy it may or may not be - do I need my counsel to post via registered service on company letterhead confirmation of my organisation's official trading details, or do I click an link in an email?
> There are also steps that customers can take to help us protect their accounts including...
The word "protect" is suitable if you were a bank, and you wanted to encourage customer behaviour to prevent them being victims to fraudsters. But you're not, so really this language is suggesting customers need to "protect" themselves from your algorithms and automated systems, which is kind of inappropriate to be saying.
This is accurate.
>> Online customers with established payment history...
> What exactly qualifies as being "established"? In the first example, additional stipulations around billing arrangements are imposed, but in the latter it remains unclear.
They can't tell you. Bad actors will even binary search the parameters of your fraud detection (source: I worked in fraud detection). Minimizing the information feedback loop to the baddies is super important to avoid becoming a loss function they can optimize against. This is true of every fraud department.
Abuse detection is cat-and-mouse. Say as a provider I track your true IP through proxies by embedding some flash that calls home. You figure it out and block flash or do some clever sandboxing. I work with proxy providers to build blacklists. You somehow get the blacklist and just avoid all proxies on it. Etc etc.
- Provide a valid phone number where we can reach you in the event of suspicious activity on your account.
- Provide one or more billing admins to your account.
- Provide a secondary payment method in case there are problems charging your primary method.
- Contact our sales team to see if you qualify for invoice billing instead of relying on credit cards.
One saying I’m sorry isn’t an amends. Neither is offering a contrition-free remedy for past bad acts. Amends requires both contrition and a remedy.
For example, inserting the following (or anything similar) after the first sentence would have demonstrated some contrition: “We have truly been humbled by our prior lack of insight, and we are very sorry for what happened to any customers affected in any way by our shortcomings in this area. We realize we need to regain your trust and with that in mind, have thoughtfully examined all the feedback we received.”
Learning you all actually thought it through and consciously chose to save face does not inspire confidence. Nor does the underlying subtext that customers big enough to pay by check and get an account rep get a free pass, while little bootstrapped guys like me can still have the hammer dropped on them, albeit with slightly more scrutiny than last week.
We screwed up. We are really sorry. This was a confluence of unexpected events that slipped through our systems (which included both humans and algorithms). We know it will take a long time to rebuild the trust we've burned, and we are committed to doing it.
In addition, as I said earlier, the options to ensure that you have additional protection (WHICH YOU SHOULDN'T HAVE TO DO, I'M JUST OFFERING IT) are at no cost:
- Provide a valid phone number where we can reach you in the event of suspicious activity on your account.
- Provide one or more billing admins to your account.
- Provide a secondary payment method in case there are problems charging your primary method.
- Contact our sales team to see if you qualify for invoice billing instead of relying on credit cards (this is much lower than you would generally think)
While you're right people will want an actual plan on how things are going to change, they also want a genuine expression of contrition. As hguhghuff noted, deleting someone's business is a serious, serious issue.
The _only_ admissions of guilt or wrongdoing was were these lines:
"Here’s what we are doing to be as good as our word, and provide a more careful, accurate, thoughtful and empathetic account management experience for our GCP customers."
"We sincerely apologize to all our customers who’ve been concerned or had to go through a service reinstatement. Please keep the feedback coming, we’ll work to continue to earn your trust every day."
Which, if you yourself were scared that your livelihood could be wiped away, would you think that was a sufficient apology?
It doesn't help that Google tends to lack a human touch when it comes to its image. But here, now, you all have an opportunity to change that. I know it sounds "politics" or "public relations" or whatever, but all we need to know is that you fully understand the fear GCP customers felt and what that means for us.
I could still see everything and all my systems continued running.
Who's we? Did you have a part in writing this? What does "not make it sound too lawyerly" even mean? This press release screams "we made a mistake but we're going to use paragraph after paragraph to ensure we don't actually say that". I have a hard time believing that the people who make up the Google Cloud team don't recognize this.
This is basically the problem. You could say "this will never happen again", but instead it's "we don't want this to happen" as if it's somehow out of GCP's control.
As long as you will still delete accounts that you suspect of fraud, based on some opaque definition of suspecting fraud, "we don't want this to happen" is the best you can do, and that's not very reassuring.
Having worked in fraud detection, this is true for every provider you use. The adversarial nature of fraud detection means making _your definition of fraud_ public is not an option because people will use it as a loss function for their fraud.
I would just make sure I don't rely on a single provider and minimize single points of failure.
In reality bad guys operate at even larger scales than this, doing all kinds of things. Depending on what company you are, you might not even be able to pull the compute resources away from them right away; so in addition to burning disk alloc they're now burning compute units. It depends on the product too -- what if they spin up pubsub instances and leave messages in the queue? You might have to freeze those queues so that if they're valid customers they don't lose data. The more offerings you have, the more potential loss.
But yeah, they don't delete accounts right away -- there is indeed a grace period, and they do keep all your stuff (I suspect legislation may have something to do with it too). Last I remember it goes to appeal process (human review), and your data can't be deleted / resources reclaimed for quite a while. So it's not zero recourse for the user. Sounds like they're adding even more humans into the loop to ensure they don't unfortunately flag and then delete valid users. But it's non-trivial.
And what more important: there is plenty of services that will do lot's of check in advance and ask your passport / card / face photo and such, but they never ever stop your servers or destoy your data unless you do something extremely bad. And if it's come to company account it's even less likely to get in any trougle since most of services take work with companies serious.
Yet Google just like everyone around have extremely easy sign up process that all criminals are happy about, but can blow you in a face at any time. So they first create a problem to make marketing easier and then try to compensate for it by increasing risk of fault for thrir legit customers.
That's a good point. What's interesting is that Google's capabilities mean that they are able to allocate you the resources you ask for post-signup pretty much instantly, whereas AWS doesn't (they actually are just unable to allocate resources so quickly). This turns out to be a nice property if that n day spinup time window is enough to detect some bad guys and take them down in the interim, before they've caused massive damage to your infra / cost to your org. It's an O(1) improvement though. Bad guys will still just wait you out and then cause damage, so it's not like you're actually less likely to have your account frozen at AWS/Azure vs Google.
If you don't freeze the _bandwidth and compute_ resources you're even more fucked, because those have far worse scaling characteristics. So big company X taking immediate action to take down services make a lot of sense in that light. They don't do it in every situation though e.g borderline cases that require human review.
Fraud fighting is costly.
what i want to hear is "we can't make this mistake again".
Maybe because you are not a nice company, and you are selling people's private information to ad networks?
That's one possible reason z another is that you probably have huge egos everywhere internally, and it's kind of tricky to actually care about customers then.
I tend to stick with vendors who are open to improvement rather than expecting perfection up front. There's always something that can be improved.
I tend to take my business away from vendors who pull this kind of crap.
Google being Google (and this probably goes for many tech leaders) probably thought that using an algorithm and some documentation would be enough, even if it means about 1% of customers slips through the cracks and loses all of their Google-stuff. The problem is that in the real world this generates enough backlash that people don't want or trust your services anymore.
While a cloud and even a more classical MSP is supposed to take what they are good at and make it available at a reasonable price (so you can focus on what you are good at instead of everything you might ever need to know to function) at this point you need a second service to backup your first service just to be sure you don't lose everything over some stupid automation you cannot influence. It's like an older HN post (week or 2 ago) about someone being transferred between systems during a company merger and the system deciding that he is fired. No human could influence it, everything was revoked and removed automatically and security just acted on what the computer was saying, and escorted him out. They had to wait until the automated process was done before he could re-enroll in the system and continue to work. That, and GC (and to an extent others like PayPal, Amazon, Apple, MS) are examples of trying to put nuances in human interactions into algorithms and failing, have bad real-world effects.
*
Hello Daniel,
I'm <Sales Rep> and you have reached the Google Cloud Platform sales development team. I understand that you're looking for an Invoice Billing.
Prior to applying for monthly invoicing, please review the following minimum requirements to determine if you are eligible to apply. These requirements include, but are not limited to:
1. Being registered as a business for a minimum of one year.
2. Spending a minimum of $2,500 a month for the last 3 months.
You can also look through the Cloud Billing Help Center which should hopefully provide answers to your questions. You can also contact the billing team through the Cloud Console Billing Support Request Form in the event you need more assistance.
Thank you.
We used to pay for gold level support. It's hilariously bad.
I once had a production outage that ended up being a low-level GKE bug. Support de-escalated my ticket and linked me to this blog post: https://cloud.google.com/solutions/scalable-and-resilient-ap...
I ended up getting help by going into the google slack and kicking up a fuss. Never heard back from the "official" support channels.
Isn't this a meaningless promise since a customer that's been compromised is likely to be violating their TOS or AUP?
So, for example, a customer that's had their webserver hacked and used to host some malware can still have their entire account shut down (as opposed to just the compromised server).
I'm interested in how this hole was actually dug in the first place, presumably by intelligent and well paid individuals, and how it might be fixed. Maybe its already on the path to being fixed and it'll be great to recap in a couple years, maybe these attempts will also prove hollow. Time will tell. They deserve some credit as individuals for trying.