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.
- 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.
- 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).
- The opportunity is rife for a new email platform to make a dent in Gmail’s marketshare.
- Prices for all Gmail apps, including GMass, will rise to cover the cost of the annual security assessment.
- 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.
- 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:
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 (cloud.google.com).
The user data policy (developers.google.com).
Detailed FAQ on the verification process and the security assessment (support.google.com).
Indie Hackers discussion of the issue (indiehackers.com).
Inbox SDK discussion on the issue (groups.google.com).