Sep 24
Security My tin foil, now covered in joyous spittle, reflects the news that I'm not crazy (and neither is the EFF or Tom). In reaction, SRWare provides Iron, which according to downloadsquad had none of the privacy invading evil zombies the German Federal Office for Information Security warned us about (you'll notice the warning is similar to mine, take *that* persistent GoogleUpdate process). If you really need another browser and aren't happy with the one, use Iron instead of Chrome at least.

I have since installed Iron, and done some checking with the source. It appears SRWare has made the following changes (this is based on the Babel translation of the page in German, so is fuzzy):

  • They are using 525.19 of Webkit rather than Chrome's current 525.13.
  • The unique clientID has been removed.
  • The TimeStamp for Chrome's install date has been removed.
  • Each keypress from the Suggest feature is no longer sent to Google.
  • Google-hosted alternative error messages have been disabled.
  • RLZ encoding of information to Google, such as where Chrome was downloaded and other configuration options has been removed.
  • The persistent GoogleUpdater services has been disabled (this isn't removed when you uninstall Chrome).
  • Something about the homepage and URL tracking has been removed.

Hat tip to cocooncrash for the link.

Posted by Dominic White

Last modified on 2008-09-30 15:15

0 Trackbacks

  1. No Trackbacks

7 Comments

Display comments as(Linear | Threaded)
  1. Tristan Seligmann says:

    You do realise that some of these "evil nasties" you keep complaining about are considered features by other users, right?

  2. Dominic White says:

    "Given a choice between dancing pigs and security, users will pick dancing pigs every time." - Edward Felten

  3. Tristan Seligmann says:

    This isn't about security, it's about sociology.

  4. Dominic White says:

    Your one-liner is kak, care to explain it a bit better?

    My point was that security holes have been considered features by many for years. A lot of time in security is devoted to securing new technologies and features. Additionally, users and the corporations whose interest is served by punching the hole are not the people to aim for the middle ground; the corporation is greedy and the user is dumb (when it comes to security decisions).

    Being a feature, however, is not enough to justify or eliminate privacy concerns.

    Finally, even if it was, of the 8 or so changes, only three of them actually disable a feature; the suggest feature, alternate error pages and the updater. The only useful one of those is the updater, and it is implemented so badly that it isn't worth keeping. I'd rather use Secunia's Personal Software Inspector.

  5. Tristan Seligmann says:

    Perhaps an example would help; if a burglar picks the lock on my front door to gain entry to my house, that is a security hole. If I *give* my girlfriend the keys to the front door, that is *not* a security hole, even if it may represent an increased security exposure risk. As to your final comment, the fact that you don't consider the other things to be features doesn't mean that they aren't features, and your statement about usefulness is similarly biased towards your own use case.

  6. Dominic White says:

    Google's not my girlfriend and I certainly don't want to give her keys to my house. The fact that Google has managed to force you to make that decision and 'bias your use case' in such an extreme manner is part of the problem. At worst, I would like Google to have keys to the garden shed.

    Well, let me clarify one thing; if a burglar picks the lock on your front door, that's an attack, not a security hole (or vulnerability). The fact that your lock can be picked is the security hole, and the ease with which it can be done, and the criticality of the assets it protects provide the severity of the vulnerability and impact. Just so we can use a common lexicon :)

    Likewise, Google (and other's) mass collection of data can be considered the vulnerability, and their malicious intentions the attack. The vulnerability can still exist without a malicious threat agent, the likelihood of it being exploited is just limited. Thus, even if Google isn't evil, they are still poking holes.

  7. Tristan Seligmann says:

    So, after some high-bandwidth discussion with Dominic about this issue at GeekDinner, I've written some slightly expanded thoughts in a blog post of my own: http://mithrandi.vox.com/library/post/asynchronicity-geekdinner-and-chrome-plating.html

Add Comment


E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA