Project Strobe: Protecting your data, improving our third-party APIs, and sunsetting consumer Google+

Many third-party apps, services and websites build on top of our various services to improve everyone’s phones, working life, and online experience. We strongly support this active ecosystem. But increasingly, its success depends on users knowing that their data is secure, and on developers having clear rules of the road.

Over the years we’ve continually strengthened our controls and policies in response to regular internal reviews, user feedback and evolving expectations about data privacy and security.

At the beginning of this year, we started an effort called Project Strobe—a root-and-branch review of third-party developer access to Google account and Android device data and of our philosophy around apps’ data access. This project looked at the operation of our privacy controls, platforms where users were not engaging with our APIs because of concerns around data privacy, areas where developers may have been granted overly broad access, and other areas in which our policies should be tightened.  

We’re announcing the first four findings and actions from this review today.

Finding 1: There are significant challenges in creating and maintaining a successful Google+ product that meets consumers’ expectations.

Action 1: We are shutting down Google+ for consumers.

Over the years we’ve received feedback that people want to better understand how to control the data they choose to share with apps on Google+. So as part of Project Strobe, one of our first priorities was to closely review all the APIs associated with Google+.  

This review crystallized what we’ve known for a while: that while our engineering teams have put a lot of effort and dedication into building Google+ over the years, it has not achieved broad consumer or developer adoption, and has seen limited user interaction with apps. The consumer version of Google+ currently has low usage and engagement: 90 percent of Google+ user sessions are less than five seconds.

Our review showed that our Google+ APIs, and the associated controls for consumers, are challenging to develop and maintain. Underlining this, as part of our Project Strobe audit, we discovered a bug in one of the Google+ People APIs:

• Users can grant access to their Profile data, and the public Profile information of their friends, to Google+ apps, via the API.

• The bug meant that apps also had access to Profile fields that were shared with the user, but not marked as public.  

• This data is limited to static, optional Google+ Profile fields including name, email address, occupation, gender and age. (See the full list on our developer site.) It does not include any other data you may have posted or connected to Google+ or any other service, like Google+ posts, messages, Google account data, phone numbers or G Suite content.

• We discovered and immediately patched this bug in March 2018. We believe it occurred after launch as a result of the API’s interaction with a subsequent Google+ code change.

• We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug. However, we ran a detailed analysis over the two weeks prior to patching the bug, and from that analysis, the Profiles of up to 500,000 Google+ accounts were potentially affected. Our analysis showed that up to 438 applications may have used this API.

• We found no evidence that any developer was aware of this bug, or abusing the API, and we found no evidence that any Profile data was misused.

Every year, we send millions of notifications to users about privacy and security bugs and issues. Whenever user data may have been affected, we go beyond our legal requirements and apply several criteria focused on our users in determining whether to provide notice.

Our Privacy & Data Protection Office reviewed this issue, looking at the type of data involved, whether we could accurately identify the users to inform, whether there was any evidence of misuse, and whether there were any actions a developer or user could take in response. None of these thresholds were met in this instance.

The review did highlight the significant challenges in creating and maintaining a successful Google+ that meets consumers’ expectations. Given these challenges and the very low usage of the consumer version of Google+, we decided to sunset the consumer version of Google+.

To give people a full opportunity to transition, we will implement this wind-down over a 10-month period, slated for completion by the end of next August. Over the coming months, we will provide consumers with additional information, including ways they can download and migrate their data.

At the same time, we have many enterprise customers who are finding great value in using Google+ within their companies. Our review showed that Google+ is better suited as an enterprise product where co-workers can engage in internal discussions on a secure corporate social network. Enterprise customers can set common access rules, and use central controls, for their entire organization. We’ve decided to focus on our enterprise efforts and will be launching new features purpose-built for businesses. We will share more information in the coming days.  

Finding 2: People want fine-grained controls over the data they share with apps.

Action 2: We are launching more granular Google Account permissions that will show in individual dialog boxes.

When an app prompts you for access to your Google account data, we always require that you see what data it has asked for, and you must grant it explicit permission.

Going forward, consumers will get more fine-grained control over what account data they choose to share with each app. Instead of seeing all requested permissions in a single screen, apps will have to show you each requested permission, one at a time, within its own dialog box.  For example, if a developer requests access to both calendar entries and Drive documents, you will be able to choose to share one but not the other. Developers can read more on the Google Developer Blog.

This is what the process looks like today when an app requests access to any data in your consumer Google account (you've always been able to choose whether to grant that permission request):

This is what it will look like:

Finding 3: When users grant apps access to their Gmail, they do so with certain use cases in mind.   

Action 3: We are limiting the types of use cases that are permitted.

We are updating our User Data Policy for the consumer Gmail API to limit the apps that may seek permission to access your consumer Gmail data. Only apps directly enhancing email functionality—such as email clients, email backup services and productivity services (e.g., CRM and mail merge services)—will be authorized to access this data. Moreover, these apps will need to agree to new rules on handling Gmail data and will be subject to security assessments. Developers can read more details on the Gmail Developer Blog. (As always, G Suite administrators are in control of their users’ apps.)

You can always review and control which apps have access to your Google account data (including Gmail) within our Security Checkup tool.

Finding 4: When users grant SMS, Contacts and Phone permissions to Android apps, they do so with certain use cases in mind.   

Action 4: We are limiting apps’ ability to receive Call Log and SMS permissions on Android devices, and are no longer making contact interaction data available via the Android Contacts API.

Some Android apps ask for permission to access a user’s phone (including call logs) and SMS data. Going forward, Google Play will limit which apps are allowed to ask for these permissions.  Only an app that you’ve selected as your default app for making calls or text messages will be able to make these requests. (There are some exceptions—e.g., voicemail and backup apps.) Developers can find more details in the Google Play Developer Policy Center and in the Help Center.

Additionally, as part of the Android Contacts permission, we had provided basic interaction data—so, for example, a messaging app could show you your most recent contacts. We will remove access to contact interaction data from the Android Contacts API within the next few months.

In the coming months, we’ll roll out additional controls and update policies across more of our APIs. As we do so, we’ll work with our developer partners to give them appropriate time to adjust and update their apps and services.

Our goal is to support a wide range of useful apps, while ensuring that everyone is confident that their data is secure. By giving developers more explicit rules of the road, and helping users control your data, we can ensure that we keep doing just that.