I'm developing an iOS app, but i need to identify the user who made the request to the web server.
I read on the internet that i cannot retrieve user's phone number, is there anything else that i can use to identify user?
I need something "legally-valid" (I mean that if the user do something illegal with my app, I should be able to track it down)
I cannot just "let user type its phone number" because i need that it's really true. I cannot risk that user type the number of someone else
You can get the phone number; you just have to ask the user for it.
In the past, people have used the device UDID for this sort of thing. The UDID is deprecated now, and new devices may not even have one. You can search on UDID to find out what people are using in place of the UDID -- in particular, look for the OpenUDID and SecureUDID projects. In some cases the device's wifi MAC address can be used, but that brings with it some of the same privacy concerns as the UDID.
You can also just generate and store a globally unique identifier. Search for "GUID" to learn how to do this. With a GUID, you can be virtually certain that the identifier is unique.
It's not clear what you mean by "legally valid". Is that "valid" with respect to privacy laws, cryptography laws, communications regulations, or something else? And in what country?
Related
As you have understood from the question's title, I would like to know, how to identify iOS device across multiple apps. Advertising identifier and identifier for vendor is not an option for me, as apps may not have AdSupport framework included, and they may not have similar vendors. MAC address of the device is also deprecated. Any working solution on this? Thanks in advance!
This functionality is explicitly disallowed by Apple. Any workaround you come up with will violate Apple's stated goal of preventing it (so you would obviously risk appstore rejection even if it "works"). You are not allowed to track devices. You are only allowed to track the vendor ID and advertising ID. Apple has steadily removed every other tool because those are the ones they intend you to use (and their limitations are intentional).
What you are allowed to do is track users by issuing them login credentials and having them log into your server. This usually works fine if the user actually wants the functionality you're providing by tracking them (for example, users don't mind logging into Facebook or Twitter). If you are tracking users or devices to achieve a goal the users don't actually want (such as targeted advertising that the user can't control, or attempts at digital rights management tied to devices), you're unlikely to find a supported or permitted solution.
In my project i want to get the serial number and IMEI number using iOS SDK, What API's we can use to get in iOS7. I went through few links where they are using IO Frameworks, If we use those Apple will reject the App. How can we got forward.
Apple does not allow you the retrieve any device specific information like IMEI, UDID, Mac address, serial number, etc..
This has to do with the misuse of these identifier and the privacy of the user.
Apple forbids retrieving such information, as this is potentially harmful to the end users. Instead they provide you with identifierForVendor:
An alphanumeric string that uniquely identifies a device to the app’s vendor. (read-only)
refs: https://developer.apple.com/library/ios/documentation/uikit/reference/UIDevice_Class/Reference/UIDevice.html#//apple_ref/occ/instp/UIDevice/identifierForVendor
If you need to distinguish different apps from same vendor(on same device) you could use advertisingIdentifier, however docs clearly states it must be used only when it is in duty of ads(whether contributing install to an ad, or presenting ads in your app). Moreover I had application rejected because it was using this id, and was not declared in iTunesConnect.
An alphanumeric string unique to each device, used only for serving advertisements. (read-only)
refs: https://developer.apple.com/library/ios/documentation/AdSupport/Reference/ASIdentifierManager_Ref/ASIdentifierManager.html#//apple_ref/occ/instp/ASIdentifierManager/advertisingIdentifier
If you still decide to go for the latter one, don't forget do add AddSupport.framework to you project settings.
I do know how to ask permission for contact's list accessing, is a very simple implementation, also I know Apple checks all this in case of going live to the App Store.
I'm about to receive a AdHoc bundle to a third party client, very very picky with privacy issues and I want to be certain that you cannot in any possible way in iOS7 access to the the address book, without previous and clear authorisation, nor storing some file in local or sending it through a web-service.
If there's other sensitive information than a programmer can access without the operating system firewall please let me know as well.
I read some subroutines can go through...
QUESTION: Can a developer access to the addressbook or personal information, directly or indirectly using a third party API or subroutine to the personal data, without explicit permission? Is an AdHoc bundle as secure as an AppStore reviewed App in that case?
Please do not punish me with negative feedback if you are not interested in privacy issues or think was that obvious, actually Apple's documentation is not clear and is focused on AppStore, mostly.
Thanks!
This answer came up in every search I did trying to find, CNContactPickerViewController, so I figured I should respond for posterity.
In iOS 9 and later you can call CNContactPickerViewController to present a system controlled contact picker that doesn't require permission to access the user's contacts. You can't hoover up all their contacts, which is what the original question implied (and is super creepy), but at least you can prompt the user to select a contact (or multiple contacts), which is sufficient for many legitimate use-cases.
Docs
The Address Book cannot be accessed without permission. No third-party API can get in, because internally, these API's need to go through the same permission checks as you need to. No app can get into a user's address book without the user's permission.
This is because of a security issue that Path, and some other apps, uploaded its users' address books to their own servers to use for whatever reason. To read more about it, look here
After this surfaced, Apple required the user's permission to access the user's contacts. Apple's iOS platform is possibly the most secure operating systems today, and there are few security holes that exist in their API's (minus the goto fail; mess-up).
App Store reviewed apps are more secure for the user than Ad-Hoc apps. The developers at Apple make sure that you do not do anything malicious with the user's contacts. In Ad-Hoc apps, there is no checkup. So, if you wanted to do anything dirty with their contacts in an Ad-Hoc app, you technically could (if the user gives you permission at all). You do not need to state what you will be doing with the permission, and so you are able to take advantage of the user's trust in you.
If you want the company to trust the app, suggest that they look it over with their own reviewers. If they don't think you are doing anything fishy, you are good.
I have a woocommerce store with a plugin which generates license keys.
The idea is that the user of my app, will enter a license key which will be checked against a server. If it is correct then the app will create a special file/persistent flag some how.
Once activated, the user can reset the device or whatever and the app will simply check to see if this persistent file/flag is there.
My questions are:
Is there a library available specifically for this sort of thing?
If not, what is the best/standard way of doing this so the file can't be copied to another device to fake an activation?
Could I use something untouchable inside the application bundle that isn't a file to do this?
Thanks guys, some guidance or suggestions would be great.
The "standard" way to do it is to have Apple manage the licensing for you via in-app purchasing or subscriptions, they provide a secure implementation for checking if something is paid for, but this may not be an option for you.
If you need to roll it yourself, you need to use assymetric encryption, with a private key on a server that nobody can access (except you) and a public key distributed in the app. You also need the [UIDevice currentDevice].identifierForVendor.UUIDString value on the device, which is a value unique to that device which cannot be changed by the user (unless they jail break).
The server encrypts some data like 2014-03-23,purchased-three-month-license,<device-identifier-for-vendor>,<long-random-number> and gives the encrypted data to the device as the license key.
The device has the public key, and uses it to decrypt the license key. Then it checks the result to see if the date is in the last three months, the device identifier matches the device's actual identifier, and verifies that the long random number is there and at least 10 digits or something (it doesn't matter what the random number is, it just needs to be there).
Anybody who jail breaks their device will still be able to bypass your security. There is no way to prevent this. But it will take the user a lot of work, they'll probably just pay instead.
All the libraries you need for the encryption are built in, but they're low level APIs and a bit complicated to use and it's easy to screw it up. I recommend RNCryptor as a high level wrapper around them.
Also note that if the user uninstalls your app, then re-installs it (or sometimes when Xcode installs a new build) the identifierForVendor will change to a new value. Apple enforces this to protect user privacy, there's no way around it. You will need to have the server re-generate a new license key based on the new identifier... perhaps by asking the user to enter an email address and password. You can prevent piracy by monitoring how many times a particular email address is used. If they generate license keys 5 times in 30 days, then you could flag them as a pirate.
Whatever license key the "woocommerce store plugin" is generating will not work, because it won't be using [UIDevice currentDevice].identifierForVendor.UUIDString as part of the license key generation. Without that value, it's going to be trivial for anybody to pirate your software.
There is no such thing as "something untouchable inside the application bundle". The only such thing is the Secure Enclave in Apple's hardware. And to protect user privacy app developers are not allowed to use it directly. identifierForVendor is the only option.
In older versions of iOS there were more options, but they were abused by advertising companies tracking Apple's customers, and so one by one Apple has blocked access over the years.
I have a social iOS app that has thousands of users (and most of them are children ages 10-13). Occasionally someone shows up that wants to cause trouble, and I wind up banning them.
Previously I used a hashed MAC address to identify the user's device, but now in iOS 7 that MAC address will no longer be accessible. Apple's solution is to use the advertising identifier.
The problem is that the advertising ID can be reset. If a user causes problems, gets banned and then resets their ID, I wont be able to block them. They'll essentially look like a new user.
Any solution to this? Perhaps I need to rethink banning users altogether? It pains me to think I wont be able to keep out the abusive users.
I think banning like this is not a good idea.
Because if the banned user sells his iPhone to someone, the new owner can't use your app.
So are you using any user Id for logging in ? If yes. Block them according to the UserId. Blocking them using the device Id is not a good solution (It's my suggestion)
From iOS 7 onwards, you can't get any ID that identifies the phone itself - the advantage is that if someone who is suspended sells their phone, the buyer won't be suspended.
Check this answer: IdentifierForVendor
identifierForVendor gives you a string that is unique to that installation of your app on that phone. So for privacy reasons, you still cannot identify the phone, but the installation of the app. That should be enough. You could also store the number in the keychain, so uninstalling and reinstalling the app wouldn't help.