cvvorous

Any update on this?

do you need the extension/plugin and the local agent to whitelist, or just the extension?

My mistake - it looks like they actually just released a new stable version and browser extension last week - https://app-updates.agilebits.com/product_history/OPW4- I completely forgot that my PC was following their beta release cadence because of new features vs the old stable version from February.

They have a ton of users on OSX. 1password on Windows is currently in beta and is frequently updated. The agent itself is sometimes updated several times per week.

Just these:

Did you see the two screenshots I added? It's set to "disable permanently". This is following a fresh install after running the ESET uninstaller, as the regular uninstall of *.349 borked the network adapters on my notebook. I tried toggling banking protection on and back off again (again, setting it to disable permanently), and it shows the red exclamation point again. I figured it was a change in the newer build, as I didn't have any trouble with the old one. I suppose I could try removing it and reinstalling again, since something must be messed up if it's not supposed to be doing that.

Uhh, no, protocol filtering is enabled/set to default. The only product functionality disabled that is usually enabled is banking protection. The "security tools" part of the UI that I mentioned encompasses banking protection, parental controls and anti-theft. The only one of those three options on by default is banking protection, and I have it turned off. Anti-theft and parental controls are off because I don't need or want either.

Is there any chance we might be given the ability to fully ignore the status of "security tools" in ESS? In build *.349.0, if you turned off banking protection and completely ignored its status, it was like it didn't exist. In *.375.0, however, I can ignore individual tool statuses, but in the case of baking protection, it signals in the UI that "required security tools aren't enabled" - If I go through the trouble to turn off banking protection, AND set ESS to ignore that it's turned off, why would I also want a persistent red "!" to remind me of that fact? I'd leave it on if it wasn't so flaky and if it supported password managers (I saw a mention in another thread that some have been whitelisted if you have prerelease updates enabled, but when I tried it, Dashlane still wasn't whitelisted). The way I would have expected this to work: Turn off banking protection > Product informs that it's turned off w/signalling of some sort (which it does) Ignore status of banking protection in UI elements / application statuses > product doesn't bother me about it in any way (it doesn't, it shows a red "!" on the setup UI element) Thanks

It's not possible. Only ESET can whitelist trusted add-ons. Is Dashlane supported? *EDIT* tried it, and it doesn't work when using the dashlane install URL their application provides (uses the chrome store to install it). Would be cool if ESET would consider vetting it and approving it, as not having a working PWM in payment protection is part of why I turn it off. (well, that and it regularly fails to detect banking sites half the time)

yeah, problem is that it's also prompting windows subsystems running when i engage properties dialogs and stuff as well

Yeah, that's how I had defined my rule and was receiving way more prompts than just on-exe (which is what I selected in my application operations) - Seems like the behavior is a little different than it was with ESS8. Guess I'll just live without the extra ruleset as I despise being prompted repeatedly. Thanks for the feedback though!

Hi, I had a simple HIPS rule on ESS8 that would prompt me for confirmation when launching an executable from my downloads folder. It was something like: application started from downloads folder > ask. It wouldn't ask on file properties inspection or for anything aside from executing an application from that folder. With ESS9, I'm having a hard time getting the HIPS to not spam me when Windows subsystems access files for properties dialogs, or any other trivial operation. Am I missing something?

FWIW, I found that the issue with protected Chrome not loading appeared (at least in my case) to be due to "allow Chrome to run in the background" being enabled by default. After I turned that off, it worked every time.

In my experience, messing with SSL can cause stuff to flake out. I had recurring problems w/Chrome when SSL scanning is enabled causing protocol errors left and right (due to SDCH issues). I gave up on trying to use it after a few module updates that were supposed to fix it didn't help.

It seems like this has fixed the issue. I'll keep trying to break it, but I haven't had any encoding errors yet. I do still have to exclude the google drive client from protocol filtering in order for it to connect with SSL scanning enabled, but I don't think that's related to the issue with Chrome (it works if I disable blocking older SSL versions, so it seems like there might be something wrong w/the client itself and not ESS.) Thank you. *EDIT* Actually, I've encountered a new error a few times since I posted this reply - the page fails to load, and Chrome indicates an "SSL_PROTOCOL_ERROR". Reloading the page sometimes fixes it.

fair enough

