[enginous]

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.

[moxie]

One way to do it would be:

1) Your plaintext password is used to generate two derivative tokens. One for user authentication with Google, and one for encrypting data stored with Google. The authentication password token is PBKDF2(N, password) and the encryption token is PBKDF2(N-1, password). You give Google the authentication token on signup. They are not capable of deriving the encryption token from it, but the user is capable of generating both from the original password.

2) For backup initialization, you prompt the user for their password, calculate the encryption token, generate an ECC keypair, encrypt the private ECC key with the encryption token, and send the encrypted private key to the backup server. This is the last time you'll need to prompt the user for their password until a restore.

3) Each time you wish to send updates to the backup server, you generate a symmetric encryption key, encrypt that using the user's public key, encrypt the data to backup with the symmetric key, and send the encrypted symmetric key and data together to the backup server. This does not require prompting the user for their password, or storing it locally.

4) On restore, you prompt the user for their password, use it to decrypt the private key that you pull down from the backup server, which you can then use to decrypt any encrypted blocks you retrieve as well.

[jlgreco]

How do you handle password changes? Download the encrypted ECC private key, decrypt it with the old password, re-encrypt it with the new one, then upload it again? Is there an easier way?

[sneak]

This is not the normal Google Account password, this is specifically for a backup/restore process.

[cbr]

People have enough trouble remembering one password. Add another that is used only in very unusual circumstances and nearly no one will remember it.

[lostlogin]

I wonder what percentage of people use the email reset for every access attempt. I have several services where I went from crappy passwords to good ones I don't know - I just reset them each time.

[Afforess]

Chances of me implementing this correctly: 0%.

Chances of me implementing a boolean on/off switch for the plaintext passwords correctly: 99%

[cbr]

Difficulty of implementation isn't the issue here. This is an important feature of Android and if moxie's approach would make things better for users I think Google could get it right.

[jiggy2011]

It shouldn't be insurmountably difficult and it's easily abstractable to more or less backup(uid,pass,data) restore (uid,pass,data).

[anigbrowl]

How are you going to check in with the backup server if you don't have a working wi-fi connection?

[MarkMc]

Using a 3G connection, perhaps? In any case such a problem doesn't excuse Google from storing plaintext rather than encrypted passwords on the server.

[fooqux]

Android is used on more than just smartphones. There are many tablets that don't have cell radios in them.

[jlgreco]

Flash the device with the password (this time encrypted) before shipping it to the user?

How is it usually done?

[brudgers]

Horseshit.

Setting up a password for an Android device only needs to be done once for each device->network pairing. The reuse of Wifi passwords across devices is an edge case given the predominate ownership pattern of Android devices - i.e. most people have a phone that runs Android and no other Android device.

Google's scheme allows them to harvest the passwords to a vast number of wireless networks.

Google has harvested the location, name and signal strength of many millions of wireless networks across the world - an act which can be in no way cast as user convenience.

The very best possible light for this nexus is that it only appears to be a very very bad thing.

[jsnell]

If you're going to dismiss an argument as "horseshit", you should perhaps offer a compelling alternative. Because your idea of what is going on is frankly ridiculous.

It's easy to see the user-experience story for this. Upgrade your phone, buy a tablet, etc, and as by magic all 10 wifi networks you use work without any configuration. No need to type that 32-character nuisance of a WPA2 password again, etc. How lovely!

Your conspiracy theory hinges on the idea that Google wants your precious wifi password for themselves, not for your convenience. That seems unlikely. Google doesn't care about your network. They might care about your web usage patterns insofar it makes it easier to provide better search results and improve ad targeting. Your network is worthless for that. Using the passwords to actually access these wifi networks would also be a massive legal and PR nightmare.

So on one side you have delighting users. On the other side you have a malicious attempt to gather useless data at massive risk. How can there even be a question of which explanation makes more sense?

[brudgers]

