GDPR/Data Privacy Concerns regards 3rd Party Add-Ons

[Matthew Hynes]

Hi All,

As data privacy becomes more and more of a concern for companies and in particular those in Europe with the GDPR regulations, it is becoming harder and harder to approve 3rd party apps for use. We as administrators can't guarantee that our data is not being accessed or transferred to the developer. Even with the privacy policy statements provided for each Add-On, these are not strong enough from a legal standpoint.

I proposed this solution a few years ago, but it never received any traction. So I thought I would resurrect it and see if now is the time for it to be adopted.

Basically the idea is simple. When we install an Add-on, give us the option of providing our own GCP project where the code will be executed, rather than on the Developer's GCP instance.

If all execution and data access is happening within our own GCP instance then there is no data privacy concern about data transferring to the Developer.

If you think it's a good idea, please give it a thumbs up on the Google Cloud Community

https://www.googlecloudcommunity.com/gc/Feature-Ideas/Proposal-to-alleviate-GDPR-Data-Privacy-Concerns-regards-3rd/idi-p/413645

[Mani Doraisamy]

Hi Mathew,

This is a great idea. However, running code in your GCP instance will complicate the deployment of new versions of the addon. It will slow down bug fixes and new feature releases. It would suggest you separate the 3 components:

1. Runtime that includes code and transient data (cache/state variables)
2. Configuration data (metadata that determines how the app works for you)
3. Tenant specific data stored in the database (Customer data that affects GDPR)

If your proposal targets the third point i.e. storing tenant specific data in your GCP instance, it might solve GDPR. New versions of  addon might still require datamodel (DDL/Schema) changes and making those changes on your GCP instance is going to be a challenge. But, it might be doable.

thanks,

mani

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/CAHyc7xrZFiJr8X10_iO5YozZyK8cBdm-DkGPDevf4BGE%3D3DPWQ%40mail.gmail.com.

[dimud...@gmail.com]

> We as administrators can't guarantee that our data is not being accessed or transferred to the developer.

Here's how things work from the developer's perspective. All Add-ons go through a verification process. Moreover, if an add-on potentially touches private data, it has to go through a security assessment where the developer has to fork out anywhere from US$10,000 to US$75,000 dollars to have the Add-on code reviewed by a certified 3rd party outside of Google to ensure compliance with data privacy regulations. This has been in place since around 2019, when Google revamped its User Data Privacy policies to fall in line with GDPR, CCPA and other data privacy rules and legislation enacted by territories world over. So I don't think you have to worry about data being transferred to developers.

[Matthew Hynes]

That level of verification is only for apps that access Restricted Scope APIs. 

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/16147804-8e2b-4f13-b8ff-143132703c73n%40googlegroups.com.

[dimud...@gmail.com]

Is not limited to just restricted scopes, here's a quote from the OAuth verification FAQ:

"Every app that requests access to restricted scope Google user’s data and has the ability to access data from or through a third party server is required to go through a security assessment from Google empanelled  security assessors."

[Matthew Hynes]

Yes, I have read the faq (https://support.google.com/cloud/answer/9110914) and I understand that all apps have some verification and the verification process is more detailed and strict depending on the scopes that are being accessed.

Ultimately it still boils down to companies trusting that Google has fulfills this verification process (I have no doubt that it does). There is no direct contractual agreement between the developer and the client.

This may turn out to be ok, but in Europe with GDPR it's all a legal gray area that has yet to be fully decided on, so many companies are shying away.

My proposal to execute developer code on our own GCP instance is an easy way to guarantee that data remains in our control.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/a9a9d776-dcbb-4200-bf27-536516cdb42an%40googlegroups.com.

[Andrew Apell]

This looks like something you should bring up in the next Totally Unscripted episode since it often hosts people from Google.

[Martin Hawksey]

My experience is Google have always shied away from commenting on data protection in the context of Workspace add-ons, in fact going as far as stating no liability https://developers.google.com/apps-script/terms#end_users_using_scripts_or_add-ons

I can see Matthew's point about running code in a domain controlled environment and there are various approaches for a developer to synchronise a central codebase. The flip side of this is as a developer I would be concerned about protecting my intellectual property. For example, if there is a per user or time based subscription there is a chance the domain could default on payment but continue to use the code. For developers the financial benefits of a domain subscription may however make it viable to consider offering a domain deployment. 

A recent development for Chrome Extensions are a set of developer badges https://www.theverge.com/2022/4/20/23034208/google-chrome-extensions-badges-featured-established. I appreciate there is already oauth verification but perhaps there should be an additional layer for Marketplace add-ons where Google can verify the publisher. This could incorporate some basic checks like is there a legal entity, what warranties are provided, for some regions this could include checking if they are a registered data processor etc.  

[Matthew Hynes]

Hi Martin,

All good points. In relation to the Intellectual Property issue, in my mind it is not that the developer code is hosted in the client's gcp project, only that execution happens there. So ideally the code would be encrypted and transferred to the client only at execution and then removed so the client would never be able to access the code directly. Something along those lines.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/aa6caa30-e9da-4187-af06-284722dd549dn%40googlegroups.com.