<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1822615684631785&amp;ev=PageView&amp;noscript=1"/>

My feelings on Google’s $15,000-$75,000 OAuth verification process and security assessment

Last October, Google announced that it would start being more stringent with software vendors building apps on top of the Gmail API. Specifically, developers using a “restricted” or “sensitive” Gmail API scope would be subject to additional scrutiny and have to pay a fee of $15,000 – $75,000 or more to have a third party security assessment done. GMass leverages the power of the Gmail API to perform its magic, and so GMass has been subject to these measures.

Since Google’s announcement, the web has become rife with stories of frustration amongst smaller companies and independent developers who simply cannot afford the fee. This new policy stands to kill innovation, be the obstacle to side projects, and overall, make Gmail less useful. One of the primary reasons Gmail has been the email platform of choice for startups and tech companies is that it’s been extensible. There are hundreds, if not thousands, of extensions for Gmail, one of which is GMass, that add functionality and make Gmail more useful than the base product. Most of these applications will disappear. Unless a product has reached the point of business sustainability, it won’t be worth it for most developers to pay the fee and go through the security process (which by the way, will likely cost more than the fee paid, because of development time necessary for remediation).

Well known extensions and Gmail apps like Boomerang, Yesware, Mixmax, and Mailtrack will likely pay the fee and succumb to the new governance, but smaller players like Context.io and EmailMonkey have already announced their plans to shut down. I’ve also decided to shut down my other Gmail extension, Wordzen, because the fee is too high to be worth it for Wordzen.

This article from The Register profiles two makers of Gmail apps, Leave Me Alone and Clean Email, and their frustrations with the new requirements.

Even a popular service like IFTTT is caving and reducing its Gmail functionality.

My stance

  1. I’m not happy about it, but given the substantial GMass user base, we’re beginning the process of the security audit. You can follow my live updates of the OAuth verification process.
  2. I’m a proponent for greater security and protection of user data, but asking software developers to pay the security fee is ludicrous. Google should pay the fee on behalf of its developers (explanation below).
  3. The opportunity is rife for a new email platform to make a dent in Gmail’s marketshare.
  4. Prices for all Gmail apps, including GMass, will rise to cover the cost of the annual security assessment.
  5. Google is grasping for straws when justifying making the developers pay. In response to the question “Why is Google asking apps to pay for the security assessment?” they state, “As we’ve pre-selected industry leading assessors, the letter of assessment your app will receive can be used for other certifications or customer engagements where a security assessment is needed.” Gee thanks, Google, for making it easier for us to get more customer engagements.
  6. Google’s support for developers who build Gmail apps has been poor, and the manner in which this issue is being handled is being done callously. Questions to the OAuth verification team go unanswered for long periods of time. Stack Overflow is littered with questions about the Gmail API, mostly which go unanswered, despite Google pointing developers to this area. Google has been playing favorites with Gmail Add-ons, allowing only some to work on iOS while claiming that iOS isn’t supported, and not providing any context for its decisions. Additionally, Chrome extensions for Gmail have never been officially sanctioned, although when Gmail launched its new UI last year, it did inform all extension makers of the upcoming changes and provided test accounts. It’s clear that it’s up to developers to solve their own issues and work around Google’s platform shortcomings.

Conflict and Confusion

There is also conflict and confusion amongst the information released by Google.

Does this process only affect you if your users include gmail.com accounts, or do you have to go through the process even if you just take on G Suite users?

The language in the announcements seem to indicate that this only affects gmail.com consumer accounts wanting access to an app.

The use of the word “my”, however, in the question is confusing. It makes the question seem to apply to internal accounts only, those that are owned by the developer of the app. But then the answer references how G Suite administrators can control access, which implies that all external G Suite accounts are included in the group that are not impacted.

In the detailed FAQ about who can skip the review process, one would hope that for consistency with the above that it would say “Those apps that only service G Suite accounts and not consumer gmail.com accounts” but it doesn’t. Hmm.

Further in the FAQ, we find:

The first paragraph references “Google Accounts outside of your organization” which I interpret to include G Suite accounts outside of your organization. But then the second paragraph says that if you don’t verify, “access for new users will be disabled” and “existing grants for consumer accounts will be revoked”. I interpret that to mean that no new G Suite nor gmail.com users will be able to OAuth connect to your app, but existing G Suite users will still be able to.

Lastly, there’s this bit:

I’m thoroughly confused at this point.

What happens if you choose to not go through the process? Will your app just show “Unverified” on the OAuth consent screen, or will it not have access to certain Gmail API scopes altogether?

The documentation is also unclear on this issue. In the User Data Policy, we find:

but this seems to conflict with what’s shown above:

Finally this text under the “Sensitive Scope Verification” section seems to indicate that the only consequence of not having your app verified is that users will see that it’s Unverified.

However, there’s no equivalent question under the “Restricted Scope Verification” section:

They really should include the question: “What happens if I don’t verify my app?”

It would be preferable for the entire developer community if the only consequence of not verifying a sensitive scope app is that users see the “Unverified” designation when connecting their accounts because it allows users to still use their apps. Personally I wouldn’t mind if GMass users go to connect their accounts and see that the app is “unverified”, if it weren’t for the 100 user cap that is imposed on Unverified Apps. But again, this is only clear for sensitive scope apps and not restricted scope apps.

