It doesn't seem to have a significant impact, AFAICT. I haven't benchmarked with and without, but at leas on my Nexus 6 I didn't observe any obvious decrease in battery life when I turned it on.

Uh, no, this can't work. Security settings changes require password authentication, and there probably isn't an app API to change them anyway (for good reasons).

I've been using this feature for a few months now (I work for Google) and I think on balance it significantly improves my security. It means that I can set my phone to lock instantly on display timeout, with a one-minute timeout, lock instantly on power button press, and use a long, complex password... and not be inconvenienced by having to constantly re-enter a long password. This is a security win, because if I did have to enter a long password two dozen times per day, I wouldn't do it; I'd choose a simpler password and settings that lock my device less aggressively. Even better, I find myself subtly encouraged by the phone to keep it in my pocket, rather than setting it down on tables, desks, etc., because if I put it down somewhere I'll have to re-enter my password.

If I were mugged, I'd just hit the power button as I remove the phone from my pocket. Actually, what I'd really like to do in that case is to power it down, but I'm not sure I could get away with that, since it requires holding the power button for a couple of seconds, then tapping the confirmation dialog. Since my phone is encrypted, getting it into a powered-down state makes my data quite secure. Not that the lockscreen is necessarily easy to bypass, but it's part of a large, complex system, which means there's a lot of attack surface. Once the device is powered down, the risk model is very simple and well-understood: If the attacker can't guess my password, he can't get at my data. Thanks to the hardware-backed encryption used in Lollipop, password guessing is rate-limited by the hardware to a level that would require, on average, about 70 years of continuous trials. Even if the attacker were that patient (a) nothing on my phone would be worth anything after a decade or so and (b) I doubt the device would last that long. Mobile devices aren't built to run flat out for years.

I've also used the bluetooth proximity Smart Lock, paired to a smartwatch, but I've decided I like the "Trusted behavior" feature better, so I've stopped trusting proximity to my watch. The range on bluetooth is large enough that I can set my phone down and be far enough away that someone could use it but still within range for keeping unlocked. Plus, I really like the encouragement to keep the device on my body. In the long run, that user training will, I think, do more for my device security than anything else.

I do still use bluetooth, but paired to my car's bluetooth, so I can put the phone in a cradle or on the center console and have it stay unlocked. I also set the phone to trust proximity to the bluetooth headset I use when cycling, because I put the phone in a cradle mounted on the handlebars and want it to stay unlocked as I use it to track my ride.

The discussion on this thread about phones being snatched from hands, though, makes me think that perhaps I should re-enable trust of my smartwatch. That would address high-speed theft pretty well. I just tested and taking the phone out of range of my smartwatch does lock the phone, even if it's in my pocket. So a thief couldn't just grab it from my hands and drop it in their pocket to keep it unlocked.

However, this means I lose the on-body self-training. I suppose if I turn the smartwatch linkage on only when I'm outside my home or office, I'd get the on-body training most of the time but the smartwatch linkage all of the rest. Hmm... I wonder if I can create a Tasker profile to automate that...

The proximity sensor (same one that prevents you from hitting buttons with your cheek while talking on the phone) should turn the screen off and disable input without locking the screen when it senses your leg/hip.

Does she prefer monolithic or microkernel?

No. "Apps featured in Google Play" isn't the same as "Featured Apps in Google Play". Neither phrase was from Google, either, but from the summary.

The summary is wrong in others ways, too. It says that Google is going to begin screening apps. The actual announcement says that this has been going on for several months. It also says that the process is "human-based", which the announcement doesn't say, just that the process "involves a team of experts who are responsible for identifying violations of our developer policies earlier in the app lifecycle." This leaves open the possibility that the team in question automates the actual screening, which is obviously much more normal for Google.

Really, your best bet is to ignore the summary and the linked article and just read the post from Google: http://android-developers.blog...

Thinkpads have always been very Linux-friendly laptops, as well as being well-designed and built, robust, and there are masses of ~3 year old ex-corporate units available via brokers, some in virtually as-new condition, at a small fraction of their original price. I've recently bought two top-condition X220s with 8GB RAM for around £300 each (I'm in UK, I got them from Tier 1 Online) and I expect them to serve me well for at least another 3-4 years. Add an SSD for a welcome performance boost for a modest outlay.

Actually, Mastercard and Visa aren't even companies. They're associations of banks. There are incorporated entities under those names (many of them, actually, one per country, plus Mastercard International and Visa International, which themselves have many national subsidiaries), but they don't issue credit cards, and only operate some pieces of the transaction processing networks.

As someone who regularly meets with representatives from both, discussing areas where the competitors are trying to collaborate on standards but without giving up any edges, I call bullshit on this claim. They're most definitely separate, and competitors. It is true that their interests align in some cases, and they work together almost as much as they compete, but your claim that they're the same company is just ludicrous.

Google doesn't use the ID verification data for anything else. Actually, it's not clear what it would be useful FOR. How does knowing your driver's license number help Google to decide what ads to show you?

Plus, the vast majority of users of Google Wallet don't have to submit this data. It's not the normal case.

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.