He/she is mentioning that an obtained client can always be hacked, no matter what, and the reader of the original comment may not realize that.

> He/she is mentioning that an obtained client can always be hacked, no matter what, and the reader of the original comment may not realize that.

That pointless remark misses the whole point. Even though ideally an attack vector would be eliminated, it's already good enough if it becomes unexploitable by the vast majority of potential attackers. That's why there is a whole field called "app hardening" as in a sliding scale instead of "perfect app protection".

I think the vast majority of HN users would realize that. Is it important for the few that don’t? Perhaps

The original commenter clearly didn't understand it, since they asserted that "statically linked libraries prevent this attack vector".

Which is unambiguously not the case, they merely slow it down by a small margin.

It's a true statement; LD_PRELOAD cannot be used with statically linked binaries. You can "fiddle" in other ways, but not by using the LD_PRELOAD attack vector (although personally I wouldn't call it an "attack vector", although in some cases it could be where you can upload a malicious file and control the environment of another program somehow, or something along those lines).

>Which is unambiguously not the case, they merely slow it down by a small margin.

When you are using shared libaries, it is fairly trivial to hook into the library calls and replace them with whatever you want. When you are using static libraries, the linker and optimizer could for example inline the machine code directly in the application code. What tools do you have to do similar tricks with statically compiled binaries?

messing with executable binaries is undoubtedly harder but not impossible.

LD_PRELOAD is the specific attack vector that is prevented by static linking. They made no claim that static linking prevents all forms of tampering.