The scope of the security audit

In the FAQ, Google states “we are requiring apps that store data on non-Google servers to demonstrate a minimum level of capability in handling data securely and deleting user data upon user request.” But deeper in the FAQ, the audit also includes developer’s code deployment practices, which seems to go beyond a minimal level in capability in handling data securely.


Google is in a position of power over its third party developers. After all, where are the developers going to go? We’ve all invested substantially into building our products, many of us make a living off of what we’ve built, so we if we don’t play by the new rules, it would mark an end to our careers. We could go and build on Outlook.com’s API instead, but with just two players — Google and Microsoft — dominating the email ecosystem, there’s no guarantee that Microsoft won’t implement the same policies. Such is the risk of building a product on top of someone else’s.

Why Google should pay the fee instead

They can afford to, and it offers a checks and balances between the security firms and Google that doesn’t exist right now. While developers benefit from building software on top of Gmail, Google too derives benefit from attracting customers to a product that has been made better by all of its third party developers. There are users of Gmail and G Suite that would NOT be users if it weren’t for their loyalty to a particular third party app. I know for certain that in GMass’s case, we’ve brought users to G Suite because they wanted to use GMass.

Resources on the new Google OAuth scope policy

Google’s original announcement: https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems

The user data policy: https://developers.google.com/terms/api-services-user-data-policy

Detailed FAQ on the verification process and the security assessment: https://support.google.com/cloud/answer/9110914?hl=en&ref_topic=3473162

Indie Hackers discussion of the issue: https://www.indiehackers.com/forum/psa-new-google-policy-creates-15k-barrier-to-entry-for-apps-using-the-gmail-api-08070e6e4c

Inbox SDK discussion on the issue: https://groups.google.com/forum/#!topic/inboxsdk/6NLvQL-5bic

14 Comments
  1. Wow this is heavy handed by google and an innovation killer (as you’ve stated) gutted to see this come into action.

    Also why the large spread from $15k to $75k, what determines that?

  2. It’s the most damn poor support and worst documentation I ever saw in my life. It is ashame to google on how it is handled, lack of understandable information, clear consistent documentation etc.

  3. Good Summary, I am currently rebuilding my extension to not use the gmail api at all as I too cannot possibly justify $75,000.
    How? All the data I need (messageId, threadId etc) is in the page or is returned to the page shortly after sending, just scrape the data.

  4. Great post. Terrible move by Google. I like Google less now, as they are breaking the ‘rules of the game’ that they set up.

  5. We have the EU’s GDPR policies to thank for this. Google was slapped a with $57 million dollar fine back in January following months of legal wranglings with the EU’s regulatory bodies.
    These new security measures are in direct response to that.

    Basically Google has shifted the responsibility of security to developers. Sucks for us as developers, but I don’t expect Google to roll back these changes, not with EU’s regulatory bodies poised to fine them again.

  6. Has anyone started a petition. I just saw that they changed their restricted api’s to include Google Calendar now. I have been using it for 3 years without issue. Now I am going to have to disable that feature in my app. The fact that their terms now states “we are requiring apps that store data on non-Google servers” is abusing their power as a monopoly. Saying if you use our api and you are using amazon or azure we are going to put you out of business or you have to pay us is absurd. If we can get enough signatures we can report it to https://www.justice.gov/atr/report-violations

  7. This article is right on. After months and months of supplying videos, back and forth emails, updating scopes to what Google said I should, more videos I get sprung with this email. Why wasn’t this the first one? I would have just told my customers “sorry, you need to use my application only for your own G Suite Accounts… let me know if you need help setting that up.”

    The funniest thing.. the mail.google.com scope, the highest restricted scope, is required, by Google, to use OAuth 2.0 with their SMTP server. I asked why and they said “use the API instead.”

    But they won’t let me (for a public app that I make for customers).

    Wouldn’t it be easier to change the scope for SMTP server OAuth authentication to readonly?

    Sometimes I think Google is getting way too big for their britches.

    I even remember years ago when 2 years in a row they let their SSL certificates expire for their SMTP server causing crazy issues. At least back then I was able to finally get in touch with someone to warn them. Now it seems we’re talking to robots.

    My Google Drive app went through verification in literally 2 days with no issues. Why is GMail more sensitive than that? (or maybe I should keep my mouth shut about that…)

    I see in the future, if this continues, even the private apps will need to go through these hoops. Then I seriously will consider telling my customers to switch to Office 365. (ugh.. I sure hope not though).

  8. @Brad:
    Google Drive is next. Only the file.scope which is useless for most apps will not be considered a restricted scope then.

  9. There is another requirement from Google on this. There’s a “connector target app” model that Google is imposing more unreasonable requirements on smaller developers or company. If your organization happens to be integrated by another third party company, that uses both your OAuth APIs and Google OAuth APIs, you have to go through this assessment as well.

Leave a Reply to Andrew Cancel reply

Your email address will not be published. Required fields are marked *

Try GMass today

It only takes 30 seconds to install it!

Install Now GMass requires Chrome
Share This