Number of XcodeGhost-Infected iOS Apps Rises

An anonymous reader writes: As the list of apps infected with the XcodeGhost malware keeps expanding, Apple, Amazon and Baidu are doing their best to purge their online properties of affected apps, malicious Xcode installers, and C&C servers used by the attackers to gather the stolen information and control the infected apps/devices. China-based jailbreaking Pangu Team claims that the number of infected app is higher than 3,400, and have offered for download a free app that apparently detects the Trojanized apps.

Comments

Detects and exploits

[xxxJonBoyxxx]

>> free app that apparently detects the Trojanized apps

"detects and exploits" probably

Re:Detects and exploits

[Junta]

"It's an App!" - Admiral Ackbar

Re:Detects and exploits

[U2xhc2hkb3QgU3Vja3M]

"It's a trap!" - Admiral Appbar

Re:Detects and exploits

[Anonymous Coward]

"It's a fap!" - Admiral Jackbar

Re:Detects and exploits

[Anonymous Coward]

"It's a map!" -- Ad-trial Ackbar

Re:Detects and exploits

[drinkypoo]

"It's a *!" -- Admiral fapbar

Re:Detects and exploits

[cfalcon]

Don't slander Pangu. They have a reputation to uphold, and they are already trusted with root on many jailbroken devices- because they have written several of the jailbreaks. All the guys that make jailbreaks happen don't want to see people fucking with jailbreakers.

Re:Detects and exploits

[Anonymous Coward]

The name Pangu makes me hungry. Reminds me of paigu.

Still better than that malware Android

[Anonymous Coward]

Still better than that malware Android

Re: Still better than that malware Android

[Anonymous Coward]

With the exception of iOS, I agree with your statement.

Re:Still better than that malware Android

[Anonymous Coward]

Still better than that malware Android

Right? I mean, who wants the freedom to change anything they want to on their device? Apple knows what is best for its users, and they'll like it.

Re:Still better than that malware Android

[Anonymous Coward]

Apparently not. Just so you understand, no walled-in garden experience is truly safe: Android, Apple, you name it. When you choose your platform, you choose your master, feudal lord, whatever. You are by definition, a slave. The platform's update mechanisms, software, and other controls are out of your control. Full stop. This sophomoric tripe about Android this, iOS that is fanboy drivel. Use the platform that suits you. Deal with the warts that come with it.

I've been in IT for across three decades. I've seen it all. None of the platforms are trustworthy, either from lax security processes or outright maliciousness on the part of submitters, or both. The reasons don't matter. How you respond and mitigate is what matters, since the control is not yours in the end.

Safe bet is to wipe the device in question if malware is suspected and refrain from apps until the problem is resolved. No apps are that compelling or needed that one cannot wait. As a species, we have become dumber because of smart phones. I can suss out a 20% tip in my head in seconds, but I see people doing it on their smartphones. Why? Thinking for yourself challenges your brain. I'll likely get flamed for this post, because the /. readership is not what it once was. These days I'm convinced it's mainly Apple/iOS hipster shills, homosexuals, and feminists.

Re: Still better than that malware Android

[Anonymous Coward]

Based on the modded up comment of the Apple Fanboi I'm inclined to agree with your hipster remark!

Re:Still better than that malware Android

[Anonymous Coward]

Way to hint at bigotry. Who cares if "homosexuals" read slashdot, how does that affect you at all? FULL STOP. It doesn't.

Now tighten up your manbun.

I agree, both "ecosystems" have their flaws. there's a start difference between IOS and Android.

IOS is a walled in garden, closed source, and you have to PAY to be a developer. You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed

Android is open source, and while you are selling a bit of your soul to google, you can EASY strip any remnants of google from your device and still have a perfectly functional smart phone. You can decide where you get your apps from, and you can download the SDK and start building apps for free, RIGHT NOW.

Both app markets are full of garbage, for every 1 good app there's 30 rip offs of varying quality and functionality. Both market places have had infected apps hosted on them.

The difference is, on android you have the ability to view the code and see what's going on, not ever app releases it's code or even in a human readable form, but the source code for android is out there, with thousands of eyes on it.

If you trust ANY hardware/software manufacturer to have your best interests at heart you are a fool, they are in it for money, they are owned by the shareholders and do whatever maximizes profit at their behest.

Offering a stable and secure produce is tertiary.

Re:Still better than that malware Android

[jazzis]

Troll much?

Re:Still better than that malware Android

[U2xhc2hkb3QgU3Vja3M]

I can suss out a 20% tip in my head in seconds, but I see people doing it on their smartphones. Why?

Reply #1: Oh, look at me, I'm a human calculator! I'm smart, you're dumb!

Reply #2: Thinking is hard! Let's go shopping!

Reply #3: People are lazy.

Reply #4: (insert your own reply here, I'm too lazy to think of another one)

Re:Still better than that malware Android

[U2xhc2hkb3QgU3Vja3M]

It's spelled iOS not IOS. Would you like it if people wrote anDroid?

Re:Still better than that malware Android

[ComputerGeek01]

I can suss out a 20% tip in my head in seconds, but I see people doing it on their smartphones. ... I'll likely get flamed for this post, because the /. readership is not what it once was.

Dangum Cleatus! He done got been able to shift yon decimal point and multiplies it by two! HooWee that there's a smart fella! I reckon the rest of us hill folk'll have to go an' un-dawn our socks to calculate that particular quandary. 'Dis here sophistimicated gentleman should be our next precedent! AC for the White House!

Re:Still better than that malware Android

[CodeArtisan]

Still better than that malware Android

Android doesn't trade on it's walled-garden security.

Re:Still better than that malware Android

[Anonymous Coward]

Yep, definitely some mac users with mod points. There is help from the BOFH however:
  "What's wrong with Apples?"

"They're just not real computers," the PFY says. "They're the piano accordion of the computing world, entertaining, but not made for professionals."

"Our Graphics people..."

"Yeah, but they're not professionals. They'd be just as happy with crayons and finger paints!"

"I... So what happened to your friend?"

"COLLEAGUE!"

"Er, colleague?"

"Who knows?" I say. "He might have run away to join the circus or he might have handed himself in for deprogramming."

"Deprogramming?"

"Yeah," the PFY says. "They strap you into a wheely chair and play In-A-Gadda-Da-Vida at 11 through headphones to you while administering electric shocks - until you renounce your faith."

"And they actually have places that do this sort of thing?"

"Yeah, they're everywhere. All you need is a place where no-one will notice a geek twitching, screaming and occasionally wetting themselves in front of a computer."

"In other words the gaming area of an internet cafe," I say.

"...And this works?"

"Who cares?" the PFY says. "They're filthy Mac users!"

Re:Still better than that malware Android

[gstoddart]

He done got been able to shift yon decimal point and multiplies it by two

You know, that there exists apps to calculate a tip says that a shocking amount of people can't do this very basic bit of math.

Apparently there is a significant enough portion of society who need help for this. Hell, I've actually watched people struggle to calculate 10%, which is utterly mind boggling.

I don't know if people are really that stupid, or just so lazy as to have the same damned effect.

Re:Still better than that malware Android

[mrchaotica]

It matters because "IOS" is a different operating system, made by Cisco. Sure, it's clear from context which one is being talked about in this case, but that's not always true.

(On a related note, it was pretty stupid of Cisco to license the trademark.)

Re:Still better than that malware Android

[mrchaotica]

I can suss out a 20% tip in my head in seconds, but I see people doing it on their smartphones. Why?

Reply #1: Oh, look at me, I'm a human calculator! I'm smart, you're dumb!

To calculate a 20% tip, move the total's decimal point one place to the left then multiply by two. Everyone should be capable of that. Calculating a 15% tip is slightly harder (requires dividing by two, then adding the original and divided value), and an 18% tip is reasonable to use a calculator for.

Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!

Re:Still better than that malware Android

[macs4all]

Still better than that malware Android

Android doesn't trade on it's walled-garden security.

That's because it CAN'T.

And this was done by fairly sophisticated means, ya gotta admit.

And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?

Re:Still better than that malware Android

[tlhIngan]

IOS is a walled in garden, closed source, and you have to PAY to be a developer. You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed

Not anymore. XCode 7 adds the ability to deploy to any personal device for "free".

Quoted because you need a Mac to run XCode.

But as long as you compile the code yourself (way to go - a proprietary OS enforcing open-source!), you can load the code on your phone.

In fact, there are emulators out there (like provenance, gba4ios, etc) that people are using just fine on their iOS devices. All you need to do is get the code from a tarball or git/svn/etc, open in XCode, build and deploy to your iPhone or iPad or whatever.

No, it doesn't qualify as "Free" because the built binary is limited to running on your own devices.

And the iOS sandbox was not breached - the amount of information the malware could access without alerting users was pretty limited anyhow - you could get the date, time, application ID, UUID (which because of advertising, is now different per-app) and a few other things. If the malware tried to access contacts, photos, or GPS, an alert would show up asking if the user wanted to allow or deny the action.

Of course, if said iOS device was jailbroken, then the malware could get way more information because the sandbox would be broken.

As bad as it goes, the infected apps really get less information than a typical app which wants to do in-app advertising.

Re:Still better than that malware Android

[0123456]

And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?

Would Android malware even need it, when every dubious app demands all possible permissions before it will install?

Re:Still better than that malware Android

[macs4all]

And also, this is the first known breach affecting more than one application since the iOS App Store opened in 2008. Who KNOWS if this has been going on in Android?

Would Android malware even need it, when every dubious app demands all possible permissions before it will install?

Good point!

Re:Still better than that malware Android

[drinkypoo]

Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!

The minimum wage hasn't kept up with inflation in over twenty years. Be a sport.

Re:Still better than that malware Android

[tepples]

IOS is also the name of the Wii's operating system, developed by Nintendo and BroadOn.

Re:Still better than that malware Android

[tlambert]

To calculate a 20% tip, move the total's decimal point one place to the left then multiply by two. Everyone should be capable of that. Calculating a 15% tip is slightly harder (requires dividing by two, then adding the original and divided value), and an 18% tip is reasonable to use a calculator for.

Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!

To calculate an 18% tip, move the decimal place again, and subtract that value from the 20% value you calculated.

Unless, you know, dividing by two combined with addition is easier than multiplying by two and subtraction?

P.S.: Yes, I know: New Math rather than rote memorization of up to two digit by two digit operations so that you can instantly spit out answers it takes more than a few seconds for a 20 year old to process through is "better", right? ;^)

