I don't intend to collect any user data from my Google Assistant app.
So I am in need of a minimal Privacy Policy, but I am unsure of the data collected by Google's Dialogflow, and how I am supposed to mention that in the Privacy Policy.
I am not a lawyer, and asking legal questions on StackOverflow is not terribly wise in general.
However - the Google reviewers are primarily concerned with what you are specifically doing and collecting. Users have already agreed to Google accessing their information.
You can reference Google's API Terms of Service (which you agreed to when you used Dialogflow) which describes how they will use user information.
Related
It's more of a general question, but What is the recommended way to protect APIs used in SIGN UP processes? Let's say there is these public APIs (No user credential required, only API KEYs);
find_person(Data about the person trying to sign up), returns if a person already exists or not (no user credentials required AND no sensitive information returned).
create_person(Data about the person trying to sign up), creates this person into the system (no user credentials required)
Can we have "anonymous" users that have a short-lived JWT token? For example, how can the SPA Web application or Mobile application securely obtain a "per-session" anonymous user?
Are Captchas actually helpful in this scenario?
We are already considering:
API KEY for every application (not per session)
Rate limiting
DDoS services to protect the APIs
Any help would be much appreciated.
Thanks
Short Live JWT Tokens
Can we have "anonymous" users that have a short-lived JWT token?
Yes, you can and its recommend that you even do it for logged users. See the Auth0 blog What Are Refresh Tokens and How to Use Them Securely:
This post will explore the concept of refresh tokens as defined by OAuth 2.0. We will learn how they compare to other token types and how they let us balance security, usability, and privacy.
The problem with using tokens for anonymous users or logged in users is that they only identify who is in the request, not what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So, think about the who as the user (anonymous or logged) your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
Your Possible Solutions
We are already considering:
API KEY for every application (not per session)
Rate limiting
DDoS services to protect the APIs
This are basic security measures that any API should implement, but they will fall short when it comes to give na high degree of confidence to API server that the request is indeed from what it expects, a genuine and untampered version of your app.
You can read more about in my article The Top 6 Mobile API Protection Techniques - Are They Enough?:
In this article we will explore the most common techniques used to protect an API, including how important it is to use HTTPS to protect the communication channel between mobile app and API, how API keys are used to identify the mobile app on each API request, how user agents, captchas and IP addresses are used for bot mitigation, and finally how user authentication is important for the mobile security and api security. We will discuss each of these techniques and discuss how they impact the business risk profile, i.e. how easy they are get around.
The reader will come to understand why today’s commonly used mobile API protection techniques are very naive and not fit for purpose to defend digital businesses against API abuse. API abuse is its various forms is much more commonplace that most businesses realize so it is important to employ the right techniques to maintain revenue and brand reputation.
Other Possible solutions
For example, how can the SPA Web application or Mobile application securely obtain a "per-session" anonymous user?
With web apps its very easy to introspect them and see the API requests and their responses by just using the developer tools on the browser.
For mobile apps more work its required but a plethora of open source tools exist to make it easy and in some cases trivial to the point that even non developers can do it, thus making the task of securing an API server very hard, but not impossible.
So, do to the completely different way how the web and mobile devices work the approaches to secure them will differ.
For Web Apps
Are Captchas actually helpful in this scenario?
Captcha gives you a score to tell you a likely who is in the request is a real human. At the best score it cannot guarantee with an high degree of confidence that what is doing the request is indeed what your API server expects, a genuine and untampered version of your web or mobile app.
To learn some useful techniques to help your API backend to try to respond only to requests coming from what you expect, your genuine web app, you can read my answer to the question Secure api data from calls out of the app, especially the section dedicated to Defending the API Server.
For Mobile Apps
It's more of a general question, but What is the recommended way to protect APIs used in SIGN UP processes?
Despite not being specifically for the signup process I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
From that answer the better approach that can be employed is by using a Mobile App Attestation solution that will enable the API server to know is receiving only requests from what it expects, a genuine and untampered version of your mobile app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For Web Apps
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
Through reading Actions on Google documentation, I found that to access user storage to store data there, obtaining consent is required in some countries. So my question is where are these countries?? Nothing was specifically detailed so I thought it might have made developers think too.
According to Actions on Google: Save Data in Conversation oogle:
Legal note: Obtaining consent prior to accessing userStorage. Some countries have regulations that require developers to obtain consent from the user before they can access, or save certain information (e.g. personal information) in the userStorage. If you operate in one of these countries and you want to access, or save such information in userStorage, you must use the Confirmation helper to ask consent to the user and obtain the consent before you can start storing such information in userStorage.
There are certain laws like GDPR, applying to European Union countries, which create standards for storing user data. Though other countries may have their own laws. I'm not a lawyer, and getting legal counsel is ideal in discussing legal matters for each country to launch your action.
Otherwise you can set up your action to always get consent ahead of time regardless of location, which isn't a substitute for legal counsel but would fit in the requirement outlined in the documentation.
Hi i create application that is common to youtube and i`ve got some questions. I use google login(oAuth), so i keep in my database all things required to use google APIs for every user that wants to log in. The question is if i can use(is it possible and legal) google analytics to get info(like gender of people which shows his/her video or age or region) about every user that is loged in to my application and show it to another users which using my application ?
edit:
I do not know if you understood me well, user log in to my app with his google account, i have in my database his google token, etc. In my application all users have got youtube account and now what i want to do is that if you are log in, you can see user`s statistics from youtube(like the gender of people who watch his/her video and what is thier age) for any user registered in my app. There is a youtube analyse api, which alow you to get your account stats, and if i have access to someone`s google account(i keep toke in my datbase), i couldnt just use it to request that analyse api for every user and in that way get access to their stats. And another question is if i get data in the way that i described(of course if it is possibe), is it legall, if i can display such an info to other users not only to the owner of the account?
Thanks for help
Is it legall, if i can display such an info to other users not only to the owner of the account? Thanks for help
If you are authenticating a user to get access to their Private data. It is your responsibility as a developer to ensure that their data remains private. You should not be sharing data between your users without there express permission.
If the data you are accessing is public then you are allowed to display that data with anyone.
Remember when you created your google developer console account you agreed to this Google APIs Terms of Service
b. Compliance with Law, Third Party Rights, and Other Google Terms of Service
You will comply with all applicable law, regulation, and third party rights (including without limitation laws regarding the import or export of data or software, privacy, and local laws). You will not use the APIs to encourage or promote illegal activity or violation of third party rights. You will not violate any other terms of service with Google (or its affiliates).
d. User Privacy and API Clients
You will comply with all applicable privacy laws and regulations including those applying to PII. You will provide and adhere to a privacy policy for your API Client that clearly and accurately describes to users of your API Client what user information you collect and how you use and share such information (including for advertising) with Google and third parties.
You may also want to read Privacy policy
I would like to know what would be the integration like to become as a expense provider for Uber? This would be mobile apps along with web.
Cheers!
From an API perspective, aggregating of receipts that would be necessary for an expense provider is not allowed. If the users called the rides through your app, however, that is allowed. See the description here:
https://developer.uber.com/docs/ride-requests/guides/scopes
"request_receipt - this is only granted to apps that request Uber rides directly and show receipts as part of the trip lifecycle. We do not allow apps to aggregate receipt information."
Beyond the API and looking at an integration into the Uber app directly, there are a few large expense providers integrated. This is described here: https://newsroom.uber.com/auto-expense/. I do not believe they are adding more integrations there, but if you work for a large expense provider company like Concur it might be worth engaging via your business department.
Hope that helps!
As a newbie to Yodlee platform, I understand the basic concepts of Aggregation API .
Is there a way to plug in as a bank to supply direct data link instead of screen scraping to supply yodlee plaf and data model to be supplied to devs?
Yes a bank can feed obfuscated data, this is done by placing a middleware server between the core banking and the channel delivery switch.
Companies like Yodlee and Mint, et. al., rely on such a mechanism to provide access to their information partners.
Having said this, I'd be very surprised if any bank would provide you with direct access. Its a pretty cumbersome process even for the most reputed and well-intentioned of companies, individually, I doubt you will get direct access.