the great Short Attention Span Company(tm) EOLs phones like there's no tomorrow. my older google phone is stuck at android 2.x and will never get updates.
You're still using a Nexus One? Even the Nexus S got upgraded to 4.1. Serious kudos on keeping that five year-old phone running. Do modern apps run on it?
From a broader perspective, while I think Google should probably do a little better at updating older Nexus devices than it has, it's really not that bad; the Nexus 4 and first-gen Nexus 7 got Lollipop (though it doesn't run all that well on the N7v1), and I suspect that if it weren't for the fact that the SoC vendor is gone, the Galaxy Nexus would have as well.
Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info.
(I'm a member of Google's Android security team.)
This is a valid issue, but separate from what the report is attempting to address. Well, not entirely separate, because the Android security team does in some cases classify apps that request excessive permissions as potentially-harmful, but only when there's evidence that the apps are actually trying to abuse the user.
Note that I'm not trying to downplay the issue of apps that request more permissions than they need. I think (based on lots of evidence) that in most cases this is more an artifact of developer laziness than malice; they aren't sure exactly what they need and definitely don't know what they're going to need in the future and so find it easier to ask for the world. This is a problem the Android security team recognizes and is working to address, in various ways that I can't go into.
How is tracking me with nothing given in return not "harmful?" My privacy has value to me, surely. The claim that there is no harm relies on the known lie that my privacy has no value to me.
Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.
The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google.
Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not. In general, the Android security team treats the rest of Google as just another app developer and online service provider. It's not our job to enable their revenue streams. Granted that we recognize that those revenue streams pay our salaries, but in the long run treating users well is what will enable Google to continue making money and paying our salaries.
If Google or Apple talk stats about their ecosystem, take it with a giant grain of salt.
It's pure marketing BS.
Take it with a grain of salt, sure, that's wise. However, there's nothing marketing-related about the numbers in the report. These numbers are snapshots of the data the Android anti-malware team uses internally to assess its effectiveness. The numbers are not fudged, and what they show is that while there are issues, Google's anti-malware team is making solid progress and the current state of the ecosystem is actually not too bad. There are some caveats (called out in the report) around the fact that the numbers describe the prevalence of known potentially-harmful apps. The charts get revised retroactively when new PHAs are discovered but snapshots in reports are static. Still, I think the numbers are quite reliable.
Note that I'm a member of the Android security team, and my manager is the primary author of the report and blog post, though I work on platform crypto features, not anti-malware.
At worst, the numbers in the report represent the ways in with the Android team fools itself about the state of ecosystem security. At best they're an accurate and nuanced reflection of the state of the ecosystem. The truth is somewhere in between, but I think it's far, far closer to the latter than the former. What the numbers definitely are not is anything cooked up specifically for the public.
It also seems pretty unlikely that the NSA had enough foresight to get VC++ instrumented to subvert TrueCrypt. It's not impossible, but there have been a lot of similar tools over the years, and I don't think the compilers could have been modified to subvert all of them.
So to you this couldn't have been anything but a perfect audit and if there was something, there was a 100% chance it would have been caught.
Naive, or NSA op
Reading comprehension fail. Please re-read this sentence from the GP:
I'm not suggesting there's no chance they've missed anything, but I am saying the process is considerably more thorough and less likely to make a mistake.
Absolute certainty is impossible, but audits like this do provide a basis for a reasonable belief that the security of TrueCrypt is good.
In other cases (DES I think??? I could be wrong.) the NSA recommended some oddball changes. No one could find a negative consequence of them so they went in - a decade or so later, it turns out that the original implementation of DES DID have a cryptographic flaw and the NSA recommendations fixed that.
Specifically, the S boxes (essentially some translation tables used in the algorithm) in the original design were vulnerable to linear cryptanalysis, which is a cryptanalytic technique that involves constructing systems of linear equations representing the transformations in key portions of the algorithm, then applying mathematical analysis to deduce key and/or plaintext bits. Linear cryptanalysis was unknown in the academic world at the time, but it was apparently known to the NSA. The NSA's changes made DES resistant to linear cryptanalysis.
However, the NSA also reduced the key size and block size from 128 bits to 56 and 64 bits, respectively. This likely made DES vulnerable to brute force attacks by particularly well-funded attackers (e.g., the NSA). Use of multiple DES operations in sequence overcomes this issue and Triple DES today is still considered to be quite strong. So, all in all, the NSA improved DES security. This isn't surprising because it was a core part of their mission; a mission that appears to have been deprecated in the post 9/11 world, but was still very important to the NSA in the 70s.
Google is completely OK with sharing personal info with all governments
Not true, not in the slightest. Google has fought hard to minimize the information they have to give to governments, and to be as transparent as the law will allow about what they do give. Remember that Google created the transparency report, and was the company that managed to negotiate permission to share aggregated data about National Security Letters. Many other companies have followed suit, but Google led the way.
They have already been caught supplying users' data to the US government.
No, Google has been shown to comply with legal requirements, and to fight questionable requests in court. Snowden also revealed that the NSA was tapping Google's fiber. Google responded by encrypting the data on that fiber.
They make money on that as well because they charge the US government a fee for that service.
Cite? Since Google is a publicly-traded company, it should be easy to point to that line item in their SEC filings.
Stood up and achieved what? Get told by the Chinese government to STFU or GTFO?
No, told by the Chinese government to participate in government-mandated censorship or GFTO. Google participated for a while and then decided it wasn't what they ought to be doing, and so chose to GTFO of the biggest market on the planet (albeit one in which they had a small market share.
except that polling it continuously will keep the device from going to sleep (have an impact on battery life).
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.
I wonder if I can create a Tasker profile to automate that
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...
you do want the screen to turn off and lock from input when you place the phone in your pocket, unless you enjoy random stuff happening.
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.
So this is telling me that the apps that Google "Features" currently are not inspected or analyzed by any humans before they become featured. "Featured," to my way of thinking, means recommended. So, currently, are algorithms recommending apps, not people? And if so, how long before algorithms recommend movies, books, music? (Currently, Wikibooks notes that "Featured books are books that the Wiki community believes to be the best . ..")
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...
Mastercard and Visa are the only two companies that handle credit card transactions at the end of the day
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.
theyve often admitted theyre effectively the same company.
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.
Just think of the absolute treasure trove of personal data... that google has OCR'd, indexed, and MONETIZED! Damn. I'm with you. Fuq em.
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.
Right because it would be so hard to forge a picture of a government photo ID and utility bill...
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.
Why would a merchant trust a computer manufacturer or a search engine company with payment processing in the first place...?
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).
Hello, that is really interesting, thanks.
My customer only treats iPhones as secure, I have a Galaxy S5. Would it be possible do you think for Google to offer a service where you analyze source code and optionally only allow passed apps to be downloaded? The impression in the corporate world is that Android is an insecure platform.
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.
The permissions system on Android is such that you can't really install any apps at all without compromising all of the data on the device.
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.
(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.)
Somehow, I wouldn't feel comfortable working for a company that would make me feel like I had to make such an extensive disclaimer. Sounds like they really *aren't* supportive of transparency, but have brainwashed you with Orwellian doublespeak to make you (and the public) think they are.
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.
On Android, you are lucky if Google deems a bug worthy of fixing.
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 best sandboxing is useless if the OS itself has known and remote exploitable security issues, as Android usually does.
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,
Slashdot Mirror
the great Short Attention Span Company(tm) EOLs phones like there's no tomorrow. my older google phone is stuck at android 2.x and will never get updates.
You're still using a Nexus One? Even the Nexus S got upgraded to 4.1. Serious kudos on keeping that five year-old phone running. Do modern apps run on it?
From a broader perspective, while I think Google should probably do a little better at updating older Nexus devices than it has, it's really not that bad; the Nexus 4 and first-gen Nexus 7 got Lollipop (though it doesn't run all that well on the N7v1), and I suspect that if it weren't for the fact that the SoC vendor is gone, the Galaxy Nexus would have as well.
Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info.
(I'm a member of Google's Android security team.)
This is a valid issue, but separate from what the report is attempting to address. Well, not entirely separate, because the Android security team does in some cases classify apps that request excessive permissions as potentially-harmful, but only when there's evidence that the apps are actually trying to abuse the user.
Note that I'm not trying to downplay the issue of apps that request more permissions than they need. I think (based on lots of evidence) that in most cases this is more an artifact of developer laziness than malice; they aren't sure exactly what they need and definitely don't know what they're going to need in the future and so find it easier to ask for the world. This is a problem the Android security team recognizes and is working to address, in various ways that I can't go into.
How is tracking me with nothing given in return not "harmful?" My privacy has value to me, surely. The claim that there is no harm relies on the known lie that my privacy has no value to me.
Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.
The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google.
Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not. In general, the Android security team treats the rest of Google as just another app developer and online service provider. It's not our job to enable their revenue streams. Granted that we recognize that those revenue streams pay our salaries, but in the long run treating users well is what will enable Google to continue making money and paying our salaries.
If Google or Apple talk stats about their ecosystem, take it with a giant grain of salt.
It's pure marketing BS.
Take it with a grain of salt, sure, that's wise. However, there's nothing marketing-related about the numbers in the report. These numbers are snapshots of the data the Android anti-malware team uses internally to assess its effectiveness. The numbers are not fudged, and what they show is that while there are issues, Google's anti-malware team is making solid progress and the current state of the ecosystem is actually not too bad. There are some caveats (called out in the report) around the fact that the numbers describe the prevalence of known potentially-harmful apps. The charts get revised retroactively when new PHAs are discovered but snapshots in reports are static. Still, I think the numbers are quite reliable.
Note that I'm a member of the Android security team, and my manager is the primary author of the report and blog post, though I work on platform crypto features, not anti-malware.
At worst, the numbers in the report represent the ways in with the Android team fools itself about the state of ecosystem security. At best they're an accurate and nuanced reflection of the state of the ecosystem. The truth is somewhere in between, but I think it's far, far closer to the latter than the former. What the numbers definitely are not is anything cooked up specifically for the public.
If this hadn't been done ten years before he talked about, it's been done by now. They have everything they want. Live accordingly.
Fortunately, we know how to counter that threat.
It also seems pretty unlikely that the NSA had enough foresight to get VC++ instrumented to subvert TrueCrypt. It's not impossible, but there have been a lot of similar tools over the years, and I don't think the compilers could have been modified to subvert all of them.
So to you this couldn't have been anything but a perfect audit and if there was something, there was a 100% chance it would have been caught.
Naive, or NSA op
Reading comprehension fail. Please re-read this sentence from the GP:
I'm not suggesting there's no chance they've missed anything, but I am saying the process is considerably more thorough and less likely to make a mistake.
Absolute certainty is impossible, but audits like this do provide a basis for a reasonable belief that the security of TrueCrypt is good.
In other cases (DES I think??? I could be wrong.) the NSA recommended some oddball changes. No one could find a negative consequence of them so they went in - a decade or so later, it turns out that the original implementation of DES DID have a cryptographic flaw and the NSA recommendations fixed that.
Specifically, the S boxes (essentially some translation tables used in the algorithm) in the original design were vulnerable to linear cryptanalysis, which is a cryptanalytic technique that involves constructing systems of linear equations representing the transformations in key portions of the algorithm, then applying mathematical analysis to deduce key and/or plaintext bits. Linear cryptanalysis was unknown in the academic world at the time, but it was apparently known to the NSA. The NSA's changes made DES resistant to linear cryptanalysis.
However, the NSA also reduced the key size and block size from 128 bits to 56 and 64 bits, respectively. This likely made DES vulnerable to brute force attacks by particularly well-funded attackers (e.g., the NSA). Use of multiple DES operations in sequence overcomes this issue and Triple DES today is still considered to be quite strong. So, all in all, the NSA improved DES security. This isn't surprising because it was a core part of their mission; a mission that appears to have been deprecated in the post 9/11 world, but was still very important to the NSA in the 70s.
Google is completely OK with sharing personal info with all governments
Not true, not in the slightest. Google has fought hard to minimize the information they have to give to governments, and to be as transparent as the law will allow about what they do give. Remember that Google created the transparency report, and was the company that managed to negotiate permission to share aggregated data about National Security Letters. Many other companies have followed suit, but Google led the way.
They have already been caught supplying users' data to the US government.
No, Google has been shown to comply with legal requirements, and to fight questionable requests in court. Snowden also revealed that the NSA was tapping Google's fiber. Google responded by encrypting the data on that fiber.
They make money on that as well because they charge the US government a fee for that service.
Cite? Since Google is a publicly-traded company, it should be easy to point to that line item in their SEC filings.
Stood up and achieved what? Get told by the Chinese government to STFU or GTFO?
No, told by the Chinese government to participate in government-mandated censorship or GFTO. Google participated for a while and then decided it wasn't what they ought to be doing, and so chose to GTFO of the biggest market on the planet (albeit one in which they had a small market share.
except that polling it continuously will keep the device from going to sleep (have an impact on battery life).
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.
I wonder if I can create a Tasker profile to automate that
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...
you do want the screen to turn off and lock from input when you place the phone in your pocket, unless you enjoy random stuff happening.
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.
She keeps wanting me to write a new operating system called PENIX.
Does she prefer monolithic or microkernel?
So this is telling me that the apps that Google "Features" currently are not inspected or analyzed by any humans before they become featured. "Featured," to my way of thinking, means recommended. So, currently, are algorithms recommending apps, not people? And if so, how long before algorithms recommend movies, books, music? (Currently, Wikibooks notes that "Featured books are books that the Wiki community believes to be the best . . .")
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...
Mastercard and Visa are the only two companies that handle credit card transactions at the end of the day
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.
theyve often admitted theyre effectively the same company.
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.
Just think of the absolute treasure trove of personal data... that google has OCR'd, indexed, and MONETIZED! Damn. I'm with you. Fuq em.
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.
Right because it would be so hard to forge a picture of a government photo ID and utility bill...
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.
Why would a merchant trust a computer manufacturer or a search engine company with payment processing in the first place...?
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).
Hello, that is really interesting, thanks. My customer only treats iPhones as secure, I have a Galaxy S5. Would it be possible do you think for Google to offer a service where you analyze source code and optionally only allow passed apps to be downloaded? The impression in the corporate world is that Android is an insecure platform.
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.
The permissions system on Android is such that you can't really install any apps at all without compromising all of the data on the device.
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.
Somehow, I wouldn't feel comfortable working for a company that would make me feel like I had to make such an extensive disclaimer. Sounds like they really *aren't* supportive of transparency, but have brainwashed you with Orwellian doublespeak to make you (and the public) think they are.
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.
You don't do something unless you have plans to use it. I call bullshit.
I see you have little experience with decisionmaking in corporate America.
I'm glad to hear that.
On Android, you are lucky if Google deems a bug worthy of fixing.
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 best sandboxing is useless if the OS itself has known and remote exploitable security issues, as Android usually does.
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,
No risk of leaks or poisoning as long as the areas around the chamber are open to the outside air... the chamber needs only be moderately airtight
No chamber needed. A typical hospital oxygen mask with a good flow of pure N2 into will do fine.