AV has to do what it does to inject itself between the internet and the browser because the browser provides no better way to work with it. If there was a better way and AV continued to do these things, complaining that AV is doing these things would be valid.

Those are separate issues: security experts would worry less about AV software hooking things if the AV developers were demonstrably following secure coding practices. Instead, they're generally shipping 90s-style C code and not following good practice like using sandboxing or other defense in depth measures, which is how you get things like a single exploit in a format decoder granting kernel access:

https://googleprojectzero.blogspot.com/2016/06/how-to-compro...

Contrast with the kind of exploit chains usually required on securely-designed systems like iOS or modern apps like Chrome where they need to chain multiple exploits together to escape from the sandbox before being able to attack something else. The AV industry has earned that bad reputation by generally being unwilling to spend the money needed to apply modern practice.

I think the premise is that broken AV doing nothing would be better than broken AV injecting itself into the browser.

So to get past that premise, you have to remove the "broken" part before the method of injection matters.

Yep, this is it. AV is fundamentally a security product. If my music player is insecure, it's still playing music and I'll lose that feature by uninstalling it. If my AV is insecure, there's really no downside to uninstalling it.

But to be very clear, the core complaint isn't the injection.

It's that AV - basically all AV - is buggy and insecure in totally unrelated, internal ways. It does shockingly dangerous and irresponsible things like leaving exposed debug frameworks on a program with kernel access.

So my concern about AV's browser injection isn't "they should interface better". It's "this is shamefully bad and dangerous software that I want to uninstall, so it should stay out of my browser". Fixing that isn't a problem for Chrome devs, it's about making a product safe enough to contemplate interfacing with. (There are a handful of AV contenders for that, and I don't object to them.)

I've hated AV products for decades for being intrusive, cumbersome, slow and often nagware. Thanks to this post, I can now add "insecure" to my list of reasons.

But I'm commenting to ask you to expand on

> "There are a handful of AV contenders for that."

Could you be pleaded to drop some names?

It is the injection preventing code checking. You are missing a majority of the point. Even if it 'worked' it still prevents a more elegant, efficient, and effective process of sandboxing and self checks.

The problem is there isn't a better way. A browser should be fully secure without needing some specific third party tool watching over its shoulder.

But let's say that you come up with some "deep hook" API that could give AV vendors a better way to look over the browser's shoulder. You can't provide the hook API and magically only hand it to trustworthy AV vendors: a "deep hook" API increases the overall API surface of the application and you have to treat it and secure it and maintain it like any other third-party accessible API, including assuming that it could be misused by untrustworthy third-parties.

A deep hook API would be wonderful for spyware.

The AV could do things better even without hooks. I don't know about ALSR, however dropping privileges when scanning a file that the user opened is pretty much a given in a security system.

The browser does this, the AV does not, so yeah, no AV devs seems to know about security.

I retract; you aren't deflecting the issue, you have no idea what the issue is.