I am using the new Google Action development environment. I would like to request a user's phone number and also give the user the option to save it for future interactions. This is so I can send text messages and make phone calls for them. Is there a way for me to do this that is compliant with the T&Cs for Google Assistant actions?
Please check with your lawyer, as every country has its regulations. For more info, consult this guide. https://developers.google.com/assistant/conversational/storage-user
We are trying to implement a google home action and it needs access to customer's email.
I can see the documentation on this page mentioned we need to have explicit consent from the user. https://developers.google.com/actions/policies/general-policies
Just wondering what sort of consent do we need to implement in order to get customer's email?
Can I please get a sample consent?
Thanks,
Yihan
You will need to implement Account Linking in some form. If you have an existing service that gets their email address, you need to link the Action to the account they have established on your service already.
If you don't have an existing service, you can take advantage of Google Sign In for Assistant, which is a streamlined way you can get permission to access their Google Profile and, if they have one, their registered email address.
For my own gmail account, I have multiple email addresses associated with it. For example, I have an email address from my university that is associated with my gmail, and I can send emails from my gmail as if they are coming from my university email address.
I'm reading up on the Google APIs, and I see that I can get a user's gmail address, but can I also get any other email address that is associated with their gmail account?
When a user logs in to my site, I'd like to present them with a list of the gmail-associated email addresses and let them select the one they would like to use.
EDIT: Thanks everyone for the answers, but I don't think any of them answers the question. I've been playing with Google's OAuth playground. It is strange that I can get lots of very personal information (a list of a user's contacts and even received emails) but I can't get the user's alternative email addresses.
Your description is a little vague. Are you talking about send-as alias accounts or alternate email accounts?
Send-as Alias
Either way, you can interact with the send-as accounts here: Manage Send-as Alias
Alternate Emails via Admin SDK
As for alternate email accounts, they can be accessed via:
Admin SDK: https://developers.google.com/admin-sdk/directory/v1/guides/manage-user-aliases?hl=en
Google Apps Script: https://developers.google.com/apps-script/reference/gmail/gmail-app#getAliases()
Additional info here on how the accounts work.
Email addresses associated with your account
Alternate email addresses and other Google products
Connect other email accounts to your Google Account
Federated Login
Also, I'm not exactly sure how you are trying to incorporate this functionality into your site but another area I recommend checking out is Federated Login for Google Account Users. This might also provide you with the functionality you seek.
Using federated login (also known as federated identity), your website
or application can allow visitors to sign in using their Google user
accounts. Federated login frees users from having to set up separate
login accounts for different websites, and frees you from the task of
implementing login authentication measures.
It has been a while since the question was asked. You can use the Google People API to get a user's primary email address and aliases. Here's the documentation. The scope you need to use is: https://www.googleapis.com/auth/user.addresses.read
This will return all the email addresses for the user and also tell you which is the primary one.
If you use OAuth to have your users sign-in with their Google accounts (with or without G+) the user will be prompted (by Google) to select which of their accounts they wish to authorize your application to use:
https://developers.google.com/accounts/docs/OAuth2Login
So to directly answer your question, I'm not aware of an API to return that list of users - however you shouldn't need to, Google will take care of this before returning to your application.
If your user is already logged in, and you wish to give them the ability to change the Google account they are using, I believe it is possible to prompt them again to select the account they are interested in (search for select_account on the link above).
This is possible. However, this has changed since Google announced the deprecation of their Google+ People API, which a lot of folks used to get all the email addresses for a user. The current most voted answer now goes to a 404.
Google Plus People API Replacement
Google has replaced the Google Plus People API /plus/v1/people/me with https://developers.google.com/people/ and you’ll want to use the https://www.googleapis.com/auth/user.emails.read profile scope as discussed here as a replacement. The schema is different, so you'll need to change your mapping as well.
If your app already used the following scopes from the old /plus/v1/people/me your user will not have to re-consent when you switch to the new API:
email
profile
https://www.googleapis.com/auth/plus.login
https://www.googleapis.com/auth/plus.me
https://www.googleapis.com/auth/plus.profile.agerange.read
https://www.googleapis.com/auth/plus.profile.emails.read
https://www.googleapis.com/auth/plus.profile.language.read
My app is a sync solution (imagine dropbox).
The user needs to sign in to access the app's features, and if he does not have any account already created, he can sign up.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
but Apple has rejected this app saying:
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
We found that your app requires customers to register with personal information to access non-account-based features, which is not in compliance with the App Store Review Guidelines.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. Additionally, the requested information must be relevant to the features.
Although guideline 11.6 of the App Store Review Guidelines requires an application to make subscription content available to all the iOS devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be made optional.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Please help me solve this. Many apps like dropbox/facebook require login.
I don't get the exact reason why they rejected my app.
Also, please guide about the in app purchase, why registering cannot be mandatory
Asked App Store Review people for clarification on their rejection.
They accepted it. and the app got approved :D
Its on Appstore now :)
I also Faced this kind of Problem and my app also Rejected due to this.And Again I Changed my App flow Like User Registration will be Optional. User can See all the Feature of the app with out Registration by skipping this step.If he want to do something user-specific then you can ask to register such as : (user like,comment,photo upload etc) or else he can use the contents and features which are public.
in Case of in-app Purchase You can Prompt user that if He will Register with your app he can able to use this Content in his all devices.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Apple does not allow apps that require you to share person information to work, like an e-mail address.
You options are, remove the need for an e-mail address or remove account creation form you app and move it to a website.
It also states that you app is asking to create an account to access the full app and even needs the account or acces features that do not require the user to have an account. You can make those features available with out the account creating you might be able to get thru the review.
The reason apps like Facebook and Dropbox got thru the review proces is because they don't have a register option which is in app only. They redirect to a website.
I recently spoke to an Apple Rep over the phone in regards to an app of mine that was also accused of violating clause 17.2.
I explained to him that the email would be used for password recovery, monitoring transactions within the marketplace, and managing any inappropriate behavior (such as users uploading offensive or copyrighted content). The rep responded, "Sir, the clause states 'Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected'. I cannot allow you to require your users to submit their emails if its not account-based". He did not seem to understand that the emails are account-based for the very sole purpose of security.
I did mention to him that Instagram and Facebook alike require logins at startup. He simply replied, "Yes but those apps are entirely account-based."
Honestly, I felt he was blindly following Apple's Guidelines ("Because that's what it says we must strictly follow!"). He had little understanding of how social networking apps operate, and even less understanding of the law (specifically the DMCA - on a separate issue). Explaining to them how all that works proves to be futile; they wont budge because they are asked to follow Apple's BROAD Clauses as strictly as they do.
My conclusion: I had to compromise the app's user flow such that the app's registration page can be skipped, and all other functions within its marketplace were locked to non-registered users. It makes no sense.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user.
It seems to me that the point is that you are asking the user to provide his email address as a step towards the creation of a user account. This is different from what dropbox and other apps do (i.e, you provide your credentials for your dropbox account, which is different from your email address, although it can be the same).
You may either remove altogether email verification, or you could postpone it to a later point when you have made clear to the user that this is required to access private information.
I got the same thing last week and this is Apple's reply:
As for the 17.2 issue, a nickname, avatar, or sharing are not inherent or specific features of those social networks, and thus, the user should not be required to register with those services, or provide you with access to their social network accounts. The user should not be prevented from using your app and service if they do not provide this information.
Instead, it would be appropriate use your own authentication method and give users the option to create a nickname and upload an avatar, independent from those networks.
Moreover, we realize that these social networks may be very popular. However, the popularity of the social network is not an appropriate reason to force a user who has not, or chose not to register and provide their personal information to those services, before they can use your app.
Therefore, we ask that you to include your own authentication mechanism to allow the user the option to register only with you, creating an account with only the information needed and relevant to your app's features.
Best regards,
App Store Review
So in short, you have to provide custom authentication and not just use Facebook. Although I've seen many Apps who do require you to login with Facebook.
Thanks,
James
It happened same for me, although the first version was approved, the second version was rejected for this reason, I added the Skip button at the landing view.
It's all summarized in the last paragraph. Apparently, your application doesn't inform the user (in a clear way) that registering is for syncing and from their reply, it seems that your application is useless without the Sign Up.
If that's the case, you should be more specific why you need the user to register.
On a side note, I personally don't like the applications/websites that force you to register before you see or try anything. I hope your application isn't the same.
I am working on a project related to both school and work where I would like to combine data from a college entrance application (which includes email address) and Facebook data, even a minimum amount of data, such as number of "friends" or any other public info they've put out there. Am I correct that you can't really programmatically search Facebook by email address? Feel free to make any suggestions.
Thanks
You can search Facebook by email address, you just can't reliably search Facebook by email address.
For instance, you can make this query with a user access token:
https://graph.facebook.com/search?type=user&q=USER#EMAIL.NET&access_token=TOKEN
I've tried this with a few people I know who are on Facebook, where I know their email address, but I am not friends with them. (Mostly my wife's friends).
In my testing, only about 20% of these queries return a Facebook user_id. I'm not sure if they don't have the email I know linked to their user account or if they have their privacy set to restrict their email address.
Once you have their user_id, you can access all their public information at
https://graph.facebook.com/USER_ID
You don't need an access token to get this information.