Encrypt the data on the device. Backup encrypted version in the cloud. Download encrypted backup to new device. Unencrypt on new device. Merge versions on the device.

No need for plaintext on Google servers. No way for monetization by Google.

Or to put my alternative another way, how much is a data set mapping WiFi passwords to networks for the city of Bejing worth to a foreign intelligence agency or other state-level actor? An answer in terms of dollars or 1000 clicks is equally acceptable.

As an alternative, how much is such a data set for Redmond worth to Google?

For extra credit, determine the value of each data set if includes historic data on password changes, changes to the individual password repositories of each user, and changes to the densities of WiFi networks at specific locations.

In the end, it comes down to money in Google's bank account, not delighting users (see Reader). Since Google does not directly profit from the sale of nearly all Android devices, the burden for the thesis of delight is to show an alternative mechanism by which Google directly profits from the plain text storage of passwords.

[jsnell]

You're providing innuendo and "exercises for the reader", not an argument. That's pretty weak.

What would such a data set of Redmond be worth to Google? Nothing. Because accessing those networks for industrial espionage (if I read your innuendo right) would be illegal and immoral. It would drag Google's name in the mud, lose them customers, credibility, and most likely a decent chunk of talented employees. The liabilities would be massive. And what's the gain? I don't know what you think it would be, but it'd have to be pretty damn valuable to outweigh the potential costs.

As for monetization... Android is a moat. The way things are going, whoever controls the client operating system controls the default web browser and the default web search. This is an existential threat to Google. Microsoft winning the mobile OS war would soon make Bing the leading search engine. Apple conclusively winning would allow them to charge monopoly rents on access to the users.

It's like Google Toolbar back in the day. It's possible it provided some information about user behavior. But the real value came in that it added a visible Google search box into IE.

[brudgers]

I look at the money.

Google made $10 billion last year.

In a cyber-war, how much would the Kremlin pay to disrupt every Chinese WiFi network to which an Android device has a current password?

In a shooting war, how much would the US pay? Keep in mind that the modern battlefield increasingly uses ordinary data devices particularly in counter-insurgency operations.

Jim McDonnell, Donald Douglas, Jack Northrup and Leroy Grumman did not start out as defense contractors. They diversified their corporations when voluntarily seizing the opportunity was a good alternative to the threat of compulsion during the Second World War.

This may in fact be the one time that the rules are different. But there's very little historical precedent upon which to premise such a belief. GM produces military vehicles. Westinghouse and GE produce powerplants for ballistic missile submarines.

[edit] The question of how plaintext leads directly to Google profits remains unaddressed. It is not as if Android users can recover their passwords by calling up Google customer service. On the other hand, storing passwords in plain text is usually a decision made to facilitate requests from a company's customers. Asking who constitutes Google's customers is a reasonable place to start when inferring motives.[/edit]

[mik3y]

  I look at the money.

  In a cyber-war, how much would the Kremlin pay to
  disrupt every Chinese WiFi network to which an Android 
  device has a current password?

Do you think Larry Page can be bought?

I'm serious: You need to consider the way Google is run before deciding if any of these theories are plausible.

This is a company which has a history of spurning money-making opportunities in favor of some higher ideal (often times to the chagrin of business-minded types within the company). To give a few examples: Licensing Android, complying with China, accepting paid placements, etc.

You can argue each of those decisions was actually more profitable for Google in the end. And that's the point: Google would not make $10B next year if they sold out their users to the Kremlin this year.

[philsnow]

> Setting up a password for an Android device only needs to be done once for each device->network pairing.

So you want _yet another_ password between the user and his magical experience or whatever ?

I see myself as a "privacy enthusiast", and even I recognize that wanting to encrypt wifi passwords in this way would only appeal to ~0.01% of android users.

You could argue that google could make this an option hidden under the three dots / context menu / whatever that thing is called, but there's probably much lower-hanging fruit than this.

