My website is a service site, it is separated with Parent company website
I want to use GG calendar API, so i access to https://console.cloud.google.com/apis to set required link.
But after that, i received below email.
I did not create a privacy policy page (because it's involved to with Parent company website).
Can i use privacy policy page on Parent companies'website to reference?
Please note that Google API Service:User Data Policy requires the following:
Your Privacy policy must be visible to users, hosted within the domain of your website, and linked to the OAuth Consent Screen on APIs & Services
on Google Cloud Console.
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.
Please make appropriate changes to the privacy policy and/or your app and reply back to us to move forward with the approval process.
When you set up the OAuth 2.0 consent screen for your app, it will look something similar to this:
If you look closely, the 4th element is represented by the app's privacy policy.
Therefore, if you have the necessary access and permissions in order to use them for your own application, it shouldn't be a problem in this sense.
Moreover, since you mentioned you are making use of the Calendar API, you might want to check the Sensitive and restricted scopes of this article here.
Reference
OAuth API verification FAQs.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
In my IOS application i am using google analytics, is it necessary to tell the app users that we using google analytics.
Is it necessary to show the google analytics primary policy in App.
Please help me.
From the App Store Review Guidelines
3.12 Apps should have all included URLs fully functional when you submit it for review, such as support and privacy policy URLs
In section 3.12: It specify that when you submit your application than you must have to include privacy policy URL. That does not mean that you need to show a separate page in application to show privacy policies.
Personally as a mobile user I have never seen privacy policy page of any analytics in application so far.
Also from Google Analytics Protocol SDK Policy you have to take care of following points.
Measurement Protocol / SDK / User ID Policy
All applications using the Measurement Protocol / SDKs / User ID must adhere to the following policies:
You must make sure you have the full rights to use this service, to upload data, and to use it with your Google Analytics account.
You will give your end users proper notice about the implementations and features of Google Analytics you use (e.g. notice about what data you will collect via Google Analytics, and whether this data can be connected to other data you have about the end user). You will either get consent from your end users, or provide them with the opportunity to opt-out from the implementations and features you use.
If you use an SDK to implement any Google Analytics Advertising Features, such as Audience Reporting or Remarketing, you will abide by the Policy for Google Analytics Advertising Features, in addition to the Google Play Developer Program Policies, or any other applicable policy.
You will not upload any data that allows Google to personally identify an individual (such as certain names, Social Security Numbers, email addresses, or any similar data), or data that permanently identifies a particular device (such as a unique device identifier if such an identifier cannot be reset), even in hashed form.
If you upload any data that allows Google to personally identify an individual, your Google Analytics account can be terminated, and you may lose your Google Analytics data.
This is a very high level question, to a high level answer too, so I'm just looking for some pointers on the right direction.
Let's say I want to build a web application to manage a user's Google Contacts. I understand this is done by allowing the user to log in with his Google Account while asking for permissions to manage his Google Contacts. So far so good.
Now I want to expose my own API layer for external browser extensions, Android clients, etc. But while I want the API clients to authenticate against Google, I don't want the applications to have full access to the user's Calendar, as the Secret Token is stored on the server.
So, how is this typically handled? I would like to do it by the book as much as possible, without having to implement a lot of security code.
Btw, while the question is too high level, feel free to point me to technical docs.
Thanks
Limited access to the user's resources can only be guaranteed by limited OAuth scopes:
https://developers.google.com/gdata/docs/auth/oauth#Scope
Some APIs, for instance the Contacts API, only provide a single scope which gives you access to all the data. In cases like this, the user can only choose between giving you access to all his contacts or none of them.
Other APIs expose different OAuth scopes, allowing the developers to only request access to a subset of the user's data. A good example of this is the Google Drive API, which has 5 different scopes for the developer to choose from:
https://developers.google.com/drive/scopes