It's pretty difficult to do for each one of a file full of CC numbers you bought from a Russian hacker.

Actually, though, I should point out that the photo ID, etc. aren't part of the normal Google Wallet onboarding flow. Google Wallet does request information about name, address etc. which are cross-checked with the bank to confirm your identity. I'm not sure why the GP had to go further. Likely something triggered a fraud risk alert, which invoked the need for stronger verification. Note that I said "stronger", not "strong". Risk management isn't about perfect security, it's about raising the bar high enough to convince fraudsters to go somewhere else.

How about because the "search engine company" processes tens of billions of dollars worth of payments annually, and achieves very low fraud with its internal risk engine -- mainly because it has a bunch of people who are really good at extracting important signals from large amounts of data (which is what both search and fraud risk analysis are about).

I'll just say we're working on it :-)

As the AC who responded mentioned, though, you can always set up your own app store with well-analyzed apps. And it's also worth pointing out that Google does analyze apps for a wide variety of malware signals before making them available on Play.

Yes, this is a big issue. Huge. It's a clear consequence of the open source nature of Android, which has a lot of value in other ways. This is a fundamental tension between openness and modifiability and security.

My best recommendation: Buy Nexus devices which are guaranteed to get timely updates. Granted that if you are the sort of person who wants to use the same device for 3+ years that doesn't necessarily solve your problem, because even Nexus devices fall out of support fairly quickly. I actually expect that to change as the ecosystem matures and the pace of development slows, but I don't know how soon you'll be able to expect to get, say, five years of updates.

My goal with that recommendation, BTW, isn't to sell Google devices. Google doesn't really make any money on them anyway. The goal is actually to motivate other manufacturers to make stronger commitments to updates. I think the thing that will motivate them is consumers choosing not to buy their devices without such a commitment.

Nonsense. Even with every permission that's offered you can't get to most of the data on the device. Apps have no access to data stored by other apps, for one huge example.

The rest of your comment seems to all follow from this erroneous assumption.

LOL. At the vast majority of companies, it wouldn't be a question of a disclaimer. Most places would fire me for speaking publicly at all without clearing everything first.

Speaking of a Young Lady's Illustrated Primer, what happens when Nell tells Barbie that her mommy's boyfriend is a bad man?

I see you have little experience with decisionmaking in corporate America.

I'm a member of Google's Android security team, and I want to correct this. The only component in which Google doesn't fix bugs is the old Webview implementation. I'm not going to try to explain or defend that decision, just note that at this point we think it's more productive to get apps to stop using it to display untrusted content on pre-4.4 Android. Outside of that, Google does provide fixes to all significant issues that are reported to us, and we provide those fixes to device manufacturers, at no cost and with security bulletins explaining the nature and severity of the issues. Further there are partnership policies in place that require manufacturers to release updates for severe issues. The nature and scope of those requirements aren't what I wish they were, but Google's ability to dictate to Android OEMs is limited (which isn't a bad thing, though arguably it is in this case).

The first portion of this sentence is indisputably true. The claim that Android usually has remote exploitable security issues, not so much. Local exploits are pretty common, as they are on every platform, frankly. Securing against local exploits is a hard problem, though I think we're making significant progress. We're finding that SELinux is making many vulnerabilities non-functional on 5.0 and above (granted that it will be a couple of years before 5.0+ represents the majority of Android devices). Functional remote root exploits, however, aren't actually that common, even on pre-5.0 devices. Also, such high-severity vulnerabilities generally *do* motivate manufacturers to deploy fixes (again, pre-4.4 Webview being the notable exception).

Also, I'll point out that thanks to the Android Verify Apps tool, which is active on several hundred million devices, Google has very good insight into exactly what (known) vulnerabilities exist on real-world devices, and even quite a bit about how often exploits are used (though that data is more squishy and speculative). This data even covers a lot of devices that don't use Google Play, since the Verify Apps opt-in is offered to all devices, not just those that use Play.

I can't provide details, but the high-level summary is that the Android ecosystem is actually surprisingly safe. Given the size and complexity of modern mobile operating systems in general and Android in particular, I would expect the situation to be bad, but it's not.

With respect to Blackberry's work here, it actually sounds really good to me. They're doing a lot of good things, some of which we are also working on. I don't think any of the mobile OSes in current use are very resistant to targeted threats. What Blackberry is doing with this tablet is trying to tackle that problem: how do you secure high-value data which may be the specific target of a skilled attacker on a commodity, open platform device? It's a really tough problem. They're doing it by creating a locked-down sub-platform within the platform, allowing only whitelisted apps, preventing data leakage between those and apps in the open portion of the platform. That's a sensible approach. If they can really achieve protection against targeted attacks, the higher price point isn't unreasonable at all. People with high-value data on their devices will pay for security. Most people won't, but there's nothing wrong with focusing on a high-value niche. It's good business, and a strategy that's consistent with the reputation of the Blackberry brand.

Google, of course, isn't targeting the niche, but trying to provide reasonably good security to the mass market. My opinion is that we're largely succeeding, but must keep pushing hard to stay (mostly) ahead of the threats.

(Disclaimer: Please don't take this as any sort of official Google statement. I'm not a Google spokesperson, and I'm taking something of a risk by being this forthright about Android security work in public. Not a huge risk, because my management is supportive of transparency -- as long as I don't cross any lines. I obviously haven't gone and cleared all of this with PR and it's possible that something I've said is inaccurate, or inconsistent with the company's official position. If there are any such issues, the fault is entirely mine.)

And I can't get 4 quarter horses to run as fast as a whole one, no matter how much duct tape I use.

No chamber needed. A typical hospital oxygen mask with a good flow of pure N2 into will do fine.

If you don't want to include euphoria, just use straight N2 or He. The feeling of suffocation is triggered by CO2 buildup, not O2 deficiency, so a person able to freely respire a low CO2 gas mixture without any O2 feels nothing at all, positive or negative, but simply falls asleep. No needles, no poisons, no discomfort... they just fall asleep and then die. Technically they suffocate, but with no feeling of suffocation.

You don't need any sort of special chamber for this. Just a typical hospital oxygen mask and a cylinder of compressed inert gas. It doesn't even matter if the person being executed gets a little bit of ambient O2, as long as the percentage of O2 in the breathing mixture is down around 2% or lower. You probably need to strap the person down so they don't try to remove the mask, but if you play it right they'll never realize when their death has begun... start with a continuous flow of air into from a compressed cylinder into the mask, then without changing pressure or temperature or otherwise notifying the person that the time has arrived, switch it over to the inert gas.

A big chunk of it is written down in the constitutions.

I'm not dissing what these guys are doing; it's good to demonstrate the increasing capabilities of self-driving cars. But I don't think it's very accurate to call this the "most ambitious" test, because long-distance driving, especially on highways like the US interstate system, is about the easiest form of driving there is to automate. I'm much more impressed with the ability of Google's self-driving cars to negotiate crowded city streets safely.