[w0utert]

>> So you want _yet another_ password between the user and his magical experience or whatever ?

I find this a pretty weak objection. Do you really want to trade all your stored passwords for the convenience of not having to enter 1 additional password ('my Android backup password') once every one or two years when you activate a new or additional device?? I wonder how this objection rhymes with having logins on 20+ different websites?

While I don't believe that Google wants to harvest your WiFi passwords (but also don't rule it out), I also don't think it's all that paranoid to assume that Google deliberately chose to not encrypt backups by default, so they can extract useful information from Android device backups. Or do you still believe Android is 'free' because Google is a charity?

[philsnow]

You missed the central part of my argument, so I'll reiterate it here: users don't care about this stuff, and passwords are user-hostile. Google chose to implement this a certain way that works for 99.99% of people.

Now, in the 0.01% case, your counter argument still doesn't hold, in my opinion:

> Do you really want to trade all your stored passwords for the convenience of not having to enter 1 additional password ('my Android backup password')

Yes.

Even strong wifi passwords can be brute-forced within minutes from the curb by anybody with an unmarked van and a measly few GPUs. At this point in the technology race, wifi passwords are really just keeping the honest people out. If you want something stronger, you're going to have to go to machine certificates on each laptop / mobile device.

> once every one or two years when you activate a new or additional device??

Even worse, passwords that aren't used often exit my fingers' memory and are thus lost to time (unless I write them down and store them in my safe deposit box or keepassdroid or whatever, but "hardly anybody" does this, so Google would get phone calls from users every year or two saying "can you give me the password that I'm supposed to be using to keep from giving you my passwords? kthx").

[archivator]

You could in theory salt the primary account password with a new salt, derive a key from it and use that to encrypt the password list (sending the salt alongside it). This of course implies that the plaintext password never hits Google's servers, which it probably does.

In general, I'm not sure this is a valid threat model. If you're not trusting Bob with your Wi-Fi passwords, why are you trusting him with everything else? If anyone compromises Google, there's far more valuable data on your account than the Wi-Fi list. Even if that's all they gain access to, it's pretty hard to exploit remotely. If someone is targeting you at this scale, you have bigger problems to worry about.

[HNaTTY]

Well I don't agree that there's far more valuable data than the ability to access my internal network. If my wifi network wasn't segregated from my wired network, by getting my wifi password you have bypassed my firewall, giving you access to my/my company's servers.

[Groxx]

Decrypt encrypted backup on the new device how? What password / key would you use, and how would that be backed up / made known to the user, which it does not do now?

If it's a device password, enjoy re-encrypting if they change it. Or handling two device passwords.

If it's a user password, then how do you change encryption everywhere when they change their password? Only option there is to have Google decrypt and re-encrypt it and push it to every device, since otherwise you losing connection means corrupting your backup, at which point they have it in plaintext, no difference.

[flipperypokery]

Most people really have 10 different WiFi networks? I have two. Home and work. Who has 10?

Apple solved this by supporting local backups. My phone backs up to my computer. When I restore to a new device, the backup goes with it.

When I set up a completely new device -- which happens only once every couple of years -- I set up WiFi again. I've never, ever, ever thought "oh wow, setting up WiFi is just So Hard! I wish Apple would store my private WiFI password on their servers by default without telling me first!".

iCloud backup does store your data on Apple's servers, but it's opt-in, and it makes it quite clear what will be stored.

[300bps]

>Most people really have 10 different WiFi networks? I have two. Home and work. Who has 10?

Home, work, the office where I do side work, my in-law's house at the beach, my parent's house in another state, multiple friend's houses that I frequent, my doctor's office, local restaurants, etc. Some of these places are cell signal dead zones and the only way to get a signal is to connect to WiFi. Plus WiFi is faster, more stable and doesn't cut into my limited cell data plan.

[babesh]

