33 ms·

Android saves wifi passwords in plaintext to the cloud

464 points by JanLaussmann 13y ago

somesay 13y ago
Of course, they don't ask for a specific password. "Encrypt synced passwords with your Google credentials" is impossible in times of app specific passwords, right?
- Tomdarkness 13y ago
  How Chrome for Android handles this, which supports encrypted sync, is that after logging in it will prompt you for your real password so that it can decrypt the sync data.
  - somesay 13y ago
    Sounds handy, but at some point breaks the concept of not saving the main password on any platform. Still not that bad, since app specific passwords only are in use if you also have 2-factor-login.
Kurts 13y ago
You can turn it off if you like: Settings > Privacy > Backup my data, backup application data, Wi-fi passwords, and other settings to Google servers. Every few months someone rediscovers that Google also syncs Wifi credentials between devices (perhaps when logging into a new device and finding it tethers itself nicely to the network on its own). It's a matter of convenience, Wifi passwords are only applicable at a certain range, and other restrictions could be applied even then (like hardware whitelisting etc) it's not your bank credentials. Here's a reddit discussion (from 2 years ago!) http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded_to_nexus_s_am_a_little_freaked_out/ http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded...
- nwh 13y ago
  > like hardware address whitelisting I wouldn't recommend that in any circumstance, it's completely false security really. MAC filtering is incredibly easy to bypass, all Malory has to do is wait for another device to connect and clone their hardware's address.
  - Kurts 13y ago
    Yeah but he doesn't have the password, unless somehow he hacked Google's servers for that specific one. It's the combination of both that makes it unlikely, there are far easier/better/more practical/likely ways of penetrating wifi networks.
    - nwh 13y ago
      My point was, it's more an illusion of security than anything. Best not to bother at all.
  - lrem 13y ago
    Wait until somebody else connects to have his MAC, then wait until he disconnects. Otherwise, you'll see a ton of RST flying, making your connection quite useless. That's a good enough deterrent for the typical "attacker", who just happens to need a connection here and now and saw a network using WEP.
  - yardie 13y ago
    It's also a diagnosis nightmare. The ISPs in my country used to use WEP with MAC filtering with their wifi-routers. The password was mildly complex (16 characters) and on a label on the box. Most users never changed the password. So Joe Blow connects his laptop using the password on the sticker, and it doesn't work. Imagine the same problem for a few million users. It's false security because (especially for wifi) MAC filtering is like a verbal password that's been written down on a billboard. Everyone can read it so its not a secret.
    - nwh 13y ago
      Heh, even the longest possibly WEP key can be broken in a few minutes with consumer hardware. At least ISPs in Australia use WPA as standard.
- mikhailt 13y ago
  Convenience isn't an excuse to not encrypt security data, it does not matter if it is a limited to a few areas where it could be exploited. If Google (any companies, including Apple) can not be trusted to protect such information, they should not be offering it in the first place. If it can be exploited, it should be protected as much as it can be. We all saw what happened with Google's StreetView cars capturing the local Wi-Fi traffic. The same thing could be used by somebody hacking into Google's servers, downloading the Wi-Fi passwords and any possible maps data if possible and workaround getting into people's Wi-Fi networks. If it is not likely but it is not impossible.
  - Kurts 13y ago
    It's more than "unlikely", it's ridiculous. It's the longest way around and possibly the stupidest route to get onto someone's Wifi network.
    - pbsdp 13y ago
      Really? Google has the knowledge of where the network is, who has access to it, and what the password is. Remember also that WiFi networks are a shared resource and often provide access to internal corporate data. From a governmental law enforcement perspective, that's an incredibly valuable trove of data. Instant network backdoors, likely with no physical entry required. Even if you're not using the data to sniff networks, you can use it to build detailed relationship graphs between people and places.
    - kryptiskt 13y ago
      It's a stupid way to get into a specific network, but it's a pretty convenient way to get access to everybody's networks. Sure, it would be hard to hack Google, but the prize for doing so would be pretty nice. And if the systems are impregnable, there are always ways in that relies on the human factor. Humans can be bribed and/or threatened. Or if you're law enforcement, the knowledge of the existence of the resource is enough.
