Restricted Scopes - Google Add-ons - Security Assessment - Cost

[Alan Wells]

Applications using Restricted Scopes must prove that they adhere to security practices. How does the developer prove that their app is in compliance with certain security practices? Your app (add-on) must pass an ANNUAL security assessment. The security assessment is not done by Google. But Google will designate who the third party is that assesses your app. If your app passes the security assessment, then you will be issued a Letter of Assessment. The 3rd party assessment will cost $15,000 to $75,000 dollars, depending upon the size and complexity of your app. For confirmation of this information, see the "Secure Data Handling" section at https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes and also the "Why is Google charging a fee for the security assessment?" section at: https://support.google.com/cloud/answer/9110914#

[Steve Webster]

This topic deserves its own deep-dive for sure. 

How does the developer prove that their app is in compliance with certain security practices?

I would add, do they define or provide a list of "security practices"? In other words, I assume we are allowed to track, store and retrieve user's and organization's data AND adhere to their "security practices".

Your app (add-on) must pass an ANNUAL security assessment.

Before you provided that "Annual" note, I was not sure if their would be more frequent security assessment on any new restricted scopes. That would be more costly.

Google will designate who the third party is that assesses your app ...

I wish there were dozens of auditing firms and we got to choose which one -- more competition would potential lower the fee.

If an add-on is making or is projected to generate $50,000 annually, and are willing to have up to 30% devoted to annual assessments, that would designate $15,000. In other words, it may be possible to NOT run away from these assessments depending on the add-on or web app revenue.

Kind Regards,

Steve Webster

SW gApps, President 

Google Product Expert in: Google Apps Script, Drive, and Docs 

Google Vendor (2012-2013) || Google Apps Developer Blog Guest Blogger 

Add-ons: Text gBlaster and Remove Blank Rows

On Wed, Jun 5, 2019 at 10:39 PM Alan Wells <aj.a...@gmail.com> wrote:

Applications using Restricted Scopes must prove that they adhere to security practices. How does the developer prove that their app is in compliance with certain security practices? Your app (add-on) must pass an ANNUAL security assessment. The security assessment is not done by Google. But Google will designate who the third party is that assesses your app. If your app passes the security assessment, then you will be issued a Letter of Assessment. The 3rd party assessment will cost $15,000 to $75,000 dollars, depending upon the size and complexity of your app. For confirmation of this information, see the "Secure Data Handling" section at https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes and also the "Why is Google charging a fee for the security assessment?" section at: https://support.google.com/cloud/answer/9110914#

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-apps-script-community.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/f34a01e7-3c25-4f56-aed0-e151e8167336%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Wells]

Thank you for the additional thoughts.  These issues are critical for any developer to consider before spending time and effort on developing an add-on.  There should be a careful Risk/Reward assessment done before deciding to develop an add-on for the general public using restricted scopes.  In my opinion, it won't be worth using restricted scopes in most cases.  If you aren't using restricted scopes, then that's different.  Let's consider the worst case scenario for using restricted scopes.

The risks for using restricted scopes:

• You could be charged $75,000 a year instead of $15,000
• What if the developer was charged $75,000 for publishing a new update that fixed a bug?
• You could be charged $15,000 the first year, and then be told in the second year that the cost will now be $75,000.  So now you've wasted a year of your life for nothing if your add-on would loose money because of the higher fee.
  

Let's assume the worst case scenario.  You are charged $75,000 for the security assessment.  Then the day after your app launch, a user reports a bug.  You want to publish a new update to fix the bug.  You get charged another $75,000 to be able to to publish a new update to fix the bug.  A week later, someone makes a feature request.  You get charged another $75,000 when publishing another version with the new feature request.  Now you've paid $225,000 within a couple of weeks.

The point is, that developers don't know what the risk ceiling is, or if there is any limit at all to the costs of security assessments.  Why would anyone take on unlimited risk in order to use restricted scopes?  The odds are very much against it.

If someone already has an established add-on that is bringing in money, and the add-on probably won't need bug fixes and feature updates, then it might be viable to keep using a restricted scope.  There might be situations where using a restricted scope for a new add-on would be viable, but it would be extremely rare.  The obvious consequence will be that developers will scramble to reduce broad access to user data in order to avoid the need for a security assessment.  The add-on user will obviously be happy that the add-on can't have access to all their information.  So, that's very good.  There are good things about this situation.

Even if my add-on were making lots of money, and I could afford the security assessment, if I could decrease the functionality of my add-on marginally, and still maintain most of my users, then I'd do that.  I can't believe that the third party security assessment companies are going to get much business from this.

[Davis Jones]

I would definitely like some clarity on these issues. Specifically, if we build an add on that enables somebody to automate portions of their communications (for example, scheduling emails under certain conditions) is that the use of a "restricted scope"? On first read from Google's documentation on OAuth scopes, anything that modifies the body of a user's content looks like it falls within a restricted scope. But, if that's the case, does this make sense? If you are building an add on that the user controls, how are you going to retrieve and store their sensitive data? The script is just running on their account, right?

The concerns Google has expressed seem to make more sense when applied to programs that pull user data and store it, for some reason -- not apps that enable the user to use Google products in custom ways.

[Alan Wells]

Here is a list of the restricted scopes:

https://support.google.com/cloud/answer/9110914#restricted-scopes

As far as I know, basically, all you can do is send an email.  That's it.  Anything else would need a restricted scope.  But you can look at the documentation which should show the scopes needed for every method that you use.

Yes, the code does run under their account, and the authority of whatever permissions they authorized.  But that isn't somehow a deterrent to malicious code.  The only way to know for sure whether your code is safe or not, is for it to be reviewed.  I don't know if the people doing the security assessment will ask for access to your code.  Just because the code doesn't pull data, doesn't mean that it couldn't do something malicious.

Whether the new rules make sense or not depends on the perspective that this issue is seen from.  Google wants to limit their liability, and increase user security.  That's the main goal.  If the new rules restrict app development of apps that would have been distributed to the public, then that's the sacrifice that will be made.  And it will effectively kill off some amount of app development.  Does it make any sense for Google to do that?  Well, it's a matter of priorities.  At the moment the priority is to tighten up access to user information.

All I can do is speculate, but I'm sure that Google feels that they have no other choice.  There are certain things that they must do to deal with the issues of access to user information.  We need to see this from the perspective of Google.  Our perspective affects our understanding.  I don't like it that the new restrictions have greatly reduced app development possibilities, but how I feel isn't going to change the real meaning of the documentation.  If you want your Google app to do anything more than send an email, then you better have a lot of money in the bank to spend on the security assessment.  That's all there is to understand.