TL;DR: Does storing instagram user access token counts as "storing user personal data" and why Privacy Policy url is a required field?
-I have an app in instagram.
-It's used to make api calls to get other users' public data (namely their posts to show on sites in "instagram widget").
-My app will always have only one user (me).
-My site doesn't store any user data, except for: one user auth_token (to make api calls) and cache of api responses (other users' public posts).
To get my app out of sandbox I have to fill "Privacy Policy url". What am I supposed to write in my Privacy Policy?
Will "My app/site stores no non-public user data" be enough and true (I still store my own token) in my case?
If the answer is "yes" to my second question, then why is privacy policy url is a required field? As far as I know privacy policy is needed only in case of actually storing private user data.
The Privacy Policy URL is required by the Instagram Platform Policy so that you can disclose:
What information you collect, and
How you will use that information
If you don't collect and use personal data from users, inform users of this practice in your Privacy Policy.
Your Privacy Policy must be used to disclose what kind of data you collect and how you use it. Example of a Privacy Policy that does not collect data from users from Ecquire:
For example, Lightwidget Privacy Policy discloses what type of data they collect through Instagram API:
Related
I'm writing an Apps Script Add-on for Google Sheets. There are duplicate fields on the OAuth consent screen and the Google Workspace Marketplace SDK Store Listing screen. These are "Terms of Service" and "Privacy Policy" URLs.
Do they need to be filled out in both places? It appears that they are optional on the OAuth consent screen since they do not have an asterisk next to them. Is that true?
If they do need to be entered in both places, do they need to match? On the Store Listing, I used URLs pointing to a shared (with everyone) Google Doc. But on the OAuth screen, it appears they are requiring the documents to be on my website, since they are under the App domain section.
I've seen a working tutorial from a few years ago where a shared Google doc was used for the store listing. But has that policy changed and now do they have to be on my website?
If you are planning to make the OAuth Consent Screen for External users you should add the Terms and Conditions as well the Privacy Policy fields, otherwise it's very unlikely that it will be approved in the verification process, if it will be for Internal users you might try to keep these fields empty as in this case the OAuth Consent Screen will not be verified.
Regarding if these fields should match the fields on the Marketplace listing, it will be weird if they doesn't match. AFAIK Google doesn't review exhaustively the Marketplace listings but if users complain the might review it. They might contact you giving some recommendations, disable the Marketplace listing, etc.
If you want to use a Google Editor files for your TOS and Policy files, you might embed them in a Google Site with a custom URL.
Resources
Use a custom domain for your site
I found the following information about the "Privacy Policy" URLs:
Make sure that your app's Privacy Policy meets the following requirements:
The Privacy Policy must be visible to users, hosted within the domain of your website, and linked from the OAuth consent screen on the Google API Console.
The Privacy Policy must 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 disclosed in your published Privacy Policy.
Based on the first requirement, I will say they need to be the same URL under the Google Workspace Marketplace SDK Store Listing and the OAuth consent screen in the project.
However, there is no such restriction for the Terms of Service inside Google Documentation.
Reference:
OAuth API verification FAQs.
Getting prepared for verification
I am in the process of implementing an OAuth2 flow for a sensitive scope in my chrome extension. In order to remove the 'unverified app' warning in the OAuth2 popup I must verify the app in the Google Cloud Console.
The verification form requires 'Authorized domains' though, and it does not accept a chrome extension URL of the form 'chrome-extension://', neither does it accept a URL of the form '.chromiumapp.org'.
Is it possible to provide another domain I own as the authorized domain, and still initiate an OAuth2 flow from the chrome extension using chrome.identity.getAuthToken({interactive: true}...?
I think you need to read though the documentation on application verification
The very first one mentions that your domain must be authorized and verified in search console. The files must also be hosted on your verified registered domain.
It clearly states that
Links to the Google Play Store or Facebook are not considered valid application homepages.
The only requirements are that
Domain is registered in Search console.
Home page listed in the auth screen is relevant to your app.
So i don't see any reason you can't put it on one of your other domains. Just make sure that it qualifies for this clear its relevance to the app you’re verifying
Relevant points in the documentation.
Verify ownership of your project’s authorized domains using the Search Console. Use an account that is either a Project Owner or a Project Editor of your Cloud Console project.
Then the section about
Make sure that your homepage meets the following requirements:
Your homepage must be publicly accessible, and not behind a sign-in page.
Your homepage must make clear its relevance to the app you’re verifying.
Your homepage must be accurate, inclusive, and easily accessible to all users.
Links to the Google Play Store or Facebook are not considered valid application homepages.
There is also the Privacy posily
Make sure that your app's Privacy Policy meets the following requirements:
The Privacy Policy must be visible to users, hosted within the domain of your website, and linked from the OAuth consent screen on the Google API Console.
The Privacy Policy must 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 disclosed in your published Privacy Policy.
I have a video that goes though the application verification process. Google OAuth. What you need to know about verification in 2021.
I have a list of 500 Instagram usernames in a spreadsheet. I want to extract the bio of all 500 accounts and put those in a spreadsheet. I am using Google Apps Scripting. I don't know how to get access to instagram's api where I can access the bio. I've look at other websites where I can pull up the Instagram accounts bio (like http://www.pikore.com/humordailyy) but those still don't have API. Is there a way I can get API? If not, is there a way I can crawl through the HTML or something to get the bio? Thank you.
As discussed in documentation, Instagram API requires authentication - specifically requests made on behalf of a user. Authenticated requests require an access_token which you could receive by doing the following:
Direct the user to our authorization url.
If the user is not logged in, they will be asked to log in.
The user will be asked if they would like to grant your application access to her Instagram data.
The server will redirect the user in one of two ways that you choose:
Server-side flow
Implicit flow: This method is less secure, but allows applications without any server component to receive an access_token.
For Implicit Authentication Flow which is for applications without any server component, simply follow these steps:
Step One: Direct your user to our authorization URL
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
At this point, Instagram present the user with a login screen and then a confirmation screen where they grant your app’s access to their Instagram data. Please note that you may provide an optional scope parameter to request additional permissions outside of the “basic” permissions scope.
Step Two: Receive the access_token via the URL fragment
Once the user has authenticated and then authorized your application, Instagram redirects them to your redirect_uri with the access_token in the url fragment. It will look like this:
http://your-redirect-uri#access_token=ACCESS-TOKEN
Simply grab the access_token off the URL fragment and you’re good to go. If the user chooses not to authorize your application, you’ll receive the same error response as in the explicit flow.
error: access_denied
error_reason: user_denied
error_description: The user denied your request
I have read all the information and guidance and watched the videos on
Developers Google Drive (sorry, I do not have enough "reputation points" to include all the links that would be relevant here).
as well as Google Privacy Policies.
In the list of Google Drive auth scopes, which ones are covered by the permissions request to users for the app to "view basic account information"?
https://developers.google.com/drive/scopes
I can only find examples, rather than a complete list.
I am also trying to understand how this relates to the Privacy Policy, ie. whether this "basic account information" is "Personal Information" or "Google Account" information.
http://www.google.com/intl/en-GB/policies/privacy/key-terms/#toc-terms-personal-info
Personal information
This is information which you provide to us which personally
identifies you, such as your name, email address or billing
information, or other data which can be reasonably linked to such
information by Google.
Google Account
You may access some of our services by signing up for a Google Account
and providing us with some personal information (typically, your name,
email address and a password). This account information will be used
to authenticate you when you access Google services and protect your
account from unauthorised access by others. You can edit or terminate
your account at any time through your Google Account settings.
I have read elsewhere that the "basic account information" is not actually "viewed", ie. visible to, the app developer but is instead transmitted in encrypted form for use by the app.
(I am not an app developer - this just seems to be the only place where there are Google staff watching and answering these sorts of questions).
User's profile and email is available if you grant access for the following scopes:
profile: https://www.googleapis.com/auth/userinfo.profile
email: https://www.googleapis.com/auth/userinfo.email
Profile stands for a Google Account and contains user's ID, name, photo, URL, country, language, timezone, and birthdate.
For the example get request:
https://api.twitter.com/1/statuses/user_timeline.json?include_entities=true&include_rts=true&screen_name=twitterapi&count=2
As documented here:
https://developer.twitter.com/en/docs/tweets/timelines/api-reference/get-statuses-user_timeline.html
I have an oauth user token and user token secret, plus my app credentials...
The docs state that authentication is supported, but how do I include it in the get request for screen names that are not publicly accessible?
If I understand your question right, you want to be able to get the tweets from a third-party user with the OAuth token and secrets belonging to a user on your site. The tweets from the third-party user are not publicly accessible, but your user has access rights to them. Is this right?
Generally if you want to access private ressources on behalf of your user, you have to sign the request with the OAuth token and your application credentials. Then Twitter can check, which user is signed in on your site and if the user gave your site access rights.
That signature is sent within the header of your GET request in a format like this:
Authorization:
OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog",
oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg",
oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318622958",
oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb",
oauth_version="1.0"
There is also documentation from Twitter on how to calculate the signature.