Re:Still better than that malware Android

[tlambert]

Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!

The minimum wage hasn't kept up with inflation in over twenty years. Be a sport.

Restaurant prices have kept up with inflation... so a 15% tip on the restaurant bill has also kept up with inflation.

Re:Still better than that malware Android

[jittles]

As bad as it goes, the infected apps really get less information than a typical app which wants to do in-app advertising.

Unless the infected app is supposed to request permissions for GPS, address book, calendar, photos access, etc etc. If snapchat were to become infected, as an example, they would have access to pretty much every piece of information you can get inside a single app except for the calendar.

Re: Still better than that malware Android

[BronsCon]

Yes, it was. The counterfeit XCode the affected developers are using is dropping additional code into their projects. Think about that, seriously. That means the code is in their app (even if they can't see it). Again, think about that. Do you see how this indicates that, perhaps, a developer might be able to slip their own malware code into an app? This is only the first *detected* instance of this, because fewer people have been looking. It's probably safe to hold your breath until the next one.

Re:Still better than that malware Android

[XxtraLarGe]

You know, that there exists apps to calculate a tip says that a shocking amount of people can't do this very basic bit of math.

Some of them also help split the bill & can do the tips on each order. Not terribly difficult to do, but made easier with an app.

Re:Still better than that malware Android

[Sleuth]

Of course, if said iOS device was jailbroken, then the malware could get way more information because the sandbox would be broken.

Actually, not always... Not all jailbreaks remove app sandboxing by default. They allow the user to pick apps that can be allowed access outside the sandbox, but they don't have to remove app sandboxing for all apps. (But it depends on which jailbreak we are talking about. There have been versions that remove all sandboxing.)

Re: Still better than that malware Android

[Karlt1]

So does that "freedom" come with the ability to update the OS the day a new version is released?

Without waiting on the carrier?

And the manufacturer?

For up to four years after you bought the phone?

Re:Still better than that malware Android

[beanpoppa]

Even moreso, Cisco owned the trademark on iPhone, too http://www.cultofmac.com/143006/how-steve-jobs-steamrolled-cisco-on-the-name-iphone/

Re:Still better than that malware Android

[Anonymous Coward]

It's not calculating the tip that's hard, it's adding it to the total!

ha

Re: Still better than that malware Android

[Karlt1]

Now tighten up your manbun.
I agree, both "ecosystems" have their flaws. there's a start difference between IOS and Android.
IOS is a walled in garden, closed source, and you have to PAY to be a developer.

Android is open source - except for the large part that is Google Play Services, and Google apps, and many of the hardware drivers, and the third party apps that most OEms and carriers put on their phone.

Parts of iOS are open source (Darwin). It's a distinction without a difference.

You don't have to pay to be a developer, you can download XCode for free and install any apps you create with it on your own devices.

You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed
Android is open source, and while you are selling a bit of your soul to google, you can EASY strip any remnants of google from your device and still have a perfectly functional smart phone.

Except for the fact that many apps depend on API's that are part of the closed source Google Play services....

You can decide where you get your apps from, and you can download the SDK and start building apps for free, RIGHT NOW.

And you can download XCode for free RIGHT NOW....

Both app markets are full of garbage, for every 1 good app there's 30 rip offs of varying quality and functionality. Both market places have had infected apps hosted on them.

The big differences are that iOS has better sandboxing that was able to keep even the infected apps from doing any real damage and when there is a vulnerability and Apple releases a patch, every IOS device worldwide released in the last four years can be updated that day without waiting on your carrier.

The difference is, on android you have the ability to view the code and see what's going on, not ever app releases it's code or even in a human readable form, but the source code for android is out there, with thousands of eyes on it

Except for the large parts of the code that encompasses Google Play Services, drivers, OEM and carrier installed apps.....

Re:Still better than that malware Android

[Anonymous Coward]

Apple's walled garden seems to be truly safe. This is for jailbreakers who break the walled garden. Obviously if users have root on the device, they can be tricked into doing bad things. If the exploit path is, you download a jailbreak from China, leave it connected to your phone, tell your phone you trust the computer, give the jailbreak program admin on your PC (all of which is still safe), then go into Cydia, decide that the apps they offer for your jailbroken phone aren't good enough, then add a repo according to instructions on a website, then give their random code root on your phone too... then it's safe to say you left the walled garden quite some time ago.

Not shitting on jailbreakers here, but this is a massive amount of effort to go through to land on some fucking malware.

Re:Still better than that malware Android

[cfalcon]

And this isn't about Apple's security. Remember, YOU MUST JAILBREAK for this to bite you. Much more than just jailbreak. Not only do you have to give some Chinese hacker group admin permission on your PC (which seems to be totally safe, but hey, this would normally be a red flag, right?), then you have to tell your phone that you trust what's going on. Then you have to take the jailbroken thing which provides its own repo of code, and say "nope, still not dangerous enough", then find some russian hacker repo and add that to trusted, then download a thing out of that, and THAT thing is what fucks you.

So don't put this on Apple. Don't put this on TaiG or Pangu. Don't put this on Cydia. This requires a serious level of idiocy on the user's end, combined with persistence. Apple is safe. Jailbreaking is mostly safe. Jailbreaking your Apple then adding fly by night bullshit that the standard jailbreak community doesn't trust is not safe. Fucking derp?

Re: Still better than that malware Android

[macs4all]

Yes, it was. The counterfeit XCode the affected developers are using is dropping additional code into their projects. Think about that, seriously. That means the code is in their app (even if they can't see it). Again, think about that. Do you see how this indicates that, perhaps, a developer might be able to slip their own malware code into an app? This is only the first *detected* instance of this, because fewer people have been looking. It's probably safe to hold your breath until the next one.

I guarantee the implications of this are NOT lost on Apple. I would be VERY surprised if this HASN'T caused a major shitstorm in the Development corridors at Apple, and I am sure that they are working on a permanent solution to this even as I type.

Re: Still better than that malware Android

[BronsCon]

There is no solution, but I look forward to seeing what functionality my iPad and my wife's iPhone lose as a result of whatever they propose as a "solution" in the next iOS update.

Re: Still better than that malware Android

[macs4all]

There is no solution, but I look forward to seeing what functionality my iPad and my wife's iPhone lose as a result of whatever they propose as a "solution" in the next iOS update.

What the hell was that snarky-ass comment about?

Why would you surmise that it would affect iOS, per se? This is a Dev. Toolchain issue, and that is only OS X.

Can't ANYONE have at least a SEMI-erudite discussion around here? Or has this site just devolved into a free-for-all orgiastic pyre of hate?

Re: Still better than that malware Android

[Anonymous Coward]

There is a simple solution that has no impact on the user at all, or actually might improve user experience. Just for devs to upload the source code to their app to Apple's servers and have Apple compile it in the cloud. Then they can make custom binaries for ever device type and run their own checks. Hell, Xcode7 almost does this now, since when you submit to the appstore it produces bytecode that Apple then uses to make custom binaries for each device type. So adding the source code upload functionality to Xcode 8 will be trivial. Might even be in a Xcode 7 point release. Either way, this problem is easily fixed, and you are a dumbass.

Re: Still better than that malware Android

[BronsCon]

This is not a dev toolchain issue. The attack avenue was the dev toolchain, but the code ended up in the binary which ended up in the App Store. you know, just like the code the app author actually wrote.

To clarify, it ended up the same place it would have ended up had the app author written it themselves. In other words, malware made it past Apple's screening process.

To further clarify, there is nothing special about how the malware was compiled into the binary that helped it pass Apple's screening process; only that it lay dormant until after the screening was complete.

Re: Still better than that malware Android

[BronsCon]

Yes, because Apple compiling the source will prevent the developer from inserting their own malware? It's not like Apple is going to review the source (though many people believe, incorrectly, that they already do). And if Apple did start reviewing code, you can guarantee that developers like Adobe, or anyone else who considers their code a trade secret, would drop out fast.

That's also ignoring that the code being injected by the affected copies of XCode is injected just ahead of compilation; why could it not similarly be injected just ahead of being uploaded in your proposed scheme?

Re: Still better than that malware Android

[macs4all]

This is not a dev toolchain issue. The attack avenue was the dev toolchain, but the code ended up in the binary which ended up in the App Store. you know, just like the code the app author actually wrote. To clarify, it ended up the same place it would have ended up had the app author written it themselves. In other words, malware made it past Apple's screening process. To further clarify, there is nothing special about how the malware was compiled into the binary that helped it pass Apple's screening process; only that it lay dormant until after the screening was complete.

Actually, I just GUESSED that code MIGHT bypass the Approval Process IF it lay dormant for a period.

But I do agree that this isn't strictly a Dev. Toolchain issue. I stand corrected on that point.

The salient question is "How does Apple change their Approval Process such that this cannot happen again?" Is that even possible? And if it isn't 100% possible, should Apple even try?

Re: Still better than that malware Android

[BronsCon]

Actually, I just GUESSED that code MIGHT bypass the Approval Process IF it lay dormant for a period.

And you guessed correctly.

The salient question has been answered. No, it is not possible. Not every bit of code is executed during every iteration of the main() loop, nor even every time an application runs; there are an infinite number of reasons a given piece of code may lie dormant during a given execution of an application, which precludes the use of dormancy as a review flag. Given that this is something that wither works 100% or works 0%, no, Apple really shouldn't try; it gives users a false sense of security, which is far more dangerous than knowing you're vulnerable.

The very first thing Apple should do is admit that it is, in fact, possible for malware to get past their screening process. Next, they should welcome security researchers to test apps on a continuing basis, and give them the tools required to do so (which currently don't exist in any official capacity, as tools of that nature are not allowed by Apples own policies), as this is how malware is discovered; it's the very reason malware has been discovered in the Play store.

I posit that it is not because there is no malware in the App Store that none has been detected until now, but because the detection tools have not been allowed to be created and run until XCode 7 began allowing sideloading, which is a very recent development. Android has always allowed this and, thus, those tools have always existed for Android. It will be very interesting to see how much more malware is found in the App Store now that everyone and their mother is looking for it, having been proven possible.

There is no point in debating this further; only time will tell which of us is correct.

Re: Still better than that malware Android

[BronsCon]

Also... f**k my HTML skills this morning. the only thing in that entire post that should be italicized is the is at the head of the italicized block.

Re: Still better than that malware Android

[macs4all]

Also... f**k my HTML skills this morning. the only thing in that entire post that should be italicized is the is at the head of the italicized block.

I hate it when that happens.

Re: Still better than that malware Android

[macs4all]

Not every bit of code is executed during every iteration of the main() loop, nor even every time an application runs

But that is IRRELEVANT to a code-review. It is whether a particular API Call EXISTS; NOT whether it is sitting inside a CASE or IF Statement that appears to be never reached. Even an Object Code (as opposed to Source Code) Review can spot API calls a MILE away. You can only Obsfucate SO much. It's when an App has a "legitimate" purpose for making that API Call that things get dicey. But when a Hello Kitty Game App digs into your Contacts, or your Emails, then a phone call to the Developer to see the Source is probably in order before Approval. As far as XCode goes, since Apple controls that Toolchain, it SHOULD be possible to have XCode "Police" Itself.

Or possibly, perhaps Apple changes the Submittal Process such that you (The Submitter) send Apple the XCode PROJECT FILES, and APPLE does the Final Compilation for the version that appears in the App Store. Big Vendors, such as Microsoft, Adobe, AutoDesk (and VERY few others) would be exempt from this rule; but for all the smaller Devs, THEY would have to have their Source COMPILED BY APPLE, on their "blessed" Copy of XCode. THAT, along with Source Code Review for Apps requiring certain types of API Calls, MIGHT actually come close enough to a perfect solution to be worth the extra trouble.

The very first thing Apple should do is admit that it is, in fact, possible for malware to get past their screening process.

This meme needs to FINALLY be taken out back and SHOT: As I said elsewhere in this thread; I don't think that APPLE has ever said that. Instead, it seems to be almost universally Fandroids that SAY that Apple (or their Users) have said that.

Please correct me if I'm wrong, and you can find ANY evidence that APPLE ITSELF has EVER said that their App Store Approval Process GUARANTEES no Malware.

Apple really shouldn't try

On this, I wholeheartedly DISAGREE.

Re:Still better than that malware Android

[morphotomy]

If I can sudo rm -rf / then I'm not really free.

Re: Still better than that malware Android

[BronsCon]

For entertainment's sake, I think Apple should do what you're proposing here. I'm sure there will no outcry whatsoever from the developer community.

Fandroids that SAY that Apple (or their Users) have said that.

As stated in the other thread where you raised this "issue", I've grown sick of my Apple fanboi friend making the claim that "this wouldn't happen on iOS" every time there's even a hint of a mention of Android malware. Hopefully this will put an end to it. And you can't really call someone sitting in front of an iPad and a Mac that are his two primary computing devices a Fandroid. Just sayin'.

Re: Still better than that malware Android

[brantondaveperson]

Of course there are solutions. Have developers submit their source for Apple to build, instead of an already-built bundle. This could be through an automated process that does not expose the source to Apple or to anyone else, and would prevent trojanned toolchains of any sort.

However, it seems to me that a trojanned xcode isn't really the issue here. If the malware was hidden inside the provided application files, then what's to prevent people from doing the same kind of thing knowingly?

Re: Still better than that malware Android

[brantondaveperson]

I think it's a question of scale.

With the compromised toolchain, a large number of infected apps were submitted. Depending on how the malware is hidden inside the app, tracking down all of them infected apps might be difficult. If the malware authors were smart, and I rather assume that they are, then each of the apps may be infected in subtly different ways.

With your regular malware author, a single infected app is submitted, and when discovered is removed and (presumably) the developers account suspended with no refund. It's trivial in this case to determine who wrote the malware, and fairly possible to direct the appropriate law-enforcement personnel to their house.

In the first case, not so much.

Re: Still better than that malware Android

[brantondaveperson]

I think you should, in general, avoid capitals.

It's bad style, and obscures your point. With which I wholeheartedly agree, as it happens.

I wonder, could apple even store the source code, for subsequent examination should your app ever prove malicious? It's a very interesting idea, and I'm going to bet that Apple are considering that option seriously.

Re:Still better than that malware Android

[drinkypoo]

Restaurant prices have kept up with inflation... so a 15% tip on the restaurant bill has also kept up with inflation.

Right, but food runs hot and cold... well, no, that's water. But the point is, there's good and bad times and sometimes they have to live on sub-minimum-wage so help 'em out eh? Unless they're better dressed than you, then ok, 15%

Re: Still better than that malware Android

[macs4all]

I think you should, in general, avoid capitals.

It's bad style, and obscures your point. With which I wholeheartedly agree, as it happens.

I wonder, could apple even store the source code, for subsequent examination should your app ever prove malicious? It's a very interesting idea, and I'm going to bet that Apple are considering that option seriously.

Sorry, showing my age. When I first started commenting on the interwebs, ther simply wasn't styled text. So, it wasn't uncommon for people to show emphasis with various other methods, including capitalizing. Yes, I know how to use HTML tags in /. Comments, but I get sooooo tired of entering them by hand...

Thanks for the support! I'm sure that Apple is worried about Developer Backlash at the suggestion that they surrender their Source to Apple for Compilation. But I do think it is an intriguing idea.

Re:Still better than that malware Android

[mjwx]

(On a related note, it was pretty stupid of Cisco to license the trademark.)

As much as I dislike Cisco for doing it, they were stupid all the way to the bank.

Re: Still better than that malware Android

[BronsCon]

However, it seems to me that a trojanned xcode isn't really the issue here. If the malware was hidden inside the provided application files, then what's to prevent people from doing the same kind of thing knowingly?

That's precisely what I was getting at when I said:

Do you see how this indicates that, perhaps, a developer might be able to slip their own malware code into an app?

Just a couple messages up in this very thread. That is what I meant by "there is no solution". The context was there the whole time; it's not my fault you didn't care to read it.

Re: Still better than that malware Android

[Anonymous Coward]

Apple owns like ten percent of Adobe, you think they can't already look at all of Adobe's code? How do you think CC got so optimized for Metal? Or how the iPad Pro has Adobe exclusives? They have always had a close relationship.

As for the code, when the developer logs into iTunes Connect and reviews their source on Apples private github or whatever, they're going to say "gee, how come my app has 300 extra lines of code between my last local snapshot and when I uploaded it?" Durr.

Re: Still better than that malware Android

[brantondaveperson]

The context was there the whole time; it's not my fault you didn't care to read it

Typical slashdotter rudeness. Fine. Carry on.

Re:Still better than that malware Android

[tlambert]

Restaurant prices have kept up with inflation... so a 15% tip on the restaurant bill has also kept up with inflation.

Right, but food runs hot and cold... well, no, that's water. But the point is, there's good and bad times and sometimes they have to live on sub-minimum-wage so help 'em out eh? Unless they're better dressed than you, then ok, 15%

The "rule" in San Francisco is 2X sales tax: you don't pay tip on the tax, and it works out to exactly the right percentage to be a "relatively good tipper" on the pre-tax bill.

Re: Still better than that malware Android

[BronsCon]

I know, right? At least you called yourself out on it, thought.

In all seriousness, though, I really did say it just two messages earlier. Are you seriously saying it was rude of me to point that out rather than accept your "correction" as though it hadn't already been said? Might want to take a look at how you approached me before calling my reaction rude.

Re: Still better than that malware Android

[ReeceTarbert]

The very first thing Apple should do is admit that it is, in fact, possible for malware to get past their screening process.

This meme needs to FINALLY be taken out back and SHOT: As I said elsewhere in this thread; I don't think that APPLE has ever said that. Instead, it seems to be almost universally Fandroids that SAY that Apple (or their Users) have said that.

Okay, I'll byte: The safest place to download apps for your Mac is the Mac App Store. Apple reviews each app before it’s accepted by the store

Yes, that's about the Mac App Store. Do you want something about the App Store? No problem: We review all apps submitted to the App Store and Mac App Store to ensure they are reliable, perform as expected, and are free of offensive material

It seems as official as it can get, don't you think?

RT.

Re:Still better than that malware Android

[antdude]

It will be more confusing with both Apple and Cisco making that recent deal. :O

Re:Still better than that malware Android

[drinkypoo]

The "rule" in San Francisco is 2X sales tax: you don't pay tip on the tax, and it works out to exactly the right percentage to be a "relatively good tipper" on the pre-tax bill.

In fact, it works pretty much anywhere in California. It's hard to find a town with less than 7.5% tax. Double the tax and round up.

Re: Still better than that malware Android

[Plumpaquatsch]

Of course there are solutions. Have developers submit their source for Apple to build, instead of an already-built bundle. This could be through an automated process that does not expose the source to Apple or to anyone else, and would prevent trojanned toolchains of any sort.

However, it seems to me that a trojanned xcode isn't really the issue here. If the malware was hidden inside the provided application files, then what's to prevent people from doing the same kind of thing knowingly?

Well, many apps already do what this malware did - which was actually pretty harmless.

Re: Still better than that malware Android

[macs4all]

It seems as official as it can get, don't you think?

...and, from your carefully-manicured excerpts, it DOES seem to IMPLY that Apps from the Apple App Stores are "Safe".

HOWEVER, further down the page (which is about OS X's built-in security features, NOT either App Store), we have the disclaimer:

"While no system can be 100 percent immune from every threat, OS X lets you do even more to keep your information as safe as possible. [emphasis mine] "

So, that sounds more like what I was saying than what you were implying that they were saying.

And as for the second Page you referenced, "App Review", being that it was hosted on Apple's DEVELOPER site, that was obviously NOT meant as a Page for the "General Public"; but rather a Developer-oriented Page to explain TO DEVELOPERS how the Review Process works. So no "claims" are implied.

Nice try, but no phattie.

Re: Still better than that malware Android

[ReeceTarbert]

Nice try, but no phattie.

Look, it's a big mess and we'll probably never know how big it really is. You can deflect all you want and I could nitpick as well as you, but what's the point? Let's just say that Apple's review process leaves a lot to be desired and leave at that, okay?

RT.

Re: Still better than that malware Android

[macs4all]

Nice try, but no phattie.

Look, it's a big mess and we'll probably never know how big it really is. You can deflect all you want and I could nitpick as well as you, but what's the point? Let's just say that Apple's review process leaves a lot to be desired and leave at that, okay?

RT.

Yeah, it leaves so much to be desired that it has kept the App Store pretty much STERILE since it opened seven years ago.

Face it, you tried to "sound bite" yourself into "winning a point" by taking words out of context, not including words that didn't fit your "point" (and which didn't apply to iOS, let alone the App Store), and representing a Developer Page banner as if it was a "Policy Statement", and got yourself caught prevaricating, or at least "creatively editing".

So no, I was not the one "Deflecting" (the fact that you were trying to pull the wool over my, and all readers-of-your-comment's eyes); that would be, er, you.

Re: Still better than that malware Android

[ReeceTarbert]

So no, I was not the one "Deflecting" (the fact that you were trying to pull the wool over my, and all readers-of-your-comment's eyes); that would be, er, you.

Sigh. I'm counting 24 posts from you on this topic. If you're on your little crusade or just get a kick out of defending Apple no matter what, be my guest. I would feel very embarrassed, but hey! whatever rocks your boat.

RT.

Re: Still better than that malware Android

[macs4all]

I'm counting 24 posts from you on this topic.

I'm not sure what you are counting as a "topic"; but I count 7 by me (now 8) in this particular thread.

Those aren't apps!

[Anonymous Coward]

Those hackers secretly installed LUDDITE software on iPhones! App appers know that apps are 100% secure and can't be infected, unlike LUDDITE software!

Apps!

Don't buy apps from made in China, problem solved!

[Anonymous Coward]

If the author's name is Xi Jinping, don't download a thing!

Next...

[Anonymous Coward]

Yesterday it was broken iPhone VPN, today it's hacked apps via xcode. Blah blah blah. Real techs use Android.

Re:Next...

[Anonymous Coward]

Sorry, no. Java is for H1Bs, not "real techs".

Re:Next...

[Anonymous Coward]

Riiiiiight. Because Android never had any problems with malware and broken VPN.

Re:Next...

[Anonymous Coward]

Yeah, real techs use an OS from a fucking advertising company! Right!

Re:Next...

[TheRaven64]

This is true. I have an Android phone, and I don't even need to go to some 'app store' thingy download malware, it still (3 months after initial public disclosure) is vulnerable to the Stagefright vulnerability, which Google researchers have shown is exploitable from the browser and allows privileged arbitrary code execution. None of this crap from Apple, where you need user action to install this stuff!

Re:Next...

[U2xhc2hkb3QgU3Vja3M]

Dumb phones for the win!

Re: Next...

[Anonymous Coward]

Real techs use Linux. Android just happens to run a variant.

Re:Next...

[MobileTatsu-NJG]

The Fandroid response to is that it's great that they have the freedom to have malware. They make it sound like they have all this extra choice but when half a million Android zombie bots appears in China that's obviously the fault of all those morons that had extra choic available to them.

Re:Next...

[macs4all]

Yesterday it was broken iPhone VPN, today it's hacked apps via xcode. Blah blah blah. Real techs use Android.

Ahem. As was pointed out yesterday on Slashdot to a Fandroid who made pretty much the same claim...

Re:Next...

[Anonymous Coward]

The iFanboi response to is that it's great that they have curated malware. They make it sound like they have all this extra security but when half a million iPhone zombie bots appears in China that's obviously the fault of all those morons.

There, I fixed your statement to make it more accurate and properly reflect the facts of the article.

Re:Next...

[Anonymous Coward]

It's really telling that you limited the scope to just this one article.

Re: Next...

[BronsCon]

Blame your phone manufacturer and carrier for your lack of update. I have a Nexus device and had the stagefright update the next day, direct from Google. Same for the password field update (which didn't affect me as I use a pattern lock). Apple has never released a patch that fast for iOS.

Re: Next...

[BronsCon]

Yeah, it tells me the topic of this discussion is the article it's attached to and the poster you're attempting to troll is staying on-topic.

Re:Next...

[Anonymous Coward]

Way to go, Sherlock. You've discovered an issue with an outdated version of Android.

Re: Next...

[Karlt1]

I've never once had to wait on Dell (my PC manufacturer) or whatever computer store I bought my computer from to patch my Windows PC.....

Re:Next...

[macs4all]

Way to go, Sherlock. You've discovered an issue with an outdated version of Android.

Too bad there are plenty of Android Victims, er, Users, that apparently are still running that version, thanks to Android's lack of updating.

Did you notice that there were comments as recently as May, 2015? So how "non-relevant" can it be?

Re: Next...

[BronsCon]

I fail to see how that is relevant here; we're not talking about PCs, but I'll bite anyway.

You do, of course, have to wait for your OS vendor (Microsoft) to patch your Windows PC, just the same as I have to wait for My phone's OS vendor (Google) to patch my Nexus device, or an iPhone user has to wait for their phone's OS vendor (Apple) to patch their iPhone. The difference here is that Google pushes those patches faster than Microsoft or Apple.

to further my point, though, since we're talking about phones: replace your PC with a Windows phone. Does your argument still hold up? Almost.

The companies that make your Windows Phone handset—or even the chips inside them—also frequently provide us updated firmware that they’ve written, tested, and want us to include.

The implication being that, if updated firmware isn't provided, your phone doesn't get an update. Yes, updates all come directly from Microsoft, but they can only be released with the cooperation of the phone manufacturer. Also, although the updates come directly from Microsoft, they still require carrier review and approval before being released.

We work closely with our carrier partners, and encourage them to test our software as swiftly as possible. But it’s still their network, and the reality is that some carriers require more time than others. By the way, this carrier testing is a common industry practice that all of our competitors must also undergo. No exceptions.

Add to that, some (I'd say most) updates are hardware-specific, just as in the iPhone and Android world, and we get this:

One important point worth highlighting: Our update technology allows us to precisely target which phones receive an update. Since some updates are hardware-specific, we don’t send every update to every device.

So, why not just bundle all the drivers and firmware and features and crap into a single image and let the devices use just what they need from all of that? Storage. We're talking about devices that don't have much of it. The solution is to tailor system images to devices, including only the drivers, firmware, and apps that are appropriate for each device. And the carriers have the final say in what is allowed on their networks.

Re: Next...

[Karlt1]

You get updates without waiting for the carrier AND the manufacturer only if you own a Nexus phone - a phone a relatively few people own -- and if the carrier allows it. Verizon (the largest carrier in the US) still blocks immediate updates for Nexus phones

Most security updates aren't hardware specific. If Google pushes an update you still have to wait on both your manufacturer and your carrier unless you are one of the tiny minority of Android users who own a Nexus phone that is not on Verizin and then Google only promises updates for 18 months.

Contrast that with IOS. When Apple pushes an update, all iOS users worldwide regardless of carrier can get the update within 24 hours. Apple is currently supporting every phone that has been released since 9/2011. How many Android phones are getting support that far back?

Last year when Apple patched the goto fail vulnerability around February. it released an update for not only iOS 7 that supported phones released since 6/2010, it also patched iOS 6 to support the 3GS that was released 6/2009. How many Androif devices received a security patch 5 years after they were released?

As far as Google patching security holes faster:

http://arstechnica.com/security/2015/01/google-wont-fix-bug-hitting-60-percent-of-android-phones/

Re: Next...

[BronsCon]

Most security updates aren't hardware specific.

But the system images are. That's kind of the point.

and then Google only promises updates for 18 months

Actually, that's:
- Three years from when the device first became available on the Google Store
- Or, 18 months after the device stopped being sold on the Google Store
For how long does Apple promise to support their handsets?

Apple is currently supporting every phone that has been released since 9/2011

While it is true that the oldest phone Google is directly releasing updates for (Nexus 4) was released on November 13, 2012, the HTC HD2, a Windows phone released in November 2009, has community-released ROMs of Lollipop. Does the iPhone have that? No, the iPhone can't have that. If you want to limit it to official vendor support of devices that originally shipped with Android, we're looking at support dating back to 2010.

http://arstechnica.com/security/2015/01/google-wont-fix-bug-hitting-60-percent-of-android-phones/

You do realize that the security hole in question is a bug in WebKit, which is more Apple's than Google's; Blink, which replaced WebKit in Android in 2013, is a fork of WebKit, and the issue has been patched there already. Google hasn't actively developed Apple's WebKit since it forked off Blink. Also, Google didn't say they wouldn't issue a patch, only that they wouldn't write one:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.

WebView 4.4 is where they replaced WebKit with Blink. They are no longer developing WebKit, so it is a reasonable position.

No less reasonable than Apple, at least. I do miss Snow Leopard.

Also, Google not writing their own patch for a 3rd-party library (WebKit) does not negate the 24hr turnaround I've seen on many issues since I've had a Nexus device; something, again, Apple and Microsoft literally never do.

All of that said, I do think Google screwed the pooch by allowing manufacturers to bake their own ROMs; that's why I own a Nexus in the first place. Android's ability to be customized to allow for quick access to apps and information (literally tap from the lock screen, then unlock) far surpasses that of iOS, which is why I prefer Android on the device I carry with me to pull out of my pocket when I want/need to access information quickly; it does lose that advantage on a tablet, which is typically only picked up to perform tasks (rather than the fetch information), which is why I also have an iPad.

Re: Next...

[Karlt1]

But the system images are. That's kind of the point.

What good are the "system images" if you can't update your phone with it -- unless you are one of the tiny minority that have non-Verizon Nexus devices?

Actually, that's:
- Three years from when the device first became available on the Google Store
- Or, 18 months after the device stopped being sold on the Google Store
For how long does Apple promise to support their handsets?

Lets look at history:

iPhone 3GS
-release 6/2009
-discontinued 6/2011
-last update 2/2014

iPhone 4 -
-released 6/2010
  discontinued 6/2013
- dropped support with iOS 8 (9/2014)

iPhone 4s
-released 9/2011
-discontinued 9/2014
-still receiving updates

iPhone 5
-released 9/2012
-discontinued 9/2013 still receiving updates

iPhone 5c
-released 9/2013
-discontinued 9/2015
-still receiving updates

iPhone 5s and later are still being sold

So if you bought any iPhone when they were the top of the line phone, you got at least four years of support. If you bought any Nexus phone when they were the top of the line phone, do you still receive updates after four years.

But Nexus phones have never been top sellers. So most Android users aren't buying Nexus phones.

You do realize that the security hole in question is a bug in WebKit, which is more Apple's than Google's; Blink, which replaced WebKit in Android in 2013, is a fork of WebKit, and the issue has been patched there already. Google hasn't actively developed Apple's WebKit since it forked off Blink. Also, Google didn't say they wouldn't issue a patch, only that they wouldn't write one:

WebKit was not "more Apple's than Google's". Before Google split Blink from WebKit, they had just as many commits to the code base as Apple.

http://appleinsider.com/articl...

Even if that's not the case would you argue that they shouldn't make a security patch in Android that was found in the Linux kernel because it wasn't "theirs"?

Could Apple get away with not patching a vulnerability found in the Darwin kernel because it was actually an issue with BSD?

And the issue was with Google's implementation of the WebView that uses WebKit, iOS didn't have the same vulnerability.

Also, Google not writing their own patch for a 3rd-party library (WebKit) does not negate the 24hr turnaround I've seen on many issues since I've had a Nexus device; something, again, Apple and Microsoft literally never do.

WebKit was not a "third party" library. It was an open source library that Google committed just as much code to as Apple. The code in question was integrated in the AOSP.

Android's ability to be customized to allow for quick access to apps and information (literally tap from the lock screen, then unlock)

Huh? For access to notifications you just swipe down on a locked phone to get to the notification and you swipe right on the actually notification to do some application defined event with it.

Or the notification pop ups directly on the screen depending on how you have notifications set for the app.

Re:Next...

[BronsCon]

thanks to Android's lack of updating

You mean thanks to lack of updates from device manufacturers and carriers. Android sees quite frequent updates and, if you own a phone not manufactured by a customer-hating profit-mill (e.g. a Nexus device) on a network that doesn't insist on being a control freak (e.g. anyone but Verizon), you get those updates as they come out.

That Nexus users are in the minority does not negate the fact that the lack of updates for non-Google-branded devices are the fault of the device manufacturers, not that of Google. Some of use are smart enough to know how things work and purchase accordingly; everyone else would be just as bitten by 3rd-party iOS devices, were Apple to license iOS. Really, that's the only mistake Google made here: licensing Android to irresponsible 3rd parties; but, then, Google never claimed to provide support for 3rd-party devices (that's up to the device manufacturer, after all), so people are still getting exactly what they bought.

Me? I bought a device that gets its updates direct from the OS vendor, just like you did.

Re: Next...

[BronsCon]

Even if that's not the case would you argue that they shouldn't make a security patch in Android that was found in the Linux kernel because it wasn't "theirs"?

No, and neither would they. Again:

If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.

Since the kernel is part of AOSP, if the kernel is patched, the patches are put into AOSP.

For access to notifications you just swipe down on a locked phone to get to the notification and you swipe right on the actually notification to do some application defined event with it.

And for access to directions, drive times, weather, stocks, and the plethora of other information I can train Google Now to display on my lock screen whenever it might actually be relevant to me (and hide at other times)? Seriously, as much as you think I must hate iOS, I can assure you (as evident by my extensive use of an iPad) that I do not; and choosing another platform over iOS for a specific use-case does not show otherwise, nor does complaining about the lack of a specific feature. If I hated the platform I'd not care if it lacked a feature I wanted; it wouldn't affect me in the slightest. As is, though, it's one of the handful of reasons I don't own an iPhone, despite the rest of my primary devices being from Apple.

Go ahead and insist that I must be a Fandroid, though. Ignorance in the face of repeated correction seems to suit you well.

Re: Next...

[Karlt1]

No, and neither would they. Again:

You claimed that Google shouldn't have to patch WebKit because it was "third party" code. WebKit -- that Google had just as many commits to as Apple -- is much less "third party code" than the Linux kernel, but it is just as much Google's responsibility to patch security holes found in WebKit as it is the Linux kernel if it affects Android.

Since the kernel is part of AOSP, if the kernel is patched, the patches are put into AOSP.

So are you saying that it is not Google's responsibility to patch security vulnerabilities and that they should wait for someone else to do it? Should Apple have waited to patch the "goto fail" bug that was part of the open source Darwin kernel?

And for access to directions, drive times, weather, stocks, and the plethora of other information I can train Google Now to display on my lock screen whenever it might actually be relevant to me (and hide at other times)?

So being on the lock screen is a major advantage over unlocking your phone just by grabbing it, having it unlock automatically with your fingerprint and sliding down to get to the notification centers "Today tab" where you can also see drive times based on your behavior, weather, stocks, appointments, flight times based on your emails, etc.? If that's not good enough -- you can install the Google app on an iPhone and get the same notifications in the Today view....

Go ahead and insist that I must be a Fandroid, though. Ignorance in the face of repeated correction seems to suit you well.

Right, I'm the one that thought "WebKit" was a "third party library" when Google actually had more commits to the WebKit repository when the security issue was found in Google's implementation of it.

Re:Next...

[0123456]

Me? I bought a device that gets its updates direct from the OS vendor, just like you did.

So did I. They've now abandoned it for anything other than security updates, even though it was still on sale less than a year ago.

That's why I dumped the Nexus and bought an iPad.

Re: Next...

[BronsCon]

Google had just as many commits to as Apple

Google had just as many commits to as Apple

So you just change the facts to fit your argument? If you can't even agree with yourself, what makes you think anyone else will? Good day, sir.

Re: Next...

[BronsCon]

WTF... Quote fail... Here's the contrast I was trying to show...

Google had just as many commits to as Apple

Google actually had more commits to the WebKit repository

Re:Next...

[BronsCon]

Which device is that, might I ask? Google supports their devices for a minimum of 3 years from when they start selling them, or 18 months from when they stop, whichever is longer; if you bought it less than a year ago from someone else, well, they can't do anything about that now, can they? By that logic, if AT&T still had an original Nexus sitting in a closet somewhere and sold it to you today, you might expect them to support it with new updates for another 18 months, no? Yeah, doesn't work that way anywhere.

Which iPad did you end up with? If it's anything older than the Air 2, let me ask you this: How are you enjoying split-screen in iOS9?

I know to ask that because I have the Air, not even 2 years old and, while it did get iOS 9, it didn't get the most important feature. Meanwhile, 2 year old Nexus devices are getting not only the latest versions of Android, but all of the features, as well; and even if Google drops support, the community keeps it up. That's something you don't get with an Apple device, because Apple won't allow it.

Re: Next...

[Karlt1]

If I have 6 Apples and you have 5 Apples

1. I have just as many Apples as you do.

2. I also have more Apples than you do.

Those two statements are not mutually exclusive.

That's just like the old kids riddle "how many months have 28 days?"

Re: Next...

[BronsCon]

Actually, the modifier "just" means "exactly" in the context of a comparison.

Example:

how many months have 28 days?

12

how many months have just 28 days?

1

Re: Next...

[BronsCon]

I forgot do address this in my other reply, so here we go...

What good are the "system images" if you can't update your phone with it -- unless you are one of the tiny minority that have non-Verizon Nexus devices?

You do realize that iOS updates are system images, right? System images aren't just something for Nexus devices on networks other than Verizon; they're how iOS and Android devices get their OS updates. Period.

Your iDevice literally downloads a disk image and overwrites the system partition. That's how most android upgrades work, as well. In more recent versions of Android, the Google stuff is more decoupled from AOSP, so those components can be updated as apps, much like the non-OS Apple components of an iOS install. On both iOS and Android, the original system apps still reside on the system partition, while updates installed on the same partition as normal apps and simply take precedence over the originals; that's why you can uninstall updates to system apps, but not the apps themselves.

Android and iOS update in very much the same way. I do applaud Apple for making recovering form a failed update somewhat simpler than it is on Android (it's a couple clicks in iTunes) but I'll also say the only time I've seen an Android update fail was when I tried to shoehorn a ROM meant for a different model onto my phone, whereas I've had to recover several iPods, iPhones, and iPads (both mine and my wife's) from failed iOS updates. Overall, I's estimate I've spent less time recovering Android than iOS, despite the recovery process for Android requiring a fair bit more manual intervention.

Re:Next...

[Anonymous Coward]

I guess you are unaware of CyanogenMod, AOSP and xda devs.

Re:Next...

[brantondaveperson]

If it's anything older than the Air 2, let me ask you this: How are you enjoying split-screen in iOS9?

It's an Air 1, and the split screen is fine, thanks for asking.

Re:Next...

[brantondaveperson]

You mean thanks to lack of updates from device manufacturers and carriers.

Technically true, but irrelevant if you actually own a device that isn't being updated. Which is most people that own Android devices.

It's simply a fact that iOS devices are kept up to date much more than Android devices. Whether or not this is Google's fault, or even within their control, is not important. This is part of the fragmented nature of Android, and is quite simply true.

Re:Next...

[macs4all]

I guess you are unaware of CyanogenMod, AOSP and xda devs.

I am aware of them just fine; but if I have to essentially "Jailbreak" my Android to fix it, then that's hardly a viable solution for most people that have any phone, including most people that own most Android phones.

Re:Next...

[BronsCon]

And an informed buyer will know to limit their purchases to Apple or Google (Nexus) devices, based on whichever best suits their needs. Non-Nexus Android devices are irrelevant to me, given that I know they're unlikely to receive updates long-term; Apple's history of supporting devices for 4 years is doubly irrelevant to me, as it is not a guarantee (as is Google's 3 year from initial date of sale, 18mo from final date of sale) and because I replace my phone at least every two years anyway.

given the above, I know that Android works better for the way I use a phone and iOS works better for the way I use a tablet. So, for me, it's a Nexus 6 and an iPad Air. You use what works for you, and try not to get offended when someone points out an issue with your pet platform, m'kay?

Re:Next...

[Anonymous Coward]

CyanogenMod offers a one click installer that automatically does everything.

Re: Next...

[TheRaven64]

I bought my phone from the company that Google owned at the time, directly. They've apparently released an update to 'carrier partners', but not yet through their own update server (for those of us who didn't by the phone through a carrier). Their web site claims that I should be able to upgrade to 5.1, but the update doesn't appear. Meanwhile, colleagues with much older iPhones are still getting security updates (and need them less because the iOS sandboxing model isn't nearly as braindead as the Android one).

Oh, and that patch you got the next day from Google didn't fix the issue. I hope you also installed the update from a couple of weeks later that did...

Re: Next...

[Karlt1]

Apple no longer uses complete system images for over the air updates. After so many people couldn't update their phone because of lack of storage space they went to just using diffs.

But a properly designed operating system that is meant for different hardware from different manufacturers like Android should be able to do modular updates. Microsoft has been able to do it for over 20 years. I don't have to wait on the hardware manufacturer to provide OS updates or even low level drivers to update the OS. Microsoft takes on that burden. When I installed Windows 7 on my 2006 Mac Mini (that Apple abandoned) it recognized all of my hardware.

Re:Next...

[macs4all]

CyanogenMod offers a one click installer that automatically does everything.

But how many plain, ordinary Users even have heard of CyanogenMod, let alone what it's about?

And that still begs the question: How awesome [not!] of an "ecosystem" must Android be, if you have to resort to "Jailbreaking" your device JUST to get a frickin' SECURITY UPDATE?!?

Yes, I know it's not "Android's" fault, per se; but it IS a SYSTEMIC problem on that platform with 95% of the OEM -> Carrier -> End-User scenarios.

Re: Next...

[BronsCon]

I do think my last Android update was a bit small to have been a system image, now that you mention it. Still, when Samsung et-al change system files and configurations from stock for their (useless, buggy, and oft shitty) skins, suddenly things that shouldn't be device-specific are. That's why Google can only offer updates directly for Nexus devices. It's also why they've been decoupling the Google ecosystem more and more from AOSP, so those parts become apps and can be updated regardless of manufacturer.

In Lollipop, they changed how carrier apps work. They're no longer baked into the ROM but, rather downloaded during setup based on the inserted SIM; no SIM, no carrier apps. The next logical step is to provide a partition for manufacturer apps (skins and such, like TouchWiz or Sense) and lock down /system completely. Then, Google will be able to update phones directly, provided the kernel ABI doesn't change so much as to break drivers; in that case, they'd need drivers from the manufacturers first. If a manufacturer skin breaks, vanilla Android is the fallback; personally, I prefer that anyway and wish I could just pop into /vendor and delete a few .apk's to get back to it every time I pick up a non-Nexus Android device.

We'll get there. I don't think it's as big of an issue for the informed consumer, though; we already know to buy only iDevices and Nexus devices, at least until BlackBerry remembers how to release a compelling device.

Re: Next...

[BronsCon]

You bought a phone from a Google subsidiary, not a Nexus device built to Google's specs and supported by Google directly; you're at the mercy of Motorola and your carrier. Have fun with that and next time get a Nexus.

And yes, I install all of my updates. II did my research and bought a phone that lets me do that. Of course, after getting burned by Motorola, HTC, and LG promising updates that either never came or were blocked by my carrier, I learned the lesson the same way you're learning it right now.

Of course, if you think you'd like an iPhone better, go for it. It has its warts just like Android. Having used both, it's Android on my phone and iOS on my tablet; Nexus and iPad for me. Yes, they really can coexist, quite peacefully at that.

Re: Next...

[BronsCon]

and need them less because the iOS sandboxing model isn't nearly as braindead as the Android one

I wanted to address this separately, as it's entirely a separate issue.

They're both equally braindead, just in different ways. Android provides apps with a sandbox, as well as a shared filesystem; they can use either or both. Many use only the shared filesystem and that is an app issue; I do wish Google would crack down on that and only allow use of the shared filesystem for sharing data between applications, requiring the use of the sandbox in most cases, but, at the end of the day it is an app problem. Perhaps making filesystem access a permission an app has to request; though, if memory serves, it already is and most apps (at least the ones I use) make use of the sandbox rather than the shared filesystem already, anyway; a few exceptions include image end document editors (which are often used to edit images and documents from other apps) and my dash cam app (which puts recorded videos on the shared filesystem so I can get them off the device easily). Where sandboxing is used by apps, it works and works well. Android also has a concept called "device administrator", which allows you to specify one or more apps which can have full control of your device; apps like Lookout, which is a security suite, can be assigned that role, which allows them to traverse sandboxes, enabling (in the case of lookout) scanning for malware based on more than just app name and version, or lock the device or turn on location tracking briefly in order to record the last location of the phone before it powers down. It's nice having a pinpoint on the map showing me where my phone is chilling when I can't remember where I left it.

The flaws are more or less related to lack of enforcement, not requiring apps to use the sandbox for their own data and only access the shared filesystem for actual sharing of data. I think making the File Open dialog a system dialog and requiring its use in order to access the shared filesystem would solve that, mostly. It might break things like my dash cam app, but there should be a solution for that, as well; perhaps by making app sandboxes browseable via MTP (which is how Android devices transfer files to/from a computer). Device administrators would be able to read/write anywhere, anyway, so it wouldn't break apps like Lookout, which need to do that

Now, iOS sandboxing is much more strict. It's been in the OS from day one, so there's never been a share filesystem to speak of. It's really braindead when you need to share a large number of files consistently between two or more apps, because in order to share files between apps, the app that owns the file must support sharing and must recognize the app you want to open the file in as being able to open the file; and the app that owns the file has to initiate the sharing every single time for every single file, there is no way to authorize sharing of an entire folder, nor to remember that app X is allowed to access file Y. This often fails and, even when it doesn't, it adds steps to the process.

I keep Git repositories for several projects on both my iPad and my Android phone; I prefer to edit on the iPad when a computer is not available, since I've got a full keyboard for it, but I typically end up making smaller (e.g. in one file) edits on my iPad and anything larger on my phone because it's just quicker. On the iPad, I have to launch my Git app, navigate to the repo, navigate to the file, choose "Open In", then choose my editor. Fine, if I just need to edit one file; if I need to make changes in a handful of files, I can't just open them all in my editor, I have to work on them one at a time; and when you share a new file, it closes the old one, you can't share more than one file between two apps at a time, so if I need to refer to two files side by side, I have to make a copy in my editor; and I have to remember I did that so I remember to go back and re-open the original before makin

Re: Next...

[BronsCon]

Gah...

(and doesn't work on iOS because Apple removed the ability for apps to even see that much)

should read:

(and doesn't work on iOS 9 because Apple removed the ability for apps to even see that much)

Re:Next...

[BronsCon]

Really? Mind walking me through it, then? The best I can seem to get on mine is sidebar apps; not two persistent split-screen apps, which is only supported on the Air 2. Sitting next to my wife's Air 2, there's definitely a difference.

Re:Next...

[BronsCon]

I ask because multiple sources confirm, split-view multitasking only works on iPad Air 2 and newer.

If it's working on your iPad Air 1, you must have one of those rare ones that lacks a mute slider; e.g. an Air 2.

Re:Next...

[Anonymous Coward]

A lot going by how popular CM is.

The "free detection app" is off-appstore

[Anonymous Coward]

The "free detection" app quoted in the summary is an off-appstore build that must be trusted by the user explicitly. Given this is a "jailbreak team" it's unlikely they'll be bothered to do an in-channel release.

Normally this channel of distribution is used by corporate IT to deliver in-house app to employees.

But if you follow their instructions (given without explanation, just a list of "do this"), the trust will be there unless you uninstall all apps developed by them. So their future, other "releases" can be installed without warning.

Guess this is just an excuse to gain the trust out of their willing, jailbreaking users, so a backdoor can be planted for future deployment of anything.

Re:The "free detection app" is off-appstore

[tlambert]

The "free detection" app quoted in the summary is an off-appstore build that must be trusted by the user explicitly. Given this is a "jailbreak team" it's unlikely they'll be bothered to do an in-channel release.

Given that it depends on crossing filesystem protection zones that are disabled for privileged apps which can only run on jailbroken phones, it's unlikely they would be *able* to do an in-channel release, since the thing simply wouldn't work.

All apple fanboys lied?

[Anonymous Coward]

Apples stuff can not get virus/malware/trojans.

Re:All apple fanboys lied?

[macs4all]

Apples stuff can not get virus/malware/trojans.

Any platform can get Trojans.

And when the Development Tools ARE the vector, it's pretty much like having physical access.

Can you prove that a similar thing hasn't been done to common Android Dev. Tools?

Re: Yuo fail It

[Anonymous Coward]

The correct fix is to shove the 'iPhone' in your ass. If it refuses to flush use a hammer.

Need to ban these companies

[ilsaloving]

So let me get this straight...

First they downloaded a dodgy version of a free development tool...

Then they completely disabled Gatekeeper, which would have warned them that they were using a problematic version of xcode...

People/Companies who demonstrate such a shockingly poor level of judgement shouldn't be allowed to flip burgers, let alone be near a computer.

Re:Need to ban these companies

[Malc]

They probably already had Gatekeeper disabled. I know I had to do this simply because of the number of tools I use as a software developer that wouldn't run otherwise. Gatekeeper's pretty good if you only play Farmville or don't do anything beyond Safari, although I wonder why you'd have a high end computer for that rather than a generic Windows system or some other portable device.

Re:Need to ban these companies

[narcc]

Yet, they still managed to get their apps inside Apple's walls. They'd make the Greeks proud.

Re:Need to ban these companies

[macs4all]

They probably already had Gatekeeper disabled. I know I had to do this simply because of the number of tools I use as a software developer that wouldn't run otherwise. Gatekeeper's pretty good if you only play Farmville or don't do anything beyond Safari, although I wonder why you'd have a high end computer for that rather than a generic Windows system or some other portable device.

1. You can reduce GateKeeper to the "Warn" level

2. You can always Right-Click and Force a Run

3. It only happens once per App. Deal with it.

Re:Need to ban these companies

[bsolar]

When Gatekeeper stops an application from running it's then possible to go under Security & Privacy to allow it. This means you need to allow your tools only once, the first time you run them (and of course eventually after you update them).

Re:Need to ban these companies

[k2r]

> I know I had to [disable gatekeeper] because of the number of tools I use as a software developer that wouldn't run otherwise.

I don't want to publicly question your qualifications as a software developer but please explain which tools exactly malfunction made you feel like (permanently?) disabling gatekeeper...

Basically I think that someone who considers disabling gatekeeper to be a good idea should not have an admin account on a Mac. But I may be wrong.

Re:Need to ban these companies

[Anonymous Coward]

That's like saying you use root as your user account because typing "sudo blahblahblah" is too much extra work. That's unprofessional and plain idiotic.

Re:Need to ban these companies

[Anonymous Coward]

2. You can always Right-Click and Force a Run

I agree with you, but here's where Apple has failed (and continues to fail spectacularly). I knew about this from the day Gatekeeper was introduced because I read tech sites. But how is the average user to know it? It's completely unintuitive and hidden. Where is the documentation? Sure, it's somewhere on Apple's website, but how does a user even know that this is possible, or to look for it?

For many years now, Apple has been hiding features and providing no immediate clues or help to the non-technical user. They believe they make the most beautiful, usable, and intuitive interfaces which users should be grateful to have the privilege of using. What a load of crap. (3D Touch has already been called out as stuff that only power users will discover because there are no cues to tell the average user that functionality exists; I haven't used it so can't judge)

Usability for the non-technical user, who doesn't poke and click everywhere or keep up with tech blogs, has gone down the toilet. They're coasting on a reputation they earned in the 1980s and 90s when they did real research in user interfaces; now they violate a massive number of those once-sacred principles in the name of "design." Bleh.

Re:Need to ban these companies

[macs4all]

For many years now, Apple has been hiding features and providing no immediate clues or help to the non-technical user.

They have been "hiding" features in the same way EVERY WIMP-based GUI has been "hiding" them: By placing certain less-used features on a Contextual and/or Sub-Menu. Could you do better?

How much Documentation comes with Windows?

How much Documentation does any of the MULTIPLE User Interfaces that an unsuspecting Linux User could encounter come with?

How would have THOSE UIs have exposed that somewhat dangerous and seldom-used command in a more reasonable manner; especially given that not EVERYTHING can be on the main menu-set? Iin fact, segregating less-used and/or somewhat dangerous actually IMPROVES usability (a point that is likely discussed in Apple's Human interface Guidelines).

You would have an argument if the command was available only through a Keyboard command, ala Emacs; but one of the great advantages of a GUI is that it is "DISCOVERABLE".

And so, I utterly reject your entire premise that Apple is "hiding" features, and especially not features that exist on a Menu, whether on the Menu Bar, or via a Right-Click.

Real Techs

[Anonymous Coward]

Real techs are still buying up batteries and other spare parts for their N900. We are currently in a bit of a dark ages when it comes to smartphones and their regressive software tech (but I'l be the first to admit that newer-than-N900 hardware is very attractive).

Moving on from the "Dark Age of iOS" (which happens to include most Android distributions, but iOS' awfulness is most exemplary so it gets top billing) should be one of the top priorities of personal computing.

Re: Real Techs

[Anonymous Coward]

We stand corrected. You mam are the ultimate hipster! Did you ever get that network stack working on your VIC-20?

Serious to get into developer path

[Anonymous Coward]

What is troubling is not just a app or two is infected. But one's that are used with developers and about 40 other known common apps in the China Apple store.
The other thing you must realize, is that Apple vetted these apps and approved them. This also brings into question their ability to properly approve these apps.
A question that most have never really been ask before this. Android of course another story and jail broke IOS devices don't count. But this is not about a small fraction of jail broke Apple devices. Its about run of the mill IOS devices. Again, Apple seems to ignore security and will bight them trying to get into enterprise if they cannot do better then this. No excuse to get this deep into IOS. Heads should role on this at Apple for sure.

Re:Serious to get into developer path

[macs4all]

Apple seems to ignore security and will bight them trying to get into enterprise if they cannot do better then this. No excuse to get this deep into IOS. Heads should role on this at Apple for sure.

1. Do you think that, by your own measure, that Android is any more suitable for Enterprise?

2. How can Apple control someone downloading/installing their Dev Tools from another location and then defeating the measures on their Dev. Macs to keep them from running unsigned code?

3. Apple provides a FREE source of SIGNED XCode in an attempt to thwart this sort of attack on their Dev. tools.

4. If Apple made it so that XCode could ONLY be installed as a "Signed" App, then how many DECADES before the Slashtards would STOP accusing them of "Vendor Lock-In" and "DRMed Toolchain", et FUCKING Cetera?

5. As long as the "poisoned" App is smart enough to WAIT a bit before firing off its attack on the User (thus not exposing its bad behavior during the Approval process), it is quite possible that such an attack could avoid detection by all but the most painstaking (and long) MANUAL code-review. Meanwhile, the Dev. world starts whining about how long the Approval Process takes, and Developers start fleeing from iOS...

So, what are your answers to THOSE points?

Re:Serious to get into developer path

[0123456]

Hint: the only way to prevent an app from doing BAD STUFF is for the operating system to prevent it from doing BAD STUFF. Even a human reading the source code has a hard time telling whether that socket it's opening to www.evilserver.com is being used legitimately, or sending your banking passwords to Elbonian hackers. And if the bad code is inserted by the compiler, reading the source is pointless.

If you want security, you need to sandbox the apps, and ensure that Fluffy Kitty Screensaver can't read your banking passwords. At best, any app scanning approach can only find the most obvious malware, as this has proven.

Oh, and don't outsource development to dubious nations.

Re: Serious to get into developer path

[BronsCon]

Not the guy you were replying to, but I'll answer #5 anyway. It means any developer can slip malware past an Apple App Store review by making it wait a month or so before activating.

Re: Serious to get into developer path

[macs4all]

Not the guy you were replying to, but I'll answer #5 anyway. It means any developer can slip malware past an Apple App Store review by making it wait a month or so before activating.

That was a guess on my part; but ANY code can be obsfucated.

The only question is, regardless of Platform, Walled Garden, etc, is there any reasonable way that this can be eliminated from possibility, without hamstringing App Developers to the point that all they CAN write is "Fart" Apps?

Does, for example, XCode have to swell to twice its size (and half the speed) by having nearly as much "self-checking" code as actual functional code? Does , for example, XCode have to be "grey-listed" such that it WON'T run if it has been modified? Or what?

Re: Serious to get into developer path

[BronsCon]

That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.

Until malware authors start leaving their code dormant for 2. then 3, 6, 12. See where this is going?

Of course, Apple would never increase the screening time to 1 month, let alone 2, 3, 6, or 12. They'd have approximately 0 developers writing for their platform if they did. So no, there is no solution; not even one involving a cat-and-mouse game with dormancy and screening durations.

The closest they could get would be to do a symbol dump of the submitted binary, identify all functional code, and require that directions for activating every bit of functional code be submitted along with the app. If a routine is found that can't be activated by following those instructions, reject the app.

Here's why that won't work:
- It makes it difficult or impossible to test applications which may call certain routines based on random outcomes (e.g. many games)
- It makes it difficult or impossible to test applications which may call certain routines based on user actions requiring much practice and skill (experience) withe the application (e.g. many games)
- It makes it impossible to test, in a reasonable timeframe, applications which call certain routines only after a set amount of time has passed
- It makes it difficult to use 3rd-party libraries, as one would have to ensure that they remove any unused routines from those libraries; this means not just stripping out any their application does not use, but also leaving in any which may be called by those their application does use. It's not always clear when some library might make internal calls to its own routines, nor always how to trigger them, which would make providing the required documentation neigh impossible, even if one were able to properly cull the code
- Even ignoring all of the above, there is nothing stopping a malware author from wrapping their malicious code in an if() statement inside a routine or function that is documented and will be tested by Apple, such that the code will lay dormant until a certain condition is met, even as the routine is otherwise executed during testing.

That is to say, as you already pointed out (while paradoxically still insisting that this should be able to be fixed):

ANY code can be obsfucated

And, more to the point, the code itself needn't be obfuscated; Apple doesn't see the code, they review the binary.

Re: Serious to get into developer path

[macs4all]

That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.

Until malware authors start leaving their code dormant for 2. then 3, 6, 12. See where this is going?

Of course, Apple would never increase the screening time to 1 month, let alone 2, 3, 6, or 12. They'd have approximately 0 developers writing for their platform if they did. So no, there is no solution; not even one involving a cat-and-mouse game with dormancy and screening durations.

The closest they could get would be to do a symbol dump of the submitted binary, identify all functional code, and require that directions for activating every bit of functional code be submitted along with the app. If a routine is found that can't be activated by following those instructions, reject the app.

Here's why that won't work:

- It makes it difficult or impossible to test applications which may call certain routines based on random outcomes (e.g. many games)

- It makes it difficult or impossible to test applications which may call certain routines based on user actions requiring much practice and skill (experience) withe the application (e.g. many games)

- It makes it impossible to test, in a reasonable timeframe, applications which call certain routines only after a set amount of time has passed

- It makes it difficult to use 3rd-party libraries, as one would have to ensure that they remove any unused routines from those libraries; this means not just stripping out any their application does not use, but also leaving in any which may be called by those their application does use. It's not always clear when some library might make internal calls to its own routines, nor always how to trigger them, which would make providing the required documentation neigh impossible, even if one were able to properly cull the code

- Even ignoring all of the above, there is nothing stopping a malware author from wrapping their malicious code in an if() statement inside a routine or function that is documented and will be tested by Apple, such that the code will lay dormant until a certain condition is met, even as the routine is otherwise executed during testing.

That is to say, as you already pointed out (while paradoxically still insisting that this should be able to be fixed):

ANY code can be obsfucated

And, more to the point, the code itself needn't be obfuscated; Apple doesn't see the code, they review the binary.

So, since no system is foolproof, we do nothing, right?

A few years ago, it DID take longer for an App to get Approved. Developers whined. Users whined. Apple Management probably whined. So they (somehow) dramatically shortened the Approval Process. Is this the result? Don't think so; but I don't really know. Do you?

Using the iOS Approval Process as an example, since API calls can easily be spotted, perhaps Apps-Under-Review that make certain iOS API Calls get kicked to a higher-tier of Review, where the Submitter HAS to hand-over their SOURCE under NDA (or something similar), and more than one Apple Developer has to manually review it, and has the right to have the Submitter explain any questionable code.

Not perfect; but perhaps better at spotting questionable code, no matter the cause.

Re: Serious to get into developer path

[BronsCon]

Which API calls would those be? Any that communicate to the outside world? There goes 99% of apps getting bumped to the "higher" review. Not a tenable solution.

I'm surely not implying that, since no solution is perfect, no solution should be implemented. I'm simply pointing out that, since no solution is perfect, no perfect level of security should be implied (as has been up until this point), while pointing out that the seemingly obvious solutions are not only imperfect, but so impractical as to be unimplementable. If you manage to come up with a practical solution, great, let's hear it; the one you provided above does not qualify, for the reasons stated.

Re: Serious to get into developer path

[macs4all]

Which API calls would those be? Any that communicate to the outside world? There goes 99% of apps getting bumped to the "higher" review. Not a tenable solution. I'm surely not implying that, since no solution is perfect, no solution should be implemented. I'm simply pointing out that, since no solution is perfect, no perfect level of security should be implied (as has been up until this point), while pointing out that the seemingly obvious solutions are not only imperfect, but so impractical as to be unimplementable. If you manage to come up with a practical solution, great, let's hear it; the one you provided above does not qualify, for the reasons stated.

Show me where APPLE has ever implied that their security is perfect?

Pretty much, it is a meme by Fandroids, NOT Apple Users, derisively put into the mouths of the latter by the former.

Re: Serious to get into developer path

[BronsCon]

Funny, I heard it from an Apple fanboi first. One of my best friends, actually. It's one of the few things we disagree on; until now, I'm pretty sure he's seen the light now. Also, I'm not sure you can call me a Fandroid; I'm typing this on an iPad keyboard that is paired to both my MacBook Pro and my iPad (e.g. it supports being paired to two devices).

Show me where APPLE has ever implied that their security is perfect?

I'm sure they never said it was perfect, but they've certainly marketed their devices as not requiring the user to think about security. This article highlights some of it.

"We’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks." ~ Steve Jobs

"We think a few months of patience now will be rewarded by many years of great third party applications running on safe and reliable iPhones" ~ Steve Jobs

Those were found skimming a single article. When taken in the context of the old "Macs don't get viruses" ads, which has also since been disproven (though I'm still often told that Macs really don't get viruses because it's not a virus if the user has to allow it -- okay, fine, it's malware, it still does something the user doesn't want, and it's still on a Mac, isn't it?), it's easy to see where people get the idea that the App Store should be safe.

And, by and far, it is safe. By the same metric, so is the Play Store.

Re: Serious to get into developer path

[macs4all]

it's easy to see where people get the idea that the App Store should be safe.

And, by and far, it is safe. By the same metric, so is the Play Store.

Frankly, I think there is a Vas Deferens between THIS and THIS.

Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.

Re: Serious to get into developer path

[BronsCon]

Frankly, I think there is a Vas Deferens between THIS [techcrunch.com] and THIS [pcworld.com].

There is also a vast difference between the availability of tools to properly scan for and detect malware on Android and tools to do the same on iOS; without filesystem access, they simply do not and can not exist on iOS. That might explain it, dontcha think?

Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.

That's not entirely correct. About 90% of affected apps are chinese-only, but there are a number of affected apps in the US and global app stores. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to sandboxing and lack of filesystem access, these solutions can only scan for app names and versions known to be infected on iOS; and that capability has even been removed from iOS 9. Interesting, no?

Re: Serious to get into developer path

[gnasher719]

That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.

A simple way for preventing developers from submitting malware is to make sure you know the developer's identity, and make sure they pay for all the damages and get thrown into jail if they submit malware. And _that_ is what doesn't work against clueless devs.

Re: Serious to get into developer path

[macs4all]

Frankly, I think there is a Vas Deferens between THIS [techcrunch.com] and THIS [pcworld.com].

There is also a vast difference between the availability of tools to properly scan for and detect malware on Android and tools to do the same on iOS; without filesystem access, they simply do not and can not exist on iOS. That might explain it, dontcha think?

Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.

That's not entirely correct. About 90% of affected apps are chinese-only, but there are a number of affected apps in the US and global app stores. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to sandboxing and lack of filesystem access, these solutions can only scan for app names and versions known to be infected on iOS; and that capability has even been removed from iOS 9. Interesting, no?

The Vas Deferens thing is a puerile joke I have used since I was a teenager, sorry.

I couldn't find any references to infected Apps in the U.S. Store, hence the comment.

Apple is in the best position to scan Apps on their own servers, anyway; so who cares about what anyone else can do? Lack of direct access to the Filesystem in iOS has significantly decreased the attack surface for malware, and has no doubt made the platform safer for everyone. It's a PHONE, get over it!

and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?

Re: Serious to get into developer path

[BronsCon]

Yeah, that'd probably work. Good luck getting it implemented, though. Also, not sure why it wouldn't work against clueless devs, as well; if it can be proven that, by using a legitimate copy of XCode, the infection would not have happened, they still get charged with negligence; otherwise, they're as much a victim as anyone else.

Re: Serious to get into developer path

[BronsCon]

It's a PHONE, get over it!

To some, it's a phone that can also do some computer-y stuff. To an increasing number, it's a computer than happens to be able to make phone calls. I'm in the latter camp; I hate phones, which is why I carry the device that lets me do more non=phone activities; that my Nexus can also make phone calls is simple a bonus, for those times when a text message or email isn't sufficient and face-to-face communication is not possible.

and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?

Who said anything about a conspiracy? I was just pointing out that it was interesting that, as malware is being discovered in the App Store, Apple is also removing the only detection method available to end users; I recognize that iOS9 was released in advance of this discovery and that the two are unrelated, but that doesn't make it any less interesting, does it?

Re: Serious to get into developer path

[macs4all]

To an increasing number, it's a computer than happens to be able to make phone calls.

I understand that; but for most people, it's still primarily a phone. And for those people, it it a device that carries around a disproportionate amount of sensitive, personal information. So, I really don't think that security measures such as strict sandboxing are such a bad idea. There are more than enough file-manipulation Apps for iOS that no one should have trouble getting files on/off of an iOS device. In fact, I just discovered the other day that there is a Lightning to USB cable (Amazon even has a third party one for $3), which file-manipulation Apps like GoodReader can use to quickly transfer files onto/off of, any iOS device. And if your device is pre-lightning, you can use WiFi in several different ways with GoodReader or several other Apps to accomplish the same thing.

Oh, and I didn't know until the other day that the same situation exists in Android; that is, you need a File Manipulation APP to transfer files on/off of an Android device, just like iOS. The only difference is that you can muck about directly in the Filesystem, which, guess what? Most non-geeks really don't understand so well.

Who said anything about a conspiracy? I was just pointing out that it was interesting that, as malware is being discovered in the App Store, Apple is also removing the only detection method available to end users; I recognize that iOS9 was released in advance of this discovery and that the two are unrelated, but that doesn't make it any less interesting, does it?

Actually, it makes it TOTALLY uninteresting. Do you have ANY idea how much time likely elapsed between the "Feature Freeze" for iOS 9 happened BEFORE the Release Date? Jeezus.

Re: Serious to get into developer path

[BronsCon]

So, I really don't think that security measures such as strict sandboxing are such a bad idea.

Neither do I, honestly. But I also think the ability to make an app a device administrator (which, in Android, allows it to traverse sandboxes) is a good idea, as it allows for administration tools to be implemented which otherwise would be impossible. Sandboxing does exist in Android; the fact that there still exists a shared "user" filesystem actually makes the platform more powerful. It also means apps can break their own sandboxes, and I do think Google needs to crack down on that.

Let's say I want to keep a Git repository on my phone. I can do this on both iOS and Android. On iOS, I have to open the Git app, browse to the repository, find the file I wish to edit, choose "Open in..." from the menu and let the Git app launch my editor. On Android, if I keep the repository on the shared filesystem, rather than in the Git app's sandbox filesystem, I can simply open my editor, navigate to the file, and edit away. Then, navigate to another file, edit, navigate, edit. When I'm done editing, I then launch the Git app and make my commit. I don't have to return to the Git app every time I want to edit a different file, as I must in iOS.

And yes, this is a real use case.

Conversely, if I keep the repository in the Git app's sandbox, it behaves just like iOS.

The issue is that many apps don't honor their own sandbox, so storing anything there is not possible for many apps; again, I do think Google should crack down on this. I also wish Apple would provide a shared "documents" filesystem, similar to Android's legacy implementation; it could even be implemented such that opening a file was an API call that launched an OS-level file selection dialog, so the app can only access files specifically requested by the user. That would be a fair balance between security and accessibility; right now, if I want that accessibility, my options are limited, I get Android's shared "user" filesystem, or Windows Phone (and pray I can find a worthy app on the platform), iOS is not an option.

Actually, it makes it TOTALLY uninteresting.

That they've neutered anti-malware apps on their platform shortly before the announcement that malware was discovered in their marketplace is uninteresting to you? It's interesting to me because now I know my anti-malware solution is ineffective on their platform; if you're not interested in that layer of security, then, well, good luck to you. It certainly doesn't point to any sort of conspiracy, but there are many other interesting things in this world.

Re: Serious to get into developer path

[Plumpaquatsch]

So you prefer Android because Apple's security isn't absolutely perfect. Which it has to be, because some fanboy supposedly said it was.

All while Google often removes much worse malware from the Play Store so often it doesn't even hit the headlines anymore. Did I mention they also scan all apps admitted? And refuse some? Like ad blockers? Must be malware.

Re: Serious to get into developer path

[BronsCon]

I'm typing this on an iPad keyboard that is paired to both my MacBook Pro and my iPad

Yes. Clearly I prefer Android.

It's a donkey

[Anonymous Coward]

"Hee haw! Hee haw! Hee haw!" - Admiral U2xhc2hkb3QgU3Vja3M

Wow, are you a wizard?

[Anonymous Coward]

I can suss out a 20% tip in my head in seconds, but I see people doing it on their smartphones. Why?

Reply #1: Oh, look at me, I'm a human calculator! I'm smart, you're dumb!

To calculate a 20% tip, move the total's decimal point one place to the left then multiply by two. Everyone should be capable of that. Calculating a 15% tip is slightly harder (requires dividing by two, then adding the original and divided value), and an 18% tip is reasonable to use a calculator for.

Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!

Yes, he be a wizard!

Phishig iCloud passwords?

[Anonymous Coward]

TFA states that
> [... ] the current version of the XcodeGhost can't be directly used to phish iCloud passwords [...]
> [...] by changing a few simple lines of code it can be made to do that, or to phish any kind of password.

I was under the impression that this was impossible because of sandboxing and restrictions in keychain-access ?!?

there are ways

[andrew71]

There is tech to inspect compiled code and try to find malicious bits, even in an automated fashion, that won't be fooled by an idle loop. It's far from perfect or being a silver bullet, but it is there and getting better by the day.

Look at what the security firms are now calling "sandboxing". Look here: https://en.wikipedia.org/wiki/Malware_analysis#Free_automated_malware_analysis_services.5B2.5D

This is most probably what Apple does already, and clearly needs to get better at.

The bad news is that _it's bound_ to happen again.

This is why I agree with BronsCon, Apple should open doors to the sec community, but I don't think it will happen anytime soon.

BronsCon mentions sideloading as a possible way to do analysis, I don't know if this is the case (can sideloaded apps break the sandbox model?) but jailbreaking would obviously do.

Re:there are ways

[Anonymous Coward]

Please refrain from commenting in the future:

Look at what the security firms are now calling "sandboxing". Look here: https://en.wikipedia.org/wiki/...

This is most probably what Apple does already, and clearly needs to get better at.

Is this a troll? Everyone knows that both iOS and OSX use sandboxing everywhere.

The bad news is that _it's bound_ to happen again.

Self-evidently true, a non-statement.

The rest is too tedious to respond to.

Re:there are ways

[Plumpaquatsch]

There is tech to inspect compiled code and try to find malicious bits, even in an automated fashion, that won't be fooled by an idle loop. It's far from perfect or being a silver bullet, but it is there and getting better by the day.

So can it identify when an app does nothing more than what most normal apps do anyway, but in a malicious way?