It actually is there already, at least in the current versions of the recovery interstitial. It says something like "Hey, this is important: We don't have a password recovery email address or phone number for your account. If you lose access, we may not be able to help you." and mentions that people without a phone number are much more likely to accidentally lose access to their account. I'm not sure we can make it much clearer than that, the more text on the screen the fewer people will read it.

Hi EzInKy,

Beyond being an avid reader of Slashdot comments (10+ years now!), I also work on Google account security, so am quite familiar with the phone number prompts you're seeing. Let me give you some background and maybe you can at least see our perspective on why we're doing this and why it's not necessarily "evil".

The traditional approach to handling users who forget their passwords, or otherwise need to be identified via a non-password based mechanism, is the secret question and answer. We have spent many years trying to make secret QA work. I myself wrote the code we use to correct typos, handle different abbreviations of street addresses, normalize unicode characters etc to try and increase the success rate. Other people have analyzed the types of questions/answers provided and encouraged users to select better ones. All to no avail. People just suck at choosing these options .... some people choose absurdly easy questions like "Do I like the incredible hulk?" or "In what month did I get married?". Lots of people forget the answer, even with the hint. The suggestions we provide (library card number, frequent flyer number) are often ignored as being too much hassle. Some questions looks superficially strong ("What is my mothers maiden name?") but we've seen fraudsters from Nigeria successfully research the answer to that question starting from nothing more than an email address! To top it all off, the success rate for good users is staggeringly low. Even with all the effort we put in to handling common mistakes, the success rate is rarely higher than 25%.

So we gave up on it. New Google accounts do not prompt you for a secret QA. Instead we ask for a phone number. The reason is that it's a kind of "second password" that cannot be guessed by random strangers unless you happen to publish it on the web (happens, but rare), most people have memorized it, and if we need a strong proof of authentication - like if you forget your password - we make an automated phone call. We have also been asking users to provide a phone number for existing accounts for the same reasons, our stats show users with phone numbers are dramatically less likely to lose their accounts.

You may think, well, I'll never forget my password so this is irrelevant. But nowadays we also use it as a second password in cases where we aren't sure a login is really coming from you (it seems unusual or suspicious in some way). You normally just have to type it in to confirm you know it. In very high risk cases, like using an IP that's been heavily abused before, we may want to send you a message.

You're right that the UI strongly encourages people to provide a number although it's still optional. I'd personally prefer to have the UI you suggest. However that will lead to a lot of users getting locked out of their accounts, no two ways about it. The alternatives for proving your identity are just so much harder. So there are no ideal solutions here. The numbers aren't used for anything else (certainly not advertising or anything like that).

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.

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.

The financial regulations that primarily apply to exchanges and trading platforms aren't what you think they are. As far as I'm aware, at least, there are no regulations that require "competence", perhaps because it's so company-specific and difficult to legislate. The regulations that DO apply are primarily about allowing governments to track money flows between identified parties for the purposes of crime fighting and who knows, maybe some general oppression as well ;)

It's nice to think that regulators can solve these kinds of problems. Experience of the last few years suggests that it's a much harder thing to solve than you believe. For instance, you say 17 year olds shouldn't be allowed to handle other peoples money. So, when he turns 18 he magically becomes competent then? Regulating ownership like this is very hard. In the UK there is a requirement that owners of major media and financial organizations are "fit and proper". This requirement is now causing the Tories to tie themselves in knots trying to explain how Murdoch and News Corp are "fit and proper" despite being at the center of a complex case of hacking and political corruption. It ends up being more about politics and backscratching than any real clear definition of who is competent or not.

This is what happens when you deal with an unregulated currency supply.

Regulation of currency has nothing to do with this. In fact shortly before it closed Bitcoinica was boasting that it had recently come under regulatory supervision. And do you think dollars and euros are immune from incompetence leading to massive losses? If so, where have you been in the last few years?

The underlying problem here is simple, and actually has little to do with Bitcoin itself. The problem is that Bitcoin has grown so extremely fast that almost anyone who sets up a unique financial service, as Bitcoinica and MtGox did, is immediately flooded with users and vast sums of money. These guys are then plunged into the pain of scaling up their operations from zero almost overnight .... setting up customer support, dealing with bugs and new features, figuring out the relevant regulations so they can start to comply with them and attempting to secure their operations.

It does not help that many of these operations started out being run by rank amateurs. MtGox was written in amateurish PHP and had to be almost completely rewritten from scratch by Mark Karpeles, who appears to be fairly competent. Their big security breach came when the previous owner (the amateur) got hacked, he had retained too much access to the business internals. Bitcoinica was, notoriously, set up by a Chinese 17 year old who was able to build a nice UI and working trading platform, but quickly realized he was in over his head with regards to building a rock solid secure operation.

Securing IT systems is hard and Bitcoin as it stands today doesn't do much to help you with it. It's worth noting here that if you just want to sell things for coins (the common merchant case) your server does not need to have the ability to spend the received money at all. You can use a split wallet (also called a "watching wallet") on the server, and then only a totally diffferent secure machine of your choosing can actually move the money. So the difficulty mostly affects companies that need to automatically receive and send large sums of money. The community knows how to make improvements - the protocol allows for money to require multiple signatures to move it, so a framework for having an independent second system that verifies/risk-analyses a transaction stream before signing it would be a good step forward. Using trusted computing platforms like Intel TXT + the TPM chip allows you to secure your wallet in such a way that root level compromise of the machine cannot be used to extract the keys. And the use of "cold storage" wallets is already commonplace. Etc, etc.

The Bitcoin world is going through a period of rapid evolution in which amateur wildcat operations prove demand and are then rapidly replaced by companies designed by highly paranoid people. If you are skilled at computer security and willing to do a lot of paperwork, there's golden opportunities for you right now.

Well, there's certainly some truth to that, but you're assuming that there is a free market at work here. That isn't the case. Markets require property rights - if I can pay you or not pay you for something depending on, basically, whether I give a crap or not, what you have is not a market in the capitalist sense. That is what has happened to music and is happening to other types of creative works due to the failure of the tech industry to implement strong DRM, or to stop file sharing networks. There is no market any more. Only beggars and charitable individuals.

That's not a large exemption any more because the dollar has been sliding in value for a long time now. It's less than the average salary for software engineers in Switzerland, for instance, and that's with an aggressive currency peg to the Euro. If that peg wasn't in place or was weaker, it'd probably start including all kinds of non-professions, just due to exchange rate disparity.