The "well you trust your AV with your computer anyway, you should trust it with this" argument is a terrible one. It's not about trust. It's about decreasing fo

The "well you trust your AV with your computer anyway, you should trust it with this" argument is a terrible one. It's not about trust. It's about decreasing footprint. ESET had a pretty big security vulnerability over the summer. As seen in this post, Avast isn't properly validating certificates. AV providers aren't bug free by any stretch of the imagination. Granted, browsers and OSes have their own vulnerabilities. At the end of the day, though, the fewer people that touch your encrypted communications, the better. Every time there's some hack or workaround or other vulnerability, the number of devices affected increases substantially. _This isn't okay._ Especially for a security vendor. Security should be done the right way, every time, period. Taking advantage of hacks or workarounds or other unsupported ways of intercepting data (e.g., MITMing HTTPS traffic with a self-signed cert) exposes users to risk. Not to mention, browser or OS vendors might close those loopholes in the future and break the security software. This is like saying, "I'll protect your car from carjackers. Just replace all your door locks with these ones." How much do you trust the security provider to not use the same key twice? How much do you trust that they're properly checking which key is the correct key? How much do you trust them that their proprietary black-box locks work as advertised? Do you trust them more than your car manufacturer? Do you trust that they aren't going to be vulnerable to a malicious key fob? That said, if encrypted traffic is a blind spot for AV vendors, they should be working with browser vendors to make sure proper, secure APIs exist to get around those limitations. Hacky workarounds are not the answer.