I don't think the comment by wfh is saying that it's not possible to prevent these hooks. In fact, wfh is saying the opposite, i.e. that they already have the m

I don't think the comment by wfh is saying that it's not possible to prevent these hooks. In fact, wfh is saying the opposite, i.e. that they already have the mitigation in place, but cannot enable it because there are legitimate use cases for hooking/injection, and users who use programs that depend on these techniques would be (rightly) upset if Chrome unilaterally decided to block all such use cases. The comment is lamenting the fact that the author of the blog post is creating yet more such use cases and will make it even harder for Chrome to ever enable the feature to prevent code injection.