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
- 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).
Send incredible emails & automations and avoid the spam folder — all in one powerful but easy-to-learn tool
TRY GMASS FOR FREE
Download Chrome extension - 30 second install!
No credit card required
Ajay is the founder of GMass and has been developing email sending software for 20 years.
I agree with you. We should speak.
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?
Hi,
Can you confirm if the security assessment needed if data hosted on google server
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.
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.
Great post. Terrible move by Google. I like Google less now, as they are breaking the ‘rules of the game’ that they set up.
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.
> We have the EU’s GDPR policies to thank for this.
No, we don’t. That’s a very convenient narrative to push for Google, but that’s not it.
First of all, Google was fined in France for not disclosing to their users the data they collect in services like the search, maps, YouTube – not or not only Gmail, yet only Gmail changes the rules.
Second of all – it has literally nothing to do with security, especially third-party apps that have to follow GDPR rules themselves. If a third-party app/service does not, they will be fined, not Google. The moment you store data that belong to the user, the moment you are responsible for that data, no matter how did you acquire it. If it would be GDPR related – the audit wouldn’t be a “security audit”, but GDPR-compliance one. And/or it would result in restricted or lack of access to data that would violate any GDPR-related laws. Plus – it would apply to all services/apps no matter if in production, under its own domain, etc.
Third – there are international norms like ISO 27001, which would allow companies to seek certification from any company or organization allowed to perform the certification process, not 2 or 3 companies from the US (another reason why it’s not an EU problem) that were hand-picked by Google to be the only ones to do the assessment.
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
Someone should start a non-profit that does these security audits for free.
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).
@Brad:
Google Drive is next. Only the file.scope which is useless for most apps will not be considered a restricted scope then.
tes comment
Any updates on the security audit ?
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.
I tried,to no avail to get clarification on the definition of “remote servers” in this section of the terms:
Can someone here perhaps clarify?
**
Security assessment
If your application is sending or has the ability to send Google user data from a Restricted Scope to REMOTE SERVERS, then our verification process requires that your app undergo a security assessment to demonstrate a minimum level of capability in handling data securely and deleting user data upon user request. Depending on the scope and complexity of your app, the cost for the third-party assessment might vary from $15,000 to $75,000.
**
Why not just boycott this scam called Google that makes billions on stolen data of people who never authorized this scam operation to collect their private data. Last two months this company has damaged us so much and even after approving the scopes our uses still see a message that new oauths are disabled. Have spent tens of hours making videos and keep making changes over and over even though we have been using the API since 2013. Keep sending them emails and no response. Crapy API, crapy documentation. This company even forced us to change our privacy policy even though we never retrieve or store any data from Google. They wanted us to spend 50K on a third party evaluation but our response included some choice words about their mothers anatomy and they backed off. Big time anti-trust violation. I have been talking to a lawyer to file a lawsuit against this scam operation. Enough is enough.
I wonder if there is enough of a ground swell to file a class action lawsuit. As many have pointed out here:
1. Google does not own the data generated by its users, who are ultimately reponsible about who they let access it.
2. Once data is out of Google’s servers, the onus is on the app, and no amount of certification can solve this.
3. Third-party certification companies supposedly look for vulnerabilities in non-Google servers storing Google data. But who made Google god to look at other’s servers?
4. Why is registering the app with Google alone not enough for Google to monitor the app? Or why not establish a set of security parameters that any competent assessment provider apply to certify the app and file the results directly with Google? What makes the 3 selected companies so special that others cannot do?
5. As someone has already pointed out, this has nothing to do with GDPR. The app owner is ultimately responsible for the data taken out of Google. Even Google knows this, and they certainly have competent lawyers to tell them this.
6. A simpler idea would be to impose a lifetime on user’s permssions, and make the app request permission, say once every 30 or 60 days.
Given a plethora of simpler solutions that are available, one has to wonder what Google’s real intentions are with this nonsense. I can only conclude that it is to kill competition. I wish someone would do with Google what Basecamp is doing with Apple.
What I don’t understand is why if users agree to allow an app (notice: with google oauth authentication) to connect to g suite data, this app shall be verified by a 3rd party. It’s another G abuse!
The supposed certification does not guarantee that developers will not sell data, breaking its own privacy policies! Are we all idiots?
This is just something that will put free (great) apps and startups out of the game. Google was great when they started, it was free and was against advertising and all what they are doing right now.
We must share this info and fight for our rights, and our Internet! If Google wants to limit/control the internet why don’t we help others grow. Believe me, this is just the beginning, nothing will never change with G controlling everything like the an emperor.
hello, Is the sync with google “Calendar” concerned? thanks
I am glad to see i am not the only one who is suffering.
Been waiting 7 weeks to get my app (kalendme.com) approved … starting to realize this is a dead end … as an independent developer this’d be impossible to pay
Did anyone go through this process ? How much did it finally cost ? How long did the process took? Appreciate any response. Thanks in Advance
Did anyone go through this process ? How much did it finally cost ? How long did the process took? Appreciate any response.
I would like to know the answer to this as well.
Did you go through the security assignment for Gmass, Ajay? Would like to hear your experience on that if you did.
Thank you!
Hi Phuc,
Yes, please see this article where Ajay provided updates for each stage: https://www.gmass.co/blog/live-updates-google-oauth-verification-security/