Comment by skymt | Hacker News Reader

Comment by skymt | Hacker News Reader

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

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.

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.

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.

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.

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

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

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.

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

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.

I wholeheartedly agree, but that is what I meant by 'own trusted stack'. From the ground up (literally), you have to control each part of the process.

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.

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.

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.

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

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?

Reply on news.ycombinator.com