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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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?
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.
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'.
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.
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.
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.
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.
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.
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?
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.
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.
Slashdot Mirror
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.
/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.
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
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.
I'm typing this on an iPad keyboard that is paired to both my MacBook Pro and my iPad
Yes. Clearly I prefer Android.
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.
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?
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.
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.
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.
Example:
how many months have 28 days?
12
how many months have just 28 days?
1
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?
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.
Google had just as many commits to as Apple
Google actually had more commits to the WebKit repository
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.
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.
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.
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?
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.
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'.
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.
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.
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.
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.
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.
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?
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.
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.