Elevating user trust in our API ecosystem | Hacker News Reader

Elevating user trust in our API ecosystem

cloud.google.com

I've been caught by this change. Google have requested that my app be audited by one of the suggested security firms. The lowest quote I have right now is $22k.

We're a bootstrapped business with nowhere near this kind of cash, so this effectively means Google are shutting our service down.

What's crazy is that while this might help protect from negligent developers accidentally losing a few user keys, it doesn't really solve the real problems like it's claiming to. It in no way protects you from the worst offenders, the Cambridge Analytica's out there, the ones with plenty of cash, from still stealing or abusing your data. They can just pay to make this go away.

This is seriously bad news for any independent developers or small companies who are building apps on top of Google's API.

I'm in the same situation and I can't figure out Google's reasoning here.

It seems like an attempt to address bad publicity in the articles mentioned below - which largely boiled down to misleading reporting. And the remedy doesn't accomplish much outside hurting small developers and Google's reputation in the ecosystem.

I'll never build anything on top of Google again. I might end up repurposing my work on top Outlook instead. From what I've heard, they are much more supportive of their developers.

https://docs.microsoft.com/en-us/outlook/add-ins/

Not sure why Outlook is really relevant? Google still let's G Suite users do whatever they want.

It would be nice to dial down the cost for the existing customers, perhaps at least a year old ones. I hope they can find a way to support those cases. For sure, it will require unplanned effort for the businesses, let alone to stand in their previous finances.

Well, that's a no-go. We're a small startup that's scraping by and only recently we're starting to get some traction on our GMail integration. If we're asked to undergo such a review, we don't have the $15k+ to spare, so we'll likely say goodbye to the ecosystem. Like someone else said in this story, we're probably just going to focus on Microsoft which is much more developer friendly.

Worst of all, this won't stop intentional bad actors from stealing user data for whatever purposes they have in mind. Big pockets are going to laugh even at a $75k fee.

Is it possible to build a browser extension to replace the existing functionality?

It is, but it's an inferior proposition for our business (and for users) without access to the Gmail store. In fact we used to have our functionality as a Chrome extension but Google aggressively marketed the native approach when they published the "New Gmail". And we went for it.

What about using the Gmail API into an app that gets overlayed into Gmail via chrome extension?

It seems like add-ons are still mostly Ok if they use the narrowly defined scopes, instead of say "gmail.readonly" which is a blanket permission. Minor heart attack, but we might be ok.

What an awful choice of a title. (Used to be something like "New Google policy charges devs $15k to access Gmail API")

Also, this isn't a bad move AFAICT (tightening policies and access to a very important API), but it's evidently a reaction to the backlash from that WSJ "exposé" about the scandalous fact that email providers allow third parties to read/manage your inbox... if you give the third parties permissions and access tokens. That was just dirty reporting and intentionally misleading average readers--the comments on that article were all akin to "I knew Google was reading my emails!". And I don't see this change mattering much to those people.

AFAIR that WSJ exposé is recent; if so, this is not a reaction to this - last year, I've been working on some code integrating with GMail, and I remember encountering the announcement of this change 6+ months ago.

EDIT: at least I think I do. I tried to find a reference to this in my project note, to confirm the timestamp, but I failed. So it could be I've seen it in October 2018, as 'Ivoirians pointed out.

Of course, I can't say for certain this is a reaction, but it seems to me like they're addressing the actual meat of the original article--third party apps can do whatever they want with your emails once they have the keys, like let their employees read through them. The issue was that the policies dictating how apps could use that access didn't seem to have much teeth; thus, the new security review.

Also, this announcement says it first came out in October 2018, while the WSJ article came out in July 2018?

> Also, this announcement says it first came out in October 2018, while the WSJ article came out in July 2018?

I tried to confirm the date I saw this in my project notes, and failed, so maybe I indeed saw it in October. If so, and if WSJ report came out months earlier, then maybe it is indeed a reaction.

I like this initiative of Google. Currently, I am very cautious about giving apps access to gmail, and I would be much happier, if I knew that the app was evaluated by security professionals.

I think this could be improved by carving out some minor exceptions for applications under development or starting off, perhaps with a low user limit to prevent abuse. Their FAQ says you can avoid reviews if you only have a single user, but it doesn't seem unreasonable that you could have a team of 2 or 3 people working on something. Once you have something working you'd probably invite close friends and family as well. Although you can work around that by using G Suite accounts, it kinda sucks that you're forced to pay.

A scaling system based on number of users and other factors would probably be better. Look at the list of requirements for a security audit [0]. I'd imagine many small businesses would struggle to sort out everything listed there.

