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.)

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.

One more point. If your criticism of NHST is more nuanced and informed than I'm assuming, please excuse me. There certainly are significant problems with the way it's generally done, including widespread misinterpretation of the meaning of p values, overemphasis on particular thresholds, and much more.

However, what came before NHST wasn't better statistical analysis of scientific data. Current methods do often leave statisticians shaking their heads, but it is still a significant improvement over the non-statistical methods of much scientific work of the past.

(I should also note that I'm not a statistician. My education is in mathematics, and I've invested a fair amount of time into furthering my statistical knowledge, but I'm not an expert.)

The problem is that if you understand what a null hypothesis is, and why the first step in demonstrating that results are potentially meaningful requires demonstrating that it can be rejected, then there's nothing to explain. And if you don't understand those things you need more education on the topic than I can provide in a slashdot post.

I wasn't being dismissive, I told you precisely (if concisely) what you need to do to understand why this change in scientific methodology was important and valuable. If you care about the issue, I suggest that you do the work to learn the material. If you don't care to do that, the best thing I can do is to point out the lack so others who also lack the requisite background are less likely to accept your misunderstanding as a fact.

Really, I'm not being elitist or dismissive. I'm completely certain that you're capable of understanding the material -- and it's not material that I would expect everyone to know. But it is sufficiently subtle and complex that I'd be doing you a disservice if I tried to explain it in a few paragraphs of non-mathematical exposition, particularly since your earlier comment about disproving chance demonstrates that you've already gotten such an explanation, and it wasn't sufficient.

You need to learn some statistics.

And that change was a huge leap forward. It didn't get us to perfection, but the shift indicated a significant (yet still insufficient) increase in statistical literacy in the sciences.

Really? My 2013 N7 is running just fine. I wonder if it's related to apps.

That difference is ALL the difference. Without that, Prey is irrelevant because the second thing the thief will do is to reset your phone, at which point they can sell it. Prey does nothing to remove the financial motive for phone theft.

Nope, because the first thing the thief will do is put the phone in airplane mode.

2012 Nexus 7? If so, 5.1 probably won't make you very happy either. You should probably go back to KitKat. The 2012 N7 doesn't have enough RAM to run Lollipop well. M may be slimmer.

Yeah, you don't want to run Lollipop on a 2012 Nexus 7. 5.0 grew a little and it's too much for the 2012 N7's hardware. A goal of 5.1 was to slim it back down, but that wasn't really achieved. Perhaps M will run well on the 2012 N7.

(Disclaimer: I'm a Google engineer on the Android team, but speaking for myself, not in an official capacity.)