In the same way, when you look closer at the virtual DOM model, you'll find that you can optimize the usage very well. For example, when you use React with immutable data structures (e.g., Immutable JS), deep equality comparisons can be done very quickly to reduce renders to the minimum subtree required, and to issue the renders for a given change in a batch operation.

With React, you often end up with even faster code than using manual DOM manipulations. Of course, your performance will vary depending on how you implement your code. Depending on which model you're using, and how you program, you may end up with a faster or slower product with either methodology.

But at the end of the day, the performance gain from running code using state mutations just doesn't seem worth the effort of having a significantly harder time reasoning about the code, and having to deal with the challenges of scaling a project where the complexity grows much faster with each line of logic.

And my feeling is that due to the time invested in managing a more complex project that deals with mutations, the "performance per engineering hour" gained for projects using a virtual DOM is more favorable for many projects.

Also, suppose I have a list of thousands of elements. Now suppose one element is added to the list. React will still perform a comparison operation on all of those thousands of elements.

That's going to be a problem regardless. You shouldn't have so many elements on one page (can a user even parse through so many at once?). Use pagination or occlusion culling to show a few at a time instead.

And, if you find that it's still too slow, there are other strategies you can employ to fix it without having to turn your whole application into a stateful soup. Odds are, though, that this is not going to be your bottleneck.

Using the `shouldComponentUpdate` API alleviates the problem, doesn't it? https://facebook.github.io/react/docs/component-specs.html#u...

But if you can't meet both those conditions, that sort of thing definitely can get quite slow.

My impression has always been that, for any constant-time operation, you're gonna need to start getting into the 100Ks or even the millions to start noticing, but I don't have the data to back me up here :/

I like the abstraction, it is super easy, has a small API surface and most of the time it is "fast enough". But it's no panacea. Often I have to throw D3 in, to get "realtime" stuff done without blowing up the browser.

  1X – $25/month compared to $36.5/month (by the hour).
  2X – $50/month compared to $73/month (by the hour).
  PX – $500/month compared to $584/month (by the hour).

The format of the post is also quite nice; a few short points with illustrations and a clear takeaway.

For larger ones, we provide lifecycle hooks so you can set up these subscriptions manually. In componentDidMount() and componentWillUnmount() you can subscribe/unsubscribe to some sort of messaging system, and when you receive the message call setState(). Usually you only need to do this in a few places and the regular React dataflow will carry you the rest of the way.

Does that make sense? We should probably write up this technique.

Or, instead of an event-based approach, you could could pass in an object and use Object.observe() to observe state changes.

It looks like React just implements the view in MVC, so you still need a separate way to observe the model.

The part of the architecture which has had the biggest impact on my code: the relationship between a component and it's subcomponents. A parent component can only pass "props" to it's subcomponents (ie it can't pass state, which is easily mutable). And a child component can only call a function on it's parent if that function is provided to it via props (ie a callback).

This design has forced me to reason about the interface between components (open/closed principle, law of demeter, etc) and has really improved my code.

Also, the team is very active/helpful in their irc room.

Due to higher taxation, low-income individuals would have even less access to medicine than today. Keeping people away from drugs with prohibitive taxation means starving entire demographics of this component of health care.

So sure, people who have the funds to take excessive amounts of medicine may be "just as healthy." Others would be considerably worse off.

If the purpose of taxing medicine is to subsidise the provision of medicine to people who couldn't afford it at cost price, then that would give such people greater access.

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.

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.

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

How is it usually done?

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.

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?

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.

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.

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]

  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?

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.

But lest my meaning is misunderstood, an offer from Fort Meade might be one Mr. Page gladly accepts as a US national - I certainly have no more reason to question his patriotism than to believe it to be partisan in the extreme.

Even removing patriotism from the equation, developing and maintaining good relations with governments and their agencies involved across national borders probably makes sound business sense for a company of Google's size. And I have little doubt that Mr. Page places substantial value on international business opportunities.

Absolutely. His price is letting him remain a billionaire. I'm of the opinion that most billionaires would sell their own mothers to organ harvesters if failure to do so would result in them becoming poor.

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.

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?

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

I found some Toms Hardware article that goes into "a few GPUs in a desktop" all the way through "renting 20 machines with GPUs from EC2 for a while for <$20 USD", and it seems like a password that is long (>=12 characters for now), doesn't have dictionary words, and uses more than just [a-zA-Z0-9] will be safe from undedicated adversaries for a number of years (probably the life of whatever router you're using).

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.

Note that non-targeted attacks (the type that leak password lists) are not a serious threat here.

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.

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.

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.

And these are just the ones that I remember.

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.

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.

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

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.

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?

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. 

It looks like that blog post only states that they deleted the erroneously collected network data.

https://en.wikipedia.org/wiki/Wardriving

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.

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?

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

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?

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.

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.

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.

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.

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"

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.

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!

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.

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?

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.

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.

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.

Improved location data on wifi is one way.

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.

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

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?

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.

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.

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.

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.

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

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.

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.

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...?

Does this happen to people in any other European countries?

Couldn't you get access to the UK's or Ireland's store? All you need is a voucher card and a fresh email address. That's how I got my US account for US-exclusive apps.

At one point, they publicly rejected any affiliation with The Pirate Bay and said that they did not condone copyright violations.

They did however use the opportunity to encourage people to learn about openly licensed content, mentioning Paulo Coelho as an example, and suggesting that people consume free content no less than they do paid content. However advisable or realistic that actually is, it's not supporting illegal downloads.

I've always found it endearing how politicians - apparently of all stripes - believe they they can change reality by issuing a statement.

The name of the pirate parties of the world can be directly traced to Piratbyrån, the same organisation that started The Pirate Bay. If they were serious about their "public rejection", they should reject the name as well. There is nothing, not even a little bit, "pirate" about consuming free content.

Also, since you're bringing up Paulo Coelho: Mr. Coelho explicitly condones the kind of piracy ("copyright violations") that you claim the pirate party does not condone. I'm not sure if it's you or the Icelandic Pirate Party that's being dishonest here.

People might say they're prepared to pay less for it now than when it's reached some adoption and they start feeling the social pressure of "everybody has it; I must get one." For now it's probably more of a futuristic toy to them.