- Home - Brother's house - Other brother's house - Sister's house - Brother-in-law's house - Work #1 - Work #2 - Cafe #1 - Cafe #2 - Cafe #3 - School

And these are just the ones that I remember.

[ollysb]

If you're in the habit of connecting wifi at cafes/bars etc. you can easily run past 10 (wow - just checked the list on my 18 month old laptop, it's currently 110 networks).

[jarek]

Though not all of the bar/cafe networks are passworded, likely.

[chrisrhoden]

This is also opt in, as part of the first boot process. It also makes it very clear what will be stored. The difference is that this is free.

[nexox]

Crucially (at least on my device,) there's no granularity to this opt in - I cannot choose to backup my application data but not my WiFi passwords. Now my options are to either accept Google's storage of my network passwords or set up and maintain my own backup system.

[kbenson]

That assumes your application data is less important than your WiFi passwords. I don't think a distinction at that level is useful. To be useful, it would have to be per application. I don't care if some game status is synced, but I surely care if my email credentials are (although caring may just means I'm aware, it doesn't necessarily mean I would change it).

[sixbrx]

Do they mention that it will be unencrypted? I don't remember that, and I think I would have remembered that.

[vectorpush]

I agree that trusting google with wifi passwords is about as benign as it gets (especially if you already trust them with everything else) but the reason we encourage password encryption isn't because we don't trust the service provider, it's because we don't trust hackers or unethical employees. There are a lot of people who would love to get their hands on that data.

[babesh]

Not benign at all. Read the story about how some Facebook administrator challenged Facebookers to hack into Facebook. The way they did it was to drive by his home and impersonate his home wireless router. My understanding is that once you do that, you can do man in the middle attacks.

Example: Oh you thought you were accessing Facebook, bank, stock, tax... oh you are... but first you are passing along your password to a third party.

Also, once you gain access to the network, what percentage of networks allow administrator access over wi-fi? I would bet a good percentage. What percentage of these have the default password? Again, a good percentage. So basically, you can hijack quite a few networks this way. Do you know what most routers keep a log of? Your entire browsing history. Do you know what else you can do to the network? Open up inbound ports.

Note: The impersonation attack may work even without passwords. Figure out what his/her network name is. Give your network the same name. Scramble the signal coming from the other router. Have him/her enter in a password to your network. Voila.

[vectorpush]

Fair enough; it's not really benign, only in comparison to all the other data google stores and aggregates regarding its customers (imagine a map of Google Now data)

[OGC]

> Because your idea of what is going on is frankly ridiculous.

Really?

> It's easy to see the user-experience story for this.

It's even easier to see how handy millions of wifi passwords might come in handy if you already have the information about the wifi networks you got from war-driving (street view).

You now have access to millions of (private) networks all over the world which you previously had not.

[mik3y]

  It's even easier to see how handy millions of wifi
  passwords might come in handy if you already have the 
  information about the wifi networks you got from
  war-driving (street view).

Do you have any idea what you're talking about?

Talk to a real live Googler (they exist!). Any one of them will tell you that:

(a) the war driving thing was one engineer's massive fuckup that was never wanted for any product, and the data was quickly quarantined (and only kept alive due to legal proceedings), and

(b) anything remotely close to nefarious conspiracy theories being posed for this .. sync protocol .. would never, ever pass peer review internally (let alone the flames of eng-misc).

User data confidentiality is one of (if not the most) serious topics within Google. Again, don't take my word for it, ask someone else.

To suggest that Google is collecting customer passwords for the express purpose of future network intrusion, or to share with spy agencies, is just ignorant.

[socillion]

I'm not sure what you're talking about. Google collects information on wireless networks for a very specific purpose - determining location to speed up or replace GPS. Skyhook Wireless is another company that sells the information obtained from wardriving.

https://support.google.com/maps/answer/1725632?hl=en

Are you saying this service was shut down despite all indications to the contrary, or are you disputing the method used to collect this data?

