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.

Not really. Just forbid the government from spying on everyone with cameras in public places for any reason. The government doing it and individuals doing it are quite different things, as individuals aren't everywhere at once like the government's cameras.

Perhaps my original post was not clear enough, or you did not read it. There are very few "government cameras". There are a lot of cameras put in places by the owners/operators of that place. Eg at railway stations it's the station operators who pay for, install and operate the cameras with the police having no special or unusual access beyond what is allowed via law. Therefore the UK government is already unable to "spy on everyone with government cameras" because there is no legal or technical mechanism for them to do that.

I don't see your point. For there to be a surveillance state, there'd have to be some capability to follow a specific person around across all these cameras, and as already pointed out, that capability does not exist. It's the modern equivalent of having security guards on patrol. Useful for security, not so useful as a method for the state to persecute annoying individuals.

If you aren't concerned about that specific capability of the state then you're making a more general argument which is very different, namely that you want some abstract notion of privacy in public places - moreover, public places that are highly trafficked and historically have been targeted by organizations like the IRA. That more abstract notion of privacy is significantly harder to guarantee (individuals would be unable to take photos or film in public places), so most countries draw the line after "the state can spy on anyone with impunity" but before "videoing people in public places is forbidden".

The idea that the UK is some kind of surveillance state is a myth propagated on Slashdot by people who don't know better. If I recall correctly the "highest density of CCTV" meme comes from an article in the Daily Mail (aka Daily Fail). They counted all CCTV cameras, including all private cameras, in one very small and specific part of London. Despite the fact that these cameras are subject to the data protection act and typically not even connected to a communications network, they then extrapolated that small area of London to the entirety of the UK and asserted everyone was "being watched all the time", which is about as accurate as saying your email is always being read (by automatic spam filters).

Internet censorship proposals keep getting floated every few years by "save the children" types in the UK, whereas the idea is taboo in the USA. That's good for America. Unfortunately, that doesn't mean there's no censorship in the states. US residents and citizens are subject to a comprehensive and effective system of financial censorship instead. For example, when politicians there decided that internet poker was bad, they decided to censor online poker sites. Rather than do it via DNS or IP blocking they commanded banks and payment processors to block financial transaction to those sites instead. The effect was the same - Americans cannot use these sites.

The financial censorship system operates the same as you would expect from an online censorship system. There is a large blocklist of questionable accuracy - it includes companies and people who do not exist and performs matching by name only. There is no right to appeal and no evidence is required to be added to the list. It is subject to political manipulation as we saw with the WikiLeaks blockade. It requires pervasive monitoring, implemented via government access to banks financial records. Foreign financial transfers are also available to the US government via the "Terrorist Finance Tracking Program", which basically dumps every wire transfer, credit card transaction etc into a giant database that is queried hundreds of times per day - essentially the equivalent of deep packet inspection.

Of course, like any form of censorship, ways around the system are also censored. Whilst attempting to evade online censorship is typically not treated as a serious crime even in places like China, attempting to evade US financial blocklists is considered to be money laundering and can result in imprisonment for up to 20 years. In fact, being used by third parties as a way to evade this type of censorship is also money laundering even if you're simply an unaware middleman! The original formulation of these laws had a "mens rea" requirement, ie, to be guilty you had to actually intend to break the law and have a guilty mind. Virtually all money laundering cases fell because of this, so Congress simply removed the requirement.

Finally, because censorship systems have to be global to be truly effective, the USA has been persistently "harmonizing" this system onto the rest of the world since its inception. It gets tiresome to read posts from Americans trashing the UK for being some kind of censorship crazy surveillance state when the depressing reality is the reverse.

Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure

Objective C, at least as used on iOS, is not a safe language. I don't see how anyone with serious programming experience could believe that.

Here are some things about it that are unsafe. Firstly, it's not garbage collected (on the phone). Manual memory management has a long history of resulting in memory corruptions, leaks, and even security vulnerabilities. Yes, on MacOS X there is GC available, so Apple clearly recognize this. They appear to believe that it's not OK on a phone.

Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application. It's actually a "defined" operation in the sense that it's defined to return garbage or another nil. Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application, unless (worse) you have some "clever" programmer who decided to rely on this obscure behavior. The nonsense of accessing NULL is why it is defined to result in an application crash on any sane platform - you want to stop the app at that point to avoid possible data corruption. But Objective C apps will happily continue their merry way, overwriting internal state with garbage or more nils until it auto-saves your now hopelessly corrupted data to disk.

This is a specific instance of a more general problem with Objective-C, which is that despite being based on C it turns a lot of failures that would be compile failures in any modern language into runtime failures or heuristically driven compiler warnings. Most research into programming languages for the last 10-15 years has been about how to catch more errors earlier, mostly through better type systems (a lot of functional research is in this direction). Objective-C takes a massive step backwards in this regard, converting errors even C++ compilers can catch ahead of time into issues you may not even notice unless you have extremely thorough testing plans. Example: typos in method names.

Thirdly, Objective-C does not have any kind of real namespacing support. The Cocoa libraries use the convention of an API prefix, but there's no language support for it, meaning "namespaces" such as they are tend to be very short or non-existant. Combined with the way symbols can mishmash together in the same binary can lead to awkward to solve linking issues.

There are a lot of problems with Objective-C that make it difficult to consistently write correct code and flatly contradict how modern languages are designed (no surprise, as it's not modern).

I ask "where can you buy users data from Google" and you reply with a bunch of links that make varied and wild assertions, but none of them allow you to buy users data. So please stop repeating this tiresome FUD. It isn't possible, has never been possible, and almost certainly never will be possible.