Much of this is borne out of not having source for code critical to your business. So, you inject patches.

This is within process access limits.

Non elevated process can't inject into elevated process. X user process can't inject into Y user process.

If user has access to process, they have very well access to modify by decompiling or reverse engineering it. Dynamic injection makes it much more seamless and less painful.

You'd be correct!

https://docs.microsoft.com/en-us/windows/win32/winstation/wi...

https://docs.microsoft.com/en-us/windows/win32/winstation/de...

https://docs.microsoft.com/en-us/windows/win32/procthread/pr...

https://docs.microsoft.com/en-us/windows/win32/procthread/th...

https://docs.microsoft.com/en-us/windows/win32/fileio/file-s...

Here https://news.ycombinator.com/item?id=31092978 suggests its not possible to prevent code injection aka system or app hooks. Preventing system and app hooks is very possible and the MS api's gve you all you need to block them, people just need to come up with innovative ways to deploy them!

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.

You can ptrace() on Linux as well, it just isn't as easy: https://blog.xpnsec.com/linux-process-injection-aka-injectin...