The Google OAuth Review Process
Picture the scenario: You’ve spent an excessive amount of time getting a mobile app ready for release. You go through the typical Apple review. As part of your app, you also have Google integrations: e.g., Google Sign-in and Google Drive. And thus, you have to switch to production mode with this Google integration. Now the zapper. In the last few months, Google has clamped down on certain integrations. And the process of getting them to sign-off on a production mode review is arcane verging on authoritarian. I’m going to document what I went through in the following for my own catharsis, to possibly help others going through this process, and with luck perhaps Google might streamline their review process to make it less ambiguous and stressful.
1. Initiating the review.
To set the context, I’m talking about the Google review process as triggered from: https://console.developers.google.com/and within a specific project. Here’s what mine looks like after the review:
…
To initiate a verification or review process, you would be pressing “Submit for verification” near the bottom of the page.
2. The first ask: Privacy policy.
The first email I got in response to my submission for verification had the following main content:
To proceed with the verification process, please update your project firebase-sharedimages to comply with our requirements.Privacy PolicyGoogle API Service:User Data Policy requires the following:1. Your Privacy policy must be: 1. Hosted within the domain of your website 2. Accessible from the app’s home page 3. Visible to users 4. Linked to the OAuth consent screen on the GoogleAPI Console2. Your privacy policy and in-product privacy notifications must clearly disclose the manner in which your application accesses, uses, stores, or shares Google user data.3. Your use of Google user data must be limited to the practices explicitly disclosed in your published privacy policy.
I had pretty rudimentary privacy policy text, and not knowing how extensive it should be, I modified it slightly and resubmitted.
This was pretty quickly bounced back to me with:
Please note that Google API Service:User Data Policy requires the following:1. Your Privacy policy must be visible to users, hosted within the domain of your website, and linked to the OAuth consent screen on Google Cloud Console.2. Your privacy policy and in-product privacy notifications must thoroughly disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices explicitly disclosed in your published privacy policy.Your privacy policy url:http://www.spasticmuffin.biz/?page=Neebla&appPage=support#PRIVACY on your OAuth consent page doesn’t comply with the requirements stated above.Please make appropriate changes to the privacy policy and/or your app and reply back to us to move forward with the approval process.
Now I started to get a sense that this process was going to be difficult. I didn’t really know what they were asking. Apparently though my brief privacy policy was not up to the task. Unfortunately, I didn’t find their email very clear on what would make for an acceptable privacy policy. Here are some links I found useful:
https://termsfeed.com/blog/privacy-policy-url-google-sign-in/
https://github.com/WeblateOrg/weblate/issues/2475
https://medium.com/@ali.muzaffar/did-you-get-one-of-these-google-play-developer-policy-violation-emails-6c529ceb082d
https://app-privacy-policy-generator.firebaseapp.com/
In particular, I based the text I used off that generated from that last link.
3. The second ask: The first video request
Well, fortunately, they found that privacy policy acceptable. And you might think that that was going to be the end of the process. But no. There was a hidden next step. Google’s response to my submission of the revised privacy policy was:
To proceed with the approval process, please reply to this email and provide a YouTube link to a demo video, in English, that showcases in detail:1. How to log into your project (ensuring that the URL bar with the client ID is clearly visible)2. How to request an OAuth token (OAuth Consent Screen/Permissions Page)3. How your project's functionality utilizes the requested scopes: o https://www.googleapis.com/auth/driveNote: You don’t need to be personally visible in the demo or narrate the video. Demonstrating the process from the keyboard/screen view is sufficient.You can find more information in the OAuth Application Verification FAQ. If you have additional questions, please respond to this email.
Here is where I had more difficulty. The user-facing part of my project is an iOS app. While I can definitely show them how to log into the app, I had no idea how to ensure “that the URL bar with the client ID is clearly visible”. I’m guessing this was a cut and paste from some document the reviewer was working with that covered all types of sign-in processes including those from web-based clients. The part about “How to request an OAuth token” wasn’t clear to me. While OAuth tokens are definitely used, they are internal to the project and aren’t really suited to a video presentation.
Their third question, retrospectively, was really at the core of the matter. I am using a scope for Google Drive access that’s actually somewhat more than what I strictly want. That’s because Google Drive doesn’t have the exactly scope I want. My app provides self-owned social media. All of a users data are saved in their own cloud storage (e.g., Google Drive), in a specific folder. If the weaker scope https://www.googleapis.com/auth/drive.file is used, and if the user edits a file in their Google Drive, my app can lose permissions to access the file. And this can cause the app to malfunction. I also would have liked to be able to use their https://www.googleapis.com/auth/drive.appdata scope. However, while this provides a sandboxed area for the user’s data, the user actually has no access to that data, which violates a principle I’m trying convey: that of self-ownership of data. So, I’m forced into using a too permissive scope — https://www.googleapis.com/auth/drive. Google Drive developers: I’d really like a scope that (a) sandboxes all of an apps activities to a single folder, and that (b) allows the app permissions to all files/folders in that directory, even those it didn’t create.
Because I was not understanding what the reviewer was wanting, I responded to this email with questions for clarification. Google responded with:
Unfortunately, we do not see the Permissions Page in your demo video or when we test the user login to Gmail within your app.To proceed with the approval process, please reply back to this email and provide a YouTube link with the demo video that showcases the process to log into 1. your project, 2. request OAuth token, and 3. use your project's functionality.Thank you for your patience. Please let us know if you have any questions.
I had provided no demo video at that point, nor had I provided them with an app. So the first sentence made no sense to me. Was this a chatbot? An employee that was underpaid or had very little time? So, I did my best with what information I had and gave them the following video:
https://youtu.be/u-15o-4xWlY
Foreshadowing, note the use of the term “Permissions Page” in the above response from Google. I pretty much disregarded that term in my video presentation because there was so much noise: The rest of the sentence just made no sense. Keep reading though!
4. The third ask: The second video request (and a threat)
Google responded with:
Thank you for your response and for your patience.Thank you for providing the video , but still we are unable to see the permission page for the project number: 751293215012 and scope usage in your application.Please provide an updated youtube video link in which must include the permission page may assist you in doing this, of your project :751293215012 (refer the attached screenshot) , showing how users install your application, grant permissions, and utilize the scopes you are requesting.Please provide the information mentioned above otherwise it may lead to discontinuation of verification process.
(Note that the video link they give above was not mine. I’m guessing it was someone else’s review submission). Now they were emphasizing the term Permission Page. Fortunately, they also attached a screen grab to define what this term means — because, at the time, it meant nothing to me. Here is an example (not Google’s example — one from my own app after I figured out how to find it):
For Google Drive, I believe the critical aspect of the Permissions Page for the Google review is the middle part:
It took me a stupid amount of time to unearth the above Permission Page in the sign in process for my mobile app. Why? Well, I’d been in the development process for so long and it had been so long since I signed in with a new Google account that it just wasn’t familiar to me anymore. I finally realized that in order to see this screen, I had to fully sign out of the app. For example, you can do this at the page: https://myaccount.google.com/permissions?hl=en Then, the next time you sign-in to the app, you will see the Permissions Page. So with many weekend hours consumed, I prepared the final video:
https://youtu.be/5GgwL3ajLQU
This solved the problem. The review process satisfied! I could release my app on the Apple app store!!
5. Conclusion
While I generally applaud Google for working to make user experiences and security better (e.g., my app is asking for a lot of Google Drive permission), the overall developer experience of this process is ambiguous, frustrating and difficult. Hopefully this article can help other developers work through this review process. I also would have slept better without the threat of “discontinuation of verification process” in their near-last email.