Google Accidentally Transmits Self-Destruct Code to Army of Chrome Browsers | Hacker News Reader

Google Accidentally Transmits Self-Destruct Code to Army of Chrome Browsers

wired.com

58 pointscyphersanctus33 comments

The actual reason for the crash is explained in the bug report http://code.google.com/p/chromium/issues/detail?id=165171#c2...

Renaming this bug as it really has nothing to do with GMail specifically.

To clarify:

- Chrome Sync Server relies on a backend infrastructure component to enforce quotas on per-datatype sync traffic.

- That quota service experienced traffic problems today due to a faulty load balancing configuration change.

- That change was to a core piece of infrastructure that many services at Google depend on. This means other services may have been affected at the same time, leading to the confounding original title of this bug.

- Because of the quota service failure, Chrome Sync Servers reacted too conservatively by telling clients to throttle "all" data types, without accounting for the fact that not all client versions support all data types.

The crash is due to faulty logic responsible for handling "throttled" data types on the client when the data types are unrecognized.

The headline is definitely ridiculous link bait. Google doesn't have some big red button somewhere to nuke Chrome browsers. There was a bug which only appeared when there was an unexpected server behaviour.

That said, it was bizarre for a bit that Chrome was crashing because Google was down. I was actually considering switching off Chrome until I learned it was only an issue with Sync. Fortunately, Google doesn't make the Sync service mandatory, unlike some game ( and mouse ) manufacturers.

Looking at the code changes, the headline is just fear mongering. The main change is a check for the datatype; it wasn't checking for it earlier:

http://src.chromium.org/viewvc/chrome/trunk/src/sync/engine/...

It was a simple logic bug. From the crash traces, it was an out of bound exception:

    terminate called after throwing an instance of           'std::out_of_range

But I don't think reporters are going to take the time to talk to someone who can analyze it and give them an accurate picture, even though chromium is open source and issues are discussed and fixed publically.

"Sync is essentially Google's answer to Apple's iCloud."

This may be a nitpick, but Sync was originally a Firefox extension that Google released in 2007, before the iPhone was even released.

Good nitpick. Fully agreed. Apple was the late-comer to this game trying to come up with an answer to Google and Android's seamless sync capabilities.

I'm saying "trying" because from the feedback I've seen online, iCloud is seriously suffering in usability because of Apple's design-decision that iOS shouldn't "have files".

Before 2011, before iCloud, Apple's best sync offer was to take your device, hook it up to a machine via USB and install iTunes on it, and then wait. Wait while your device was in a locked, non-usable state, with no ETA.

In 2011, Apple told you to get your cables out. And people claiming Google was the one responding. That's absurd. But it seems people are good at forgetting stuff like this. Stuff which made me and several others permanently leave Apple's platform.

Apple is the one who fell behind, Apple was the one trying to catch up, Apple is still the one needing to catch up. The article framing it the other way around is disingenuous.

If people stopped giving Apple credit for shit they didn't do nor invent, maybe people would realize there are better options out there, at a much cheaper price.

Have you ever used iCloud? It just takes a username and a password and you can replicate anything from an iPhone to another (minus some passwords that may not be all saved in iCloud). I don't know what's not working, I had no issue with it.

Agreed, as a straightforward sync service for things like bookmarks, preferences, photos, etc it's fine. As a competitor to Google sync it's top notch. The fact that my iPhone photos just show up in iPhoto on the Mac automatically is great.

Where it hits limitations is for more complex apps where you want to share more complex content in apps with other apps or other people. It supports specific work flows that Apple has hard-coded into it, but it's hard or impossible to impose your own workflow on it. But then that's no different from other basic sync service like Google Sync, instant upload, etc. As a competitor to them it's fine, but as a competitor to Dropbox it's got a long way to go.

My impression was that iCloud is OK at getting things from your iPhone elsewhere (like other iPhones), but it doesn't in any way solve the issue of creating a document "in the cloud" (or on your laptop or whatever) and getting access to it on your mobile device. Here is one of the places where iCloud goes tits up.

And that's before you bring up the confusion caused by iTunes backup + iCloud, for which there has been numerous reports here and other places, leading to complete data-loss.

On the flip side, Google has this nailed. Apple is still trying to get it right, and failing. With "iCloud not working" having over 21 million hits on Google.

I think saying the user-experience is lacking is putting it lightly. Google is light-years ahead here.

Really, don't talk about user experience without having any.

Fair enough, but in my defence, I was pretty clear about that this was my impression based on information obtained elsewhere.

Still. I don't think there can be any doubt about the main point's validity: Apple was the USB company. They are still trying to find their way out of there. They are responding to Google, not the other way around.

  > If people stopped giving Apple credit for shit they
  > didn't do nor invent,

How about people not rushing to voice their opinion about something they only saw feedback online?

Terrible headline, I thought this was the revelation of a purposeful feature of Chrome that Google can use to remotely kill it.

And "self-destruct" does not mean "crash". I thought they corrupted the installation or something.

Interesting to see such a widespread failure in a system built to have high redundancy. My software reliability final exam is in an hour, this came at a good time :)

Ah, so this was why Chrome kept crashing when I stayed up late last night! It prompted me to just go sleep though

More than just a little "oops" then?! Should Google be sandboxing the Sync service, and other similar potential non-essential processes that could take down the browser? (Assuming that Sync is not an essential process?)

As with Play, Google itself is assumed to be perfectly trustworthy, fallibility just doesn't enter into their thinking. (As a reminder, Google literally have remote root on every Android device that has market installed. If your device is online, it's a few hundred bytes over an always-on socket away from remote install/wipe)

