Slashdot Mirror
Bitdefender Disables Anti-Exploit Monitoring in Chrome After Google Policy Change (bleepingcomputer.com)
secwatcher shares a report: Last week we reported that Chrome has started displaying alerts more often that suggest users remove programs that are considered incompatible applications with Chrome because they inject code into the browser's processes. These alerts are displayed by Chrome after the browser crashes and suggest the user remove the listed programs because "this application could prevent Chrome from working properly." One of the programs that a lot of users have seen listed in these alerts and is suggested to be removed is the Bitdefender antivirus program as shown above. Having a well known company like Google telling users to remove a security solution is a problem as these programs are important for many users to have installed on their computers in order to protect them from malware, unwanted programs, and malicious websites. Due to these alerts and their suggestion to remove the antivirus software, Bogdan Botezatu, a senior e-threat analyst for Bitdefender, has told Bleeping Computer that as of August 20th, Bitdefender is no longer monitoring Chrome 66 and later with their anti-exploit technology.
This is actually good news. It means your antivirus is not MitM-ing all your web traffic and downgrading HTTPS connections.
Good, the security solutions vendors will finally learn how to do their job without creating more security holes than they're trying to block.
Using anti-virus like Bitdefender is rather like paying a rude thug to live in your house, eat all your food, and hog the TV just to ensure a burglar doesn't break in.
From treating perfectly good encryption algorithms as 'not good enough and warn the user immediately even though it's still perfectly safe', even though Google's own keys use the same algorithm but don't trigger a warning, to trying to freak the user out about 'this totally static site that doesn't use HTTPS must be insecure even though you can't submit info to it because it's totally static', Chrome has become the worst browser to use by a company throwing its weight around like a bully to get everything done its way.
AC comments get piped to
Google is starting to sound like Microsoft. "We own your computer, not you, you should do as we say when we say to do it because we say so".
In this case BitDefender is the bad guy. Broadcast-injecting DLLs into processes is *not* safe, and is how Google is able to say what to uninstall. If they did their code-injection correctly there wouldn't be as much issue.
If you replace "tv" with "couch", and add "lick your face with the same tongue that just slobbered over a rotting bird wing she found in the bushes" you'll have perfectly described my dog.
... a senior e-threat analyst for Bitdefender ... [said that] ... Bitdefender is no longer monitoring Chrome 66 and later with their anti-exploit technology.
I entirely understand their chagrin -- but this response might be a mistake. For an anti-virus/anti-malware package to blatantly state that they're not monitoring a browser, just because the makers of that browser are getting a bit paranoid about plugins (rightfully so, mind you) ... yeah, that's not going to sit well with a lot of people. Some people will blame Google, and some will blame Bitdefender... and both will lose face to some degree -- as well as lose users. Thing is, Google can afford to lose both of those to some degree, as they'll regain those numbers long before they run out of cash to throw at their reputation reparation PR folks.
Can Bitdefender afford that, though?
I nuked Bitdefender because at seemingly random intervals, it regards gcc++ as a hacking tool and quarantines parts of it. Good riddance.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Your pencil and your socks are not secured. You don't have any locks in your socks to keep other feet out. Anyone can use your pencil.
The reason they aren't secured is because there is no significant strong reason to do so. They aren't security sensitive. It's not that your pencil or your socks are INSECURE, they just are not secured because there is no reason to.
Similarly, a cat video isn't security sensitive. It's neither secure nor insecure.
This matters because if you get confused and start trying to secure your socks, pencils, and flower bushes, you won't have time and energy left to secure your security-sensitive items properly.
In my line of work, I see outdated TLS (SSL) configurations daily and have to tell the customer to update it. 80% of them are pointless - there is no reason for it to be TLS in the first place. If the admins weren't busy upgrading public marketing videos to eleptic curve cryptography, they might have time to update the security of the payment portal.
Sounds like you're confusing whitelisting with it's opposite, blacklisting.
Blacklisting says "this person isn't allowed to do this to that". Anyone can do anything, except for the listed blocks. Blacklisting has been outdated for 20 years.
Whitelisting says "only this person can do this thing to that". Nobody can do anything unless they have been explicitly approved. Whitelisting is fundamentally the most secure approach you can ever have.
For public resources, including accessing the public internet, the right approach is generally much more complex, a matrix of different parameters.
If they did their code-injection correctly there wouldn't be as much issue.
Is there even a "correctly" in Chrome's extension API?
Many routers, printers, and network attached storage (NAS) boxes for home use offer a web-based configuration interface. If someone buys one of these devices, where should he or she obtain a TLS certificate to use with said device in order to suppress "Not Secure" messages in web browsers?
Let's Encrypt and other publicly trusted CAs won't issue a certificate for a private IP or a name in a made-up TLD, such as .internal or .test. It has to be a real domain. Nor do all dynamic DNS providers offer enough features to pass an ACME dns-01 challenge, namely being on the Public Suffix List and supporting TXT records.
Or should it be the device manufacturer's responsibility to issue a name under the manufacturer's domain and resell a certificate from a known CA, the way Plex does? If so, watch the manufacturer set the certificate's expiry the same as that of the warranty on the device, so that the user has to re-buy hardware in order to renew the certificate. Nor do I see how that would apply to a home-built server made out of a Raspberry Pi or Intel NUC.
Store your data at home on your own hardware.
That has a few drawbacks. First, it does nothing to protect the data from fire, flood, or another disaster that renders electronics in your home inoperable. Second, many home ISPs ban running a server at home or block incoming connections or both, as do their direct competitors in the same geographic market (if any even exist). Third, if your dynamic DNS provider isn't on the Public Suffix List or doesn't support TXT records, you still have to buy a domain and keep it renewed in order to qualify for a Let's Encrypt certificate for your home server.
USB flash drives come in gigantic capacities these days. So do SSDs.
Colocation facilities in which to store and access USB flash drives and SSDs offsite aren't quite as cheap.
to trying to freak the user out about 'this totally static site that doesn't use HTTPS must be insecure even though you can't submit info to it because it's totally static'
The sentiment that Chrome is trying to get across in that case is "Chrome cannot guarantee that your Internet service provider has refrained from injecting malicious JavaScript code into the static site that you are viewing." Xfinity by Comcast, for example, has been caught doing this. What would be a better way to express this in a manner short enough to fit in the location bar?
That's art.
AV vendors inject DLLs into browser processes and monkeypatch browser machine code in crazy ways to monitor browser activity. Predictably, this has created all kinds of problems. It's common for browser updates to invalidate some assumption made by the AV developers, causing frequent browser crashes. It's also common for the AV hooks to have terrible performance properties. It's also common for the AV code to introduce security vulnerabilities.
AV vendors know that when the browser crashes or is slow, users will inevitably blame the browser, not the AV vendor, because the AV software is not visible when the problem occurs. Thus, they have few incentives to fix their issues.
A few concrete examples from Firefox:
* For a long time an AV vendor injected ASLR-disabled DLLs into Firefox, making browser exploits much easier.
* An AV application parsed Firefox DLLs to find the right places to apply patches. Their PE-format DLL parser had bugs; a small and completely legal change to a Firefox DLL triggered a parser bug, causing the AV patch to be applied at the wrong place, i.e. randomly corrupting Firefox code.
* An AV application patched Firefox code, obtained a pointer to a Firefox object, and started using it on another thread. That object was only safe to use on the main thread. Result: random crashes.
Of course people argue that all AV vendors shouldn't be tarred with the same brush. But no-one agrees on who that mythical "good" AV vendor is.
auto backup of photos as I take them on my phone. Let's start there. I don't have to worry about syncing my phone when I get home to protect my vacation trip photos. I don't have to worry about dropping my phone off the boat and losing the days photos. I don't have to worry about how much storage I've got left. That's what google has.