"Jekyll" Test Attack Sneaks Through Apple App Store, Wreaks Havoc 206
An anonymous reader writes "A malware test app sneaked through Apple's review process disguised as a harmless app, and then re-assembled itself into an aggressive attacker even while running inside the iOS 'sandbox' designed to isolate apps and data from each other. The app, dubbed Jekyll, was helped by Apple's review process. The malware designers, a research team from Georgia Institute of Technology's Information Security Center, were able to monitor their app during the review: they discovered Apple ran the app for only a few seconds, before ultimately approving it. That wasn't anywhere near long enough to discover Jekyll's deceitful nature."
BUT MACS DON'T GET ... (Score:3, Funny)
BUT MACS DON'T GET VIRUSES.
Unless they're too slow.
Re:BUT MACS DON'T GET ... (Score:5, Insightful)
Why waste your time with viruses when people will pay to run your Trojan?
Re: (Score:3)
But Macs DON'T GET VIRUSES.
Except when they do.
Fixed that for you.
Re:BUT MACS DON'T GET ... (Score:5, Interesting)
Heh, remember when Apple changed the info on their page from "DOES NOT GET VIRUSES" to "DOES NOT GET PC VIRUSES"?
That was classic.
Re:BUT MACS DON'T GET ... (Score:5, Funny)
No, I believe it was OS X.
Re: (Score:2)
No, I believe it was OS X.
I believe you're right.
That does bring to mind an interesting, slightly OT question - if the new Microsoft OS for phones and tablets is basically the same as Windows 8, does that mean they will all be affected by the same malware?
Re: (Score:2)
If they're x86 tables & phones, potentially, though I'd suspect there are some gotchas that would make existing malware unlikely to run as-is. ARM based devices would be immune to x86-targeted malware.
Re: (Score:2)
But Macs DON'T GET VIRUSES.
Except when they do.
Fixed that for you.
If I remember correctly believe the statement from apple was: (there was an article a long time ago so I could be wrong)
But Macs DON'T GET PC VIRUSES.
well except when they are running on a cross platform VM. Marketing weasel words.
Re:BUT MACS DON'T GET ... (Score:5, Informative)
Re: (Score:2)
It's not a Mac, and it's not a virus, so actually I don't get his point.
"If you run a program on your computer, that program can do stuff to your computer, so maybe don't run malicious software on your computer."
I literally can't think of a way to avoid that. It's pretty fundamental to how computers work.
Re: (Score:3)
Access to contacts, calendar, camera, and a number of other "sensitive" data stores on iOS requires your permission. Compared to Android, rather than asking at install (and preventing you from running the app if you'd rather not grant access), iOS asks at runtime, and you can revoke that access at any time after install. You're given the choice of still running an app in a restricted fashion by denying permission to access certain API's. In order to pass the review process, apps must operate in a reasona
Apple review process = a few seconds? (Score:5, Insightful)
There is no point to the closed system if you let just anyone come in.
Re:Apple review process = a few seconds? (Score:5, Insightful)
There is no point to the closed system if you let just anyone come in.
Of course there is, silly! It's called "style". More specifically, "illusion of security", which is a style. Apple's big on that sort of thing, you know.
Re:Apple review process = a few seconds? (Score:4, Insightful)
Re:Apple review process = a few seconds? (Score:5, Insightful)
Re:Apple review process = a few seconds? (Score:5, Insightful)
Checklist for approval:
Note that Apple's motivation is not to ensure that only quality apps get into the store. Rather, they just want to make sure that the store itself isn't tarnished. If 30% of your downloaded apps are just shells around scam-laden videos, you'll stop using the store, so they just test each app long enough to make sure that it kinda-sorta does what's claimed. Any problems after that are going to be blamed on the developer, not Apple.
Re: (Score:3)
Re: (Score:2)
Apple already prompts the user for address book access in iOS 6. iOS 7 adds camera and microphone I think.
Re: (Score:2)
So as long as the hardcore porn only kicks in after the Colouring Fun For Kids app after 11 seconds Apple will approve it. Good job.
Re:Apple review process = a few seconds? (Score:4, Funny)
Don't forget the disapproval checklist:
Does the app compete with any of our own current or future products in any way?
Does the app violate the sensibilities of the reviewer, his boss, or her mother-in-law's cat?
Is my coffee cold?
Re:Apple review process = a few seconds? (Score:5, Interesting)
I've had a game published which wasn't even started, or approved while only displaying 'an internet connection is required to proceed'. It's hard to be checked out less than this..
Re:Apple review process = a few seconds? (Score:5, Insightful)
Without knowing much about the setup, I'm kind of doubtful that they can have a high level of confidence that it really ran for a few seconds. If I were testing apps like this, I'd run a good bit of my testing on a disposable VM with a faked network. That way it couldn't send connections out and any self-modification it did while in the test harness would be ignored, so nobody but me would have any way of knowing what went on in the harness
Re:Apple review process = a few seconds? (Score:5, Insightful)
Without knowing much about the setup, I'm kind of doubtful that they can have a high level of confidence that it really ran for a few seconds. If I were testing apps like this, I'd run a good bit of my testing on a disposable VM with a faked network. That way it couldn't send connections out and any self-modification it did while in the test harness would be ignored, so nobody but me would have any way of knowing what went on in the harness
In other words, you would reject any app relying on a webservice somewhere on the internet. Good policy I guess. Nobody needs Instagram, Facebook of Twitter apps.
Re: (Score:2)
Sure they can, just make the app require an active internet connection and do nothing other than display a message saying "no internet" otherwise. Only launch the attack when you know you can communicate with the researcher's server.
Remember, the goal here was to probe the vetting process, so it's reasonable to assume they anticipated common techniques like isolated VMs.
Re: (Score:2)
If I were testing apps like this, I'd run a good bit of my testing on a disposable VM with a faked network.
Meaning any application that required web services wouldn't work...great plan!
TARGETS (Score:5, Insightful)
Sadly, it's a matter of expenses stripped to the bone. The "testers" have targets to fill. Here, you have 1000 apps to test and 3 days to do it. You miss this target twice, you get fired.
It's a method I've seen (generally) pretty much everywhere. UAT or internal testing is considered "money sink" and its attached expenses are minimized by all means.
I would frankly have been surprised if the testing method were to be any different.
Re: (Score:2)
Did you expect Apple to decompile everyone of those apps and pay an engineer 100k/year to read out decompiled code?
Re: (Score:2)
No, I didn't. If you would have read my post carefully, you would have realized that.
Apparently other people did expect it, though.
Re:Apple review process = a few seconds? (Score:5, Insightful)
Not true. A closed system can be used to ban competitors whose work you plan to steal.
Re:Apple review process = a few seconds? (Score:4, Insightful)
Sure there is.
They get a cut of all software on the platform. That is the entire point.
Re:Apple review process = a few seconds? (Score:5, Insightful)
Not from any apps sold via the Amazon Appstore for Android.
The entire point of Apple's closed system is that they are the only publisher of software for the platform. This means they get a cut of sales no matter what.
Re: (Score:2)
Not from any apps sold via the Amazon Appstore for Android.
The entire point of Apple's closed system is that they are the only publisher of software for the platform. This means they get a cut of sales no matter what.
Plus the cut they get from charging $99/yr for the privilege of developing iOS apps.
Re: (Score:2)
This means they get a cut of sales no matter what.
Which is not the point of the whole thing, by they own word and their own accountants. Did you see the dent AppStore sales makes on their overall profit margin? Do you really think they did all that JUST for the money? Do you think they got where they are by being this shortsightedly stupid?
I'm not a fanboy or anything, but give some credit to Jobs. If he was that dumbfuck stupid he wouldn't have died 1000000 times as rich as you will.
Re: (Score:3)
You could also distribute the app via your own website.
Quite different from other mobile stores. Since there is more than one option. You are even free to become your own publisher with no middleman.
Re: (Score:3)
The point of Android is openness and choice. If you don't like Amazon getting a cut, use F-Droid, manually load APK files, or use one of the many other sources for Android applications. Apple is very difdferent than most other software repositories in that it's the only one you are allowed to use. Microsoft is pushing hard for this model with Windows 8 and their Metro apps an it's very profitable and you can lock out competition if you wish.
Re: (Score:2)
You mean, aside from the fact that Win8 "Modern" (the interface formerly known as Metro) apps are allowed to be sideloaded? That enabling sideloading can be done by anybody with Admin access to the machine in question, even on the otherwise-locked-down Windows RT (yes, Admin is available by default on RT)?
MS would surely *like* that cut, but they aren't locking out alternative distribution... although admittedly they are discouraging it.
Re: (Score:3)
Microsoft offers free developer licenses for Windows 8. These licenses allow developers to test and evaluate their apps before submitting them to the Windows Store. Each developer license license will expire after some time, but you can repeat the process to acquire a new license in the future.
Is that no longer accurate?
Re:Apple review process = a few seconds? (Score:5, Informative)
you can go without a middleman for android apps.. all android devices allow you to install apk's.
now that is a large difference to iOS or windows phone.
if you don't see the difference then you're a fucking moron, the other os allows you to point to a file on any fucking webserver and the other doesn't. the other platform allows you to install anything without the device(or os) manufacturer greenlighting the app while the other censors whatever the fuck it wants that week to censor.
Wreak Havoc seems a bit overblown (Score:5, Insightful)
Re: (Score:3)
You are showing your human bias. Think in terms of clock ticks and the amount that can be accomplished by a computing device in "a few moments" and it becomes clear that "Wreak Havoc" is justifiable even if harm wasn't necessarily found after their analysis.
Re: (Score:2, Interesting)
Reminds me of this scene from First Contact:
(Picard drains the coolant, finds the Borg Queen's head and neck that is still blinking. He breaks the neck) ...are you all right? ...feel. ...Strange. ...Part of me is sorry she is dead.
DATA: Captain.
PICARD: Data,
DATA: I would imagine that I look worse than I
PICARD: She was unique.
DATA: She brought me closer to humanity than I could have thought possible. And for a time I was tempted by her offer.
PICARD: How long a time?
DATA: Zero point six eight seconds, sir. Fo
Re: (Score:3)
was on the store for a few moments.
Agreed. All iOS apps claiming to be "malware" need to actually destroy something or we aren't going to believe you could actually do it.
Re: (Score:3)
Yes, but it was only on the app store for a few minutes due to the researchers removing it:
A better headline may have been:
"Researchers demonstrate that havoc-wreaking malware can bypass Apple's app store review process"
Re: Wreak Havoc seems a bit overblown (Score:2)
Malware that has reach end users on the App Store can be counted on your fingers. Do you *really* want to compare that to Android malware figures?
You can argue *why* that is, but reality begs to differ that App Store security is a 'delusion'.
iOS apps -- can they self-modify? (Score:4, Interesting)
Let's say you submit an app to the app store, and like many it's designed to do something fairly idiotic that today's kids find funny, say, take a picture and then superimpose the picture onto a set of background images included with the app.
Now, let's say the app writer has steganographically embedded "naughty" code in the background images, maybe even going so far as to spread the code across all the images, encrypt, etc. to make it difficult to find.
Can the app modify itself by taking its hidden code from the images and actually execute it? Can you download "new" code from the internet, even if its steganographically hidden? It seems like you shouldn't be able to do this, like the apps should be sandboxed from modifying their own code just to prevent importing unapproved code.
Re:iOS apps -- can they self-modify? (Score:5, Interesting)
Re: (Score:2)
Re: (Score:3)
Why would it need to modify its own code?
Why not just have an interpreter in there to begin with? Or just have a simple date check. Don't be evil for X days.
Since they only have the compiled program they have no idea what it will do in the future.
Re:iOS apps -- can they self-modify? (Score:4, Interesting)
Re: (Score:2)
Build an interpreter into the app. No need for it to modify it's own code, just the data that tells it when to do what.
Re: (Score:2)
For the most part, yes, but not in the way you think. Objective-C is a very dynamic language. It's not really about sandboxing - apps can't modify their own code. What they can do is include components that do fairly generic, innocuous things, then take external input and construct messages to those existing components on the fly based on that input.
Re: (Score:2)
Can the app modify itself by taking its hidden code from the images and actually execute it? Can you download "new" code from the internet, even if its steganographically hidden? It seems like you shouldn't be able to do this, like the apps should be sandboxed from modifying their own code just to prevent importing unapproved code.
It may be quite possible that you can create code on the fly. However, the app is still sandboxed. It has permissions, and it cannot do anything that it isn't permitted to do. Which _should_ be a protection against viruses (even if some virus or malware can attack your app, it cannot break out of the sandbox and do things that the app isn't allowed to do), but it also protects against the app maker doing naughty things himself.
Q&A (Score:5, Interesting)
I had a apps declined due to improper usage of a certain widget in another certain widget which was not deemed "correct" (switch button in a table footer for example), but always was able to either find a similar solution or - in one rare case (the one mentioned) - explaining WHY that switch button is there, and how if you take a look at the UI, understand what it does.
Then again I saw apps in the store which completely failed most of the even basic guidelines, described as (between the lines): "fail these, and your app will 100% be NOT approved", and I wondered "how did they get in there"?
Talked to other developers, same experience. Some knew they had a few things in there against the guidelines (custom springboards, views not conform with the UI guidelines) and hoped to get through. Sometimes they managed, sometime not, so they also got the feeling that the Q&A for the App store is somewhat like tax declaration. They don't seem to have enough time/ressources to check all, so if you something that is against the guidelines, you have to hope that you are one who doesn't get checked thoroughly.
Re: (Score:2)
Of course I meant QA! How could that go through my Q&A.....
Re: (Score:2)
Talked to other developers, same experience. Some knew they had a few things in there against the guidelines (custom springboards, views not conform with the UI guidelines) and hoped to get through. Sometimes they managed, sometime not, so they also got the feeling that the Q&A for the App store is somewhat like tax declaration. They don't seem to have enough time/ressources to check all, so if you something that is against the guidelines, you have to hope that you are one who doesn't get checked thoroughly.
It sounds like someone is rubber stamping apps, and not doing his job.
Re: (Score:2)
Well it is an impossible task, so no surprise there.
I can easily make an app that has a good mode and an evil mode, it decides which by downloading some images from my website. Since the app is used for some image related task you would never notice.
Unless Apple has solved the halting problem and they failed to tell us.
Re: (Score:2)
Unless Apple has solved the halting problem and they failed to tell us.
There's an app for that. Wait, why has my screen filled with skulls and crossbones?
Re:Q&A (Score:5, Insightful)
I'm an iOS developer, and the approval process can be a real problem for me sometimes, but I still think the App Store is far better with it than without it.
I've seen a lot of clients ask for dumb stuff. Using UI elements in confusing ways. Doing user-abusive stuff. Being generally annoying and self-serving rather than being designed with the user's best interests as a goal.
The great thing about the approval process is that I can tell those clients "Apple won't allow it" and it instantly shuts them up. The alternative would be hours of trying to convince them not to do something horrible, which leaves everybody unhappy no matter what decision is made. And this is the best case scenario, when you've got a developer willing to go to bat for the users. There's plenty of developers out there who will blindly do whatever the client asks, no matter how shitty it makes the UX.
It's not just bad decisions. It's QA as well. Do you have any idea how keen people are to just push stuff live and then fix it after? I don't know about you, but I don't want a dozen updates every morning as developers meddle with their apps trying to get things right. The approval process gives developers the stick necessary to perform proper QA. We don't dare push anything live if there's the possibility of a crasher, because Apple will reject it and we have to wait another week to get reviewed again.
If the approval process wasn't there, then the quality of the apps on the App Store would plummet. You think it's bad with Android, but Android doesn't attract the worst kinds of ambulance chasers. The App Store would be 75% Geocities level quality in no time at all.
What I do disagree with is making the App Store the only way to get applications onto the device. There's really no legitimate reason for not allowing side-loading for people willing to go into settings and agree to a disclaimer.
Re: (Score:3)
Running a closed app store with a tight approval process is fine. Preventing use of outside apps or app stores is not fine. That's where the line is, and Apple is over the line [youtube.com]. They could still have their branded kid-safe no-porn carefully-checked pre-installed app garden, and everyone would trust it and use it and they would make tons of money, but Apple has an ideology of control which means they can't abide [youtube.com] alternatives.
I call bullshit on "unaware" claims (Score:4, Interesting)
I can totally see getting an app through the submission process that does something a bit sneaky. Sometimes the app reviewers hardly look at a thing (though sometimes they look very carefully, it just depends on the reviewer).
But the claim the app could "wreak havoc" needs some proof. They said:
a Jekyll-based app can successfully perform many malicious tasks, such as posting tweets, taking photos, sending email and SMS, and even attacking other apps â" all without the users knowledge
Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet. Same thing for email/SMS. Taking photos requires an OK from the user to access the camera. You cannot "attack other apps" because of the sandbox.
Extraordinary claims, like a complete breaking of the sandbox, require more proof than they have presented. I would bet they are saying they THEORETICALLY could break out of the sandbox but have absolutely no actual working exploits that go outside of existing user permissions and the sandbox...
Re: (Score:2)
You can't attack other apps?
So how does jailbreaking work?
If you can jailbreak, you can use that to attack other apps or do any of those other wonderful things.
Sure you would need to use a jailbreak after being installed, but chaining together attacks is a well known thing to do.
Jailbreaking works by attacking update mechanism (Score:2)
You can't attack other apps?
So how does jailbreaking work?
Jailbreaking works by attacking the device over USB, generally the update mechanism - not something you can do through an app.
Re: (Score:2)
Only the most recent one.
There was a time you could jailbreak via pdf or just visiting a webpage. It is quite possible another such exploit will be found in the future.
That didn't work in an app (Score:4, Insightful)
There was a time you could jailbreak via pdf or just visiting a webpage.
The only reason THAT worked is because the Safari javascript engine has native code JIT that an app cannot use. And now you know why...
So still true that you cannot jailbreak out of an arbitrary app, only ever from system apps that have elevated privileges, and then only once years ago...
Im not saying such an attack will never exist, it's just exceedingly unlikely and far more unlikely inside of an app you deploy to the store.
Re: (Score:2)
Either way security problems will exist and pretending that their app auditing is anything more than a justification for a walled garden is simply burying your head in the sand.
Re: (Score:2)
The walled garden is probably one reason for the approval process, but it's certainly not the only one. Apple seem genuinely motivated to use it to raise the quality of the end-user experience.
Here's one example: a few years ago, developers were complaining that Apple was rejecting their apps for having an icon of a phone in t
Re: (Score:2)
Then why not allow outside markets and advertise theirs as the premium one?
The simplest answer is, they want their 30%.
Re: (Score:2)
I'm responding to what you said here:
You were arguing that the promotion of a walled garden was the sole purpose for the approval process for the App Store. That's a silly thing to say, and I explained why. You've now changed your argument to someth
Re:I call bullshit on "unaware" claims (Score:5, Informative)
Read the paper - they watched the interaction in a debugger to find the right messages to send to the right private classes in order to bypass this.
This only worked with iOS 5 - last year Apple moved sheets like these into external processes and used a proxy view controller to show them in applications instead of embedding the functionality directly, so attacks like this aren't possible any more where this technique has been used.
I agree that this is somewhat sensationalised, but they were able to do this without the normal user approval in the 4% or so of people still running a two year old version of iOS.
Aha (Score:3, Informative)
I looked for the paper but could not find the link. Thanks for the extra info.
As I thought, they did not break the sandbox at all. Attacks that don't work in iOS6 are irrelevant at this point...
It's totally sensationalized. It remains true there's no way a real app can "wreak havoc" even if you inject code later.
Re: (Score:2)
That's a naive view. Getting users to grant permission for just about anything is pretty easy. Everyone knows this and it works on all platforms.
Re:I call bullshit on "unaware" claims (Score:5, Informative)
Some items only worked in iOS 5.
Based on Table 1 from their paper here [usenix.org], the following items could be accomplished by their app on iOS 6:
- posting tweets
- using the camera
- dialing
- using bluetooth
- crashing safari
- stealing device
It was only sending SMS messages, sending email, and rebooting the system that were limited to iOS 5.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But they never discuss if the app had to be given permissions. Sure they say they did it all secretly and hidden using private apis, but they never indicate they did not give the app permissions when it was run.
Hard to believe this paper has been peer reviewed.
Re: (Score:2)
Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet. Same thing for email/SMS. Taking photos requires an OK from the user to access the camera. You cannot "attack other apps" because of the sandbox.
Good point. I guess that this never happened [arstechnica.com] because of the tight limits put on app capabilities.
Extraordinary claims, like a complete breaking of the sandbox, require more proof than they have presented. I would bet they are saying they THEORETICALLY could break out of the sandbox but have absolutely no actual working exploits that go outside of existing user permissions and the sandbox...
Ah, the old "That vulnerability is completely theoretical" [l0pht.com] defense. It worked so well for Microsoft in 1992, and it's still working for Apple today.
Corrections (Score:3)
Good point. I guess that this never happened
Not in iOS6 it didn't. Apple started taking user security much more seriously in iOS6, anticipating a potential for such attacks. I always thought prior to that it was kind of nuts you could access the address book without permission - now you cannot.
Ah, the old "That vulnerability is completely theoretical" defense.
And yet it turns out to be true. The vulnerability is not real, only a theoretical possibility that relies on breaking the sandbox, which they hav
Re: (Score:2)
Are you certain users did not give the app permission to use their twitter account? Nowhere in the article on the dictionary app does it claim they broke out of the sandbox and took control of people's twitter accounts.
You seem to have a tendency to use completely unrelated links to try and bolster a pretty weak position. Your l0pht link is equally puzzling.
Re: (Score:2)
In fact, from the article you linked:
" A notification appeared locally on the device and if the user had authorized the app to access their Twitter account, a tweet of the notification was sent out under their account with a hash tag #softwarepiracyconfession"
See the if part of the statement? Maybe it would help to read what you link? Maybe a little?
Re: (Score:2)
No, they do not. Their claims require more proof than the reporter presented in the article.
The researchers wrote a fairly in-depth paper on the attack which can be read here [usenix.org]
In the case of tweets, they make use of "private API's" to avoid notifying the user:
Re: (Score:2)
I don't see them actually claim that anywhere and their paper is not out yet.
Re: (Score:2)
Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet.
This example isn't correct. Apps can get access to the social framework, which allows them to do things directly to the Twitter web API, which as far as I know, includes posting Tweets. This is used for apps that want to have their own custom UIs but also have access to the user's Twitter data (for example, Twitter clients.)
Now, you are right in that this would spawn a dialog that requires user authorization. Trying to access the user's Twitter account token will cause the system to ask the user's permissio
Re: (Score:2)
It's also a reminder that slashdot headlines have reached new levels of absurdity.
Which is not breaking the sandbox (Score:2)
Private API calls are not breaking the sandbox.
Pretty much none of what they did that they consider an attack is possible in IOS 6., much less iOS7 which is on the eve of release - and some 95% of active devices are running iOS6 now.
I can break into Windos95 pretty easy too. But who cares and why would it warrant an article? The whole paper really boils down to "sometimes the app reviewers do not run an app for long" which is news to pretty much no-one.
The value isn't in review, it's in revocation. (Score:5, Insightful)
No review process will ever catch all bad actors. I think Apple should be doing a better job with reviews in several dimensions, but that's not the prime advantage to the Apple ecosystem.
The main advantage is Apple can revoke the application. If this app started doing bad things Apple can remotely prevent it from running, and in fact revoke all apps by the same developer. This central control is what scares people, but it's also what makes long term exploitation impossible. The Google ecosystem doesn't have this feature, with no centralized control.
Re: (Score:3, Insightful)
No review process will ever catch all bad actors. I think Apple should be doing a better job with reviews in several dimensions, but that's not the prime advantage to the Apple ecosystem.
The main advantage is Apple can revoke the application. If this app started doing bad things Apple can remotely prevent it from running, and in fact revoke all apps by the same developer. This central control is what scares people, but it's also what makes long term exploitation impossible. The Google ecosystem doesn't have this feature, with no centralized control.
I'm pretty sure (though not 100%) that this isn't true.
I've downloaded many apps that have since been pulled from the app store (some MAME apps and some tethering apps). They all still run. Apple can pull apps from the store so that they can't be downloaded again but once you've got them on your device they can't do anything.
Re: (Score:2)
Apple can pull apps from the store so that they can't be downloaded again but once you've got them on your device they can't do anything.
I wouldn't put money on that. There just haven't been any transgressions worth the Amazon "1984" outrage, more likely.
Re: (Score:2, Insightful)
There is a difference between removing an application from the store because it goes against the terms and removing an application because it is malware. Apple is certainly able to make this distinction.
Google is able to remove applications remotely, they did so in the past, google it up.
Re: (Score:3)
There are plenty of articles on the remote kill switch, here's one of the first: Steve Jobs confirms iPhone application "kill switch" [macworld.com]
Re: (Score:3)
-1, wrong.
Yes Google does have the ability. If I get an app from the Play Store and it is removed by Google, they have the ability to remove it from my phone. Its happened a couple times with emulators. Now if I decide to circumvent the Play Store that is a different story.
However, that is what Android gives... choice. With the App Store you don't have that choice; you only use what Apple lets you use. If you want to be a moron and run any old app, you can't.
Monitored? (Score:5, Interesting)
What kind of two-bit operation is Apple running if apps can phone home during the vetting process.
Re: (Score:3)
load external content = phone home.
There are a lot of apps whose purpose is to present external data in a useful way. That's only marginally different than phoning home - you still want to proxy the data through your own domain for compatibility changes with the data provider if it's not your own data.
Re: (Score:2)
I have one that logs into my company's server to retrieve configuration information (and has a special 'Apple' account that the Apple testers use to validate the app.)
I can see them testing releases in real-time on the server monitoring dashboard - "Oh, look, Apple just ran the app..."
Many business applications require this type of functionality when being tested by the App store (as mine does.)
As usual: Headline completely made up (Score:3)
2. The app is sandboxed. It doesn't escape out of its sandbox. Therefore, it can only do things that it is allowed to do.
3. The identity of the developers was known to Apple. If malware was delivered to end users, Apple could get hold of the developer.
4. To actually attack an end user, you still have to create an app that does what it claims it does, and that does things interesting enough to make people download it.
5. If an app did "wreak havoc", then Apple could kill it dead on all iOS devices.
Wreaks Havoc? (Score:2)
Just gonna lie in the headlines now? Come on...
Re:Most apps only get used for a few seconds anywa (Score:5, Funny)
oh, you mean like my single-serving friends that I meet in my travels
Re: (Score:2)
“The Jekyll app was live for only a few minutes in March, and no innocent victims installed it, Lu says,”
So it "wreaked havoc" when no one installed it? lolwut?
"No innocent victims" != "no one"
Re: (Score:2)
So, then, someone did install it, as opposed to "no one."
Kinda funny how your defense contradicts itself.
Re: (Score:2)
I think RLS already beat you to that pun.
Re: (Score:2)
made the app store....rotten to the core! LOL
You're entitled to a free pair of sunglasses and a "YEEEEEAAAAAAAHHHHHH!!!!!" for every pun like that you make.