[mik3y]

I was referring to the StreetView Skyhook-like program that did exist, and yes, it was shut down after it was discovered to be collecting more than just SSIDs:

http://googleblog.blogspot.com/2010/05/wifi-data-collection-...

  In addition, given the concerns raised, we have
  decided that it’s best to stop our Street View
  cars collecting WiFi network data entirely. 

I presume this is what the OP meant by "war driving (street view)", and not the on-device collection you refer to.

[babesh]

So the NSA knows that Google has access to this information. I bet they have ALREADY forced Google to give this information up even if only on a warrant basis (but perhaps not).

[untog]

an act which can be in no way cast as user convenience.

It's very convenient to me. I have both an Android phone and tablet. I've also switched Android phones multiple times- it's been quite gratifying to return to a city I visited three years ago and have it automatically connect to the WiFi hotspots I used back then.

[jusben1369]

Yes. I just upgraded from one Android phone to another. Was resigned to the tedious nightmare of setting up multiple WiFi connections again. This feature is fantastic. Not that that negates privacy issues but it is a massive user convenience.

[gcb0]

You guys can't be serious.

How many APs do you even have to use regularly?

And slightly related, do you have two factor enabled on your email or is that the end of modern life convenience as well?

[untog]

The hotspots I use "regularly" aren't actually the issue- I could certainly remember the passwords for them easily. But over time I've built up a huge network of hotspots that I wouldn't like to lose- that coffee shop I went to a few months ago? That hotel I stayed in last year? It's quite nice to have that just connect automatically.

And you're presenting a false dilemma here. Of course I'd prefer this information be encrypted. I was simply replying to the OP that stated WiFi saving could be in "no way cast as user convenience".

[Karunamon]

>How many APs do you even have to use regularly?

Let's see, I've got a private side and a guest side wifi at home, no less than three at work depending on location, the motel I usually end up booked in for trips, local bars and restaurants.

So i'd say.. probably 10ish in a given month? Sometimes more?

[moultano]

The first time I traveled to my sister's house for Thanksgiving setting up the WiFi on our devices was a several hour ordeal that stressed out the whole family. They aren't used to keeping track of these things. I'm very glad I have never had to do that again through several device upgrades.

[lostlogin]

Do some windows versions still demand that your password fits a set format - length as character type as I recall? Trying to get a (?XP ?Vista) PC onto our until-then Mac only network just about caused its owner a stroke.

[sksksk]

Do you never go to a friend's house and use their wifi?

[gcb0]

honestly, nope. I never had reception issues at a friend's place, but for coffee shops and hotels, even if reception is bad, i rather use 2G than go login in random networks.

i'm already exposed to the phone operator issues, don't want to have to worry about coffee shops and hotels.

...as using those networks is the very reason passwords in plain text is an issue! you guys are just making your situation 10x worse with this convenience.

[jusben1369]

I am serious and please don't call me Shirley.

[brudgers]

That's perhaps a 3rd standard deviation case for backing up WiFi passwords, but not plausibly for harvesting data on all Wifi networks including those in private dwellings.

And collecting data on every network was what I said could not be cast as user convenience, so it appears that my statement has been taken out of context and then strawmanned.

In no event, however, is it a case for storing those passwords as plaintext.

[chrisrhoden]

Yeah, I mean, this simply isn't true.

Google's pretty clear on their motivations here. It's the same reason that they back up what you have set as your background. It's not about multiple devices, it's about fungible devices.

The result is that you log in to any fresh android device and in a few minutes it's automatically configured itself. If you wipe your device, or lose it, or whatever, replacement cost is the biggest issue.

As for the harvesting of signal strength and name of wireless networks, the user convenience is that Google Maps will work even when you don't have clear line-of-sight to GPS satellites in most places. That's pretty darn convenient.

