Hacker News Reader

Comment by cupcake-unicorn | Hacker News Reader

I actually never ended up switching to Chrome from Firefox in the first place, but those are still good tips. I guess I did the right thing :)

Yes, it has a terrible memory leak issue, but all of my computers have enough ram as to not notice.

I'm still not ready to make the switch to DuckDuckGo. I figure that if I'm going to stick with Gmail no matter what, if Google already has that information, collecting a few search queries is nothing.

Also, perhaps I'm missing something, but as far as I can tell Chrome is at least partially open source, no? http://www.chromium.org/developers/how-tos/get-the-code

Why aren't people forking it to create a more privacy friendly version?

View on HN

There aren't any memory leak issues in Firefox. I have been using Firefox since Firefox 10 and it has made huge strides in memory performance so much so that it beats every browser out there on memory benchmarks.

In fact, on the mac, with the same number (34) of tabs, the same content, no add-ons or extensions, Firefox takes 600MB - 800MB, Safari takes around 900MB-1GB and Chrome takes around 900-1.2GB. I use these browsers every day and I have the same results every day.

I have the same tabs open now in Firefox, all 34 of them and it's only taking 740MB. You just can't beat that. It's really awesome.

None of that points to the absence of memory leaks.

(I'm not saying Firefox has memory leaks. Though it's extremely unlikely it has none, same goes for Chrome and Safari)

  > Also, perhaps I'm missing something, but as far as I
  > can tell Chrome is at least partially open source, no?
  > http://www.chromium.org/developers/how-tos/get-the-code
  > 
  > Why aren't people forking it to create a more privacy
  > friendly version?

People citing privacy as a reason to move away from Chrome are doing so on moral rather than technical grounds. Chromium itself doesn't have anything harmful in it, so there's no point in forking. Chrome is just Chromium plus some third-party proprietary plugins (Flash, the PDF renderer).

Well you hope it is.

All sorts can happen between source and binary.

There's enough security researchers (of any hat color) crawling over the Chrome binaries that I'm fairly confident there are no backdoors being introduced. To verify, you could disassemble the Chrome binary and compare it against a disassembled Chromium binary that you built. You could also use a packet sniffer and/or MITM proxy to verify that no unexpected data transmissions are occurring.

That probably depends on your definition of ‘backdoors’. Some of the data Chrome sends to Google could easily be considered a breach of privacy (and the corresponding functionality hence supposedly doesn’t exist in Chromium).

I've never heard a claim that Chrome sends more data than Chromium. Do you have a link?

The Wikipedia page on Chromium[0] gives some differences, though my remark was admittedly mostly based on the description of the chromium package in Debian[1], which at least claims ‘usage tracking’ (and the generally useless and backdoor-like auto-updater).

[0] https://en.wikipedia.org/wiki/Chromium_(web_browser)#Differe...

[1] http://packages.debian.org/wheezy/chromium

That assumption relies on two uncertainties:

1. The probability of discovering something in all that binary code, especially with the intricate and non-orthogonal nature of x86/x64 assembly and odd compiler optimisations. This isn't some 80's game.

A comparison:

    28500000 = Chrome binary size [1]
   750000000 = Human Genome size (converted to bytes - 1BP = 2bits so 4BP per byte) [2]

So we're only 26x more complicated than Chrome and we have absolutely no fucking idea what is going on with us most of the time.

2. The probability of a vulnerability being published to Google versus selling it on the private market.

[1] http://neugierig.org/software/chromium/bloat/

[2] http://www.biostars.org/p/5514/

The actual comparison would be between the Chrome binary size and the Chromium binary size, which is quite small if you exclude embedded graphical resources.

Actually that's a really bad comparison.

The binary size may be similar but that doesn't mean the content is. Consider the two cases below to back up my assertion:

   000000WE_COME_IN_PEACE000000000000000000
   000000WE_COME_IN_PEACE_SHOOT_TO_KILL0000

I don't understand your point. If there were such a difference between Chromium and Chrome, then it would surely show up in a diff of the binaries' disassemblies. The size of the binaries doesn't matter, because (assuming you trust the Chromium source and your local system) only the difference between the two is relevant.

My point is that it will show up in a diff of the binaries.

Isn't that what I said?

I said that the binaries could be diffed, then you responded that finding a difference is unlikely because the binary is very large. I don't understand what the absolute size of the binaries has to do with being able to compare them.

> All sorts can happen between source and binary.

True. But also true of firefox. But you can install chromium and firefox from source and be sure that apart from your compiler nobody planted anything in your browser.

> terrible memory leak issue

I don't think this is as terrible as you think anymore (or if it is really even an issue anymore). The MemShrink[0] project has made huge progress. See also: https://areweslimyet.com/

[0] https://wiki.mozilla.org/Performance/MemShrink

Reply on news.ycombinator.com