Your slander against Rubin, that he was the major factor, is unsubstantiated. And your 'X' sentence makes no sense, it translates to "He thought nothing was secure", huh?
Dan is characterizing Rubin's position around security as non-inclusive. Not that "nothing was secure", but that any feature (X) that was prioritized was done so not just without taking security into account, but with a belief that security was at odds with said feature (for all examples of X).
Basically, in a bastardized form of the "Good, Fast, Cheap. Pick two."
I don't know who was the responsible party for Android's terrible security track record, but Dan knows a lot more about mobile security than I do, so I'm hesitant to say he's slandering anybody.
heh thanks for the support and, yes, you got my position right. For anyone who might be thinking I'm an iOS fanboy or something, our company is probably harder on Apple than any other in the world with regard to security:
His attitude towards security is well known among those attempting to help make Android devices safe for people to use. His refusal to believe that a device could be both safe to use and popular or safe to use and useful has directly led to hundreds of millions of unsafe devices around the world.
You couldn't be more wrong and, unfortunately, I don't have the karma yet to enable downvoting :-). Easy example as long as we're on the topic, the Chrome browser or ChromeOS.
I can think of a dozen things that could be done to Android to both mitigate against current threats and exploited weaknesses and either not interfere with or improve user experience. Unfortunately, we are long past the point where fundamental architecture changes can be made to Android. We are stuck with a system that allows execution of downloaded code at runtime, that never updates, and that blames the user for security problems. Android would have been wise to adopt some of the best security decisions from iOS.
Please be humble, when you have the capability to down vote comments in the future and think of the humbleness from the HN Guidelines and this particular part: "When disagreeing, please reply to the argument instead of calling names." (Albeit, you're not calling names - but threatening to down vote is a little bit uneasing.)
The usability of the browser is severely hampered by the security requirements. For one, it necessitates running code downloaded from the web in a sandbox, which prevents it from interacting with the rest of the computer in a meaningful way except through narrow channels designed painstakingly by committee.
The web would be a much more interesting place if we could hook up arbitrary peripherals. It's holding back the entire world from developing better computer interfaces.
>The web would be a much more interesting place if we could hook up >arbitrary peripherals. It's holding back the entire world from developing >better computer interfaces.
Im enginering something, that was a spinoff of this thougths.. i 've go an answer balancing the good parts of the web with the good parts of the app platforms.. plus some concepts of biological cells..
it may be a party for google, apple samsung and the like.. but we technological people are back to the nighmare that were the 90's.. with multiple platforms.. and thats the only reason browsers became popular..
even when we were loosing so much..
here we are into the nightmare again.. have to create things for multiple platforms :(
I think Google can fix many of the security issues with Android, even at the cost of breaking compatibility. They will presumably try to merge Android and ChromeOS, and taking more of the ChromeOS security model on tablet/PC-form-factor devices makes sense.
You manage to say a lot while saying absolutely nothing of value. That sounds harsh, but seriously thus far you've said that Andy Rubin is to blame for <something vague and unsubstantiated> because <something vague and unsubstantiated>, and Android has <some unstated fundamental security gap> versus <some other alternative>. I don't think I've ever read such an absolutely and completely unsupported comment chain that wasn't sitting deep in negative territory on HN. And seriously, the nonsense tweet by Schiller (who would have known that Apple would toss barbs Android's way?) is why you think Rubin moved on? Give me a break.
Android has a deeply secure design that runs each process as isolated, low-privilege users, needing to request services after passing through fine grained permissions. Do you contest this? Architecturally Android is much more secure than iOS.
The only issues remaining are getting security updates out quickly, though in actual practice this has proven to not be an actual problem (somehow people imagine that if a device is on Gingerbread that also means security patches can't be deployed, I guess having never worked in branched source control systems), and better vetting of the Play store (which will come. The Play store can be both vetted and agile/inclusive. They need to block the bullshit). Neither of this are the apocalyptic "that ship has sailed" nonsense that you are parading.
If you think that Android has a "deeply secure design", than then you probably want to start at the top. Android sits somewhere between "gift to hackers" and "Windows XP". Phil Schiller's tweet was pointing out the consequences of this and how it shows up in successful attacks performed against the Android platform. F-Secure, even though they're an AV firm, does good work once in a while :-).
First, Android hasn't solved the updating problem. It's getting better but at far too slow a rate. Every day, hundreds of thousands more devices that takes month to years to patch are entering the market. Furthermore, poor patch management by OEMs and carriers mean that sometimes they think they've patched when they've really rolled back updates. They do this unknowingly because their software deployment processes are abysmal. See http://www.xray.io for more info.
Second, Android exploit mitigations are very, very weak. It lacks code-signing, one of the strongest mitigations available (just go ask an iOS jailbreaker). Apps have access to a shell. The Linux kernel is full of infoleaks that make kernel ASLR nearly useless. App Permissions, though many people think they help with this problem, actually have nearly no effect whatsoever on the ability to root/jailbreak/privilege escalate on Android. This is what I meant by "blaming users" for security problems, since so many people fall back on "educating" people not to allow apps with certain permissions even though, ironically, it does nothing. End effect: even if Android could patch, rooters will write new exploits when they need them, as they need them. It's getting harder, but it's nowhere near where it needs to be and we're on version 4 now.
Third, Bouncer has a severely limited ability to impact this problem. Due to the lack of code signing and the overall architecture of Android, Bouncer can't ensure that the app that it scans is the app that runs on the phone. Apps can dynamically update their own code at runtime. Bouncer appears to rely principally on dynamic, rather than static, verification leading to tricks you can play with timers and environment detection (these attacks have been proven). Further, what about third party appstores? There are dozens out there and you can't just say that they're all second-class (third?) citizens that deserve to get 0wned. 3rd-party appstores are supposed to be a key feature for Android, but they're unsupported entirely by these controls.
If you wanted to develop a mobile/embedded platform to bring a new generation of users onto the web and into your customer base, you should have spent about 5 minutes figuring out how to do it without opening them up to harm. Android is the way it is because it wasn't believed these design features (aka safety) couldn't be included in the beginning.
> First, Android hasn't solved the updating problem.
Sure it has - buy a nexus device, get updates. The rest isn't Google's problem as they aren't Google's devices.
> It lacks code-signing
Wrong.
> Apps have access to a shell.
So? The shell they can access can't do anything the app can't. That's like saying apps can run code - no shit, what's your point?
> App Permissions, though many people think they help with this problem, actually have nearly no effect whatsoever on the ability to root/jailbreak/privilege escalate on Android.
Of course they don't, because those are completely unrelated. iOS's code signing and other stuff hasn't stopped it from getting jailbroken. Complex systems have bugs, who'd have guessed it?
Also rooting is an actual feature on some Android phones (such as all Nexus ones) - not an exploit.
> Apps can dynamically update their own code at runtime.
Yup, and as a result Android users get to enjoy real web browsers, for example. And languages with JITs.
> If you wanted to develop a mobile/embedded platform to bring a new generation of users onto the web and into your customer base, you should have spent about 5 minutes figuring out how to do it without opening them up to harm. Android is the way it is because it wasn't believed these design features (aka safety) couldn't be included in the beginning.
Wrong. Android is easily the most securely designed OS out there that still allows side loading, period. Not claiming it is the most secure, as there are obviously bugs, but the most securely designed. Desktop OSes are incredibly bad here, and iOS only manages to prevent it by stripping you of all your freedom.
I'm getting tired of this. If you want to stick your head in the sand and ignore the data, then fine. Try and ignore this: 50% of all Android devices have unpatched vulnerabilities for which exploits exist.
Firstly, the updating problem is a distribution flaw, not a design flaw. The carriers are to blame for that.
Secondly, code-signing is a very restrictive approach and is hardly without tradeoffs. If you're going to use iOS as an example, it strongly discourages casual development for a slew of reasons, and there are countless examples of Apple rejecting apps for arbitrary reasons, far beyond issues of malware.
Your third point is really only an extension of your second.
Maybe you don't personally feel you've had to give anything up for the security that iOS affords, but it's disingenuous to assert that there aren't any tradeoffs at all. Android's more open approach is more true to its open source roots. For it to be different than iOS gives us choice, which is a good thing.
The updating problem is a design flaw they knew they would have to deal with and that they did nothing about until version 4, when they started trying to separate core functionality out into apps. That's not acceptable.
Code signing can be implemented while still allowing for casual development. See my comment above about the hardware switch on ChromeOS devices.
My third point is regarding how the architecture of the platform complicates the ability to analyze apps that run on it for malicious behavior. The NDK, the access to the Linux kernel, and a strategy based around dynamic analysis were all design choices that impacted that.
I understand that Android wants to be more open than iOS but you're making the same mistakes the Android team did. Namely that there's no way to deploy the same or similar security improvements without sacrificing something else. It's just not true.
If Android didn't have side-loading, the capability of having third-party app stores, and access to the shell (to the point of being able to run a terminal), I would likely not be using it. The more PC-like it is, the more usable it is to me, in the medium / longer term, as devices in tablet form factor replace mobile PC use cases.
There are safe ways to enable access to it. Take ChromeOS for example, which has a hardware switch on the outside of the device that "jailbreaks" it and allows access to these features. Lack of such creativity by the Android team with regard to security has had a major impact on their current state.
>Android sits somewhere between "gift to hackers" and "Windows XP".
It is hard to take you seriously.
Let's be clear that the malware problem on Android aren't apps exploiting any weakness in the platform itself beyond the simplicity of pushing apps onto the market. They aren't exploiting that devices are running Gingerbread or anything like that.
These are apps doing exactly what they are allowed to do by the system -- after advertising their intentions and doing exactly what they declared that they could do -- but they are malicious because the things they are doing aren't in the best interest of the user.
e.g. an ostensible puzzle app that actually sends contact information to a third party (after declaring and getting permissions for contacts and internet access), or that sends pay SMS' to Nigerian sex operators, again after declaring and getting permissions for contacts and internet access.
When anti-virus vendors and please-pay-attention-to-us tiny security upstarts talk about malware, that occupies 99.9% of the space (if not 100%). It is a trust and validity issue with Google and the Play Store that requires much better vetting and culpability of developers, and vetting of applications (not in the "don't do anything that overlaps us" manner of Apple, but simply to validate the scope of functionality, fitness for advertised purpose, and lack of clear trademark and copyright infringement that is so prolific on the Play store).
That has nothing to do with the platform and everything to do with one store.
You clearly didn't read a single link that I posted. I did a comprehensive study of all malware targeting mobile devices between 2011 and 2012 and, yes, they are targeting the device itself and the design choices made while building it.
EDIT: oh wait, there you go blaming the user again. "Grandma should have known the difference between THIS app that requested her contacts and THAT app that requests her contacts and stole them. Jeez Grandma! Get with it!"
How is that not a design problem? I thought we gave up delegating security decisions to the user after we saw what happened with SSL?
EDIT: oh wait, there you go blaming the user again. "Grandma should have known the difference between THIS app that requested her contacts and THAT app that requests her contacts and stole them. Jeez Grandma! Get with it!"
No, I didn't blame the user. I pointed out that most of the problem with malware on Android, for the overwhelming majority of users (who don't sideload), was that the Play store is a wild west right now, where people pay $25 and make an account where they can instantly publish "Temp1e Run" that is actually nothing of the sort. This is the cause of the overwhelming majority of malware on Android.
Should apps be able to have those specific rights (such as sending pay SMS')? Yes, absolutely they should. The ability for apps to do more interesting things is exactly what differentiates it and makes it better. Simply saying "keep every app in a silo where it can't do anything" is not a choice users want.
EDIT: And just to loopback again, you again claim that malware needs to somehow break the bounds of the Android system to do its evil deed (exceeding permissions, cracking ASLR, etc). That is absolutely untrue in practice. Malware on Android, courtesy of the practically unmaintained primary market, is largely a study of social hacking.
Surely some security comes for "free". My iPhone has military grade encryption, but all I see is a 4 digit passcode. If I shut it off, however, and have the 10 max attempts, then it's virtually impossible to break in (without other data, e.g. smudges where the passcode numbers are).
In any case, it should be a tradeoff the user controls. People have drastically different needs, think OpenBSD versus Windows for a usability/security tradeoff.
What's your benchmark? If you have access to the hardware virtually everything can be jailbroken. With the iPhone, however, you can't do it non-destructively (i.e. you can't get personal information). At least that's my understanding, if I'm wrong please correct me.
The original user-friendly jailbreaks worked by pressing a button on a website. That means that any website could use the same technique to run native code with root privileges on your iPhone. I'm not sure how much physical access is required for current jailbreaks.
IIRC it's been years since that's been possible, recent attempts seem to all fake a software update/reset via host computer connection. I'm not saying the iPhone is anywhere impossible to break into (I'm sure, like all OSs, there are vulnerabilities that allow access exposed to the user that have not been found yet), but because the apps are sandboxed, hackers need to break into software and then out of the sandbox (probably into kernely memory, again, but possibly just into privileged system access to the file system). The iPhone is certainly far more secure than most desktops because of this, and I suspect that because of Apple's control over it, the chance of your iPhone getting accessed without your permission is miniscule.
However, I am no mobile developer, so take this with a grain of salt.
