There is similar partitioning on ios. The firm I work for can remote erase my phone, etc
Remote erase your whole phone, or just the work part? I hadn't heard that iOS had acquired anything comparable to the Android work profile, and some quick googling just turned up comments about how it was needed. Am I missing something or are you mistaken?
It is even worse: The productivity you get this way is wayyyy lower than with a 40h week.
That depends on the nature of the work. For intellectual work, what you say is true (in the long run, anyway, the the short run productivity per hour can actually be higher due to increased focus), but for rote work productivity doesn't fall off that much.
I'm not suggesting that Alibaba's approach is good, just correcting your overbroad claim.
We have hundreds of iPhones returned by former employees that are unusable because of this. Apple refuses to unlock them even though they belong to the company.
Sounds like the company needs to learn how to properly deploy corporate-managed iPhones.
Yes. Both Android and iOS provide key escrow services for corp-managed devices, so the corporation can unlock them without the employee's help. Android goes a step further and offers the ability for user-owned devices to set up a "work profile" which contains all corporate apps and data, and gives enterprises the ability to manage or delete the work profile apps, but no access to the personal profile or data.
If some company is suffering because it fails to use the enterprise features available, that's its own fault. This stuff has been available in mobile OSes for some time.
Yeah, but unlike Samsung phones iPhones are secure.
I'd say that Samsung phones are roughly as secure as iPhones, though neither is quite as secure as the Google Pixel. Of course, security is a multi-dimensional discrete space, not a one-dimensional continuum, so any comparisons of this sort are of questionable validity without a precisely-defined threat model. However, if we use the results of public competitions as our metric, Samsung and Apple phones get cracked with roughly equal frequency, while Pixel phones fare much better (Pixel has stood unbeaten three years running in Mobile Pwn2Own, for example, while both Apple and Samsung were cracked every year).
Do a factory reset and you have to log into the original owners samsung account
Not just Samsung... all Android phones. Though usually it's your Google account, not your Samsung account, that you need to authenticate to prove ownership after a factory reset. (In fact, even Samsung says it's your Google account; so I think maybe you're confused about that.)
This feature, called Factory Reset Protection (FRP) by the Android team, was implemented in both iOS and Android 4-5 years ago,, to comply with a California state law that mandated it. For Android, it was launched in May 2016, in Android 5.1. Although it is only legally required for devices sold in California (AFAIK), it's generally a very good idea. Device theft was rapidly ballooning into a huge problem, but thanks to FRP has ceased to be a significant issue. If you set a password on your phone, thieves get no value from it.
However, there's no reason that FRP-locked devices have to be destroyed. At least in the Android world, device makers install keys on the devices which can be used to bypass FRP. These keys are only accessible to authorized refurbishing centers, of course, because if they leak to phone thieves then the purpose of the feature is defeated.
While I do agree with you, I will point out a benefit paper maps do offer.
Bloody good battery life.
If you're navigating in the back country, this is a good point. If you're in a car... do you seriously not carry a cable so you can plug your phone in? Cars provide all the power you could possibly need.
As a practical matter, my Pixel 3's battery never gets below about 25% full. It lasts all day and recharges very quickly so with just a few minutes' time plugged in I'm good for several more hours. It's really not a problem for me. YMMV, I suppose.
Do you have any evidence -- at all -- that these devices scan for something other than the configured hotword?
Note that since the companies that make them are publicly-traded, there's a legally-enforceable expectation that when those companies say that the devices don't search for any other phrases, they're telling the truth. If anyone could prove that they weren't it would get the companies in significant trouble with the FTC and SEC. This is especially true for Google, which is operating under the terms of an FTC consent decree put into effect after the Google Buzz incident.
Have you not seen this?
In today's world, just because The Big Company doesn't tell you about a thing that their product does, doesn't mean that they told you that it doesn't do that. And that's the logic that we're dealing with. The mentality that you perceive from Silicon Valley seems outdated.
Meh. That was clearly a simple mistake. They added the mic because they intended to use it later, then failed to include it in the spec sheet. There is also no evidence whatsoever that it was ever used at all until after it was actually announced.
This is actually an important point, though: Most of the tinfoil-hat crowd who is certain that companies are constantly maliciously lying have to attribute impossibly-high levels of competence and planning to them. In the real world, companies are made up of fallible people, and this not only means that mistakes like the one you linked happen... it also means that the sort of conspiracies of silence required to carry out the theorized malicious acts are just impossible.
Never use any Google services, unless you are prototyping something that doesn't have a lifespan of more than a year. They deprecate APIs and whole services at random. I am shocked when I heard a friend say their start-up uses Go. Go! And tried to sell me how great it was. Which may be true, but it probably only has a year left.
Go is already nine years old. At what point does the one-year lifespan limit start?
We can call it "listening" or "phrase recognition". They're the same. Now, maybe when phrase #1 is detected, action #1 is preformed. But then if phrase #2 is detected, then action #2 is preformed. However, that action #1 talks to you, and you're made aware of that, doesn't mean that action #2 needs to let you in on it all.
Do you have any evidence -- at all -- that these devices scan for something other than the configured hotword?
Note that since the companies that make them are publicly-traded, there's a legally-enforceable expectation that when those companies say that the devices don't search for any other phrases, they're telling the truth. If anyone could prove that they weren't it would get the companies in significant trouble with the FTC and SEC. This is especially true for Google, which is operating under the terms of an FTC consent decree put into effect after the Google Buzz incident.
Oh, and if the devices were doing anything else, it wouldn't be at all difficult for skilled engineers to tell by disassembling the devices and observing what parts to what, when. Or by reversing the firmware. In addition, we're talking about Silicon Valley companies, where the engineering staff is notoriously willing to blow the whistle on anything they perceive as bad behavior.
Given all of that, the company leaders would have to be complete idiots to allow anything like what you postulate to be done.
I wouldn't call it their 'best thing going', it's been massively bloated for quite some time now. You shouldn't need a quad-core 3GHz processor just to look at a fucking map.
You shouldn't need a computer at all to look at a fucking map. Ironically, that doesn't compute for anyone under the age of 30.
Bah (and I'm long past 30).
Who wants to deal with paper maps? Certainly no one who travels very much. I remember the pre-mobile maps days quite well, and NO THANK YOU! What a pain in the ass. You either had to find a place to buy a real map every time you went somewhere, or try to make do with the crappy, detail-free maps provided by the car rental agency. Oh, and you had better not be traveling alone, because trying to navigate with a paper map while driving basically meant having to choose between dying or getting repeatedly lost and having to pull over and stop to examine the map and figure out where you went wrong.
Oh, and forget trying to navigate by paper map in a foreign country where you don't speak the language -- especially if they don't use a latin alphabet. Back in the day, it would never have occurred to me even to try to drive -- or use the mass transit system -- in any Asian country. Now, no problem.
And good luck trying to refold a blasted paper map. (Actually, I'm pretty good at it, but it's a rare and hard-won skill.)
Nope, I'll take mobile maps with offline download, automatic route calculation, incredibly-accurate travel time estimates, in my language, with excellent mass transit support (often with real-time arrival info) and voice prompts while driving every day of the week and twice on Sunday. Oh, and walking directions that don't tell you to walk where you shouldn't (though I'll grant that walking directions have only recently gotten good enough to be really useful in Google Maps).
And that's just for getting around. Those cruddy paper maps were almost, but not quite, utterly useless for finding restaurants, gas stations or anything else. Sometimes they had a marginally-useful gazetteer, but that was rare (and generally only included places who'd paid for the privilege of being listed -- hmm). And on the rare occasions where restaurant info was provided, the maps completely and totally failed to provide reviews on the food quality, timeliness and friendliness of the waitstaff, or even price range! Much less the full menu (that's hit or miss even today; but happens often enough that I usually skip any place that doesn't provide it.)
Paper. Maps. Suck.
Not because I don't know how to use them, but because they are severely feature-deficient. They only tell me a tiny fraction of what I want to know, and do it in an extremely inconvenient way.
My servers have been negotiating TLS connections for years. What's all this about?
What do your servers do when they attempt to negotiate a TLS connection with another SMTP server, but the other server doesn't appear to support TLS? Do they refuse to connect and deliver email? Or do they shrug and deliver it anyway?
The latter is what you have to do, because not every SMTP server supports TLS. MTA-STS provides a way for your server to check whether a given remote server is expected to support TLS. If yes, and if the TLS negotiation fails, your server can safely assume that something funny is going on and refuse to deliver the mail. If no, then your server can safely assume that the remote server probably really doesn't support TLS, and that probably nothing funny is going on.
The root problem is that TLS can only defend against active attacks if it's mandatory. As long as the sending server is willing to fall back to a non-TLS connection, then TLS does nothing against active attacks. It still protects against passive eavesdropping, so it's not useless, but it's much less useful. Being able to know for sure when you should demands TLS fixes this -- at least for the servers that support TLS and advertise the fact through MTA-STS.
Such as cornering the market for harvesting e-mail content to sell us more targeted ads.
I strongly doubt that the Gmail security team ever thinks about advertising at all. I also doubt that any executive in the advertising division ever heard about this before it launched. The nature of Google is that nearly all of these initiatives are bottom up, with little or no coordination across divisions. If something one group is doing seems like it might actively harm another, then that gets escalated. Otherwise, there's not much central planning, not at this level of detail.
...that Alexa actually has no AI at all. It just records audio commands, sends them to a central server, where human monkeys listen to conversations, and make Alexa act accordingly. It is just like the Truman show, only bigger. Probably the same happens for Siri.
They do take the security and privacy of their customers’ info seriously. They keep it locked away and sell it only to people they trust. It would be a bad idea to sell it to someone who might not pay for the info.
I doubt they're dumb enough to sell data, to anyone.
Aside from the PR and regulatory concerns raised by selling data, if you sell data you can only sell it once to each buyer. If you sell some service that uses the data (e.g. targeted advertising), without revealing the data itself or the identity of the user, then you can sell that service many times to each buyer. Further, if the prospective buyer doesn't have as much expertise as you do, they probably get more value from the data-based service than they would from the data itself, so they're actually perfectly happy to pay for the service and let you do all of the hard work. This is Google's business model. Not sure about Amazon.
While I feel pretty confident that when I deny a random app's access to the microphone, that app really can't access it, but I have less confidence Google themselves can't turn on the mic anytime they want.
FWIW, if any Google apps (including Google Play services) had the ability to turn on the mic without the user's knowledge or permission, the Google security and privacy teams would both consider it to be a serious bug. And, of course, there's nothing in the base Android platform that provides Google with any special access. Note that I'm not saying Google apps don't have the permissions required to enable the mic -- I think Play services has pretty much every permission defined by the platform -- but that the apps must not use that permission without user knowledge and permission.
But what people still don't seem to get is that these devices are not recording 24/7. They monitor for the trigger names to activate...
You said "record", but I don't know why. It's silly to think that a voice-operated device is only listening when you say a certain phrase. Obviously it's listening all the time, otherwise how would it hear the phrase?
The phrase recognition is done locally, nothing is saved on-device or sent to the cloud. I don't know about the home devices, but phones have dedicated circuitry that does nothing but hotword recognition. This is done to keep power usage down Having to keep a core of the main CPU awake would consume far too much power, draining the battery. Having to transmit the data via the cellular radio would destroy battery life, and burn expensive data.
Does having a powered-up microphone and very simple pattern recognition system processing the audio stream count as "listening"? Does having a router scanning Ethernet signals looking for packet boundaries and IP addresses count as "reading"? Seems like pretty much the same thing to me.
Absolutely not. I didn't mention the fact that I screwed up and tried out Google Fi. It FORCE tied my phone to my google account. There is no way to untie it now. I have been all the way to the developer level and they said that is by design.
I don't think so. If you really can't remove the phone number associated with your account (and you're not on Fi any more) please email me and I'll file a bug. My slashdot username @google.com.
SMS can be hijacked and rerouted. There have been a lot of real-world examples over the last year or two where attackers have social-engineered the telco to reroute SMS to a device they control, then used the SMS auth to compromise user accounts.
If you save your password on the phone (so that it gets entered automatically on an app or website), then you are not really adding a second factor by proving that you have the device. For the password to be the "something you know" factor, the something needs to be something in your brain, not something stored the same device that is the "something you have" factor. Does this new setup ensure that passwords can not be saved?
This is for logging into a web site on a separate computer. Google doesn't provide any way to save your Google password on your phone and have it automatically sent to your computer, AFAIK.
Actually your saved passwords are synced from computer to phone and back again if you are signed in to chrome on both devices. Very convenient but some risk for sure.
your browser communicates via bluetooth with your phone
Hard pass.
Why? This is very good for security. Uses a separate, non-Internet and inherently local (in the absence of sophisticated relay attacks), channel significantly increases security. Do you have a problem with bluetooth in particular, or some other aspect?
I don't WANT there to be any tie in between my user account and my device. I want my accounts to both secure AND as anonymous as possible. I don't want Google's repeated efforts of tieing a specific human to a specific user account.
Google has no interest in tying a specific human to a user account, outside of some groups within Google that fight abuse (a common abuse tactic is to great huge numbers of accounts, and spread the abuse across them), and even they don't care about tying specific people to accounts, they just want to make bulk account creation hard. Besides that, Google doesn't care if you have several accounts or few of them, and doesn't really care if the names, etc. on them are real.
In any case, this new 2FA feature has nothing to do with that, and, actually, does nothing to make your goal of using Google services anonymously any harder.
This feature is all about preventing account hijacking and theft. Passwords alone have not been secure for quite some time, and are getting worse all the time. Something more is needed. The "security questions" approach is laughably bad. Worse than the passwords it's trying to cover for. SMS-based two-step verification is better, but SMS hijacking can defeat it. Plus, people like you don't want to add a phone number to your Google account, and SMS 2SV obviously requires that.
This new 2FA option allows your phone to act as a cryptographic second factor for logging you on. It does not use your phone number to do this, and doesn't in any way tie you as a human to the Google account... it involves creating a new (random!) cryptographic key on your phone and then associating that with your account.
If you save your password on the phone (so that it gets entered automatically on an app or website), then you are not really adding a second factor by proving that you have the device. For the password to be the "something you know" factor, the something needs to be something in your brain, not something stored the same device that is the "something you have" factor. Does this new setup ensure that passwords can not be saved?
This is for logging into a web site on a separate computer. Google doesn't provide any way to save your Google password on your phone and have it automatically sent to your computer, AFAIK.
Next will be 3FA, then 4, and at some point they will wear you down and you will be assimilated.
Arguably, if your phone has a fingerprint scanner, this is three-factor. You have to unlock your phone to authorize it to send the cryptographic second-factor message to your computer via bluetooth. And, of course, this is after you entered your password. So... something you know (your password), something you have (your phone) and something you are (your fingerprint, to unlock the phone).
It's "arguable" not "fact", because some definitions of 3FA would require that the backend verify the third authenticator as well, where in this case that's done on the phone (the something-you-have). In practice, secure remote biometric verification is, er, hard.
Yeah, "The feature is coming only to Android devices versions 7 and up" is confusing for those of us already using 2FA. I've been using 2FA via Google Authenicator for some google accounts since Android 5. 2SV is not the only option, we already have a 2FA option. Or did we lose that 2FA option in recent history and now its returning? I am only using 2FA on a somewhat "old" account.
This is a new 2FA option. A pretty nice one, actually.
Google Authenticator requires you to unlock your phone, open the app, read the number, type it into the browser window and click a submit button. Oh, and you have to do it relatively quickly because the number is only valid for a short period of time.
With this new approach, which builds on Android's ability to act as a FIDO token (which itself is built on top of Android Keystore authentication -- which, BTW, I designed and built:-) ), your browser communicates via bluetooth with your phone to get a cryptographic authentication token. So from the user perspective, when you get to the 2FA request screen, you just unlock your phone and tap "okay".
If you have a nano security key that just lives in the USB port all of the time, then that's still the most convenient 2FA approach, IMO. But there's a valid (though not strong, for most users) argument that leaving the security key in the USB port all of the time is a bad idea. In addition, to use a security key you have to buy a security key, which you probably don't already have.
Of course the 2SV option (SMS code) still exists, but it's significantly weaker from a security perspective.
Security is context-dependent, so you can't really place these things on a continuum, but if I make a bunch of simplifying assumptions about common user scenarios, I'd say that Android-as-FIDO is the strongest second factor auth option currently offered. Security keys generally use certified hardware which is arguably more secure than the relevant hardware in a phone, but Android-as-FIDO also requires user authentication (usually biometric; so it's arguably three factor), while security keys do not. The Authenticator app is a little weaker because a root compromise of the phone can extract the relevant long-lived secret.
This new feature is good stuff. It's quite secure, and also very user-friendly, which encourages people who might otherwise not use 2FA to turn it on.
Slashdot Mirror
There is similar partitioning on ios. The firm I work for can remote erase my phone, etc
Remote erase your whole phone, or just the work part? I hadn't heard that iOS had acquired anything comparable to the Android work profile, and some quick googling just turned up comments about how it was needed. Am I missing something or are you mistaken?
It is even worse: The productivity you get this way is wayyyy lower than with a 40h week.
That depends on the nature of the work. For intellectual work, what you say is true (in the long run, anyway, the the short run productivity per hour can actually be higher due to increased focus), but for rote work productivity doesn't fall off that much.
I'm not suggesting that Alibaba's approach is good, just correcting your overbroad claim.
We have hundreds of iPhones returned by former employees that are unusable because of this. Apple refuses to unlock them even though they belong to the company.
Sounds like the company needs to learn how to properly deploy corporate-managed iPhones.
Yes. Both Android and iOS provide key escrow services for corp-managed devices, so the corporation can unlock them without the employee's help. Android goes a step further and offers the ability for user-owned devices to set up a "work profile" which contains all corporate apps and data, and gives enterprises the ability to manage or delete the work profile apps, but no access to the personal profile or data.
If some company is suffering because it fails to use the enterprise features available, that's its own fault. This stuff has been available in mobile OSes for some time.
Yeah, but unlike Samsung phones iPhones are secure.
I'd say that Samsung phones are roughly as secure as iPhones, though neither is quite as secure as the Google Pixel. Of course, security is a multi-dimensional discrete space, not a one-dimensional continuum, so any comparisons of this sort are of questionable validity without a precisely-defined threat model. However, if we use the results of public competitions as our metric, Samsung and Apple phones get cracked with roughly equal frequency, while Pixel phones fare much better (Pixel has stood unbeaten three years running in Mobile Pwn2Own, for example, while both Apple and Samsung were cracked every year).
Do a factory reset and you have to log into the original owners samsung account
Not just Samsung... all Android phones. Though usually it's your Google account, not your Samsung account, that you need to authenticate to prove ownership after a factory reset. (In fact, even Samsung says it's your Google account; so I think maybe you're confused about that.)
This feature, called Factory Reset Protection (FRP) by the Android team, was implemented in both iOS and Android 4-5 years ago,, to comply with a California state law that mandated it. For Android, it was launched in May 2016, in Android 5.1. Although it is only legally required for devices sold in California (AFAIK), it's generally a very good idea. Device theft was rapidly ballooning into a huge problem, but thanks to FRP has ceased to be a significant issue. If you set a password on your phone, thieves get no value from it.
However, there's no reason that FRP-locked devices have to be destroyed. At least in the Android world, device makers install keys on the devices which can be used to bypass FRP. These keys are only accessible to authorized refurbishing centers, of course, because if they leak to phone thieves then the purpose of the feature is defeated.
While I do agree with you, I will point out a benefit paper maps do offer.
Bloody good battery life.
If you're navigating in the back country, this is a good point. If you're in a car... do you seriously not carry a cable so you can plug your phone in? Cars provide all the power you could possibly need.
As a practical matter, my Pixel 3's battery never gets below about 25% full. It lasts all day and recharges very quickly so with just a few minutes' time plugged in I'm good for several more hours. It's really not a problem for me. YMMV, I suppose.
Do you have any evidence -- at all -- that these devices scan for something other than the configured hotword?
Note that since the companies that make them are publicly-traded, there's a legally-enforceable expectation that when those companies say that the devices don't search for any other phrases, they're telling the truth. If anyone could prove that they weren't it would get the companies in significant trouble with the FTC and SEC. This is especially true for Google, which is operating under the terms of an FTC consent decree put into effect after the Google Buzz incident.
Have you not seen this? In today's world, just because The Big Company doesn't tell you about a thing that their product does, doesn't mean that they told you that it doesn't do that. And that's the logic that we're dealing with. The mentality that you perceive from Silicon Valley seems outdated.
Meh. That was clearly a simple mistake. They added the mic because they intended to use it later, then failed to include it in the spec sheet. There is also no evidence whatsoever that it was ever used at all until after it was actually announced.
This is actually an important point, though: Most of the tinfoil-hat crowd who is certain that companies are constantly maliciously lying have to attribute impossibly-high levels of competence and planning to them. In the real world, companies are made up of fallible people, and this not only means that mistakes like the one you linked happen... it also means that the sort of conspiracies of silence required to carry out the theorized malicious acts are just impossible.
Never use any Google services, unless you are prototyping something that doesn't have a lifespan of more than a year. They deprecate APIs and whole services at random. I am shocked when I heard a friend say their start-up uses Go. Go! And tried to sell me how great it was. Which may be true, but it probably only has a year left.
Go is already nine years old. At what point does the one-year lifespan limit start?
We can call it "listening" or "phrase recognition". They're the same. Now, maybe when phrase #1 is detected, action #1 is preformed. But then if phrase #2 is detected, then action #2 is preformed. However, that action #1 talks to you, and you're made aware of that, doesn't mean that action #2 needs to let you in on it all.
Do you have any evidence -- at all -- that these devices scan for something other than the configured hotword?
Note that since the companies that make them are publicly-traded, there's a legally-enforceable expectation that when those companies say that the devices don't search for any other phrases, they're telling the truth. If anyone could prove that they weren't it would get the companies in significant trouble with the FTC and SEC. This is especially true for Google, which is operating under the terms of an FTC consent decree put into effect after the Google Buzz incident.
Oh, and if the devices were doing anything else, it wouldn't be at all difficult for skilled engineers to tell by disassembling the devices and observing what parts to what, when. Or by reversing the firmware. In addition, we're talking about Silicon Valley companies, where the engineering staff is notoriously willing to blow the whistle on anything they perceive as bad behavior.
Given all of that, the company leaders would have to be complete idiots to allow anything like what you postulate to be done.
I wouldn't call it their 'best thing going', it's been massively bloated for quite some time now. You shouldn't need a quad-core 3GHz processor just to look at a fucking map.
You shouldn't need a computer at all to look at a fucking map. Ironically, that doesn't compute for anyone under the age of 30.
Bah (and I'm long past 30).
Who wants to deal with paper maps? Certainly no one who travels very much. I remember the pre-mobile maps days quite well, and NO THANK YOU! What a pain in the ass. You either had to find a place to buy a real map every time you went somewhere, or try to make do with the crappy, detail-free maps provided by the car rental agency. Oh, and you had better not be traveling alone, because trying to navigate with a paper map while driving basically meant having to choose between dying or getting repeatedly lost and having to pull over and stop to examine the map and figure out where you went wrong.
Oh, and forget trying to navigate by paper map in a foreign country where you don't speak the language -- especially if they don't use a latin alphabet. Back in the day, it would never have occurred to me even to try to drive -- or use the mass transit system -- in any Asian country. Now, no problem.
And good luck trying to refold a blasted paper map. (Actually, I'm pretty good at it, but it's a rare and hard-won skill.)
Nope, I'll take mobile maps with offline download, automatic route calculation, incredibly-accurate travel time estimates, in my language, with excellent mass transit support (often with real-time arrival info) and voice prompts while driving every day of the week and twice on Sunday. Oh, and walking directions that don't tell you to walk where you shouldn't (though I'll grant that walking directions have only recently gotten good enough to be really useful in Google Maps).
And that's just for getting around. Those cruddy paper maps were almost, but not quite, utterly useless for finding restaurants, gas stations or anything else. Sometimes they had a marginally-useful gazetteer, but that was rare (and generally only included places who'd paid for the privilege of being listed -- hmm). And on the rare occasions where restaurant info was provided, the maps completely and totally failed to provide reviews on the food quality, timeliness and friendliness of the waitstaff, or even price range! Much less the full menu (that's hit or miss even today; but happens often enough that I usually skip any place that doesn't provide it.)
Paper. Maps. Suck.
Not because I don't know how to use them, but because they are severely feature-deficient. They only tell me a tiny fraction of what I want to know, and do it in an extremely inconvenient way.
My servers have been negotiating TLS connections for years. What's all this about?
What do your servers do when they attempt to negotiate a TLS connection with another SMTP server, but the other server doesn't appear to support TLS? Do they refuse to connect and deliver email? Or do they shrug and deliver it anyway?
The latter is what you have to do, because not every SMTP server supports TLS. MTA-STS provides a way for your server to check whether a given remote server is expected to support TLS. If yes, and if the TLS negotiation fails, your server can safely assume that something funny is going on and refuse to deliver the mail. If no, then your server can safely assume that the remote server probably really doesn't support TLS, and that probably nothing funny is going on.
The root problem is that TLS can only defend against active attacks if it's mandatory. As long as the sending server is willing to fall back to a non-TLS connection, then TLS does nothing against active attacks. It still protects against passive eavesdropping, so it's not useless, but it's much less useful. Being able to know for sure when you should demands TLS fixes this -- at least for the servers that support TLS and advertise the fact through MTA-STS.
Such as cornering the market for harvesting e-mail content to sell us more targeted ads.
I strongly doubt that the Gmail security team ever thinks about advertising at all. I also doubt that any executive in the advertising division ever heard about this before it launched. The nature of Google is that nearly all of these initiatives are bottom up, with little or no coordination across divisions. If something one group is doing seems like it might actively harm another, then that gets escalated. Otherwise, there's not much central planning, not at this level of detail.
...that Alexa actually has no AI at all. It just records audio commands, sends them to a central server, where human monkeys listen to conversations, and make Alexa act accordingly. It is just like the Truman show, only bigger. Probably the same happens for Siri.
But not Google Home / Google Assistant?
They do take the security and privacy of their customers’ info seriously. They keep it locked away and sell it only to people they trust. It would be a bad idea to sell it to someone who might not pay for the info.
I doubt they're dumb enough to sell data, to anyone.
Aside from the PR and regulatory concerns raised by selling data, if you sell data you can only sell it once to each buyer. If you sell some service that uses the data (e.g. targeted advertising), without revealing the data itself or the identity of the user, then you can sell that service many times to each buyer. Further, if the prospective buyer doesn't have as much expertise as you do, they probably get more value from the data-based service than they would from the data itself, so they're actually perfectly happy to pay for the service and let you do all of the hard work. This is Google's business model. Not sure about Amazon.
While I feel pretty confident that when I deny a random app's access to the microphone, that app really can't access it, but I have less confidence Google themselves can't turn on the mic anytime they want.
FWIW, if any Google apps (including Google Play services) had the ability to turn on the mic without the user's knowledge or permission, the Google security and privacy teams would both consider it to be a serious bug. And, of course, there's nothing in the base Android platform that provides Google with any special access. Note that I'm not saying Google apps don't have the permissions required to enable the mic -- I think Play services has pretty much every permission defined by the platform -- but that the apps must not use that permission without user knowledge and permission.
But what people still don't seem to get is that these devices are not recording 24/7. They monitor for the trigger names to activate...
You said "record", but I don't know why. It's silly to think that a voice-operated device is only listening when you say a certain phrase. Obviously it's listening all the time, otherwise how would it hear the phrase?
The phrase recognition is done locally, nothing is saved on-device or sent to the cloud. I don't know about the home devices, but phones have dedicated circuitry that does nothing but hotword recognition. This is done to keep power usage down Having to keep a core of the main CPU awake would consume far too much power, draining the battery. Having to transmit the data via the cellular radio would destroy battery life, and burn expensive data.
Does having a powered-up microphone and very simple pattern recognition system processing the audio stream count as "listening"? Does having a router scanning Ethernet signals looking for packet boundaries and IP addresses count as "reading"? Seems like pretty much the same thing to me.
Absolutely not. I didn't mention the fact that I screwed up and tried out Google Fi. It FORCE tied my phone to my google account. There is no way to untie it now. I have been all the way to the developer level and they said that is by design.
I don't think so. If you really can't remove the phone number associated with your account (and you're not on Fi any more) please email me and I'll file a bug. My slashdot username @google.com.
SMS can be hijacked and rerouted. There have been a lot of real-world examples over the last year or two where attackers have social-engineered the telco to reroute SMS to a device they control, then used the SMS auth to compromise user accounts.
If you save your password on the phone (so that it gets entered automatically on an app or website), then you are not really adding a second factor by proving that you have the device. For the password to be the "something you know" factor, the something needs to be something in your brain, not something stored the same device that is the "something you have" factor. Does this new setup ensure that passwords can not be saved?
This is for logging into a web site on a separate computer. Google doesn't provide any way to save your Google password on your phone and have it automatically sent to your computer, AFAIK.
Actually your saved passwords are synced from computer to phone and back again if you are signed in to chrome on both devices. Very convenient but some risk for sure.
Not your Google account password.
your browser communicates via bluetooth with your phone
Hard pass.
Why? This is very good for security. Uses a separate, non-Internet and inherently local (in the absence of sophisticated relay attacks), channel significantly increases security. Do you have a problem with bluetooth in particular, or some other aspect?
I don't WANT there to be any tie in between my user account and my device. I want my accounts to both secure AND as anonymous as possible. I don't want Google's repeated efforts of tieing a specific human to a specific user account.
Google has no interest in tying a specific human to a user account, outside of some groups within Google that fight abuse (a common abuse tactic is to great huge numbers of accounts, and spread the abuse across them), and even they don't care about tying specific people to accounts, they just want to make bulk account creation hard. Besides that, Google doesn't care if you have several accounts or few of them, and doesn't really care if the names, etc. on them are real.
In any case, this new 2FA feature has nothing to do with that, and, actually, does nothing to make your goal of using Google services anonymously any harder.
This feature is all about preventing account hijacking and theft. Passwords alone have not been secure for quite some time, and are getting worse all the time. Something more is needed. The "security questions" approach is laughably bad. Worse than the passwords it's trying to cover for. SMS-based two-step verification is better, but SMS hijacking can defeat it. Plus, people like you don't want to add a phone number to your Google account, and SMS 2SV obviously requires that.
This new 2FA option allows your phone to act as a cryptographic second factor for logging you on. It does not use your phone number to do this, and doesn't in any way tie you as a human to the Google account... it involves creating a new (random!) cryptographic key on your phone and then associating that with your account.
If you save your password on the phone (so that it gets entered automatically on an app or website), then you are not really adding a second factor by proving that you have the device. For the password to be the "something you know" factor, the something needs to be something in your brain, not something stored the same device that is the "something you have" factor. Does this new setup ensure that passwords can not be saved?
This is for logging into a web site on a separate computer. Google doesn't provide any way to save your Google password on your phone and have it automatically sent to your computer, AFAIK.
Next will be 3FA, then 4, and at some point they will wear you down and you will be assimilated.
Arguably, if your phone has a fingerprint scanner, this is three-factor. You have to unlock your phone to authorize it to send the cryptographic second-factor message to your computer via bluetooth. And, of course, this is after you entered your password. So... something you know (your password), something you have (your phone) and something you are (your fingerprint, to unlock the phone).
It's "arguable" not "fact", because some definitions of 3FA would require that the backend verify the third authenticator as well, where in this case that's done on the phone (the something-you-have). In practice, secure remote biometric verification is, er, hard.
Geez, why would anyone want to voluntarily GIVE google your phone number?
This 2FA option does not require giving Google your phone number, unlike the much-weaker SMS-based 2SV option.
Yeah, "The feature is coming only to Android devices versions 7 and up" is confusing for those of us already using 2FA. I've been using 2FA via Google Authenicator for some google accounts since Android 5. 2SV is not the only option, we already have a 2FA option. Or did we lose that 2FA option in recent history and now its returning? I am only using 2FA on a somewhat "old" account.
This is a new 2FA option. A pretty nice one, actually.
Google Authenticator requires you to unlock your phone, open the app, read the number, type it into the browser window and click a submit button. Oh, and you have to do it relatively quickly because the number is only valid for a short period of time.
With this new approach, which builds on Android's ability to act as a FIDO token (which itself is built on top of Android Keystore authentication -- which, BTW, I designed and built :-) ), your browser communicates via bluetooth with your phone to get a cryptographic authentication token. So from the user perspective, when you get to the 2FA request screen, you just unlock your phone and tap "okay".
If you have a nano security key that just lives in the USB port all of the time, then that's still the most convenient 2FA approach, IMO. But there's a valid (though not strong, for most users) argument that leaving the security key in the USB port all of the time is a bad idea. In addition, to use a security key you have to buy a security key, which you probably don't already have.
Of course the 2SV option (SMS code) still exists, but it's significantly weaker from a security perspective.
Security is context-dependent, so you can't really place these things on a continuum, but if I make a bunch of simplifying assumptions about common user scenarios, I'd say that Android-as-FIDO is the strongest second factor auth option currently offered. Security keys generally use certified hardware which is arguably more secure than the relevant hardware in a phone, but Android-as-FIDO also requires user authentication (usually biometric; so it's arguably three factor), while security keys do not. The Authenticator app is a little weaker because a root compromise of the phone can extract the relevant long-lived secret.
This new feature is good stuff. It's quite secure, and also very user-friendly, which encourages people who might otherwise not use 2FA to turn it on.