Well, "security" is a huge topic and the mechanisms are constantly evolving. But there are some differences that are worth analyzing.

Both operating systems run apps in a sandbox, unlike desktop operating systems like Linux or Windows (OS X is starting to move in the mobile-ish direction). There are some tasks that the OS simply forbids apps to do entirely. In this regard they are similar, and in the absence of local root exploits it's much harder to write viruses that target such a system.

The main differences are as follows: the iOS sandbox is somewhat weaker than the Android sandbox. It restricts fewer things and in the past (not sure if it was fixed these days), key first-party apps such as the web browser were not sandboxed at all, which is how several generations of jailbreak worked. Android was designed from the ground up with the mentality that there should ideally not be an "us vs them" divide - Android treats all apps more or less the same, security-wise, meaning that the browser is just a regular app that runs in a permission-controlled sandbox like any other. This open design is one reason why the permissions UI on Android is more complex than for iOS - apps can do more things and the OS has to communicate that to you.

With a weaker sandbox and permissions system, Apple relies much more heavily on manual review and the ability to control what software you can run. Android, by default, will not install software from outside the Google Play market (which does have various forms of review by the way), but if you tick a box and acknowledge a warning box it will let you do so. This is another reason the sandbox is stronger - Android phones can and do run code controlled by nobody but the author. iOS requires Apple signatures in all cases. The impact of the weaker sandbox is also mitigated by the fact that iOS users upgrade at a faster rate than Android users do (though it's still nothing compared to systems like ChromeOS), so when sandbox escapes are found they can be fixed faster. Android is more vulnerable, which is why there's more of a rigorous approach to privilege minimization.

With the virus angle largely taken care of, "malware" on these platforms is being redefined to mean "software that does something the users probably won't like" rather than "software that does that, and also takes over your machine / hides from you / both". For instance if you install an off-market app on Android and the OS tells you "Services that cost you money: send SMS messages" when you install it, and then you install it and it sends premium SMS in the background, that's typically being classified as malware by various AV companies .... which is kind of fair, but the remedy is just to uninstall the app. These apps can't resist uninstallation or hide from you as desktop viruses can. And beyond obviously bad stuff like running up a phone bill, they're also starting to classify apps that have poor privacy practices or which are too aggressive with their advertising as "malware" which is rather questionable.

With regards to other features, like drive encryption, as of the latest releases I believe both operating systems are largely comparable. The biggest remaining difference of interest (at least to me) is the approach to secure boot. Apple uses a form of online authorization to personalize OS reimaging to the device, this is to avoid downgrade attacks where users jailbreak the device by reflashing to an older, vulnerable version of the OS. Android secure boot is largely up to the OEMs and their approaches differ .... some like the Google Nexus devices allow you to reflash to any OS image you like, including ones you compiled yourself. No authorization from anyone is required, however, the phone will do a data wipe before performing the reflash to stop people who stole your phone from stealing your data too. Other phones will only boot firmwares signed by the manufacturer and use eFuses to stop downgrades rather than a server.

It's a 'good-enough' approximation to an optimal selection process.

The probability of someone clicking on option A, B or C is unknown, but is expected to be constant when averaged over the population. Given the ratio of clicks versus views on any given option, the posterior distribution of that probability can be modelled as a Beta distribution. The experimental question is then: given the current estimates, which option should be presented to maximise the utility of the test?

For simply ranking the options, the utility may be the Shannon information. In this case though, the utility also has to incorporate the expected benefit of a click-through. One could set up a utility function which is weighted between the two outcomes, possibly varying over time.

In practice though, Beta distributions with different means tend to converge to separate peaks quite quickly, so taking a possible 10% hit on the current best estimate click-through outcome seems an entirely plausible approximation. Bayesian experimental design though could also tell you when to stop testing and stick with the winner.

Did you even read TFA? The article explicitly states that a Red Hat or "Linux community" key would be allowed and OEMs were even enthusiastic about it (Microsoft not involved), but Red Hat didn't want one for themselves and the overheads involved with running a "Linux community" key and keeping it secure enough were too high. How did you get from that to "only their private key will be permitted by default"?

Oddly enough, that's pretty much what I read routinely here on Slashdot. A trading platform that was managing large sums of money gets hacked after the datacenter providers get socially engineered into providing root on the box, and that's the fault of Bitcoin. Business accounts get drained from stupid US banks which think a secret question or JavaScript gathered browser profile is a "second factor", that's not even newsworthy enough to be a slashdot story because it happens all the time.

Insecure IT systems can affect any currency or payment system. The only difference is with Bitcoin you are in control - you can outsource security of your wallet to competing providers if you want, or handle it yourself, or invent entirely new security technologies. With a bank you can ..... switch to one of a small number of other banks, which probably have the same policies.

Because charging Red Hat, a billion dollar company, $99 for access to signing services is not "monopoly abuse"? The author of TFA already pointed out that nothing stops somebody from providing the same services to the Linux community, but it's difficult and expensive and they can't be bothered, so it's easier to pay Microsoft to do it for them. As can anyone else.

Secure boots and trusted computing are fundamentally a good idea. Having OEMs provide a set of root keys to control what boots is a good idea. The problem is the creator of BobLinux who wants to have thousands of random users install his random kernel is indistinguishable technically from the creator of some boot sector malware who wants to have thousands of users permanently rooted. It becomes distinguishable once you have people who check out what the software is and signs it, which is the service Microsoft are providing - for very little, actually. As I said, apparently others don't feel like offering similar services when it's expensive to do and Microsoft are offering to do it cheaply. But they could.

Uh? They reported it when they could have hid it, with essentially no risk to themselves. Doesn't that count as a damn?

I think Eliza may have you cornered on this one, AC.

(For the record, the recommendation originates from the NYC Health Department, and Bloomberg points out that you can still easily carry two smaller drinks.)

RTFS again. There was an ethically questionable engineer at Google who was responsible for collecting and retaining the unnecessary data. If memory serves, he wanted to do statistical analysis on the passwords he was collecting. Eventually, Google fessed up to it, even though they could have just covered it up and no one would ever have known. The only possible question is why his superiors took so long to deal with the problem once they knew about it, and my guess would be that they wanted to give him a chance to clean up his act before sacking him. He didn't, so they did.

In short, they're squeaky-clean on this issue, and any efforts to get it investigated further are unjustifiable.