3 ms·

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 th

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

hosay123 14y ago
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.
- css771 14y ago
  > 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?
  - hosay123 14y ago
    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/ 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.
    - css771 14y ago
      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?)
      - codeka 14y ago
        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.
        hosay123 14y ago
        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.
      - hosay123 14y ago
        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'.
- opinali 14y ago
  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.

hosay123 14y ago

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.

css771 14y ago
> 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?
- hosay123 14y ago
  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/ 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.
  - css771 14y ago
    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?)
    - codeka 14y ago
      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.
      - hosay123 14y ago
        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.
    - hosay123 14y ago
      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'.
opinali 14y ago
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.