30 October 2019
Google API Services is a set of Application Programming Interfaces (APIs) that allow your application to interact with and use Google features. Tools such as Gmail, Maps and Login can all be used within your own application as part of these Services.
In this article, we will discuss and provide examples of:
Here's where Google sets out some requirements in its :
To summarize, your user needs to know:
Later in the policy it lists specific information that will be collected, and what each is used for. For example, in the Edison Mail app, there is a specific use for commercial emails, so it is appropriately mentioned in the policy:
At the same time, Google is very clear about what you should avoid in your policy:
To be clear, Google has stated that, "Making false representations about client credentials to Google or Google users is grounds for suspension." It can be assumed that any violation on the above points is grounds for said suspension.
Although you don't need to go into extreme detail, discussing your security measures is a good way to maintain transparency for your users.
If your app is directed at children under the age of thirteen, or is for mixed-audience use (including both those above and below the age of thirteen), you will need to make special mention of the Children's Online Privacy Protection Act (COPPA).
According to Google's User Data Policy, "child-directed apps may use some Google services" but they are careful to state that you are the one responsible for obeying COPPA
That being said, Google does provide two instructions specifically concerning the Google Sign-In API:
To summarize what Google requires here:
Plarium notes that through certain services, it may in fact have users under the age of thirteen. The policy goes on to state that if this is the case, it will take the necessary precautions to accept only the bare minimum of data for the service to function:
Clauses and statements like this show that you're aware of privacy laws regarding children and are making efforts to keep the data of minors secure.
As of January 15, 2019, Google has added a term to its User Data Policy called a Restricted Scope. A Restricted Scope is an area of data that has extra rules about how that data can be handled. For now, the only data that falls into the Restricted Scope category is anything from an email, or anything related to an email mailbox address.
It is easy to understand why Google has added these extra rules for accessing email data. The contents of an email message can be very personal. There have also been plenty of breaches in security when it comes to emails and email servers. Some apps have even found themselves in hot water for the way they have handled user's email data.
To start, Google only permits certain kinds of applications to access this Restricted Scope data:
If your app doesn't fall into one of the above categories, then it has no business requesting email data from a user:
The way you handle the Restricted Scope data is tightly controlled by Google. It has multiple requirements for what your app can do with this data and who can see it:
We'll go through each of these requirements below.
The features must be prominent in the sense that the app needs to be primarily focused on the use of this data. It must be made clear from the beginning that this app uses email data, and it is not some peripheral, extra category of data for the app to use.
The features must also be user-facing, meaning you cannot simply scan through this email data for some other purpose than giving value back to the same user who gave you the data.
This data can only be transferred if:
This section presumably exists because of the danger of selling this private email data, or providing it as a service to people other than the user providing it. The first point is a repetition of the rule from above in that the transfer of data must be for the service of the end user, and must be clearly stated and part of the main purpose of your app.
The second two points are concessions to the fact that sometimes a legal investigation may require you to provide data as evidence. Also, in the event that your company is bought, this "transfer" of data is still considered acceptable. Note that any transfer of this kind must be accompanied with a "notice to users" as per the User Data Policy.
This requirement is mentioned briefly, but it's very clear: use of any email or mailbox data for the use of advertising or targeting is strictly forbidden by Google.
According to the User Data Policy, it should be assumed that no one should be reading private email data except for the person it belongs to. Though this seems like a hard and fast rule, there are actually a few reasons email data could still be read:
These echo the points above, but there is one more way the data can be used that needs to be highlighted:
The highlighted portion is a bit complicated, so let's break it down:
Aggregated means that you cannot look at a single user's data, or a single email, but you can look at a large set of data, over a period of time for example. Anonymized means that all personal information must be removed from this data.
Here's another example from Edison, which states that the data is both aggregated and anonymized. This can be assuring to users, and similar language should be used in your Policy:
You must assume that your user will want to review your policy at the moment they must decide to connect to their google account.
Here's an example from Edison showing how this information can be included:
This article is not a substitute for professional legal advice. This article does not create an attorney-client relationship, nor is it a solicitation to offer legal advice.