- progx 13y ago
  But where is the problem that google encrypt them? To restore, i have to use my account and my password. And why can i not change the option, to backup the application data without WLAN passwords? For a billion dollar company, this should not be so complicated, or ?
  - Kurts 13y ago
    https://news.ycombinator.com/item?id=6057363 https://news.ycombinator.com/item?id=6057363
- Nogwater 13y ago
  Hmm. That path doesn't seem to work on my Nexus 4 running Android 4.2.2. The closest I could find is Settings > Backup & reset > Backup my data (Backup app data, Wi-Fi passwords, and other settings to Google services). Tapping this, it says "Stop backing up your Wi-Fi passwords, bookmarks, other settings, and app data, plus erase all copies on Google servers?". So, it sounds like it's all or nothing.
  - ChrisAntaki 13y ago
    Thanks, that path you posted applies to my phone too. It looks like the Backup setting was already off for me. It might be one of those settings that you are prompted about while setting up the phone.
  - jessaustin 13y ago
    Phew! It appears that my instincts were correct when I first turned on this device. I keep wifi passphrases in a location that is just as secure as the ethernet network to which the wifi is tied: on a piece of tape on the bottom of the WAP. Looking at this again, in the unlikely event I forget the passphrase, seems not to be a burden.
nodata 13y ago
..otherwise it wouldn't work. You can disable backups when you setup your phone.
- TallGuyShort 13y ago
  Otherwise what wouldn't work?
  - Dylan16807 13y ago
    Saving wifi passwords to the cloud.
DanBC 13y ago
Frustrating that it's really hard to make my android phone show me the saved password it's using for a wifi.
deleted 13y ago
[deleted]
spdy 13y ago
With the street view wifi scandal, this on going encryption problem and the revelations about prism this looks very bad.
- sil3ntmac 13y ago
  Reference: http://www.engadget.com/2013/04/22/google-street-view-fine-germany/ http://www.engadget.com/2013/04/22/google-street-view-fine-g... (for others like myself who had not heard of this)
  - Plutor 13y ago
    Just to add to everyone's knowledge: this Street View wifi snooping was a) three years ago, b) accidental, and c) only known by the public because Google voluntarily revealed that it had been doing it (and immediately deleted all of the collected data).
