6 ms·

The developers of Iridium don't reveal that their browser phones home to their servers, and that's cause enough for distrust here. A quick "grep -r iridiumbrow

by skymt 11y ago

The developers of Iridium don't reveal that their browser phones home to their servers, and that's cause enough for distrust here. A quick "grep -r iridiumbrowser.de" of the source reveals that they replace calls home to Google with calls home to various hostnames of the form "trk-NNN.iridiumbrowser.de", where NNN is a three-digit number. Presumably these hosts act as proxies. For example, lines 37-38 of chrome/browser/history/web_history_service.cc: const char kHistoryQueryHistoryUrl[] = "https://trk-139.iridiumbrowser.de/history.google.com/history/api/lookup?client=chrome"; Edit: The git log for this change: https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/commit/chrome/browser/history/web_history_service.cc?id=3bb27d9887bef87a41b56f2ec5ef62df81319a0a https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/commi... "Replace URLs to Google services by URLs to our own server, so as to analyze where we still have to patch the browser to make it stop blurting data out." That's an acceptable excuse in a debug branch, but there's no reason for this kind of privacy-impacting debug code to reach a public build.

justonepost 11y ago
I think you want to reach out to them and find out their reason for this. Obviously they are revealing what's going on because it's in the publicly available source and commits.
- skymt 11y ago
  Iridium's website makes a selling point of the fact that Chrome contacts Google servers, but fails to mention that it may phone home to servers of its own. Having to search the source to discover that large a privacy difference isn't proper disclosure to my mind. I don't claim it's necessarily malicious. The explanation given in the git log makes sense, though there are better ways to accomplish the stated goal, such as replacing Google's tracking URLs with invalid ones. But leaving those changes in public releases of software supposed to increase privacy seems negligent.
  - bigiain 11y ago
    FWIW, whatever Iridium might be doing with "phoned home" data, it's spectacularly unlikely they're capable of getting anything like the datamining utility out of it that an assumed-currently-doing-evil-Google could do. Google Analytics across 60% of the web, Adwords, the other end of a large proportion of my email content even if I don't use gmail (because it's sitting there in my correspondents Google hosted mailboxes) - Iridium don't have any of that to correlate my browser's behaviour with. And from a person assumed to have no privacy rights by the NSA (since I'm not an American citizen) there's some benefit of that phoned home data existing in a non US legal jurisdiction too... Even if you _don't_ assume Google is currently doing evil, we _do_ know they're subject to PRISM and NSLs...
  - bigiain 11y ago
    I'll also mention that - in a completely unfair-to-you way - I just went and scanned through your comment history to see if I could quickly identify NSA shilling... Such is the nature of the discourse these days. Sorry. (Or, if you _are_ an NSA stooge, congratulation, you do a reasonable job of hiding it...)
    - socceroos 11y ago
      Hahaha, distrust goes both ways though! Suppose you're trying to coerce people into using this browser knowing that you've (NSA) already snuck in some backdoors? They used to say that you have to trust the compiler. But not even that is true these days. Perhaps you've read about the secret hdd partitions that the NSA were using. These days it goes like this: open-source hardware, open-source firmware, open-source compiler, open-source software. Only when an entity can follow this path to build their own trusted stack can we begin to move with high confidence.
      - bigiain 11y ago
        Even open source hardware isn't sufficient against an attacker as seriously resource rich (both cash and technical ability-wise) as the NSA. You can't trust the supply chain any more, you can't even trust the silicon unless you made it (and all the machines you used to make it) yourself. Are you _sure_ that network chip, usb controller, or flash ram you built your open source hardware out of isn't exploited? If you're on the fence about whether you're "too paranoid" or "not paranoid enough", make sure you've read what some people do for free, just for fun/curiosity/geek-cred/reputation: http://travisgoodspeed.blogspot.com.au/2012/07/emulating-usb-devices-with-python.html http://travisgoodspeed.blogspot.com.au/2012/07/emulating-usb... http://www.bunniestudios.com/blog/?p=3554 http://www.bunniestudios.com/blog/?p=3554 Then imagine what their grey-suited counterparts on 200K salaries at the NSA with (for all intents and purposes) unlimited research budgets might be up to.
damm 11y ago
All the links in that commit result into a 404; so if they are collecting data it's purely off of whatever they have output in the Access logs. Possible something in the future; or possibly something they could not neuter as easily as they would like?
jerf 11y ago
Have you verified that the browser actually phones home via network sniffing? If they have in fact successfully used that commit to remove all cases of phoning home, than it is an unfortunate oversight in the commit history of a browser that still doesn't ever phone home, and in practical terms, nothing more. If the code paths can not be reached, they can not be reached. Before somebody hops up, yes, I am as aware as the next guy that today's "path that can't be reached" is tomorrow's path that can, and yes, of course outright removal would be better. It's absolutely fair to raise an eyebrow and ask sharp, pointy questions under the circumstances. But it's not fair to say a browser "phones home" if in fact it doesn't.
- TheLoneWolfling 11y ago
  Have you seen the underhanded C contest? Even if it's not phoning home now (and I'll assume it isn't, in good faith), it's far too easy for a seemingly-trivial change later to enable it.
  - jerf 11y ago
    People's ability to echo my own points back at me as if I somehow failed to consider them and they are somehow correcting me never ceases to amaze me.
geofft 11y ago
In the following commit, the IPv6 probe is changed from Google Public DNS's IPv6 address to that of iridiumbrowser.de: https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/commit/?id=f3f60d31d8997d68293461f81eebccf1af95f6a4 https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/commi... To be fair, that's a very tiny leak: it only indicates (maybe) that someone is running your browser at the source IPv6 address. But if it's tiny, it might as well continue going to Google Public DNS, since it's much more likely to get lost in the noise there (Google Public DNS probably gets a fair bit of IPv6 traffic from users, not to mention all the existing Chrome / Chromium users).
longsleep 11y ago
This is really great feedback. Reading this and the other comments makes clear that we need to improve documentation what and why we changed things. All the trk-xxx.iridiumbrowser.de hosts are there to find connections which we were not able to disable yet. All these end up at nothing (404 not found) and are not proxied in any way. Essentially Iridium browser should never contact them - if it does then it is a code path we have missed and a bug.
- TheLoneWolfling 11y ago
  Then replace them with a crash or popup ("Line <x> was reached but shouldn't be reachable. Please report this." or whatever) Phoning home without permission goes against the entire concept of a secure browser. Have you ever seen the underhanded C contests? There are far too many ways for something like this to turn nasty. Especially given there's inherent plausible deniability.

by skymt 11y ago

justonepost 11y ago

I think you want to reach out to them and find out their reason for this. Obviously they are revealing what's going on because it's in the publicly available source and commits.

skymt 11y ago
Iridium's website makes a selling point of the fact that Chrome contacts Google servers, but fails to mention that it may phone home to servers of its own. Having to search the source to discover that large a privacy difference isn't proper disclosure to my mind. I don't claim it's necessarily malicious. The explanation given in the git log makes sense, though there are better ways to accomplish the stated goal, such as replacing Google's tracking URLs with invalid ones. But leaving those changes in public releases of software supposed to increase privacy seems negligent.
- bigiain 11y ago
  FWIW, whatever Iridium might be doing with "phoned home" data, it's spectacularly unlikely they're capable of getting anything like the datamining utility out of it that an assumed-currently-doing-evil-Google could do. Google Analytics across 60% of the web, Adwords, the other end of a large proportion of my email content even if I don't use gmail (because it's sitting there in my correspondents Google hosted mailboxes) - Iridium don't have any of that to correlate my browser's behaviour with. And from a person assumed to have no privacy rights by the NSA (since I'm not an American citizen) there's some benefit of that phoned home data existing in a non US legal jurisdiction too... Even if you _don't_ assume Google is currently doing evil, we _do_ know they're subject to PRISM and NSLs...
- bigiain 11y ago
  I'll also mention that - in a completely unfair-to-you way - I just went and scanned through your comment history to see if I could quickly identify NSA shilling... Such is the nature of the discourse these days. Sorry. (Or, if you _are_ an NSA stooge, congratulation, you do a reasonable job of hiding it...)
  - socceroos 11y ago
    Hahaha, distrust goes both ways though! Suppose you're trying to coerce people into using this browser knowing that you've (NSA) already snuck in some backdoors? They used to say that you have to trust the compiler. But not even that is true these days. Perhaps you've read about the secret hdd partitions that the NSA were using. These days it goes like this: open-source hardware, open-source firmware, open-source compiler, open-source software. Only when an entity can follow this path to build their own trusted stack can we begin to move with high confidence.
    - bigiain 11y ago
      Even open source hardware isn't sufficient against an attacker as seriously resource rich (both cash and technical ability-wise) as the NSA. You can't trust the supply chain any more, you can't even trust the silicon unless you made it (and all the machines you used to make it) yourself. Are you _sure_ that network chip, usb controller, or flash ram you built your open source hardware out of isn't exploited? If you're on the fence about whether you're "too paranoid" or "not paranoid enough", make sure you've read what some people do for free, just for fun/curiosity/geek-cred/reputation: http://travisgoodspeed.blogspot.com.au/2012/07/emulating-usb-devices-with-python.html http://travisgoodspeed.blogspot.com.au/2012/07/emulating-usb... http://www.bunniestudios.com/blog/?p=3554 http://www.bunniestudios.com/blog/?p=3554 Then imagine what their grey-suited counterparts on 200K salaries at the NSA with (for all intents and purposes) unlimited research budgets might be up to.

damm 11y ago

All the links in that commit result into a 404; so if they are collecting data it's purely off of whatever they have output in the Access logs. Possible something in the future; or possibly something they could not neuter as easily as they would like?

jerf 11y ago

Have you verified that the browser actually phones home via network sniffing? If they have in fact successfully used that commit to remove all cases of phoning home, than it is an unfortunate oversight in the commit history of a browser that still doesn't ever phone home, and in practical terms, nothing more. If the code paths can not be reached, they can not be reached. Before somebody hops up, yes, I am as aware as the next guy that today's "path that can't be reached" is tomorrow's path that can, and yes, of course outright removal would be better. It's absolutely fair to raise an eyebrow and ask sharp, pointy questions under the circumstances. But it's not fair to say a browser "phones home" if in fact it doesn't.

TheLoneWolfling 11y ago
Have you seen the underhanded C contest? Even if it's not phoning home now (and I'll assume it isn't, in good faith), it's far too easy for a seemingly-trivial change later to enable it.
- jerf 11y ago
  People's ability to echo my own points back at me as if I somehow failed to consider them and they are somehow correcting me never ceases to amaze me.

geofft 11y ago

In the following commit, the IPv6 probe is changed from Google Public DNS's IPv6 address to that of iridiumbrowser.de: https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/commit/?id=f3f60d31d8997d68293461f81eebccf1af95f6a4 https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/commi... To be fair, that's a very tiny leak: it only indicates (maybe) that someone is running your browser at the source IPv6 address. But if it's tiny, it might as well continue going to Google Public DNS, since it's much more likely to get lost in the noise there (Google Public DNS probably gets a fair bit of IPv6 traffic from users, not to mention all the existing Chrome / Chromium users).

longsleep 11y ago

This is really great feedback. Reading this and the other comments makes clear that we need to improve documentation what and why we changed things. All the trk-xxx.iridiumbrowser.de hosts are there to find connections which we were not able to disable yet. All these end up at nothing (404 not found) and are not proxied in any way. Essentially Iridium browser should never contact them - if it does then it is a code path we have missed and a bug.

TheLoneWolfling 11y ago
Then replace them with a crash or popup ("Line <x> was reached but shouldn't be reachable. Please report this." or whatever) Phoning home without permission goes against the entire concept of a secure browser. Have you ever seen the underhanded C contests? There are far too many ways for something like this to turn nasty. Especially given there's inherent plausible deniability.