I think it's bad that they have this data, because the potential for abuse is large, but please don't suggest that there aren't clear and benevolent reasons for these decisions. It's extremely rare that people do things with obviously dubious motives. This is clearly not one of those cases.

[leoedin]

You give large corporations way too much credit. There's no evidence beyond your conspiracy theories that this is a feature designed for anything other than convenience (one which I and many others in the thread have found to be quite convenient).

Not every feature in Android is designed to be monetised. Google develop Android with the intent that users will use their app store/click on Google provided ads. They can only do that if they are seen to be offering a competitive, feature full product. The cloud-based syncing of your phone configuration is one of those features.

Having worked in various large organisations (including ones which are definitely part of the military-industrial complex) I can say wholeheartedly that there is no grand conspiracy. Most people, wherever they work, want to produce the best product they can.

[samstave]

>You give large corporations way too much credit. There's no evidence beyond your conspiracy theories that this is a feature designed for anything other than convenience

Yeah, excepting the whole NSA issue, the fact that Google was previously caught/accused of war-driving every wifi net they could see with their streetview cars etc.

While the feature may be convenient, that does not preclude the worst case from also being true.

Facebook is convenient, but its pretty well proven now that the data conveniently stored within is harvested and mined by "infiltrators thereof"

[amalter]

>fact that Google was previously caught/accused of war-driving every wifi net they could see with their streetview cars

I am a bit amused when folks trot this out and forget to mention that Google itself discovered this, voluntarily came forward, owned up to the mistake, provided the information to the prosecutors and paid the fines related.

You would think if they were so determined to continue with this nefarious activity they might have been a bit more mum about it.

[leoedin]

Google gathered wifi data to improve their location services. The capturing of unencrypted payload data was an unintended consequence of that due to poor software design. The initial wifi data collection was intentional and was designed to improve their location product (which it did - the Google Maps location service can be very speedy if it's near a wifi access point that google cars picked up - another feature likely to encourage people to use their product). The additional capture of packet data was unintentional. Numerous third parties have been involved in auditing google in their actions after it all came out and there's been no hint that they ever intended to do anything with the packet data they collected.

Facebook (and google) do "harvest" your data. They also mine it for relevent information from which they can show you adverts. There's no debate about that. It's not a conspiracy though - they state in their privacy policies that they'll use your data for targeted adverts. It's their revenue model!

[antimagic]

This, in addition to Google's demonstrated willingness to hand user data over to the US government means that the government (or a rogue Google employee, or a hacker that gets access to Google's database, or a rogue member of the US government, or ... you get the picture) can hit you with a LAN-based MotM attack pretty much whenever they wish. That means they can own your computer, because your Android phone connected to the same Wifi router. Uh, no thanks.

[packetslave]

I realize you're just being a troll, but what you really mean by "Google's demonstrated willingness to hand user data" is "[...] comply with U.S. law and valid court orders while doing everything they can to push back on overly-broad fishing expeditions by the government."

Yes, I'm a Googler, and yes I'm tired of hearing this horseshit. Every single U.S. company complies with warrants, court orders, NSLs, and FISA demands. Every. Single. One. If you don't like that, work to change the bloody laws.

[antimagic]

Are you suggesting that Google doesn't hand over data? Google has decided to do that because it's good for business (in the sense that going up against the US government is bad for business, and realistically would require Google to move overseas). That's fine, but it changes nothing of the fact that they will hand over data requested by the US government, which means that my comment was perfectly valid.

You seem uncomfortable with the consequences of that. Maybe you should re-evaluate your own relationship with Google - do you really want to be party to these shenanigans?

[packetslave]

Did you even read what I wrote? Yes, Google will hand over user data in response to a legal demand from the U.S. government (warrant, court order, NSL, etc.). So will every other company in the US, whether it's Yahoo, Rackspace, Amazon, or Joe's Linux Servers, Inc. It's called "obeying the law". Characterizing this as "Google's demonstrated willingness to hand user data over to the US government" is dishonest.