I'd secretly hoped the Chrome incident was bigger than it turned out to be. The world needs something like this to remind ourselves why centralization of any kind is fucking evil, regardless of the pin-up CEOs involved.

There's nothing special in the fact that this problem involved a cloud service, or a bundled feature that some users may consider non-essential (all desktop browsers are shock-full of such features... unless you count Lynx). Consider this: Google might have pushed a regular Chrome-stable update containing a bug that would make the browser crash frequently for many users. Would that mean there's some fault in the process because Google has the privilege to push updates to the core browser? The fact is, there no much difference, Google "trusts itself" to update any aspect of Chrome, from the code that runs in your machine to any cloud services it may connect to; we can screw up in any of these components, and we should obviously work hard to prevent crashers no matter where.

Also notice that this bug was not a pure cloud bug: there was a bug in the client Sync code, i.e. in the browser; but this bug was only activated when the Sync servers also misbehaved, so it could be prevented with a server-only fix/workaround. Still it doesn't count as a real "cloud crash", not any more than an HTML renderer crash that only happens if some website sends corrupt content.

> As a reminder, Google literally have remote root on every Android device that has market installed. If your device is online, it's a few hundred bytes over an always-on socket away from remote install/wipe

Is there a source for this?

One or two security researchers have written about it, but you can easily see it for yourself: you can remotely install anything you want via http://play.google.com/ (as can anyone with your account username and password).

The protocol does not require mutual authentication. Your ability to install to the phone from the Play site is not dependent on your phone authenticating you being logged into the site. The phone simply trusts whatever Google sends.

But isn't it a jump from that to "remote root on every Android device that has market installed" and "If your device is online, it's a few hundred bytes over an always-on socket away from remote install/wipe" (remote install yes but wipe?)

Of course it's a jump. The original claim seems like pure FUD to me. If you don't have a Google account on the phone, then the Play store does not work.

If you have a Google account, then you trust Google. If you don't trust Google then it would seem silly to have a Google account.

It's ridiculous to call this FUD in a thread about a few million Chrome instances being accidentally DoS'd by the same company.

The ultimatum you describe (which is also the present reality) isn't the only possibility here. Even a simple confirmation dialog box is enough to prevent a situation where an evil actor could silently mass-install malware on every Android device, or for that matter an authoritarian actor installing legal spyware outside the device owner's control.

I'm not sure I understand the disconnect. If I wire up a machine that produces rainbows and unicorns to a button that primarily initiates thermonuclear destruction, is the button somehow less dangerous?

The simple fact is that there is a socket connected on the phone to my left, with exactly the features I just described. Just as it can produce apps at my leisure, similarly it can be used for less desirable actions. In the past, Google have used this legitimately to remove malware, but it's not Google I'm concerned about. One nationstate (China) has already shown Google's production environment little more than a few nasty PDFs sent to the right e-mail addresses away.

As for remote wipe, that's a feature of the platform – search for 'android device administrator'.

Talk about link bait! There was no self-destruct code.

This is why I'm staying away from the "cloud" for as long as I can. I don't like this tight integration that much, you'll be frozen out of everything if one feature goes down.

And I have all my essential files on my PC and backed up several times. Even if Gmail is nuked, I still have a local copy.

I don't use gmail either, but if "frozen out of everything" is you concern go and use the imap connector to integrate gmail into the local mail program of your choice. From there on the failure mode is about the same as you'd expect from any other mail server - and I'd bet that gmails uptime is about on par or better than any other mail-service you can get out there, including your own server.

> gmails uptime is about on par or better than

I see this argument a lot, and there is truth in it.

However, there is a key difference. My own machine's uptime is certainly lower, but I have some control over when the downtime is.

Google chose to push a change that accidentally broke things. If I have a critical deadline, I can choose not to push any changes to my systems at all. When you use a cloud provider, you lose this choice.

So the question isn't really about comparing uptimes as a single figure any more. What about uptime during defined critical periods?

Edit: people replying seem to have inferred that I'm saying that running your own email server is better than using Google Apps. I didn't say that. I'm just saying that in any comparison, there is more to "cloud" reliability than a single uptime figure, and so using a single uptime figure comparison is not helpful in such a debate. The control you have over update timing is an important consideration to make in the general "move to the cloud" case.

You're still dependent on your Intenet service provider's decisions. If your ISP decides to have some downtime while you've got a critical deadline, there's not much you can do to make your e-mail flow. And Google probably has less downtime than an average ISP.

Of course ISP maintenance doesn't keep you from using your local office applications and such, like Google downtime would if you used Docs.

Control as in you get to choose when hardware fails or zero-day exploits get released?

I hear that argument a lot, but you really need to invest a lot of time to provide a secure and reliable e-mail service. It just doesn't pay of in most cases. So yes, you can do it, but don't pretend it's a viable way to save money. I get to see hacked e-mail servers every couple of month.

What about things like critical deadlines coinciding with security updates? The constant background effort of supporting email is a rather unfavorable return on your time.

I was reading that Chrome wouldn't work either because of Gmail was down. Then we have algorithmic account deletions for "spam" or violating whatever rule. That's more than enough for me to be very cautious. Uptime is not as relevant, in 99.999% of cases we can wait to email or we can just pick the phone and call, losing access for ever is scarier.

Do not put all your eggs in one basket, be it Google's, Apple's or Microsoft's.

This is why I'll never cross the street. You could get run over. Instead I've built my own shopping mall in the back yard, to keep everything local.

Reply on news.ycombinator.com