For example, is it possible the storage container key in the entitlements dictionary would accept "*" or "/", allowing me to access any and all data in that user's iCloud?
I am not worried about getting this app accepted into the app store.
No.
And, even if you could, there wouldn't be any way to enumerate that data. -[NSFileManager URLForUbiquityContainerIdentifier:] and friends require you to know the containers you want to access. (You can pass nil, but that just returns the first container you have access to, not some parent of all containers.)
And this is intentional. The public APIs aren't meant to let your app interfere with other apps' storage (except for related apps that share a team), for pretty good reasons. You may want to read iCloud Storage in Mac App Programming Guide (which doesn't require a paid membership to access).
So, how does the iCloud preference pane do it? Well, that's a secret. Presumably it either uses private APIs, or just talks to the iCloud web service directly in a way that the APIs can't. You could presumably reverse-engineer it, but that's the only way you'll be able to do this.
Related
here is the things: there are some data sensitive which be stored in the device using NSCoding serialization.
I'd like to know is there a way the other people can find the key and unarchived the serialized object file to get data?
Thanks for help.
It is not safe to store sensitive data just using NSCoding. The NSCoded values are not encrypted in any way - you don't even need to know the keys - you can just look at a stored file directly and easily see the values if they are strings.
Sensitive data (particularly API access keys that provide privileged access to back-end web services or financial information) ideally should not be kept on the client device at all. Even when encrypted. In the extreme case, a black hat who has your app installed on their device can mount a man-in-the-middle attack and snoop on your internet traffic with your server. Instead you should a device-specific token approach if concerned about security so you can revoke a token if necessary without affecting other users.
If really concerned, you should look at two factor authentication in addition to the token.
Here is an intro for further reading.
It depends. Each application is given its own 'sandbox' on the filesystem. On a device that has not been jailbroken, an app cannot look outside of its own sandbox. However, when a user connects their device to a Mac or PC, it is possible to use utility applications such as iExplorer (http://www.macroplant.com/iexplorer/) to access the sandbox of each app on their device.
We are currently working on an app and would like to sync favorites across devices using iCloud. The favorites are fairly lightweight and text only. Do we need to ask the user for permission to use iCloud or can we simply go ahead and use iCloud if available?
I have setup all iCloud syncing code already. So it is more a question about AppStore submission rules. Any experiences?
Apple guidelines state that you should invite the user to use iCloud, and give them the choice as to whether they want to use it or not. (Documentation, see "Prepare Your App to Use iCloud").
As per the App Store Review Guidelines, there isn't a concrete rule that states you need to do this, it's more of a guideline and a courtesy. I'd suggest you do though, it provides a better user experience, and happy customers.
Why should I need permission anyway?
Users only have a limited amount of storage (typically the 5GB allowance), and it's up to them how it should be used. If all applications decided to use iCloud without permission, it'd be a free-for-all, and space would be eaten up fast.
If I'm not mistaken (and if I am mistaken, here or in what I say below, please correct me), non-jailbroken iPhones provide two broad areas of storage space:
for apps (and data that comes bundled with apps);
for user-managed files.
I understand that the former is protected storage, meaning that data bundled with an app and stored in that area is not accessible to the user except via the app.
On a jailbroken iPhone, does this protected area still exist? If so, what protections remain; i.e. is data stored within it still inaccessible to the user?
On a jailbroken iPhone the user has full access to all resources. The user will have more control over the device than any developer. There is no place to hide secrets on the device, even memory is accessible.
Even on a non-Jailbroken phone it's easy to extract the user data from the backups that iTunes creates when the user syncs (unless the user specifically enables the "encrypt backups" option).
The apps themselves are nominally encrypted using iTunes DRM, but since you can download apps in iTunes on a desktop and (AIUI) easily remove the DRM, again, even users without jailbroken devices can access your resources.
You have it backwards:
Third-party apps are sandboxed so they cannot access "protected" data, including some system data and other apps' data.
System apps tend to not be sandboxed and have extra privileges (they might all do). For example, App Store has to be able to upgrade other apps, and exploiting holes through Safari was one way to root a phone (suggesting Safari runs as root).
Nowhere is app data protected from the user. Instead, Apple apps do not expose the filesystem (and third-party apps can only expose a small portion of it).
Additionally, the "two areas of storage" are actually / (more or less the firmware image) and /var/mobile (more or less the user data partition). AIUI, upgrading the OS overwrites / but leaves /var/mobile intact; this is how a normal upgrade manages to preserve all your data without a long backup/restore process. IIRC, system apps are in /Applications and third-party apps are installed to /var/mobile/Applications.
I'm not sure what category Apple apps distributed on the App Store fall under (iBooks, Remote, Pages/Numbers/etc).
It is possible to store some application files and share it with another application?
Can application A remove files created in such shared space by application B?
In general, no. There are a few things you can consider.
All apps can read/write/share photos via the user's photos library.
Some apps have been known to share data via the address book. That is, they put data in a special address card which can be read by multiple apps.
If the apps have matching App ID bundle seeds, they can access the same keychain entries. I'm not sure how much data can be stored in the keychain, but it is possible to share data this way.
Apps can pass data to each other via a launch URL. That is, one app can ask iOS to open a URL that launches the next app, and that URL can have parameters that pass data.
No, each application has its own sandbox. Only way to communicate is to use custom URLs to call the other application or have a 'middle man' (eg a computer).
As an alternative to RupertP's answer, the only real work-around is to use a globally-accessible server. A lot of iOS devs use MobileMe's iDisk (not free) or DropBox (free for a limited account).
Is storing secret keys (internal use passwords and such) on iPhone source code and project resources (such as plist files) secure?
Obviously nothing is 100% secure, but can this information be extracted easily from an installed app?
How do you recommend storing these keys to use them in the source code?
Just in case, this question is not about storing user passwords.
Found basically the same question with a longer discussion:
How would you keep secret data secret in an iPhone application?
To sump up: it seems there's no official way to securely store secret keys in the app binary.
Sorry for posting a duplicate question.
A lot depends on what you mean by secure. For normal device use it could be considered secure in that there is no way for a user to access it. However all bets are off for a jail-broken device which has complete access to the filesystem. So viewing a plist file in your application bundle is trivial on a jail-broken phone.
You might consider the use of the keychain which in theory would be safer and also has the advantage that the data will survive a reinstallation of your app. As before on a jail broken device nothing can be considered to be 100% secure but it depends how much trouble you want to go to.