Comment by kryten | Hacker News Reader

Comment by kryten | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com