I'm not a fan of removing user choice. If someone has established trust out-of-band then they should be able to opt-in after acknowledging that they accept and understand the risks. But I guess we need big daddy Google to step in and protect us, since we're too dumb to critically asses the situation.

Something that nobody seems to be mentioning is that you need to perform these security assessments on a yearly basis. Talk about drastically raising the barrier to entry...

[0] https://support.google.com/cloud/answer/9110914#assessment-i...

> it doesn't seem unreasonable that you could have a team of 2 or 3 people working on something

You can have unlimited developers using the app from accounts with your domain.

You really should get at least 250 users though, since at $10 / user / month that would be enough to cover the cost of the security assessment, and the assets under protection are going to be minimal enough so as to not attract any non-automated attacks.

Whatever one's view of this approach, it seems to justify a FAQ entry like "My app doesn't charge money. How does Google recommend I proceed?"

Even if the answer is that Google is indeed shutting out free/not-for-profit and pre-revenue apps (collateral damage), it should at least be stated explicitly.

I have a few convenience scripts that access the Gmail API for my own inbox, and only my own account. Does anybody know if there is some kind of "under development" flag I can set so that I don't have to undergo this review? Am I going to need to convert them to directly using IMAP or something similar?

I'm not horribly against this policy, email is pretty central to a lot of peoples' world, and I suspect there's lots of really really scummy actors out there. In an ideal world I'd be able to say "hey this is my email and I personally wrote the code accessing it, so let it do what it wants".

This is part of the verification step, and you don't need to get your app verified if you only have one user.

Would something like gmailieer[0][1] be affected? (Or, in general, FOSS software for syncing with one's gmail data.)

It uses some of the "restricted" scopes[2].

Also, what does the verification as "non-malicious software" entail?

[0] https://github.com/gauteh/gmailieer/

[1] A cli program that downloads one's (i.e. the user's) gmail e-mails onto one's computer (without touching any third-party servers on the way) — it's effectively a better offlineimap for gmail, for use with notmuch.[3]

[2] https://support.google.com/cloud/answer/9110914#restricted-s...

[3] http://notmuchmail.org/

What I have found out by talking with the Google verification team is that if the requests are made from the client and not from a server then they do not require audit.

I am actually very happy about this. For too long, private data has been viewed as an easy business opportunity. Now we are getting to the point where private data is being viewed as a liability.

The thing is a bad actor with deep pockets is going to sail by this review because their security systems and practices might be top notch, but the moment they're rubberstamped, they can turn on evil mode and start doing whatever they want with your data. Small players get cut off if they can't afford the fee, even if they're honest and secure.

We just got blindsided with a $16,500 charge from Experian for a security audit. Previously they accepted out PCI letter now they insist on selecting an auditor and sending them onsite for us to continue using their API. Maybe this will become the norm gong forward? Any vendor you get PII from will insist on you paying for an audit of their choice?

I don't get the scope. So, an app I've made within the company which is reading company inbox (located on a server) using Gmail API, does this policy apply for e.g.? Or it's related to some kind of oauth rather?

> When can I skip publishing my app for a review?

"The owner and users of your apps belong to the same G Suite domain or customer."

https://support.google.com/cloud/answer/9110914?visit_id=636...

Thank you for pointing out, so looks like it is 'oauth' related.

Ouch, this is likely to affect us as well. We ask our users to give us access to their contacts and calendars. This is opt in and helps us help them. This all completely optional, opt in, we comply with GDPR, and use common sense.

Having a whole lot of bureaucracy and cost from Google is not going to help and is going to cause us a lot of hassle.

To me this sounds very much like an anti competitive measure aimed at shutting down the vast majority of third party software currently accessing their APIs and forcing users to use their official apps to access their email.

Linkedin did a similar move a few years ago where they basically shut down their entire API ecosystem in favor of tightly controlled partnerships with selected partners. Twitter killed the market for third party UIs as well.

I would love to know what connection the "industry leading assessors" have to any Google employees at all. Surely they are completely impartial and unrelated, when 15 to 75 thousand dollars is on the line!

I mean by gut response was "That's a lot" But then as a consumer I much prefer that figure to $50

I've been quoted $22k, an amount that was apparently previously agreed upon with Google.

Google Cloud Blog article title: Elevating user trust in our API ecosystem

$15k+ barrier refers to a mandatory security assessment fee -- see "How will the security assessment work?" on the FAQ

We've reverted the title from “New Google policy creates $15k barrier to entry for apps using the Gmail API”, which breaks the guidelines by editorializing.

Reply on news.ycombinator.com