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 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.
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.
I wonder why this guy thought sacrificing his iPhone developer status was a good idea. If it gets 'remote killed', it was all for naught. Maybe he's going Droid.
EDIT: He's just a kid
> Hi, I'm Nick Lee, an aspiring 15-year-old web designer and programmer. I consider ...
Why? Does he have something else to sell? Assuming he doesn't, he's just put his effort into learning what could be a valuable skill, but now can't work on the platform (ever again?).
If he wants to get a regular job later /or/ if he wants to launch a product later, having his name in the headlines helps quite a lot.
i don't want to say "there is no such thing as bad publicity" because there is, but in this case, enough people, I think, will feel that a tethering application is 'not evil' and that this was overall a good thing to make it a net win for the programmer.
Even if apple blocks him forever (I don't know their history... would they really say "no, f-ck you" five years from now?) and even if the apple platform remains dominant (I will be very surprised if apple continues its dominance after Jobs runs out of spare parts.) there are plenty of companies that make iphone apps that I'm sure would be happy to hire the kid.
And there are plenty of other platforms out there to work on, too.
This is app. not really 'bad' or evil as such. It's not like he is breaking into computers, stealing money or defrauding people. All the app. does is something other phones can do like Nokias and Android phones, but Apple or AT&T don't want you too.
In a few years this tethering will free on the iPhone (think competition) and common place or obsolete (multiple SIMs, same contract) and no one will care.
I was not aware he had an account. hm. he also looks like he's interested in MySQL NDB cluster, a really promising technology that it seems people are ignoring.
Indeed -- any iOS developer ($100/year) can install this on their own phone, and give it to friends (by using one of the limited number of test-device registrations), without jailbreaking.
It's rather annoying to give to your friends though, as you have to re-sign the code once a month and dish out binaries to everyone again. Plus, you'll run out of device codes quickly if you use your dev account to build apps for clients (whose devices you need to register too).
You just need to give a new mobileprovision file every three months, no need to update the app unless necessary.
I've always found it to be quite weird that the App Store is so closed, but a person with a developer certificate and MobileProvision can install whatever he wants and can do whatever he wants so long as the apps are codesigned. $99/yr is less than a couple coffees a month (or a good sushi plate) and way less than your phone bill, and is quite worth it for the bored hacker who wants to keep the warranty.
Not directly, but -- if Pandora can make a fresh HTTP request out for each song-reload, could a not-quite-SOCKS proxy app make two outbound requests and relay traffic between them? Then, with some additional support on your laptop -- maybe just netcat in a loop -- things might work well enough for browsing.
Or could some novel proxy otherwise keep alive a tunnel to another machine in the background? The latest iSSH app says it can keep a session alive for 10 minutes in the background -- though it's not clear if it can relay significant data while backgrounded.
Looks like iSSH is using beginBackgroundTaskWithExpirationHandler. So, yes, it's possible it would run for up to 10 min. in the background but my guess is the watchdog would kill the SOCKS app for taking up too much CPU time for a bg process and/or network access would be killed intermittently.
Pandora is using Background Audio API, isn't it? If so, the app is able to stay alive as long as it still play music. Background Task API, on the other hand, has 10 minutes time limit.
...it sounds like a background audio app could do arbitrary other things while remaining unsuspended, and receiving audio callbacks, as long as it also keeps playing audio. (I'm sure Apple would frown on such behavior, and ultimately thwart it, but it seems like the framework gives enough discretion to the app to do other things.)
iPhone tethering is allowed on my carrier, but I got the app anyway because setting up an ad-hoc WiFi network will allow me to tether my iPhone to my iPad, as well as the fact that bluetooth tethering between Mac <--> iPhone is flaky as hell. Will be interesting to see if Apple kills it, and if they go as far as to kill it outside of the US where tethering is allowed anyway.
Without a server to tunnel ssh, it's not possible but with somr Apache/root server access, your
best bet is tsocks which is not intuitive to get working.
I bought NetShare when it was briefly on the app store and it still works. Or at least it did last time I was at my cabin a few months ago with my 3G.
If they were going to kill an app, I'd assume they would have killed that. And they didn't. Or if they claimed to have killed it then they failed.
I bought this app. I'm more than willing to support the the Rebellion. I haven't actually verified that this app works as demonstrated but for a dollar it's worth the risk. I have no intentions of paying another $20 a month to AT&T.
This may sound silly now, but a long time ago I bought myLite - an iphone flashlight app. And when the app starts it has a frustratingly long and dark splashscreen before you get the actual light.
Even as a flash light HandyLight outperforms myLite. When I start it - it's immediate white.
> I bought this app. I'm more than willing to support the the Rebellion. I haven't actually verified that this app works as demonstrated but for a dollar it's worth the risk. I have no intentions of paying another $20 a month to AT&T.
As a current iOS developer, I’ve always wondered what the financial repercussions of getting pulled from the App Store would be. I wouldn’t be surprised if Apple refused to pay the kid his post-commission cut from what he was able to sell due to this kind of hidden behavior.
The kid's under 18. You need to be 18 or over to sell apps in the App Store, as per the agreement. They could choose to pull his apps, remove his account and not pay him for that reason alone.
That depends if the parent was involved in approving the agreement. When I skimmed it last year when I first signed up, I remembered there being some kind of “if the developer is under 18, have a representative of age read and agree instead” clause, but it’s been awhile.
Apple isn't going to use the kill switch on this, just like they didn't on the last tethering app. They simply remove the apps from the store much like they've removed other apps from the store that violated a policy (the commodore emulator). The kill switch, i.e. removing something from phones would be for extreme cases where actual harm is being done (virus propagating out of control, etc.). They aren't going to use it without having a _very_ good reason as it will no doubt be highly scrutinized.
Apple should include a warning on the box to that effect.
(+) I don't actually own an iPhone.