Hacker News Reader

Comment by napierzaza | Hacker News Reader

People hate the App store regardless of the iPhones HTML app capacity because they want what the App store offers without the compromise that Apple makes them take.

They want centralized marketing, distribution, security and payment handling which the HTML option doesn't have. They could build a website selling these apps if they wanted, but that would be work outside of developing, which they don't want to do.

Everyone wants to be on the App Store because that's where you go for apps. You don't Google for "html iPad App RSS reader". So no one is going to install your app.

With the recent security issues with Android phones (this will happen with Apple apps too, but maybe to a smaller degree) Apple's controls are looking nicer and nicer.

Sour grapes.

Also, what's with the title "which Apple can't stop". You're thumbing your nose at Apple with a feature they developed and encouraged?

View on HN

I was with you until the end, where you start pretending that Apple's guidelines are capable of preventing malware. Take a look at the kind of stuff they reject apps for and tell me this is a process that has anything to do with security.

I mean, remember just a few days ago, when a 15-year-old released a tethering app right under Apple's nose? Remember a year ago when everyone was outraged because an iPhone app covertly uploaded your whole address book to the developer's server? This Android app is arguably less of a violation than that one. They only check the visible behavior of your program and whether you're using private API. As long as you don't throw up a dialog that says "DURRR, I'M STEALIN UR INFO NOW MAN," Apple isn't really looking for you.

It wasn't a true "teathering" app. It was just a flashlight app that also opened up a SOCKS proxy within the app. Its very possibly that if the App also had network code for loading ads, say through iAds or AdMob, that an API scanner wouldn't notice anything unusual for a reviewer to feel concerned about.

Apple did find an app that exploited an App Store feature that you only need to type in your iTunes password once for a period of 5 minutes -- allowing you to DL multiple apps with minimum hassle. An app used its in-app content purchase to bill buyers for $200 worth on content it purchases without the user's explicit consent.

Apple may not be looking out for you in general, but they looking out for their brand, which is tied to consumer experience.

Its very possibly that if the App also had network code for loading ads, say through iAds or AdMob, that an API scanner wouldn't notice anything unusual for a reviewer to feel concerned about.

That's precisely the point. They can't catch underhanded code in the app unless they do a full source code audit - and honestly, I wouldn't be the least bit surprised if Apple changed the SDK license to require developers to upload their .xcodeproj files which get built and released from Apple's servers directly.

I'm not sure even a full code-audit is practical. Some big vendors use libraries under licenses that don't allow them to distribute the source to third parties (I don't know how prevalent this is on iPhone, but I know it happens in general), and Apple has shown an aversion to rules that mess with the big guns this way. It would also require a much higher caliber of app testers, because finding malicious code in a large codebase is nontrivial even if the malware writer isn't being particularly clever.

This would basically require Apple to severely choke the App Store pipeline, and given Apple's relatively lax attitude toward security, I don't think they'd make that tradeoff.

Regarding: With the recent security issues with Android phones (this will happen with Apple apps too, but maybe to a smaller degree) Apple's controls are looking nicer and nicer.

I respectfully disagree. App approval process has nothing, repeat nothing, to do with security. As an example I can create a time-bomb app, which does nothing nasty for 6 months and then once it is deployed on several Apple devices it begins to do whatever it was programmed to do.

There is no way an app approval process can handle that or catch that. That requires disassembly and careful analysis of the source or disassembled code.

That apps on Apple's devices are more secure is an illusion.

"That apps on Apple's devices are more secure is an illusion."

Yeah, and careful sandboxing of each app and control of the functions you use has nothing to do with security either.

Apple knows what functions you use and when, and the data you send receive using them. They know the format, nothing else is needed. That's one of the reason they only let you use documented calls.

For me its easy to make a software that monitors that activity,so with so many people smarter than me, I can not imagine that Apple has not done it. I know they have automated tools for analyzing Apps proposals, so I'm confident they monitor live the apps activity.

> That apps on Apple's devices are more secure is an illusion.

You're 100% on the money, but it's an illusion that the users believe in.

It's a war of public opinion, and Apple is winning.

Actually, no, I don't think I've ever heard anyone complain about lack of a central marketing and distribution channel. Having one is nice but many developers would do away with it if it also means doing away with Apple's draconian control policies.

In any case, the argument is bogus because there's no reason why you can't have both except that it doesn't directly serve Apple's interests.

Its not that developers want to deal with central marketing and distribution. They don't. But customers do.

Reply on news.ycombinator.com