Jump to content

m0unds

Member
  • Posts

    138
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by m0unds

  1. tbh, i think this is more a pitfall of convicting an entire domain/subdomain vs specific path than anything else. i've run into enough weird FPs in shared envs (multiple platforms, AWS/S3/cloudfront, backblaze b2, numerous other providers) that i don't even bother submitting them anymore.
  2. seeing as they track & merge the majority of Mozilla's security code changes in Firefox, I wouldn't count on them continuing to allow code injection if Firefox ends up blocking it in the next few mos.
  3. that's what google would prefer, yes. browser mfgs would prefer third parties stop injecting code into their processes - you already can't do it with edge because of appcontainer isolation, and google and others are tired of being blamed for every browser crash that could be caused by third party code they have no control over. additionally, there are instances where code injection can unintentionally compromise browser security. re: hosts stuff, i would avoid writing large lists to your hosts file as it will significantly slow DNS queries as system has to examine it first. @Ken1943 - as i mentioned, other browsers using chromium (open source project) are merging in the same changes being made to chrome, as is mozilla with firefox (q4 2018 / q1 2019) so this is not purely a "google wants to know everything" concern.
  4. that's fun. firefox doesn't block code injection yet, but it's on their roadmap for q4 2018/q1 2019. i'd also expect opera to start doing it if they merge upstream changes from chromium. *EDIT* Opera is tracking Chromium 69 for Opera 56, and Vivaldi is tracking Chromium 69 for Vivaldi 2.x.
  5. make that two requests - it'd be a nice QoL improvement, imo
  6. Same here, connection error in SW USA
  7. that's great and all, but appcontainer lockdown still breaks EAM's surf protection.
  8. I'm not the OP, but I didn't want to start a new thread, as this one already exists: Is this something you guys are going to be able to work around? Surf Protection still isn't working with Edge on my system (and I can reproduce the issue w/AppContainer lockdown and Chrome as well).
  9. yea, BD's name for it is strange. it's a banker/dropper trojan (fareit family)
  10. will your filtering be further impacted when the chromium project (and chrome by extension) start blocking third party code injection altogether?
  11. Seems to me like it might be a bug with isthisfilesafe.com
  12. yea, DNS cache poisoning is increasingly rare because common DNS servers like bind, unbound, etc. do it by default
  13. Yup, you're correct. OpenDNS has limited malicious/bad site blocking (they focus on long-lived stuff like botnets) and phishing protection. Quad9 uses a bunch of vendors' threat intelligence feeds to block malicious and phishing sites. Comodo is vague, but claim they use RBLs. They aren't RFC-compliant with regard to DNS TTLs. No idea whether they redirect on NXDOMAIN (I don't trust Comodo as a company, so I haven't used this svc) Norton uses their own threat intelligence feeds to block phishing, malicious sites, etc, but last I checked, they redirect instead of returning NXDOMAIN, and partner with ask.com for that monetization stuff (yuck).
  14. Quad 9 is another good option w/malicious site blocking, but they're still working out some routing quirks in certain regions (Oceania, Eastern Europe, South America)
  15. Seems like it's this blocklist: https://iplists.firehol.org/?ipset=bbcan177_ms1 this particular list hasn't been touched since january 8, 2018 - not like stuff on the internet changes all that often, right? imo, a lot of these user-submitted lists are junk and are really poorly maintained - this particular list includes IP ranges belonging to CDNs used by a ton of reputable services including github (and emsisoft, and any other customer of highwinds). maybe that's why the maintainer hasn't updated - he can't push his changes to the git repo
  16. looks like you might be on an older product build. this is what the current one looks like:
  17. in "view" dropdown, under "components", untick "select all", tick "scanner"
  18. Sure thing - I took two screenshots and put them both on the same image:
  19. No issue observed with Norton, Webroot or ESET products on systems with the fall creators update. Each machine with any of the aforementioned products shows a green check mark and Windows Defender Security Center indicates "no actions needed".
  20. yea, there must be a setting because I only have FF for testing and it's always up-to-date on launch. in task scheduler on my system (win10), it shows next run/last run and last exec status (successful, etc) - last execution in my case coincided w/system boot. looks like the task parameters for one are "at logon" and "at 19:09 daily", second task fires at 19:09 and executes hourly for one day then stops.
  21. I was asking because if Opera is like Chrome or Firefox or lots of other browsers, it has a silent automatic update process that launches when the machine starts, and can update the browser regardless of whether you're actively using it. The folder hierarchy reminds me of Chrome (version # in the path) and it would make sense if it had updated, and the version change removed the old folder, causing EAM to remove the rule because it no longer applies.
  22. Did opera happen to auto-update before eam deleted the application rule?
  23. Yep, that's how I run the product, however in the case of this particular file: See screenshot below
×
×
  • Create New...