开云体育

Joe,

I've been using AVG for over since 2003 and have NOT had 'meltdowns' nor
have I had programs arbitrarily deleted without the program notifying me
before it did anything. ? Of course, I made sure that I had the program
settings setup to notify me before any actions are taken, so YMMV.

As far as Norton ... totally agree.

As far as Defender ... I see more issues with that program removing
executables without any advance notice than any other AV program, not
only here, but with other programs which have a small user base.

Neil, KN3ILZ

On 4/12/2020 4:50 PM, Joe Subich, W4TV wrote:
>
> I also agree with Gil.? The Windows anti-malware has given me far
> less problems than either Norton or AVG - both of which have been
> banned from my systems after resulting in major melt downs *MULTIPLE*
> times.
>
> The recent issue with Defender quarantining Commander was entirely
> my own fault for not excluding the DXLab Suite folder from Defender
> scanning.? However in my defense, I have been using Defender since
> it was introduced and this is the first false positive I have
> encountered.? As the recovery was relatively painless (as documented
> here): </g/DXLab/message/192460>, I consider this
> recent false positive to be a learning experience (and reminder to
> always exclude the folders of trusted applications like DXLab Suite
> and JtAlert).
>
> In the future, I will add the folders of "niche" applications to
> Defender's exclusions once I have evaluated them and decided to add
> them to my roster of "production" software.
>
> 73,
>
> ?? ... Joe, W4TV
>
>
> On 2020-04-12 2:34 PM, Gilbert Baron W0MN wrote:
>> I have to agree but I doubt there is an anti malware application in
>> existence that would not be susceptible to this problem and since
>> defender has only given me this one problem over the years I will
>> stick with it. Free and for the most part as effective as any
>> antivirus can be. I think not running as an admin and effective
>> backups are the real protection even though they are a real pain at
>> times.
>>
>> Outlook Laptop Gil W0MN
>> Hierro candente, batir de repente
>> 44.08226N 92.51265W EN34rb
>>
>> -----Original Message-----
>> From: [email protected] <[email protected]> On Behalf Of Dave AA6YQ
>> Sent: Sunday, April 12, 2020 13:02
>> To: [email protected]
>> Subject: Re: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus
>> / Anti-Malware Solutions like Defender etc...
>>
>> Regarding the lengthy post from Max NG7M appended below,
>>
>> 1. Windows is vulnerable to malware because it fails to implement
>> well-known operating system security measures; correcting this
>> architectural defect would break many existing Windows applications,
>> some of which can no longer be updated because their source code or
>> unique development tools no longer exist. Microsoft has chosen to
>> live with this defect and mitigate it with anti-malware applications,
>> which are provided by many software companies and Microsoft itself.
>>
>> 2. During Microsoft's two unsuccessful attempts to recruit me (once
>> to lead the Visual Studio organization, once to lead the Windows
>> Mobile organization), I interviewed with several senior Windows
>> developers and executives. They acknowledged that "protected folders"
>> and "User Account Control" (UAC) provide little actual security
>> value; these mechanisms were introduced to visibly demonstrate that
>> Microsoft was taking security concerns seriously. "Oh, so you want a
>> secure operating system, do you?" one of them joked.
>>
>> 3. There is no evidence that installing DXLab applications in
>>
>> c:\Program Files
>>
>> or digitally signing them would protect them from mis-identification
>> by Microsoft anti-malware applications.
>>
>> 4. Since there is no malware in any DXLab application, Microsoft
>> anti-malware applications that identify them as malware are by
>> definition defective. If you chose to use a defective anti-malware
>> application, enable it to autonomously upgrade itself, and enable it
>> to autonomously quarantine applications it considers malware, then
>> you should not be surprised when one of you applications suddenly
>> stops working.
>>
>> 5. Microsoft's "solution" to their defective anti-malware is to
>> accept submissions of executables incorrectly identified as malware
>> for reconsideration. Over the past several days, multiple attempts to
>> submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the
>> Microsoft submission site was evidently over-subscribed. Last night,?
>> the submission site took less than a minute to accept Commander's
>> executable; today, the submission status shows "not malware". How
>> long it will take for this updated determination to reach deployed
>> instances of Windows Defender is anybody's guess. Will this stop the
>> next public version of Commander from being mis-identifed as malware?
>> Unknown.
>>
>> My inclination at this point is to add Microsoft anti-malware to the
>> list of applications that can interfere with DXLab applications in
>>
>> <>
>>
>> Control your computing environment, or it will control you.
>>
>> ??????? 73,
>>
>> ?????????????? Dave, AA6YQ
>>
>>
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of Max NG7M
>> Sent: Sunday, April 12, 2020 11:53 AM
>> To: [email protected]
>> Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus /
>> Anti-Malware Solutions like Defender etc...
>>
>> As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti
>> Virus / Anti Malware solutions (MS Defender in this case) have
>> reached a new rhetorical level in regards to DXLab applications /
>> exe's. (based on the number of posts)
>>
>> First off, I'm not suggesting Dave AA6YQ change anything at this
>> point because the effort would be rather high and the migration of
>> currently installed application exe's to the proper location for a
>> modern day operating system bring a level of complexity along with
>> the change... installer changes and proper use of User Access Control
>> (UAC) would be required along with changes to the installer code used
>> by DXLab (digital signing of exe code etc...).? So I'm happy with the
>> way things are and I know that I need to exclude the directory where
>> DXLab applications are installed in my Anti Virus software.? So let
>> me make that clear, I'm not complaining or suggesting that Dave do
>> anything to address why this topic keeps coming up over and over and
>> over and over and over again. Well, other than repeating the current
>> solution and referring users to how you need to exclude the DXLab
>> installation path from your anti-virus / anti-malware solution. The
>> bitching and complaining about controls that are put in place to
>> protect you and other users in what is in effect a shared network
>> (the Internet) is rather comical at this point.
>>
>> If you want to know why DXLab executables are getting identified as
>> having problems, the problem is not Windows Defender or any other
>> anti-virus / malware solution.? Identifying Defender as the problem,
>> just exposes your ignorance around this topic. In a nut shell, the
>> problem is where the exe's (any any other executable code like dll's)
>> for DXLab are getting installed along with the fact that the exe's
>> are not digitally signed.? If you don't agree, ask a software
>> engineer who has been coding and helping release commercial Windows
>> exe based (rich client) applications for over 30 years.? And it helps
>> if the engineer you are asking has had extensive experience related
>> to using industry standard practices which are designed to help users
>> keep their computers safe. Your lack of understanding about bad
>> actors out there that are trying to exploit executable code and at
>> what OS level this code can execute, is not helpful to the
>> discussion.? Stop acting like you are a 'safe computing expert' when
>> you are not one... especially when you are disparaging solutions that
>> have been put in place to protect you and others despite your own
>> stupidity.
>>
>> So for DXLab users at this stage of the game... which I am one of
>> them and very happy with the amazing job Dave has and continues to do
>> an amazing job with this free software offering!? I'm perfectly happy
>> excluding the default directory location where DXLab exe's are
>> installed from my anti-virus software solution as an exclusion.? I'm
>> trusting Dave to not deliver exe based code that is malicious. And
>> even if it pains me so, I'm letting the DXLab installation process
>> install this executable code (that is not digitally signed) in a
>> read/write location.
>>
>> If you are happy with what you have and have excluded your DXLab
>> installation path from your anti-virus / malware solution's scans,
>> then you can stop reading now... or you probably never made it this
>> far anyway.? If you want more of the details as to what the industry
>> standard has been for decades now, keep reading.? DXLab has been
>> around so long, it may be hard for Dave to justify a big change (and
>> personal expense to digitally sign things) at this point.? I total
>> get that as I have stated above. However, when other users spew out
>> fear, uncertainty and doubt regarding this topic, they should be
>> corrected and their ignorance should be exposed.
>>
>> Solutions like Windows Defender (a darn good free solution) are
>> designed to protect you despite your, ignorance and laziness. You can
>> give someone a Twenty Dollar Bill for free and then based on their
>> ignorance, they will complain that you didn't give them two Ten
>> Dollar Bills.
>>
>> For decades now, the industry and creators of commercial operating
>> systems in use in business and at home have tried and tried to make
>> commercial and home computing safer. Linux / Unix based OS's and even
>> MS Windows (make your silly evil sounds and wiggle your fingers in
>> the air), have been trying to get software developers to locate
>> executable code in a OS level protected directory structure.? i.e.
>> for Linux it would be /bin, or /usr/bin etc... for Windows it would
>> be C:\Program Files (x86) for 32bit executables, and or C:\Program
>> Files for 64bit executables.? Constrains are put in place to protect
>> the executable code in these directories using an OS level of User
>> Access Control to keep code from executing at a 'root' level or
>> administrator level (in the case of windows) where bad / malicious
>> code could do all kinds of bad things... install key loggers to steal
>> you passwords, or execute code to encrypt all your data and hold you
>> hostage to ransomware schemes.? Or just help use your computing power
>> and network bandwidth to jump start other evil bad things without you
>> even knowing day after day and week after week.
>>
>> For the above reasons and many others not even listed, modern OS's
>> and their designers do all they can to try and get software installed
>> into protected areas of the file system and to only be run at levels
>> where other bad code can't do bad things without you knowing.? Is it
>> perfect?? nope but it's better than nothing and it's better than just
>> burying your head in the sand and turning off all the protection.
>>
>> So what is a Mother to do?? The best practices which have been in
>> place for decades now (and are not enforced with a draconian solution
>> yet) are to install executable code in protected directories like,
>> you guessed it: C:\Program Files etc... AND to locate application
>> down a path specific to data like c:\Documents\YourUserName where
>> read write access to data is based on user privilege's.?? AND in the
>> case of executable data you digitally sign your executable code with
>> a signature that can be verified by a known good certificate
>> authority. (do a google search on PKI infrastructure if you want to
>> learn more) this is what virus scanning software is looking at when
>> it scan for issues.? If the exe code of application A is properly
>> signed and in the proper directories, then it's less likely to report
>> a false positive. (yes a pretty simple description of what is going on)
>>
>> Older software that has been around for a long time gets a bit of a
>> pass on the above, but users are still required to know what is going
>> on when they trust this software.? DXLab applications fall into this
>> category.? Exclude the installation paths from virus scan's / malware
>> scans.? It's just the way it is right now, and only Dave can decide
>> if the effort and cost is worth it to revamp the install locations
>> and incur the cost of executable code signing into his build routines
>> of the VB application in question, not to mention move all the
>> read/write data to User/Document paths and deal with UAC.? The arm
>> flailing and weeping and wailing and gnashing of teeth from existing
>> users of an amazing and free application, would reach an exponential
>> level if they had to move their data around etc.... even if automated
>> in the installer.? I shudder at the flood of questions if this change
>> were made and I'm guessing Dave would fear the same thing on the
>> list here.? I certainly don't speak for Dave at all.
>>
>> An example of another amazing and free Ham related application that
>> has adopted most if not all of the above standards is N1MM Logger+.?
>> Multiple developers in this case are coding on the N1MM project. N1MM
>> Logger+ exe's are signed (see the link at the end of this post) and
>> N1MM's installer tries to get you to install the exe's down the
>> proper path in a Windows operating system.? However, as we all
>> know... you can override all of this and in effect disable all the
>> efforts to try and protect you from yourself.? But there is a cost
>> here... time, money and laborious education.? And this requires
>> dealing with a new set of questions from uninformed users.
>>
>> So, at the end of the day... DXLab users need to understand the
>> current state of how DXLab is coded and how and where it is installed
>> and understand that the exe's are not signed.? It's okay if you
>> understand that Dave clearly isn't out to deliver malicious code, but
>> DXLab, like many other older exe based applications install into a
>> directory structure that violates current best practices in the
>> software industry.? It's just the nature of the technical debt
>> incurred with an older application that has been around for a long
>> time. Again, I'm not suggesting Dave stop the train and crack this
>> nut.? We get the benefit of using DXLab which is an amazing suite of
>> applications written by one super human developer and we just need to
>> understand that the legacy nature of the installation and location of
>> the data and exe's will make it suspect for industry standard virus
>> scanning / malware scanning / bad actor detection software. Stop
>> blaming Windows and modern virus / malware scanning / detection
>> solutions and start understanding and why things were created they
>> way they are.
>>
>> In the ending of this massive diatribe of mine, executable code on a
>> modern OS needs to be installed in OS / UAC locations and the exe
>> code needs to be signed.? Data needs to be installed in OS / UAC
>> controlled locations where read/write is possible for the processes
>> that need access to this data.? And all executable code should be
>> signed with a known digital certificate that is trusted by a known
>> certificate authority so you a user knows where the code comes from
>> in the first place.? Is it all 100% fool proof?? Nope, but it's
>> better to understand how things work rather than spewing out the
>> continued FUD around this ongoing topic.
>>
>> Image showing the digital signature on the main N1MM exe
>> <>
>>
>>
>> Max NG7M
>>
>>
>>
>>
>>
>>
>>
>
>
>

--
This email has been checked for viruses by AVG.