New Installs of UNVERIFIED Apps will be Blocked in domains starting July 8, 2019

[Alan Wells]

New Installs of UNVERIFIED third-party Apps will be Blocked in domains starting July 8, 2019

Apps using sensitive or restricted scopes must be verified through the Verification Process in order to avoid certain restrictions.  This is a new restriction starting July 8, 2019.

Google cares about security and privacy, and this is why actions are being taken to protect general access to user data.

If your app is verified, then this will not affect you.  This security policy is specific to third-party apps being installed in domains (Eg. GSuite).  What is NOT a third party app?  An app inside of GSuite isn't a third-party app.

What is the difference between this new policy, and the existing requirements for apps using sensitive and restricted scopes?  Technically, the existing policy governs apps accessing user data for non-enterprise accounts.  This new policy affects domains.  (enterprise accounts, Eg. GSuite)

Anyone who has already removed sensitive or restricted scopes from their publicly published app and/or been approved through the OAuth API Verification process, doesn't need to do anything.

Even though this new policy is specific to enterprise accounts, most developers who wanted their app published to the GSuite Marketplace, have probably already taken action.  So, in that sense, the new policy really has no new implications for those developers.

I am not an official source of information on this topic.  This post is my personal understanding of the information that is publicly available.

[Romain Vialard]

If I understood well, this means that if a developer / app creator has chosen not to do anything (eg because he doesn't want to pay for the security review or simply doesn't want to spend time on this), gmail.com users won't be able to install his app after a certain date (I guess near July 8) but G Suite domains could decide to whitelist the app and continue to use it, even if it hasn't been verified by Google (and this whitelisting needs to be done manually by an admin).

[Alan Wells]

Good point.  The official information states that domains are given a choice to "trust" (Whitelist) any third-party apps.  The implication of the domain administrator whitelisting your app, is that the third-party app is thereby not required to be verified by Google.  So, for example, if you are a developer who wanted to provide an app that uses restricted scopes, to an organization, but didn't want to pay for the cost to go through the security assessment, then the developer could tell the client to whitelist your app.  However, I'm not sure how the developer would distribute that unverified app.  If the app was meant for one particular domain (organization) then how would the developer prevent users from outside of the target domain from installing it from the GSuite Marketplace?

[Steve Webster]

This appears to be a distribution with liability concerns. Since Google is providing a store to make the installation easy, they have liability and reputation to consider. Therefore, it makes sense that they perform this due diligence. 

In theory, with legal counsel, we should be able to skip the Google store and its installation, by advertising publicly, but selling the add-on or web app source code directly and we, the developer, assist with its internal domain publication. The agreement will state the organization does not own the code, but is being licensed that allows us as developers to keep selling the same software.

I'm planning to explore this more deeply so my SW gApps LLC company can assist developers and their software products in this way. For example, my company could perform the installation on behalf of the developer and charge their customer for the installation service -- no cost or time on the developer.

As I mentioned in another post, it may be possible to have an add-on or  web app, with 2 versions: 1) without restricted scopes, 2) with restricted scopes. The #1 would inform the user that an advance version is available (#2 version) for G Suite domains (then you would provide the source code, and assist with installation). For #2, if they choose to update the code, then a decision is needed if the developer wants to provide support for modifications.

Kind Regards,

Steve Webster

SW gApps LLC, 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

--
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/5d4343e3-8062-417d-8697-d275d9846f32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dimu Designs]

In theory, with legal counsel, we should be able to skip the Google store and its installation, by advertising publicly, but selling the add-on or web app source code directly and we, the developer, assist with its internal domain publication. The agreement will state the organization does not own the code, but is being licensed that allows us as developers to keep selling the same software.

This is precisely the approach I've been leaning towards. Problem is, even with a license agreement in place, once an end-user has direct access to source code there is little one can do to prevent piracy,