Today, 8 years later, my Mom and Dad think Windows is a "secure" system as they haven't had any issues for long enough that their opinion of it has changed.
The final leg of this journey will be when Windows + Windows Defender is all you need to keep your system secure. Basically once there isn't a market for add-on security products because the base product is "good enough."
I'm curious why you mention Google though, their security record on Android is a lot worse than either Windows phone or IOS. In many ways I feel like they are exactly Windows in 2003 with regard to "its secure if you use our APIs" kind of security. Would love to hear your thoughts on that.
Chrome (OS)'s security model is a lot better, and compared to Android it was designed more in-house. Android was an acquisition and has more legacy design baggage (though of course the vast majority of the code has been written by Google at this point).
The latest junk even made it into Android 4.1 devices for security updates. But that is neither here nor there, the fact that we have 4.1 devices is a problem.
But, iOS's superiority (a) derives in significant part from Apple's total control over the hardware platform†, and (b) comes at the cost of a lot of user control tradeoffs that nerds like us tend to hate.
Really, to suggest that Android's security is at parity with Apple's, you'd have to be arguing that Apple does a terrible job at exploiting their inherent advantages of control over hardware and control over what's allowed to run on the platform. Apple does not do a terrible job at those things.
† Yes, Google controls some of their hardware, but they have an ongoing support requirement for a lot of hardware they have no control over at all, and will have that requirement forever, which limits their options.
Android development feels a lot like current web development plans, where things are released, and not a lot of thought is given to backward compatibility and backporting security. Google needs to tighten those reins a bit, either by pushing handset developers forward faster and/or giving reasonable support for older devices themselves.
What was that? All I can think of is when the chinese stole their source code but the response to that would presumably be more about managing who has access to what internally than improving the security of their user facing products.
edit: to be clear I'm thinking of the time they had code stolen by a chinese employee in their china office, presumably on request of the govt.
https://www.usenix.org/conference/lisa13/enterprise-architec...
Unfortunately, other than the default full disk encryption it's pushing on Android 6+ devices, I'm not really seeing Google push client-side encryption anymore. I wonder if it even wants the E2E email extension to be fully developed anymore. And even though it should be quite trivial for Google to adopt Signal's text and voice encryption in Hangouts, I doubt it has any intention of ever doing that.
> The US National Security Agency and Federal Bureau of Investigation have been harvesting data such as audio, video, photographs, emails, and documents from the internal servers of nine major technology companies, according to a leaked 41-slide security presentation obtained by The Washington Post and The Guardian.
Google is in that list. Granted, this did not demonstrate full access to all of Google's internal communications, but the category of "audio, video, photographs, emails, and documents" is broad and damaging enough that it doesn't really matter if NSA had full access or not.
And yes, I know that Google and all the other major companies vigorously denied any back doors, but as people were saying at the time on this very forum they didn't have any other realistic or legal choices. The President of the United States himself was saying things like: "You can't have 100% security, and also then have 100% privacy and zero inconvenience", which, if you were a smart enough CEO, was a very good hint about what to do and say in the heat of the moment.
[1] http://apps.washingtonpost.com/g/page/world/what-yahoo-and-g...
[0] http://arstechnica.com/tech-policy/2013/10/new-docs-show-nsa...
That being said: A lot of Android's security issues are not always Google's fault. Some of them are in generic Linux libraries, some of them are in OEM added components (Samsung), and some of them are security issues unique to an app ecosystem (i.e. on Windows Win32 user applications normally have full permissions as that user, on Android an APK running as a user has a limited set of permissions, if it exceeds those permissions this is now an "exploit" which is now an additional set of security issues), and many are simply malware being placed on an app store.
Android's biggest issue isn't really that it is poorly designed (in particular with SELinux as standard). Android's biggest issue is how horribly the OS update mechanism works, so relatively minor security issues may not be fixed for years.
I think these mostly are Google's fault. They chose those Linux libraries and implemented them; they certainly have the resources to modify them, to otherwise secure them, or to develop their own. They are producing an OS not for a laboratory but for the real world where there are OEM components, app ecosystems, and malware. Dealing with those issues is an essential part of what an OS does. If you build a ship that works fine in calm weather but sinks when a storm hits, the problem is not the weather.
But is the cutting edge comparison really that much more skewed in Apple's favor?
I'd say that prior to the improvement on patch cycles as of recent in Android - iOS had an edge, but - outside of the walled garden I'm still very curious on the quality between the two with specific regard to the SDLC and resulting output.
Did they really turn it around that fast, in one iteration of Windows (XP was released 2001, Vista in 2007)? I would think that fixing bugs would be necessary but not nearly sufficient, and they would have had to re-architect and re-develop major parts of the system. And Microsoft needed to do that while maintaing the backward compatibility that is a major selling point and pushing products out the door quickly enough to generate revenue.
It sounds like a nightmare, and not acheivable in 4 years. My impression was that many bugs were fixed but there wasn't a major redesign, which always made me doubt how secure Windows could be.
Vista had A LOT of security improvements overall, but UAC shouldn't be considered as one of them (similar to PatchGuard for x64 Windows - it's cited as sometimes a security feature, but it's not).
I assumed it was just an interface stapled onto the old system, and something underneath that allowed changing permissions without logging off.
It might have had a big effect, but it doesn't sound like a significant change in the system. But maybe my assumptions are wrong ...
Windows 7 has the same permissions model as Vista, but has a much better reputation, because by the time 7 was released, applications had been updated to not require as much in the way of permissions. From the users perspective, this meant that 7 "worked properly", even though little had changed in terms of the security model between Vista and 7.
I'm conflating processor date with date-you-could-buy-a-computer-with-that-chip, but still: Pentium 4 is a world away from Core. Windows Vista does a lot more than XP.
The complaints went away because people gradually bought computers with Core architectures.
Microsoft has a program where they certify that hardware will work acceptably with their operating systems. This is important in the run-up to a new version of Windows, because during the period when everyone knows that Windows X+1 is coming soon but all you can buy off the shelf are machines with Windows X, people want to be confident that they'll be able to upgrade to Windows X+1 when it's available.
For Vista, if your machine passed this certification, you got the right to ship it with a shiny sticker that said "Vista Ready." Seeing the "Vista Ready" sticker on that XP laptop on the shelf at Best Buy told customers that they could buy it without fear. It was certified future-proof.
However, Vista required more resources than XP did to run with acceptable performance. That meant that OEMs had a ton of ultra-cheap XP machines in the pipeline that could not with a straight face be called "Vista Ready." And this was a problem, because they didn't want to get stuck with warehouses full of machines nobody would buy because they couldn't run Vista.
So what they pushed for, and what MS eventually gave them, was a new certification: "Vista Capable." Unlike "Vista Ready," "Vista Capable" didn't mean Vista would run well on the hardware in question. It just meant you could install Vista on it, with no guarantees as to how it would actually run. And the shiny "Vista Capable" sticker looked pretty much exactly like the shiny "Vista Ready" sticker, so if you weren't looking carefully, it was easy to confuse the two.
The OEMs loved this solution, because they could now slap "Vista Capable" stickers on all those crappy XP machines and unload them on people. But, entirely predictably, then Vista came out and suddenly tons of people were installing it on hardware that was nowhere near beefy enough for it. So for umpty-ump millions of people who bought that crappy hardware, the experience of using Vista was painful and awkward and slooooow. Eventually even the cheapest machines were powerful enough to meet Vista's requirements -- but by that point Vista's reputation had been sealed. As the saying goes, you never get a second chance to make a first impression.
But the OEMs did get all that inventory out of their warehouses. So, you know, mission accomplished.
Vista is now my go-to example for when people managing platforms say "just break badly written applications, their incompetence is their problem, not ours." Microsoft took a staggering PR hit when all sorts of crappy, poorly-written applications broke under Vista, because their users all blamed Microsoft for it. People don't know their applications are crappy under the hood; all they know is that they used to work, and now they don't.
Each token has different privileges on what it allows/ doesn't allow. One notable change in Vista was the introduction of SetTimeZonePrivilege, since in XP, you had to be an adminstrator in order to change the time.
So you could run as a non privileged users, and you'd only need to log in as Administrator for some very specific tasks.
However, there were many applications that didn't play nice with that model and required you to run as Administrator. By changing the default, MS had to do a big push to make software makers abide by the rules (which had been in place since XP (edit: in the mainstream branch) but were often ignored)
Vista introduced a model that was almost as good, but made it more user-friendly and the default.
f = open('C:/windows/test.txt')
try:
f.write('test')
print ex
In my particular legacy-apps' field, I believe most problems are due to interactions with the DCOM subsystem though.
Umm no - the update situation is better on iOS but fundamentally iOS has bigger problems - https://twit.tv/shows/security-now/episodes/532?autostart=fa... . That problem is unfixable easily due to the way ObjC works. Android gets code access control for free with Java. There have always been Jailbreaks for most iOS versions and it's not like they haven't had other security issues. The ability to fix them quickly is certainly an advantage but there is nothing in iOS that is fundamentally more secure than anything else on the market.
Frankly I think Apple's security is a combination of happenstance and restrictive policies - I don't think they care (yet) about the processes, infrastructure and people required to do what Google and Microsoft do. (No offense to the good security people at Apple - this isn't about them, this is about having organization wide security focus like MS needed to turn around Windows.)
>"There was significant growth in Android malware, which currently consists of 97 percent of all mobile malware developed. In 2014 alone, there were 1,268 known families of Android malware, which is an increase of 464 from 2013 and 1,030 from 2012", it said.
Apple’s iOS, on the other hand, went through last year basically unscratched. The report said that there were just four iOS targeted attacks in 2014, and the majority of those were designed to infiltrate jailbroken devices.
If you want to talk impacts - both iOS and Android have been similarly impacted - big name apps getting into App Store that were compiled by hacked XCode, Ad SDKs using forbidden APIs etc. Likewise most Android malware is due to rooting and side loading apps from questionable sources.
Remember that Android is a lot of things - there are Nexus phones, there are OHA OEM phones (majority of them), there are Chinese no name phones that use open source Android etc. So if most Chinese people use AOSP build provided by their phone maker and they all sideload apps and get infected - that's different. Even considering all this nobody is making the above statement.
Just having malware written for an OS means nothing. It only suggest that it is targeted more due to market share. If people jailbreak their iPhones and install random apps from untrusted sources there is hardly anything Apple's security can do to prevent it. Same goes for Android. Nothing in that reflects the security of the underlying platform.
Can you explain that?
Some apps were exploiting this to get a list of running apps and things like that.
I would have thought you will research it a bit before asserting silliness - but oh well.
Retrieving the application list is a particularly poor example as there used to be a public API that did exactly that: CFPreferencesCopyApplicationList
The "receivers that they don't want you to" on iOS is not about security, but correctness, binary compatibility, and app store guidelines. iOS's security model is not defeated by bypassing the ObjC runtime.
See https://www.usenix.org/system/files/conference/usenixsecurit... for details of how to write an app that bypasses App Store review but will have security holes that allow your app to access APIs at runtime with no notification that it was not supposed to have access to.
I certainly don't understand characterizing iOS's security model as "ordinary." For example, it encrypts using a separate coprocessor running an entirely separate OS, that is protected against even an iOS kernel exploit. That's definitely not an ordinary design!
On both platforms, these security policies are enforced at the process boundary, not by the runtime.
You should read Apple's iOS Security Whitepaper: http://www.apple.com/business/docs/iOS_Security_Guide.pdf See for example the data protection classes: a very thoughtful design, with no analog in Android, and that certainly could not have come about by "happenstance."
Heck, Android doesn't even encrypt your data by default! That alone makes iOS "fundamentally more secure."
You keep repeating that but I am certain you don't understand what you are talking about. Go download the Android SDK, emulator and write an app that does that and post it on Github We will talk about it then.
Also - I'll leave this here - http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds...
Here's a sample of how to invoke `Activity.savedDialogKeyFor`, which is private:
Method privateMethod =
Activity.class.getDeclaredMethod("savedDialogKeyFor", int.class);
privateMethod.setAccessible(true);
String result = (String)privateMethod.invoke(this, 42);
System.out.println("Got result: " + result);
> Also - I'll leave this here
What's your point? There was no security exploit here, and no security policy can realistically prevent networked apps from sharing data like your email address. That falls to the review process.
What's remarkable here is how little data this malware was actually able to capture. Certainly less than on Android, where users routinely grant excessive permissions, like giving Netflix access to your phone.
Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.
You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java."
But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process boundary, not by the runtime.
My hope is that you now appreciate that neither the ObjC nor Android Java runtimes are a security risk, because they are not responsible for enforcing any security policy.
> Also my larger point was the iOS security is not fundamentally better than anything else
iOS security is fundamentally better. You can read the whitepaper to understand the ways: data protection classes, the Secure Enclave, and lots more.
But here's a damning fact: iOS encrypts your data by default, Android does not. That by itself makes iOS fundamentally more secure.
What you are not understanding or ignoring is that iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses by reverse engineering the names of the private APIs and using message passing. Android sure has private APIs and you can access those but you're still restricted to the permissions you asked for. For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently where they rely on manual review to ensure you are not calling the Private API - which fails as can be seen in the Chinese AD SDK fiasco I posted.
So no Android runtime isn't a security risk as much as iOS private APIs are - your app gets a broad set of permissions on iOS by default and you can do clever trickery to call private APIs to collect personal info and who knows what else without the user knowing. Android needs your app to ask for that permission first (and at runtime on M)- you aren't calling a private method on Android without declaring the necessary permission to get what you want without user interaction.
I have read it. It describes an attack on the app review process, i.e. a trojan. Their apps require the user to grant privileges. For example, their GreetingCard app requests access to the user's address book, and the user has to grant it.
> iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses
This is not true. Here's the blog: https://sourcedna.com/blog/20151018/ios-apps-using-private-a...
The data they collected was list of installed apps, serial numbers, and some sort of AppleID numeric identifier. In particular, they did not (could not) collect email addresses.
It's bad that the SDK was collecting this stuff, but this data is fairly innocuous. Last I checked, Android provides information like the list of installed apps and various serial numbers without requiring elevated permission.
If you think it's possible to get the user's email address through an iOS private API, I challenge you to tell me what that private API is.
> For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently
This is wrong. On iOS, the only way to access the user's email is through the Address Book framework, which prompts the user at the time of access.
> your app gets a broad set of permissions on iOS by default
This is completely false. iOS has a comprehensive on-demand permissions model, which is widely recognized as better than the install-time permission model on Android. This is why Android is switching to iOS style on-demand permissions in Marshmallow.
> you aren't calling a private method on Android without declaring the necessary permission
Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates.
[Edited for unnecessary stuff]
Oh the article you linked has Apple response that is quoted verbatim below - it references user email addresses. Specifically.
“We’ve identified a group of apps that are using a third-party advertising SDK, developed by Youmi, a mobile advertising provider, that uses private APIs to gather private information, such as user email addresses.."
> Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates.
What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it.
All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim - it is fallible like every other platform except with the exception of fingerprints which are currently believed to be secure - but that's now the case with Android as well - in M they are using ARM Trust Zone with no app access.
> What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it
Just like on iOS, with the difference that it happens at call time and not installation time.
> All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim
It shows the exact opposite! Notice how ridiculously weak these results are. On one of the most high-profile targets today, an app may (unconfirmed) be able to determine the user's email address and send it to a server. On a trojan app that the user deliberately installed, and then deliberately granted access to Twitter, it can post a tweet without the user's confirmation, if the user has not updated the OS. Fetch the smelling salts!
Meanwhile, millions of Android phones are part of botnets, like NotCompatible.C, at one point reaching 1.5% of mobile devices in the USA. A Chrome 0-day came out last week, allowing full control remotely of fully-patched Android phones. These aren't research papers showing theoretical attacks, this is real life.
Yes, iOS has extraordinary security, and its competition only makes it look better.
/jeez why do I bother with Apple fanboys?
I think it's more to do with the development culture inside Apple. The features in Swift designed to improve secure coding shows you they're actively thinking about secuirty and how to achieve it, and have been for a while.
The only regular security headlines you see about the Mac is in the Pwn2Own contest and their like, where researchers trot out vicious exploits that are then dutifully squashed by Apple in the next update, never to be seen in the wild. (And there's a reason Apple makes it a PITA to install Flash and Java these days, and includes their own very nice .pdf reader.)
Second, retail-level malware is a numbers game. Malware isn't cross-platform. A malware author chooses their target based on how remunerative the target is. Windows remains more remunerative than OS X.
There is no fundamental difference between the security models of modern Windows and OS X that accounts for the disparity in malware infections.
(I'm a Mac user, and have been since ~2001.)
Windows wasn't originally designed to be secure. Even NT, which is a serious multi-user kernel, was a product of 1990s C programming style. And while that's true of the Unices of the time as well, none of them had Microsoft's absurd user base, and so none of them had the same terrible malware incentives.
This all came to a head around 2001-2003, when the Internet worm phenomenon got so bad that Microsoft was routinely on the front page of CNN, and serious talk of congressional action began.
From what I understand, there was a dramatic top-down response, led by Gates and Ballmer, requiring software security training for developers, giving product managers the power to slip release dates to ensure bugs were caught, and funding what I believe is probably the largest 3rd-party software pentesting program in the industry. Several well-known software security firms (my old firm, Matasano, not really among them) were basically bootstrapped out of Microsoft contracts.
Today, Google probably does a better job on software security than Microsoft does, but it's hard to come up with another rival. Tellingly, Google's security efforts were also a top-down reaction to a major security incident.