I am working on a project dealing with Swift and HealthKit and my team and I are wondering if given permission by a user, are we allowed to store HealthKit data externally in a database? I have looked through the documentation for HealthKit and didn't really find anything unless I overlooked it. Any help would be appreciated!
There is plenty of information in the guidelines and the documentation
Here are some highlights...
The guidelines state
Privacy Protection
You must request permission to access people's data, and you must take all necessary steps to protect that data. After you receive permission, it's essential to maintain people's trust by clearly showing them how you use their data. For developer guidance, see Protecting User Privacy.
Provide a coherent privacy policy. During the app submission process, you must provide a URL to a clearly stated privacy policy, so that people can view the policy when they click the link in the App Store page for your app. For developer guidance, see App Information > App Store Connect Help.
Request access to health data only when you need it. It makes sense to request access to weight information when people log their weight, for example, but not immediately after your app launches. When your request is clearly related to the current context, you help people understand your app’s intentions. Also, people can change the permissions they grant, so your app should make a request every time it needs access. For developer guidance, see requestAuthorization(toShare:read:completion:).
Clarify your app's intent by adding descriptive messages to the standard permission screen. People expect to see the system-provided permission screen when asked to approve access to health data. Write a few succinct sentences that explain why you need the information and how people can benefit from sharing it with your app. Avoid adding custom screens that replicate the standard permission screen’s behavior or content.
https://developer.apple.com/design/human-interface-guidelines/healthkit/overview/
Another thing to note
The user’s device stores all HealthKit data locally. For security, the device encrypts the HealthKit store when the user locks the device. As a result, your app may not be able to read data from the store when it runs in the background. However, your app can still write to the store, even when the phone is locked. HealthKit temporarily caches the data and saves it to the encrypted store as soon as the user unlocks the phone.
Specify How Your App Uses the Health Data
In addition, your app must not access the HealthKit APIs unless the app is primarily designed to provide health or fitness services. Your app’s role as a health and fitness service must be clear in both your marketing text and your user interface. Specifically, the following guidelines apply to all HealthKit apps:
Your app may not use information gained through the use of the HealthKit framework for advertising or similar services. Note that you may still serve advertising in an app that uses the HealthKit framework, but you can’t use data from the HealthKit store to serve ads.
You must not disclose any information gained through HealthKit to a third party without express permission from the user. Even with permission, you can only share information to a third party if they also provide a health or fitness service to the user.
You can’t sell information gained through HealthKit to advertising platforms, data brokers, or information resellers.
If the user consents, you may share their HealthKit data with a third party for medical research.
You must clearly disclose to the user how you and your app will use their HealthKit data.
https://developer.apple.com/documentation/healthkit/protecting_user_privacy
To match Apple's security you would have to encrypt the data and therefore you would likely have to comply with Federal Encryption Guidelines
https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations
It takes a lot to do it "correctly"
Related
I found a previous question very similar to mine, however the other developper needed to write to Firebase and I don’t, hence this near duplicate question:
I have a very simple database with about 150 documents and the users don’t need to authenticate to use my app. Authentication just don’t make sense for what the app does and users only read the database, they don’t write.
My current rules are read allow only which of course triggers the Firebase rule warning daily.
1) Is there a way to set rules similar to “only requests coming from my app can access it”. Given that the app is linked to firebase one would think it’s possible?
2) If I must use authentification, is there a way that I can do this behind the scenes so that the user is unaware of that? Maybe by using a UUID to identify a user and no password or something like that. I want to avoid showing a log in screen at all cost. Think of it as asking to log in to check gas prices...
** This is an iOS app
No, it's not possible.
You can use anonymous authentication to create a user account without requiring a sign-in.
I am developing an app on unity3d and using firebase realtime database for user info and stats. The users need to authorize (via google) to read/write data to database inside the app. Since, users do not know the database address, which is embedded inside the app, do I still have security problem? If yes, what should I do? I do not want any user to change their own stats :)
Yes you still might have a security problem. Security by obscurity is not true security. It is still possible for people to snoop network traffic away from your app to get the address of the database. The firebase way of solving this is via Database Rules configured in the console/CLI. Making it so users cannot change their own stats will depend on how your app is structured and who IS allowed to change them. In any case, this can be expressed in Rules as well.
Just you have accessibility to database and its rules. Users just can read and write and change their data and they can't change another one's data.
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 use the Dropbox Datastore in an app that uses both the iOS and JavaScript SDKs. Aside from the 10MB datastore limit, it works pretty well.
But nearly every support request I get makes me wish I could have access to the user's data for debugging. Being able to see exactly what the user sees helps me to find and fix bugs very quickly.
Is there any way for me to access a user's data without logging into their account? Can I maybe store their access token and gain access to just their Dropbox Datastore data?
This is one of the attractive things about Parse: you can see all user data. While there is a lot of wisdom in sharding user data across Dropbox user accounts, it makes app debugging crazy-hard.
Any ideas? What do you do to get around this?
Dropbox datastores, like files, are considered the user's private data, and as such there isn't a way for an arbitrary party to gain access to said data without some sort of authorization (e.g., access to the account, having the data explicitly shared with them, etc.) Likewise, even the developer of an API app that a user happens to be using doesn't automatically get access to the data.
That said, if, as the developer of the app, you want to troubleshoot using your user's data, the most straightforward method would probably be to get an access token for that app/user pair from the user. That would replicate their setup most accurately. (Unfortunately, the Sync/Datastore SDK doesn't make it easy to extract/insert arbitrary access tokens like that though. So, in that case, this would be a bit of work to build some flow to get an access token, e.g., a small web app, and then some work to read data directly from the API.)
Alternatively, you may want to make it possible for the user to share the datastore with your own account.
In any case, it's very important that the user not be misled or confused as to what is happening or what the developer is requesting. That means being clear with user with regards to what the developer is requesting and what will be done with the data. In addition, apps should provide privacy policies in general.
I'm developing an iPhone app that lets users upload photos to a Google App Engine backend written in Python.
Data is transferred between the device and server via HTTP POST and GET. What is the simplest, most secure way to ensure only iPhones with my app can get data? Also, I don't want the user to enter in credentials, it should be invisible to her.
I could embed a key in the device and send that with every request which the server would check against. But a malicious user could potentially decompile the app and obtain the key. Any suggestions?
With your requirement that the user not enter any form of password, your options are severely limited. As you note, any shared secret key in the app can be pulled out by someone via binary extraction etc. -- in effect, you can't stop a really dedicated cracker finding out the secret and then just submitting that to the server.
There are approaches that are not watertight, but which might make it harder for wholesale abuse of your service. One example might be to release updates for your app every month (or two weeks, or whatever) that contain a new shared secret. Then obviously your web service has to expect the new shared secret, as well as accepting the exising secret, for each time period.
If your data is very sensitive, you might want to stop eavesdropping by using HTTPS; but as Nick says, if you use HTTPS for anything except authentication, you have extra hoops to jump through at App submission time.
Whenever you have a key stored on a device or in software that is accessible by someone it is subject to attack. iOS's keychain is generally a helpful way to store things you want to secure. However, it is still subject to attack. As with all security you need come up with a model that is appropriate for your application.
Also note that there are encryption export restrictions that you should familiarize yourself with if you be intending to use encryption for more than authorization.