
Elevating user trust in our API ecosystem - wayoverthecloud
https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems
======
jivings
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.

~~~
tylerkovacs
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/](https://docs.microsoft.com/en-us/outlook/add-ins/)

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

------
ihaveajob
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.

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

~~~
ihaveajob
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.

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

~~~
ihaveajob
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.

------
Ivoirians
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.

~~~
TeMPOraL
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.

~~~
Ivoirians
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?

~~~
TeMPOraL
> _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.

------
solomatov
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.

------
TheAceOfHearts
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...](https://support.google.com/cloud/answer/9110914#assessment-
includes)

~~~
Alex3917
> 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.

------
troydavis
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.

------
patrickyeon
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".

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

------
gnomewascool
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/](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...](https://support.google.com/cloud/answer/9110914#restricted-
scopes)

[3] [http://notmuchmail.org/](http://notmuchmail.org/)

~~~
jivings
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.

------
RcouF1uZ4gsC
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.

~~~
ihaveajob
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.

------
abarringer
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?

------
leowoo91
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?

~~~
Alex3917
> 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...](https://support.google.com/cloud/answer/9110914?visit_id=636840431142079898-1547745173&rd=1#ensure-
approval)

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

------
jillesvangurp
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.

------
anoncoward111
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!

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

------
__initbrian__
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

~~~
sctb
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.