Google is one of the industry leaders in being transparent and open about government requests for data (http://www.google.com/transparencyreport/) and in fighting the government on improper or overly-broad data requests, or those that don't exactly follow the legal procedures. I'm perfectly happy with my relationship with them. I'm quite unhappy with the U.S. legal environment that allows things like secret FISA orders, but that's hardly Google's fault.

[antimagic]

Here's the thing - I don't give a rat's arse why Google hands over my data to the US government. All I care about is that they do. They apparently find it easier to hand over my data than to shut down operations or move overseas so that they don't have to. OK, they are free to make that decision (as I have already stated), but they are still bloody well handing over my data! And you, as a googler, are party to that. You really should have a long think about that.

[Symmetry]

I'd imagine people getting new phones is the common use case.

[brudgers]

If I buy a new Android phone, odds are it is not one which makes me a Google customer - i.e. Google gets none of the proceeds should I purchase a Samsung Galaxy.

The only means by which Google profits is by monetizing data leaking from my device. And my WiFi password is something potentially monetizable. When choosing between ignorance and malice as motivations, it is perhaps proper to choose ignorance even with Google. When choosing between my privacy interests and Google's monetary interests, it seems naive to place my privacy interests above those of Google's actual customers.

An American corporation is determined to be part of the military-industrial complex; film at 11.

[azernik]

By that logic, they shouldn't make the Android OS at all - they don't get any money for it!

[randomchars]

> The only means by which Google profits is by monetizing data leaking from my device.

You have no idea what you're talking about. It directly profits from sales on the Play Store(apps, movies, TV shows, magazines, music) and advertisement clicks. They also benefit from building better user profiles, so they can better target advertisements.

[vegasbrianc]

or a factory reset.

[jimmaswell]

>Google has harvested the location, name and signal strength of many millions of wireless networks across the world - an act which can be in no way cast as user convenience.

Improved location data on wifi is one way.

[shameless_1]

> Google has harvested the location, name and signal strength of many millions of wireless networks across the world

Don't forget that that dataset of wireless locations is updated continuously through crowdsourcing.

[amalter]

>> Google has harvested the location, name and signal strength of many millions of wireless networks across the world > Don't forget that that dataset of wireless locations is updated continuously through crowdsourcing.

Along with Apple, Skyhook, Nokia and a number of other location providers.

[throwaway2048]

to make this a bit clearer, android, apple, etc devices send back wifi BSSID+GPS coordinates to the mothership for AGPS purposes. Im really suprised there hasn't been more concern about this.

[shameless_1]

As an engineering project this is truly a resourceful and rather elegant solution to tune a Kahlman filter for positioning. But on the level of privacy ... big consequences. The BSSID allows tracking when someone moves to a different place. And since that's tied to GPS with multiple captures over time you get a pretty accurate location for the WiFi device.

[nodata]

I appreciate not re-entering ten cryptic wifi passphrases when I replace a phone.

[swamp40]

> Google's scheme allows them to harvest the passwords to a vast number of wireless networks.

I wasn't too worried until I read this from you.

[Sindisil]

I wouldn't worry.

It's not as if the government could compel our friends at goooogle to give up said passwords.

Besides, you don't have anything to hide. Do you?

[jamesaguilar]

Yep, we all know google needs extra bandwidth and/or has the capability or need to illegally snoop on your over the air http traffic at enormous legal risk.

[enneff]

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.

[tzs]

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

If we are just talking about encrypting for backup, then that is not correct. The device would only need to ask for the password before the first backup that includes a wifi password, on the first backup after any wifi password change, and before a restore. Wifi password storage on the device itself can continue to use whatever mechanism it currently uses.

This can actually be cut down to just needing to ask before the first backup and before a restore. Generate a public/private key pair. Ask for the GA password and verify it, and use that to deterministically derive a key to encrypt the private key. Store the public and private keys in the cloud. Cloud data can then be encrypted with the public key before being sent to the cloud.

They only need to ask for the GA password again when they need the private key, such as for restoring the data.

[jordanthoms]

Thing is, this is actually not a one-time backup but an ongoing sync. And it's super convenient - I only have to enter the password on one of my devices and then all the others can connect.

[snom380]

Even with ongoing sync there could be an option to store the password on the device, either permanently or to enter it at boot time. Just like with SSH keys.

[Camillo]

Not backing up wifi passwords would be a better tradeoff, especially as the default.

[eli]

I seem to recall that not backing up anything is the default. Am I wrong?

[mtgx]

Most such Android settings are on by default, including all the location tracking ones.

[damian2000]

I believe cyanogenmod has backup turned off. But I had used previous (earlier version) of Android and it was turned on.

[eli]

I only use the Android that comes with my phone and I recall having to check the box myself on my T-Mobile Galaxy S3.

[threeseed]

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.

[enginous]

Encrypting anything with your Google Accounts password doesn't really make you invulnerable against Google. They can get your clear text Google Accounts password from you any time they want by just reading the password you enter on any of their clients.

[shawnz]

Here's the problem with encrypting via the account password, directly or indirectly:

Google gets subpoena'd for your data. At next logon they capture your password and grab the key. There goes your data, including your wifi password or whatever else.

Of course I don't think that this would ever happen, and even OP's complaint is a bit unnecessarily paranoid in my opinion. But there's your answer.

EDIT: However this might be plausible if the stored key was also encrypted with some sort of passphrase or PIN that was not known to Google, which I believe is how Chrome does it currently.

[valisystem]

Firefox does it by asking you to enter a code displayed on a device that already has the key. My guess is that the displayed key is used to decrypt the actual key on the device, and that the key is never seen in clear on the network.

[eslaught]

Correct, and not only is it never in the clear over the network, the key is stored such that Mozilla cannot decrypt your content.

https://support.mozilla.org/en-US/kb/firefox-sync-data-secur...

[drzaiusapelord]

What common use case is backing up wifi passwords or any passwords, for that matter? Yeah, there are difficulties here, but I don't want or need you to backup my wifi password. Its none of your business.

[snom380]

I've probably saved hours of phone support because my parents wifi passwords and email setups is saved in their iPhone backup (this is only done if the backups are password protected). When they get a new device it's just a matter of plugging it in, choose restore, and that's it. They do have to enter some payment info again for each new device on the App Store though.

[gcb0]

Why do you even have to backup a password? It's idiotic from every way you look at it

[ajross]

Sorry, that doesn't make any sense. The specific use case here is unboxing a new phone, logging in, and having access to all of your standard networks without having to look up your wifi passwords. Clearly that has value to anyone who has ever used a new phone.

But to get to your core point: unless you have an amazing memory (unlikely) or reuse passwords (not unlikely, but, to borrow a term, "idiotic") you have to be storing those passwords somewhere. Password escrow certainly counts as "backup" by any normal definition of the term, although it has some extra requirements.

[sixbrx]

Or use a password manager, which does proper encryption.

[Nursie]

Perhaps it's a trade-off that shouldn't be on by default.

I didn't even know this happened until a friend bought a new device and it suddenly knew everything. Didn't bother him, did bother me.

[claudius]

Let the user create a private/public key on the device and allow them to store the file somewhere safe with only the public key remaining on the device. It can then easily do the backup (and even store the public key on Google’s servers, if required) whenever required, and if the user gets a new phone, he’ll be prompted to feed his private key into it again to decrypt the backup. This can be done over the network, from an SD card/usb key or maybe even with a QR code.

[MarkMc]

> 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

That is strictly true, but isn't it significantly more difficult for an infiltrator to (a) obtain Google's private code-signing key and push a compromised client build to devices; than (b) hack into a Google database and read the 'users' table...?