Hacker News Reader

Comment by jrockway | Hacker News Reader

I wonder how many other apps on Apple's "guaranteed-safe" App Store have hidden behavior like this? Since I can't actually audit the app code that runs on my device (like by compiling it myself), nor can I audit the OS, I guess I now have to assume that any application on my iPhone is compromised. (+)

Apple should include a warning on the box to that effect.

(+) I don't actually own an iPhone.

View on HN

I feel pretty vindicated, because I've been saying all along that the App Store review process is pointless at best, because the things apps are usually rejected for are fairly petty and it has almost no way of picking up on anything but the dumbest malware.

I think that should be "the things that people make a huge fuss about are pretty petty." I think that the review process adds a certain value to the App Store. I know that if I download an app, (1) it will run and (2) it will do more or less what the description says. That is not to say that this is the one true way, but it adds value.

I think a model that the web has followed is better: apps should be ranked based on some organic factors (e.g.: content of description + reviews) and the best apps can just float to the top. Security can be ensured via reviews/ratings + sandboxes access to phone's core functions.

I think you may have misunderstood the term "petty." Even the rejections people don't make a fuss about are fairly petty for the most part (dictionary definition: "of little importance; trivial"). They're mostly things like "You forgot this one guideline" or "You have a small bug in this part of the app."

Same as the Debian policy. That doesn't seem to be a big deal in that community. Are the guidelines for the the App Store? Does it seem okay to ship a product with known bugs? Admittedly, I've never gotten an app approved by Apple, but as an iPhone user I can appreciate these things.

Well, ignoring for the moment that there's always some controversy with regards to contributions to Debian and other Linux distributions, Debian doesn't have an app store. If there is software you can't get using apt-get out of the box, for example, if you want the real firefox and not iceweasel, you might need to add a repository to your config file. Or maybe just wget a url and install a .deb file manually. Or you can just download the source and compile it yourself.

Can't do any of that on the iPhone. It's the app store or you figure out some way to beat Apple's security.

My point with this is that while Apple is going about things the wrong way, they are in fact adding value. Simply removing the approval process and letting any app into the app store will be a bad thing.

Apps are sandboxed. They can send and receive data over http/https at will. Location sharing is much more audited in iOS 4. Your calendar data and some address book data is not well protected. Your pictures are only accessible through the camera roll UI; apps can't slurp them.

Contacts (and in iOS 4, calendar data) are completely unprotected. Just create an instance of an AddressBook and go to town. Your pictures are only accessible through the camera roll UI... IF the developer is only using public APIs.

Since we can assume that there are no public APIs that support tethering setup, we can also assume that it's still possible for them to be used in rogue apps and for developers to have access to private data.

You can make a perfectly fine SOCKS proxy without using any unpublished API's. It's just listening on one socket and then opening a new one based on the request.

It's possible to create a tethering app using public APIs. The APIs for HTTP/HTTPS connectivity and WiFi connectivity are public.

Apple rejects apps that use private APIs.

How does Apple actually scan for private APIs?

Couldn't you write the instructions necessary to make the private API call on the stack at runtime and then simply execute an assembly jump instruction?

iOS4 added the ability to access the Photo Library in a similar way to the Address Book. You are no longer limited to accessing one user-chosen photo at a time.

Even better/worse, you also have direct access to the camera(s), which means you don't need to prompt the user or display anything on-screen to capture photos or video.

I know Android clearly warns users about an app's capabilities. Does anyone know if that opt-in, or is it derived by some type of code analysis?

The required permissions are listed specificaly by app developer, so no, there is no code analysis.

However, during app runtime, only those listed capabalities are provided to app. If the app tried to use something else, it would get exception. Short of bug in the platform, there is no way getting around.

Your contacts are pretty much completely unprotected as well. As an iPhone developer myself, I don't think it's unreasonable to have the device ask for permission to use this data (in a similar manner as location data access is approved).

Apple has never guaranteed the App Store is safe. They've pushed the idea that the App Store is safer than alternatives though. The iPhone EULA covers this.

Well, that's pretty much the a basic OSS argument that's been around since day 1, just applied to a specific device.

Reply on news.ycombinator.com