A Privacy Policy for Google's API Services

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.

If you are a developer or owner of an application that uses Google API Services, it is important that you construct your Privacy Policy according to Google's standards as laid out in its API Services User Data Policy.

The Privacy Policy you include is so important because the Google API Services allow you to access Google user data under certain conditions, and protecting this data is a top priority.

In this article, we will discuss and provide examples of:

• How to accurately represent you and your application to your users
• How to describe to your users the security of your application
• How to comply with COPPA rules which concern children's online privacy
• How to handle restricted scopes, such as email data
• Where and how to display your policy

This will help simplify Google's API Services User Data Policy and make it easier for you to write your own Privacy Policy.

Representing Yourself and Your App

It's very important to Google for you to be honest and transparent about what you and your app are doing with your users' data. Part of this assurance involves being up front about who you are in the first place. Not only that, you must be specific about what data you are requesting. Some of this should be covered by the notifications that are a part of your app, but all of this will need to be acknowledged in your Privacy Policy as well.

Here's where Google sets out some requirements in its :

To summarize, your user needs to know:

• Who is requesting their data
• What data is specifically being requested
• Why the data has been requested

A great example of a Privacy Policy addressing Google's requirements is the one provided by Edison Software for its Mail app. Edison describes its app in a way that will communicate clearly and effectively with users what they can expect. You can see a clearly stated purpose of the app, and a brief description of how it works:

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:

• Don't lie about what data you collect or why
• Don't lie about the operating environment
• Don't use undocumented APIs unless you have permission
• Don't lie about who manages your application

The undocumented APIs rule is worth mentioning because it may be a good idea to list what other applications you rely on in your Privacy Policy. This is a good way to be fully transparent about who you are working with.

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.

Inform Users of Your Security Precautions

Another important feature of your Privacy Policy should be a description of your application security. In its User Data Policy, Google urges you to maintain your app security:

This section, though small, is very important, and is a good thing to note in your Privacy Policy. Take this passage for example, where the company describes the various ways it secures the user's data, involving encryption, and cyber security, but also "administrative [...] safeguards.":

Although you don't need to go into extreme detail, discussing your security measures is a good way to maintain transparency for your users.

Special Considerations for Minors

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:

• If your app is directed primarily at children, it should not use Google Sign-In or any other service that requires an account.
• If your app is directed at a mixed audience, it cannot require an account, but it can offer the use of one as an optional feature.

Whichever approach you take to the COPPA rules and the direction of your app, be sure to mention the approach in your Privacy Policy.

Below is an example of an app's Privacy Policy that is not directed at children. Edison does a good job of stating its policy regarding minors very clearly and noting the consequences if the rules are broken. The company prioritizes obedience with the law and states that it will delete the data in question:

Let's look at another example of a Privacy Policy for an app with a mixed audience.

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.

Restricted Scopes: How to Handle User Email Data

If your app has anything to do with email, you may need to take extra precautions with how you handle that data and how you write your Privacy Policy.

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:

• Email clients
• Automatic email backups
• Productivity enhancements for email
• Reporting services using email info for the benefit of the user

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.

Restricted Scope Data is Only For Prominent, User-Facing Features

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.

In terms of writing your Privacy Policy, much of this comes down to clearly identifying your app, who manages it, and what its intended use is, as discussed above.

Restricted Scope Data Transfer Rules

This data can only be transferred if:

• The transfer of data is necessary for prominent, user-facing features
• It is necessary to comply with the law
• It is part of a merger or sale of assets

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.

Since providing notice to users is required, it is a good idea to go ahead and mention these things in your own Privacy Policy to properly forewarn users of how their data can be transferred.

Here's how Edison discusses its legal compliance in its Privacy Policy:

Don't Use Restricted Scope Data for Advertising

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.

Allowing Humans to Read the Data is Heavily Restricted

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:

• You have the user's permission for specific messages
• Security purposes
• Legal compliance

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:

• Use must be "limited to internal operations"
• Data includes derivations and must be aggregated and anonymized

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.

As you can see, the rules on using Restricted Scope data are very firm. In your Privacy Policy, you should be sure to mention if your app uses any of this data at all and be clear on how it works.

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:

Where to Display Your Privacy Policy

Once you have written your Privacy Policy, you must also take special care to make it available to your users in the right place and time. Many applications have a link to the Privacy Policy in some corner of its website, but there are a couple other times when you are required to link to it:

• At the moment users will connect their Google data to your app
• Whenever changes are made to your Privacy Policy

These two things are part of Google's requirement that your Privacy Policy be "easily accessible."

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 you can see that the Edison app links its Privacy Policy and Terms of Service right from the start at its sign-in screen:

This may be related to your OAuth configuration, which Google says must include a link to your own Privacy Policy

Whenever changes are made to your Privacy Policy, you may choose to notify the user through the app, but another common way to do so is to send an email to the associated account. Here is an example of a notification email from Asana:

Notice of changes to your Privacy Policy is also a good thing to mention within the policy itself. You can mention that changes may happen, as well as how you will go about notifying users of them.

Here's an example from Edison showing how this information can be included:

Summary of Privacy Policy Contents for Google API Services

As you can see, Google's requirements for your Privacy Policy are not far off from what you should be providing for your app and your end users anyway. Just be sure to take care of the following details and you'll be alright with Google, too:

• Read Google's API Services User Data Policy carefully
• Accurately represent who manages your app and who you partner with
• Be clear about what your app does and how it uses the user's information
• Note that deceptive use of Google API Services is prohibited
• Give a clear description of your security measures
• Take special consideration for minors to comply with COPPA laws
• Obey the Google User Data Policy when it comes to email data:
• Understand what kind of apps can use this data
• Only use the data for prominent, user-facing features
• Don't use the data for ads
• For the most part, don't let humans read the data
• Display your Privacy Policy when:
• A user first signs up to share their Google information
• Whenever you make a change to your policy