https://en.wikipedia.org/wiki/HTTP_compression It seems as this were also bug in Privoxy (a proxy which also filters web traffic) and as it was caused by a problem how it handles HTTP compressions. This could be a similar problem in ESS too. About the commando line parameter of Chrome: Normally it should work. Can you try it with --enable-sdch=never_enabled_sdch_for_any_domain? I mentioned I already tried the switch and it didn't change anything

Sure: Google Chrome 40.0.2214.115 (Official Build) m Revision 831713c5c90271926c2ca70afaa969d32e4576f5-refs/branch-heads/2214@{#490} OS Windows Blink 537.36 (@189787) JavaScript V8 3.30.33.16 Flash 16.0.0.305 User Agent Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --no-startup-window --flag-switches-begin --disable-quic --manual-enhanced-bookmarks --flag-switches-end Executable Path C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

I might have nailed down what causes this. It seems to be related to google's use of SDCH protocol. Google doesn't advertise SDCH on the first query, but will on subsequent search queries. I'm guessing this is why I can typically manage one search before I start getting content decoding errors. To test, I set up a local proxy and had it scrub out SDCH from "Accept-Encoding" headers, and that seems to have fixed the issue, however, it's not really a permanent solution. There's supposedly a Chrome command line flag that should only allow SDCH on domains set by the flag (e.g. --enable-sdch=eset.com), but it doesn't work.

It was for me. The alternative is to exclude chrome from protocol filtering altogether, which I don't think is an acceptable solution. I don't really think disabling SSL filtering is all that great either, but as I mentioned, doing "stuff" to SSL traffic can cause issues, so I'm not upset about it.

Hi, I installed the new module and confirmed it via the "About" menu. I'm still experiencing the issue with content decoding errors and google search. At this point, I think I'll just give up on enabling SSL protocol filtering. It seems like this issue is an ongoing thing (threads on this board and others, including posts dating back to Chrome 33.x with the same issue when SSL filtering is enabled in ESS). I know doing things to SSL traffic can cause weird stuff to happen. Thanks for the assistance.

Thanks

Would the OS version have any impact on whether you'd be having issues? Both FrancoVP and I are on Windows 8.1 x64, not Win7. I've enabled pre-release updates and I'm updating now. I'll let you know if I still see the issue in question. *EDIT* I enabled pre-release updates and performed an update within the product UI and rebooted after. The signature version is showing 11123P, but I didn't receive a new internet protection module (still on Internet protection module: 1165B (20141128)). Did I need to do something else, aside from enabling pre-release updates in ESS? Also, I think I figured out a way to cause the decoding error w/SSL filtering enabled- go to google.com in Chrome Begin typing a query in the search box on the site. Instant should immediately attempt to display search results. In my case, I get an error about instant being unavailable. If I then press enter or click the search icon, I get the decoding error immediately.

Yep, still borked w/pre-release updates enabled. Guess I'll just leave it disabled til the updated module is released.

And that's a really strange thing, because I highly doubt that Google Drive would be using SSL v2. Does ESS shows any (SSL-related) message when it blocks this? Hi, Yes, I've tried all of the following: - With all browsers closed, enable SSL protocol scanning. Stuff randomly fails to connect via SSL in Chrome. - With all browsers closed, enable SSL protocol scanning and reboot. After booting, stuff randomly fails to connect via SSL in Chrome. - With all browsers closed, disable SSL protocol scanning, reboot, re-enable it with browsers closed. Same issue. The error message in Chrome is: ERR_CONTENT_DECODING_FAILED - it seems as if ESS is mangling SSL content and causing Chrome to error out. Re: the root certificate, it defaults to add it when you enable SSL protocol scanning, so that's how it's set. Add root cert, ask about validity and block on invalid/corrupt cert. Re: the drive client, it doesn't display any error messages or anything else. Drive just says it's unable to connect (even after rebooting) when SSL protocol scanning is enabled. If I turn it off, it immediately connects without error. With drive: Any of the combinations of actions listed above for enabling SSL scanning, including the "block SSLv2" option --> drive won't connect. Uncheck "block SSLv2" drive instantly connects. *EDIT* forgot to mention I also raised log verbosity to diagnostic to see if there was anything showing up in product logs when I experienced the issue with Chrome, but the only odd thing I saw was "ESET Live Grid request failed because of authentication" Thanks