enginous 13y ago
What key are you going to encrypt these passwords with? If you were to encrypt passwords in the cloud with a key that's stored on the device, you can't unlock the passwords on a different device (or the same device after flashing), which is the whole point of backing it up in the cloud. If you were to encrypt them with the user's Google Accounts password, the device would need to ask for that password on every startup or store the GA password on the device at all times (the latter option is a far greater evil than the current "situation"). As long as Google is ever given the clear text password (i.e., before hashing), this would be open to interception by Google -- or infiltrators thereof. If the GA password were to be used to authenticate in a way where Google doesn't get access to the clear text password (through digest-like authentication), a user wouldn't be able to access the backups after resetting her password. However, this method is not reliable if you don't trust Google (or its infiltrators), because Google provides the clients that would do the hashing before sending the password, so they could obtain the clear text password (by skipping the hash step, or by sending it through side channel) on any client they control such as HTTP login pages or mobile apps provided by Google. Like all things security, it's a trade-off between security and convenience.
- enneff 13y ago
  For Chrome Sync data, you can specify a pass phrase that is not your Google Account password, nor is it tied to a specific device. It would be nice if you could specify a pass phrase to use when sending Android backup data. Of course, many people would set the pass phrase when they set up their phone and promptly forget it, making their backup useless. (I've done forgotten enough crypto keys myself to know...) Like you say, it's a tradeoff, but the Chrome team has been able to make it work with Chrome Sync. Of course, you only need to set up Sync once, and if you forget your Sync pass phrase you're not losing much. Perhaps the Android team decided that pass-phrase-encrypting the backups would cause more problems than it might solve. nb: I am a Google employee, but I have no inside knowledge of any of these products nor the decision making processes of their teams.
- threeseed 13y ago
  Why couldn't Google just have a shared key stored on each of the user's devices ? The shared key could be backed up to Google's servers and encrypted using the user's password so in the event of a new device/flashing the shared key could be re-downloaded. Then you only ask the user once for their password.
foley 13y ago
And all for nothing - none of my Android devices have ever restored my wifi passwords, it is always a mission to find and input my password on a fresh phone.
- jsnell 13y ago
  FWIW, it has always worked for me. After remembering one WiFi password, so that I can get on a network and bootstrap...
- myko 13y ago
  I've always had great experiences upgrading Android devices. Once I log in for the first time they sync wifi and applications pretty seamlessly. My wife recently picked up an S4 and none of her things synchronized. I was pretty surprised at the time but thinking about it later I realized the AT&T clerk skipped the initial sign-in process. It looks like the option to sync old apps/passwords is only available upon launching a fresh device (which being a Nexus user no clerk ever bypasses setup on my devices). Anyway, this might be why your phone isn't syncing? I'd be interested in seeing some option to force sync Android devices with backed up data at any time.
jpalomaki 13y ago
I guess it would be fairly difficult to make this truly secure without making it too difficult to use. Simply encrypting the data with your Google account password does not do much good, since you are going to provide that password to Google and they could obviously use that to decrypt the data (should the government request it). One option would be to use separate password for protecting the data, but that would not be very convenient for the user. Very easy to forget such password since you are not going to need it very often.
jmngomes 13y ago
This reply "This report applies to a mobile Google application or service, and the issue tracker where you reported it specializes in issues within the Open Source source code of the Android platform." is a bit off, IMO. The developer reported a bug found on Android to the Android forum. The reply he gets sounds like a dismissal, which is quite strange given that the problem is not only related to Android but also with a Google product. A few days ago I submitted an Android bug verified on a Samsung phone. The reply was something in the line of "that's Samsung's problem, talk to them". I'd say this isn't the right way for Google to handle a severe issue such as this, i.e. simply rejecting accountability. It's like having a team say "go talk to some other team" when they're actually all aboard the same ship. Is big company bureaucracy / turf wars getting to Google? Hope not...
- hrjet 13y ago
  This. I recently found the same irksome behaviour by Goog on another important issue: https://code.google.com/p/android/issues/detail?id=56803 https://code.google.com/p/android/issues/detail?id=56803
  - DannyBee 13y ago
    From what I can tell, JBQ is right and the maps folks are not understanding the issue you have. :) The Location Services API is not part of AOSP (or at least, this implementation isn't) IIRC You should rephrase the bug report to make clear you are talking about the google play services location API. As for the complaint on that bug report that google should file and track these issues for folks, AOSP is an open source project, and like most open source projects, prefers folks file upstream/downstream issues directly.
- DannyBee 13y ago
  What was the bug you submitted? The thing about AOSP is exactly what JBQ said: It's meant for reports about open source parts of Android, not reports about Samsung's skin on top of it, etc. Most of the bugs submitted are not AOSP bugs (I know it's hard to believe, but i've done triage on it). They are bugs in some vendor's patches or changes to AOSP, which, for the most part, Google can do nothing about. It would be worse if these bugs were left open, giving people the false hope that Google can solve their problem, or that the bug got to the right place. If this bug/feature is somewhere in the AOSP code, great, reopen the bug and point it out.
durkie 13y ago
I know it doesn't really address the issue at hand, but as an alternative here Android features a little-documented local backup feature that can be done through adb, and can be encrypted. Even google's official adb page has no mention of it, but I've done it and it works fine: http://tutznet.com/1283-perform-full-backup-android-phone-adb/ http://tutznet.com/1283-perform-full-backup-android-phone-ad... (not my blog -- just the least spammy site i could find)
bhauer 13y ago
Yet another place where I feel a tinge of anger that VPNs utterly failed to deliver on the potential of private secure connectivity to personal data storage from anywhere. Several of us here at HN set up and manage home networks to which we connect over an encrypted channel. To us--well, to me at least--it seems plain as day that my device should allow me to backup its sensitive data to a file that I store on a file system of my choosing. I would store it on my encrypted disk array at home (which is then backed up to a data center disk array). But to a layperson, the lack of a secure private channel to personal data storage remains an infeasibility. So laypeople embrace third-party "cloud" storage offerings, this one included. These services offer omnipresence of data. They don't offer personal control, but many people are willing to concede control because omnipresence is such a convenience. Putting all of that aside, however, and accepting the world as it is, with VPNs the tragedy of user experience that they are... An open question remains: why not ask the user to create a passphrase for use in encrypting the device's data before storing it at the GoogleCloud + NSACloud? The seemingly obvious answer to the rhetorical question is a worry about user experience pain ("woe is me, I need to remember another passphrase now"). So perhaps the user would be instructed to provide a passphrase if and only if they are concerned about their backup being stored on the NSACloud. If they are not concerned, they can leave the field empty.
- js2 13y ago
  Back to my Mac pretty seamlessly establishes an ipsec connection back to a time capsule or other Mac on your home network.
  - ctb_mg 13y ago
    Yes, but as far as backups and backup security is concerned -- a time capsule is fairly proprietary, and a Mac on your home network is susceptible to local catastrophe.
ksowocki 13y ago
If anyone hasn't downloaded [cloud to butt](https://github.com/panicsteve/cloud-to-butt https://github.com/panicsteve/cloud-to-butt) Let [this](http://cl.ly/image/1X0o212T3B0Y http://cl.ly/image/1X0o212T3B0Y) be your reminder to do so.
brudgers 13y ago
The most plausible explanation for this behavior, if the assertions are true, is that Google is acting in a way which serves its customers interests. If you don't write checks to Google for a service, you are not among Google's customers.
keithnoizu 13y ago
That's a feature, saves NSA from the effort of building up rainbow tables.
pedrocr 13y ago
Google could use this to bootstrap a FON like worldwide network. Have an additional option in the settings for "Make this network part of Google Free Wifi" and then any android phone anywhere can connect seamlessly to the network. If you change the security settings they are immediately updated because you also update them on your own phone. At least for networks that are already designed to be public (e.g., coffeeshop wifi) this would be awesome. For my home network I'd have to first setup a second SSID myself that I firewall from the rest so that I don't expose all my wifi devices to any passer by. That bit isn't very user friendly.
krapp 13y ago
At this point I feel you might as well assume that every device and every website stores your credentials in plaintext until explicitly proven otherwise, I guess. Or maybe unsalted md5 if they're a bank.
rsync 13y ago
The title is, I think, a bit misleading. That's because it is not Android per se that is sending your wifi passwords to the cloud, it's the use of the "backup my data" tool. If you're interested in robust, secure storage of your data, the candy-flavored OS built-in-cloud-tool may not be your best bet. It's only there to check a feature box on a sales card. "Oooh but I get 5 gigs for free!"
deleted 13y ago
[deleted]
babesh 13y ago
No need to belabor the point given the many examples beyond this one. If you want security, you're not going with Android. If you want configurability, you're not going with iOS. Android: slurping phone numbers, texting behind the scenes on your behalf, etc... iOS: no access to apps that Apple doesn't approve, no replacement of built-in apps with third-party apps, etc... These systems were not built exactly with your benefit in mind. Android was built to prevent Apple domination of mobile and thus continue selling ads by providing services. Apple has several services that would be much more useful cross platform but are not: Facetime, iMessage, etc... and that reinforce platform lock-in.
- nly 13y ago
  > Android: slurping phone numbers, texting behind the scenes on your behalf, etc... Debatable. If you install something like Permissions Explorer you can see which apps access your contacts and/or texts. It's generally a small list. And the Google sync features can be disabled.
  - babesh 13y ago
    The problem is that you've checked the chicken coop AFTER the fox has gotten to the chickens.
sasda 13y ago
weqw
tazjin 13y ago
I would like to know how this works with 802.1X credentials. Does this "feature" save my company internal LDAP password that I use to authenticate to the network to the cloud? Unencrypted?

464 points by JanLaussmann 13y ago

Of course, they don't ask for a specific password. "Encrypt synced passwords with your Google credentials" is impossible in times of app specific passwords, right?

Tomdarkness 13y ago
How Chrome for Android handles this, which supports encrypted sync, is that after logging in it will prompt you for your real password so that it can decrypt the sync data.
- somesay 13y ago
  Sounds handy, but at some point breaks the concept of not saving the main password on any platform. Still not that bad, since app specific passwords only are in use if you also have 2-factor-login.

Kurts 13y ago

You can turn it off if you like: Settings > Privacy > Backup my data, backup application data, Wi-fi passwords, and other settings to Google servers. Every few months someone rediscovers that Google also syncs Wifi credentials between devices (perhaps when logging into a new device and finding it tethers itself nicely to the network on its own). It's a matter of convenience, Wifi passwords are only applicable at a certain range, and other restrictions could be applied even then (like hardware whitelisting etc) it's not your bank credentials. Here's a reddit discussion (from 2 years ago!) http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded_to_nexus_s_am_a_little_freaked_out/ http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded...

nwh 13y ago
> like hardware address whitelisting I wouldn't recommend that in any circumstance, it's completely false security really. MAC filtering is incredibly easy to bypass, all Malory has to do is wait for another device to connect and clone their hardware's address.
- Kurts 13y ago
  Yeah but he doesn't have the password, unless somehow he hacked Google's servers for that specific one. It's the combination of both that makes it unlikely, there are far easier/better/more practical/likely ways of penetrating wifi networks.
  - nwh 13y ago
    My point was, it's more an illusion of security than anything. Best not to bother at all.
- lrem 13y ago
  Wait until somebody else connects to have his MAC, then wait until he disconnects. Otherwise, you'll see a ton of RST flying, making your connection quite useless. That's a good enough deterrent for the typical "attacker", who just happens to need a connection here and now and saw a network using WEP.
- yardie 13y ago
  It's also a diagnosis nightmare. The ISPs in my country used to use WEP with MAC filtering with their wifi-routers. The password was mildly complex (16 characters) and on a label on the box. Most users never changed the password. So Joe Blow connects his laptop using the password on the sticker, and it doesn't work. Imagine the same problem for a few million users. It's false security because (especially for wifi) MAC filtering is like a verbal password that's been written down on a billboard. Everyone can read it so its not a secret.
  - nwh 13y ago
    Heh, even the longest possibly WEP key can be broken in a few minutes with consumer hardware. At least ISPs in Australia use WPA as standard.
mikhailt 13y ago
Convenience isn't an excuse to not encrypt security data, it does not matter if it is a limited to a few areas where it could be exploited. If Google (any companies, including Apple) can not be trusted to protect such information, they should not be offering it in the first place. If it can be exploited, it should be protected as much as it can be. We all saw what happened with Google's StreetView cars capturing the local Wi-Fi traffic. The same thing could be used by somebody hacking into Google's servers, downloading the Wi-Fi passwords and any possible maps data if possible and workaround getting into people's Wi-Fi networks. If it is not likely but it is not impossible.
- Kurts 13y ago
  It's more than "unlikely", it's ridiculous. It's the longest way around and possibly the stupidest route to get onto someone's Wifi network.
  - pbsdp 13y ago
    Really? Google has the knowledge of where the network is, who has access to it, and what the password is. Remember also that WiFi networks are a shared resource and often provide access to internal corporate data. From a governmental law enforcement perspective, that's an incredibly valuable trove of data. Instant network backdoors, likely with no physical entry required. Even if you're not using the data to sniff networks, you can use it to build detailed relationship graphs between people and places.
  - kryptiskt 13y ago
    It's a stupid way to get into a specific network, but it's a pretty convenient way to get access to everybody's networks. Sure, it would be hard to hack Google, but the prize for doing so would be pretty nice. And if the systems are impregnable, there are always ways in that relies on the human factor. Humans can be bribed and/or threatened. Or if you're law enforcement, the knowledge of the existence of the resource is enough.
progx 13y ago
But where is the problem that google encrypt them? To restore, i have to use my account and my password. And why can i not change the option, to backup the application data without WLAN passwords? For a billion dollar company, this should not be so complicated, or ?
- Kurts 13y ago
  https://news.ycombinator.com/item?id=6057363 https://news.ycombinator.com/item?id=6057363
Nogwater 13y ago
Hmm. That path doesn't seem to work on my Nexus 4 running Android 4.2.2. The closest I could find is Settings > Backup & reset > Backup my data (Backup app data, Wi-Fi passwords, and other settings to Google services). Tapping this, it says "Stop backing up your Wi-Fi passwords, bookmarks, other settings, and app data, plus erase all copies on Google servers?". So, it sounds like it's all or nothing.
- ChrisAntaki 13y ago
  Thanks, that path you posted applies to my phone too. It looks like the Backup setting was already off for me. It might be one of those settings that you are prompted about while setting up the phone.
- jessaustin 13y ago
  Phew! It appears that my instincts were correct when I first turned on this device. I keep wifi passphrases in a location that is just as secure as the ethernet network to which the wifi is tied: on a piece of tape on the bottom of the WAP. Looking at this again, in the unlikely event I forget the passphrase, seems not to be a burden.

nodata 13y ago

..otherwise it wouldn't work. You can disable backups when you setup your phone.

TallGuyShort 13y ago
Otherwise what wouldn't work?
- Dylan16807 13y ago
  Saving wifi passwords to the cloud.

DanBC 13y ago

Frustrating that it's really hard to make my android phone show me the saved password it's using for a wifi.

deleted 13y ago

[deleted]

spdy 13y ago

With the street view wifi scandal, this on going encryption problem and the revelations about prism this looks very bad.

sil3ntmac 13y ago
Reference: http://www.engadget.com/2013/04/22/google-street-view-fine-germany/ http://www.engadget.com/2013/04/22/google-street-view-fine-g... (for others like myself who had not heard of this)
- Plutor 13y ago
  Just to add to everyone's knowledge: this Street View wifi snooping was a) three years ago, b) accidental, and c) only known by the public because Google voluntarily revealed that it had been doing it (and immediately deleted all of the collected data).

enginous 13y ago

What key are you going to encrypt these passwords with? If you were to encrypt passwords in the cloud with a key that's stored on the device, you can't unlock the passwords on a different device (or the same device after flashing), which is the whole point of backing it up in the cloud. If you were to encrypt them with the user's Google Accounts password, the device would need to ask for that password on every startup or store the GA password on the device at all times (the latter option is a far greater evil than the current "situation"). As long as Google is ever given the clear text password (i.e., before hashing), this would be open to interception by Google -- or infiltrators thereof. If the GA password were to be used to authenticate in a way where Google doesn't get access to the clear text password (through digest-like authentication), a user wouldn't be able to access the backups after resetting her password. However, this method is not reliable if you don't trust Google (or its infiltrators), because Google provides the clients that would do the hashing before sending the password, so they could obtain the clear text password (by skipping the hash step, or by sending it through side channel) on any client they control such as HTTP login pages or mobile apps provided by Google. Like all things security, it's a trade-off between security and convenience.

enneff 13y ago
For Chrome Sync data, you can specify a pass phrase that is not your Google Account password, nor is it tied to a specific device. It would be nice if you could specify a pass phrase to use when sending Android backup data. Of course, many people would set the pass phrase when they set up their phone and promptly forget it, making their backup useless. (I've done forgotten enough crypto keys myself to know...) Like you say, it's a tradeoff, but the Chrome team has been able to make it work with Chrome Sync. Of course, you only need to set up Sync once, and if you forget your Sync pass phrase you're not losing much. Perhaps the Android team decided that pass-phrase-encrypting the backups would cause more problems than it might solve. nb: I am a Google employee, but I have no inside knowledge of any of these products nor the decision making processes of their teams.
threeseed 13y ago
Why couldn't Google just have a shared key stored on each of the user's devices ? The shared key could be backed up to Google's servers and encrypted using the user's password so in the event of a new device/flashing the shared key could be re-downloaded. Then you only ask the user once for their password.

foley 13y ago

And all for nothing - none of my Android devices have ever restored my wifi passwords, it is always a mission to find and input my password on a fresh phone.

jsnell 13y ago
FWIW, it has always worked for me. After remembering one WiFi password, so that I can get on a network and bootstrap...
myko 13y ago
I've always had great experiences upgrading Android devices. Once I log in for the first time they sync wifi and applications pretty seamlessly. My wife recently picked up an S4 and none of her things synchronized. I was pretty surprised at the time but thinking about it later I realized the AT&T clerk skipped the initial sign-in process. It looks like the option to sync old apps/passwords is only available upon launching a fresh device (which being a Nexus user no clerk ever bypasses setup on my devices). Anyway, this might be why your phone isn't syncing? I'd be interested in seeing some option to force sync Android devices with backed up data at any time.

jpalomaki 13y ago

I guess it would be fairly difficult to make this truly secure without making it too difficult to use. Simply encrypting the data with your Google account password does not do much good, since you are going to provide that password to Google and they could obviously use that to decrypt the data (should the government request it). One option would be to use separate password for protecting the data, but that would not be very convenient for the user. Very easy to forget such password since you are not going to need it very often.

jmngomes 13y ago

This reply "This report applies to a mobile Google application or service, and the issue tracker where you reported it specializes in issues within the Open Source source code of the Android platform." is a bit off, IMO. The developer reported a bug found on Android to the Android forum. The reply he gets sounds like a dismissal, which is quite strange given that the problem is not only related to Android but also with a Google product. A few days ago I submitted an Android bug verified on a Samsung phone. The reply was something in the line of "that's Samsung's problem, talk to them". I'd say this isn't the right way for Google to handle a severe issue such as this, i.e. simply rejecting accountability. It's like having a team say "go talk to some other team" when they're actually all aboard the same ship. Is big company bureaucracy / turf wars getting to Google? Hope not...

hrjet 13y ago
This. I recently found the same irksome behaviour by Goog on another important issue: https://code.google.com/p/android/issues/detail?id=56803 https://code.google.com/p/android/issues/detail?id=56803
- DannyBee 13y ago
  From what I can tell, JBQ is right and the maps folks are not understanding the issue you have. :) The Location Services API is not part of AOSP (or at least, this implementation isn't) IIRC You should rephrase the bug report to make clear you are talking about the google play services location API. As for the complaint on that bug report that google should file and track these issues for folks, AOSP is an open source project, and like most open source projects, prefers folks file upstream/downstream issues directly.
DannyBee 13y ago
What was the bug you submitted? The thing about AOSP is exactly what JBQ said: It's meant for reports about open source parts of Android, not reports about Samsung's skin on top of it, etc. Most of the bugs submitted are not AOSP bugs (I know it's hard to believe, but i've done triage on it). They are bugs in some vendor's patches or changes to AOSP, which, for the most part, Google can do nothing about. It would be worse if these bugs were left open, giving people the false hope that Google can solve their problem, or that the bug got to the right place. If this bug/feature is somewhere in the AOSP code, great, reopen the bug and point it out.

durkie 13y ago

I know it doesn't really address the issue at hand, but as an alternative here Android features a little-documented local backup feature that can be done through adb, and can be encrypted. Even google's official adb page has no mention of it, but I've done it and it works fine: http://tutznet.com/1283-perform-full-backup-android-phone-adb/ http://tutznet.com/1283-perform-full-backup-android-phone-ad... (not my blog -- just the least spammy site i could find)

bhauer 13y ago

Yet another place where I feel a tinge of anger that VPNs utterly failed to deliver on the potential of private secure connectivity to personal data storage from anywhere. Several of us here at HN set up and manage home networks to which we connect over an encrypted channel. To us--well, to me at least--it seems plain as day that my device should allow me to backup its sensitive data to a file that I store on a file system of my choosing. I would store it on my encrypted disk array at home (which is then backed up to a data center disk array). But to a layperson, the lack of a secure private channel to personal data storage remains an infeasibility. So laypeople embrace third-party "cloud" storage offerings, this one included. These services offer omnipresence of data. They don't offer personal control, but many people are willing to concede control because omnipresence is such a convenience. Putting all of that aside, however, and accepting the world as it is, with VPNs the tragedy of user experience that they are... An open question remains: why not ask the user to create a passphrase for use in encrypting the device's data before storing it at the GoogleCloud + NSACloud? The seemingly obvious answer to the rhetorical question is a worry about user experience pain ("woe is me, I need to remember another passphrase now"). So perhaps the user would be instructed to provide a passphrase if and only if they are concerned about their backup being stored on the NSACloud. If they are not concerned, they can leave the field empty.

js2 13y ago
Back to my Mac pretty seamlessly establishes an ipsec connection back to a time capsule or other Mac on your home network.
- ctb_mg 13y ago
  Yes, but as far as backups and backup security is concerned -- a time capsule is fairly proprietary, and a Mac on your home network is susceptible to local catastrophe.

ksowocki 13y ago

If anyone hasn't downloaded [cloud to butt](https://github.com/panicsteve/cloud-to-butt https://github.com/panicsteve/cloud-to-butt) Let [this](http://cl.ly/image/1X0o212T3B0Y http://cl.ly/image/1X0o212T3B0Y) be your reminder to do so.

brudgers 13y ago

The most plausible explanation for this behavior, if the assertions are true, is that Google is acting in a way which serves its customers interests. If you don't write checks to Google for a service, you are not among Google's customers.

keithnoizu 13y ago

That's a feature, saves NSA from the effort of building up rainbow tables.

pedrocr 13y ago

Google could use this to bootstrap a FON like worldwide network. Have an additional option in the settings for "Make this network part of Google Free Wifi" and then any android phone anywhere can connect seamlessly to the network. If you change the security settings they are immediately updated because you also update them on your own phone. At least for networks that are already designed to be public (e.g., coffeeshop wifi) this would be awesome. For my home network I'd have to first setup a second SSID myself that I firewall from the rest so that I don't expose all my wifi devices to any passer by. That bit isn't very user friendly.

krapp 13y ago

At this point I feel you might as well assume that every device and every website stores your credentials in plaintext until explicitly proven otherwise, I guess. Or maybe unsalted md5 if they're a bank.

rsync 13y ago

The title is, I think, a bit misleading. That's because it is not Android per se that is sending your wifi passwords to the cloud, it's the use of the "backup my data" tool. If you're interested in robust, secure storage of your data, the candy-flavored OS built-in-cloud-tool may not be your best bet. It's only there to check a feature box on a sales card. "Oooh but I get 5 gigs for free!"

deleted 13y ago

[deleted]

babesh 13y ago

No need to belabor the point given the many examples beyond this one. If you want security, you're not going with Android. If you want configurability, you're not going with iOS. Android: slurping phone numbers, texting behind the scenes on your behalf, etc... iOS: no access to apps that Apple doesn't approve, no replacement of built-in apps with third-party apps, etc... These systems were not built exactly with your benefit in mind. Android was built to prevent Apple domination of mobile and thus continue selling ads by providing services. Apple has several services that would be much more useful cross platform but are not: Facetime, iMessage, etc... and that reinforce platform lock-in.

nly 13y ago
> Android: slurping phone numbers, texting behind the scenes on your behalf, etc... Debatable. If you install something like Permissions Explorer you can see which apps access your contacts and/or texts. It's generally a small list. And the Google sync features can be disabled.
- babesh 13y ago
  The problem is that you've checked the chicken coop AFTER the fox has gotten to the chickens.

sasda 13y ago

weqw

tazjin 13y ago

I would like to know how this works with 802.1X credentials. Does this "feature" save my company internal LDAP password that I use to authenticate to the network to the cloud? Unencrypted?