Thought not part of the usual obligatory set:

http://thedevilspanties.com/archives/6062

"And that one link right there blows the rest of your argument away."

I don't really see how it does. He got the color spectrum of light absorption by chlorophyll wrong, but he's correct that you got the law of conservation of energy wrong. Claiming that a single error disproves everything someone said, even the parts unrelated to the error, is a logical fallacy, and claiming so in an arrogant manner just makes you sound like an ass and makes people more inclined to distrust what you have to say.

Do yourself a favor, either learn how to discourse in a more polite manner, or stop trying to "help" by arguing in a manner that's just going to drive everyone away from what you're trying to convince them of.

"Don't know why I keep buying these"

"That said, World of Goo, Frozen Synapse & Dungeons of Dredmor alone were worth all the frustration."

Also, if you feel like you're only getting 50% of the worth, why not then just pay about half what you would otherwise expect if the games all worked? Or shift the balance so less money goes to the developers and more goes to Child's Play or the EFF?

(Also, are you playing on Linux or something? I haven't had any issues getting the games to run. Admittedly i haven't actually tried all of them yet, but i know specifically that SpaceChem, Crayon Physics Deluxe and Braid run just fine on my Windows 7 machine.)

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.

Very much agreed. I know that i sometimes work better without audio distractions going on. However there are a lot of times where if i'm not listening to anything i'll distract myself with the internet or playing with spreadsheets or any number of other things. For those times i'll listen to music or podcasts or audiobooks. There's a delicate balancing act that needs to go on between what kind of task i'm supposed to be working on, how distracted my brain is trying to be, and what kind of audio stimulus i should listen to. It's a balancing act that i admittedly fail at a non-trivial amount, but so far all my attempts to go cold turkey without have been even more disastrous.