Apparently I found the assets i.e. graphics, html etc I used in my compiled iPhone.app file.
This yields for a concern for its safety, anyone got something to say about this?
They are not safe at all, you can safely browse application directory using iPhone Explorer on Mac or iFunBox on Windows even the device is not jailbroken. So, leave it as is unless you want to waste some or more CPU time for decrypting those assets when your app starts, which can make it a little more safe*r*
Extracting data from an iPhone app is extremely simple - you do not even have to own an iPhone.
Locate .ipa file on your file system
Rename it to .zip
Extract the content
On mac: Use Display package content
It's all there - Images, files, sounds, ... no protection - nothing.
The only way to protect your content is to encrypt the data. Decoding it on the after/while loading.
This is not a 100% protection - simply because you have to add the key and the decoding algorithm to your application. Otherwise you would not be able to display the assets.
But: It should give script kiddies something to chew on - maybe they even search for easier prey.
If you encrypt your contents you should in my opinion also be free from filling out the encryption export statements - since only the decryption is available in your app and only for DRM / content protection.
I've decided to add an content protection to TexturePacker after some people in the cocos2d forums reported that some people created exact clones of games - even using the original graphics and sounds. Apple seemed to have responded by removing the clone from appstore.
Related
I am making a mobile app using Cordova and I need to save some sensitive and not so sensitive data inside the phone. I am a bit lost on what is the best way to do it.
I need to save:
A JSON web-token (for authentication).
A response from server (I save this to populate my page in case the GET request fails).
Coordinates information when user is logging data to the app (for later upload to a server from with in the app). These will be many separate logs, and can be large in size for local storage ~5-10 MB.
Till now i have been successfully saving everything I need to the local storage but I don't think that is the correct way to do it. So that is why I need some help in deciding what is the best course to take from security point of view.
Saving server response is just for better UI experience and static in size so I guess local storage is a good option to use.
But web-tokens and GPS logs is sensitive information and I dont want to keep it in the local storage as it is accessible from outside the app.
What other options do I have?
Cordova still doesn't have encrypted storage.
Is saving to files a good approach? This here says that data contained inside cordova.file.applicationStorageDirectory is private to the app.So can I use it to save the logs and the token?
The plugin also lists the file systems for Android and iOS and lists which of those are private.
I am currently working with android phones but want to extend the app to iOS later. I have never worked with file systems and caches before so I am a bit lost.
Since i cant play an audio file from a DB blob, i have to write it as a file, before i can play it.
Looking at the documentation, my choices are:
Ti.Filesystem.applicationDataDirectory
Ti.Filesystem.tempDirectory
Ti.Filesystem.externalStorageDirectory
Ti.Filesystem.applicationCacheDirectory
Considering that i want my file to be secret, so no other app can see that file, what is my best option?
EDIT: So the issue is more with Android, i'm afraid that any file browser will be able to find the file.
I'm assuming you're building for android, because ios data are sandboxed and not readily accessible by default (until ios8). Rather than hiding them, just encode them using base64encode(). And then you can decode when accessing the file with base64decode().
With that said, I've never had to use it. So, I don't have an example. But you can read about it in the api doc.
Hope that helps.
You haven't mentioned if you are building an app for iOS or Android. For example Ti.Filesystem.externalStorageDirectory is available only for Android (SD card).
Anyway if you want to save an audio file, you should save it in <Application_Home>/Documents ,so you should use Ti.Filesystem.applicationDataDirectory. Don't forgot to set up a remoteBackup flag see http://docs.appcelerator.com/titanium/3.0/#!/api/Titanium.Filesystem.File-property-remoteBackup
Also have a look at iOS Data Storage Guidelines for more details
https://developer.apple.com/icloud/documentation/data-storage/index.html
*If you want to save an audio file only because you need to play it ,but you don't need to store it in a fileSystem then is better to use Ti.Filesystem.tempDirectory
I need my native iPad application to store its data (say .DOC documents downloaded via HTTPS) in an encrypted form. Those .DOC files are to be opened in 3rd party apps on the iPad.
I need to know whether there is a way that data of both my application and those of 3rd party apps can be encrypted? Meaning that my .DOC file will never be stored in unencrypted form on the device. (motivation here being that my app downloads documents with sensitive information and I want those documents to be read on the iPad, but with the layer of disk-encryption protection.)
I was reading through Advanced App Tricks # apple.com, section "Protecting Data Using On-Disk Encryption", but was unable to find any relevant information.
First, let's get the hardware encryption aspect out of the way:
iOS supports hardware encrpytion of everything on the disk. It's encrypted with a key that has nothing to do with your device pass code. This feature is there to allow quick wiping of the device's data (by overwriting the device encryption key). It doesn't really protect your data from being retrieved by a skilled interloper who can get your device, however; a jailbreak will get around this.
Per-file encryption via the Data Protection API: iOS can be told that certain files are to be encrypted by setting a flag on them. They are then encrypted using the device pass code (if one has been set). Note: if the user hasn't set a passcode, this extra protection isn't applied! Therefore, technically, this protection is out of your control, unless your users work at an organisation that enforces passcode lock policies (using iPhone Configuration Utility or similar).
Encryption using CommonCrypto: you can use encryption APIs such as this to manually do your own encryption/decryption. Note that if you don't know what you're doing it's easily to abuse such APIs and end up with not very secure encryption. However, there are some wrappers such as RNCryptor which make it much harder to abuse these APIs.
Protecting files used by third party apps: Can you clarify how your app will share files with third party apps please?
More info:
http://support.apple.com/kb/HT4175
http://www.ilounge.com/index.php/articles/comments/ios-encryption-and-data-protection/
http://developer.apple.com/library/ios/#documentation/security/Conceptual/cryptoservices/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011172-CH1-SW1
https://github.com/rnapier/RNCryptor
Update
On using UIDocumentInteractionController:
Once you've handed off your document to another app using this method, the data is out of your hands and the third party app can do what it likes with it. If you're happy with that, and your main concern is just having the document stored on your device in a protected way, then there are a couple of possibilities:
Rely on Data Protection API to protect the document on-disk (user has to set a passcode and you need to tell iOS that the particular file is to be protected for this to work)
Using the NSURLProtocol trick mentioned here to decrypt an encrypted file on disk on-the-fly
I'm in the process of planning out the infrastructure for a Mac App, and we have a startup screen with many user files listed. We want the App to be iCloud-compatible (thus the need for Document-based (key-value won't cut it since they aren't nested - correct me if I'm wrong here)). Essentially, we don't want to have the user keep track of each individual file themselves as that would be irritating, but rather store it in the App's folder until the user needs it (i.e. Email, Export, etc). It would eliminate a lot of the friction in the app, we think. I guess my question is:
Is it possible to store files automatically in the App's installation folder (or somewhere locally?) without bothering the user - in a Document-based app - and still be App Store compatible? Seems like the ideal solution - user opens app, App knows it's save location and automatically saves documents there when a user creates one, and pulls them to share if needed. Any help?
Yes, it's possible. You won't want to store document's in the application's installation folder. For one thing that'll violate the App Store rules, but it's bad behavior anyway, since Applications are normally installed in /Applications, which shouldn't be cluttered up with other files. So storing things in ~/Library/Application Support/YourAppName is the way to go.
To actually implement this, take a look at NSDocumentController and NSDocument itself. You'll basically want to override/modify any UI that allows users to choose a location to save/open documents. Instead, just let them name the documents, and then automatically save them with the given name in the app support folder. Then create a UI that allows them to browse and open those files within the app.
I have created one sample application for demonstrating a working of HTTP live streaming.
What I have done is, I have one library that takes input as video file (avi, mpeg, mov, .ts) and generating segments (.ts) and playlist (.m3u8) files for the given video file. I am storing playlist (as string) in a linked list, as an when i am getting playlist data from the library.
I have written one basic web server which will server the user requested segment and playlist files. I am requesting playlist.m3u8 file from the iPhone safari browser and it is launching the QuickTime player where it is requesting the segment.ts files listed in the received playlist files. after playing every segments (listed in current playlist) it again requests for the playlist, where i am responding with the next playlist file which contains the next set of segment.ts files listed in it.
Is this what we call HTTP live streaming?
Is there anything else, other that this i need to do for implementing HTTP live streaming?
Thanks.
Not much more. If you are taking input streams of media, encoding them, encapsulating in a format suitable for delivery and preparing the encapsulated media for distribution by placing it in such a way that they can be requested from the HTTP server, you are done. The idea behind the live streaming is that it leverages existing Internet architecture that is already optimized for serving HTTP requests for reasonably sized resources.
HTTP streaming renders many existing CDN solutions obsolete with their custom streaming protocols, custom routing and custom content caching.
You can also use media stream validator command line application for mac os x for validating streams generated by the HTTP Web server.
More or less but there's also adaptive bit-rate streaming to take care of if you want your server to push files to iOS devices. Which means your scope expands from having a single "index.m3u8" file that tracks all the TS files to a master index that then tracks the index files for each bitrate you'd want to support in your application which then individually track the TS files encoded at the respective bit-rates.
It's a good amount of work, but mostly routine/repetitive once you've got the hang of the basics.
For more on streaming, your bible, from the iOS standpoint, should ALWAYS be TN2224. Adhering closely to the specs in the Technote, is your best chance of getting through the App Store approval process vis-a-vis streaming.
Some people don't bother (building a streaming app over the past couple of months and looked at the HTTP logs of a whole bunch of video apps that don't quite seem to stick by the rules) - sometimes Apple notices, sometimes they don't, and sometimes the player is just too big for Apple to interfere.
So it's not very different there from every other aspect of the functionality of your app that undergoes Apple's scrutiny. It's just that there are ways you can be sure you're on the right track.
And of course, from a purely technical standpoint, as #psp1 mentioned the mediastreamvalidator tool can help you figure out if your streams are - at their very core, even if not in terms of their overall abilities - compatible with what's expected of HLS implementations.
Note: You can either roll with your own encoding solution (with ffmpeg, the plus being you have more control, the minus being it takes time to configure and get working just RIGHT. Plus once you start talking even the least amount of scale, you run into a whole host of other problems. And once you're done with all the technical hard-work, you'd find that was easy. Now you'd have to actually figure out which license you need to get for having a fancy H.264 encoder with you and jump through all the legal/procedural hoops to get one).
The easier solution for a developer without a legal/accounting team that could fill a football field, IMO, it's easier to go third-party with sites like Encoding.com, Zencoder etc who provide their encoding services a-la-carte or with a monthly fee. The plus is that they've taken care of all the licensing BS and are just providing you a simple "pay to use" service, which could also be extremely useful when you're building a project for a client. The minus is that you're now DEPENDENT on Zencoder/Encoding, the flip-side of which you'd know when your encoding jobs fail for a whole day because their servers are down, or even otherwise, when the API doesn't quite act as you expect or has been documented!
But anyhow that's about all the factors you got to Grok before pushing a HLS server into production!