Windows Security

[John Robin Dove]

Hi Clifton,

Windows Security has swung into action once again declaring that the file video-js.js is a dangerous Trojan horse.

I assume the file is one of yours or is it part of the TB system? Microsoft seems intent on purging all 3rd party software from its system. The technique is probably successful because it looks very plausible. Most users probably click on the button to remove the file from their computer permanently with dire consequences for us. I have had to add this warning to my download site. https://www.mediacours.com/downloads/downloadEN.html#security

John

[Clifton]

Obviously a false positive.
This is the first time I've seen a flag from Microsoft for a js file.
Make sure to check LZW compression during export. This may help mitigate this.
Regarding exe's that you create, make sure they are code signed by you with our without a certificate helps because your name and company is attached to the file. This may help keep security software from flagging your stuff.

[John Robin Dove]

I do this for all the Microsoft VS exes and I used to do it for AutoIt exes but the method I was using no longer seems to work. I'll have to have another look at it. But if Windows is now taregeting JS files will it make any difference? You can't sign a JS file can you?

[John Robin Dove]

I've just had a look at my exe files created with AutoIt and as it happens they all still have the original details attached. In fact surprisingly they seem to display slightly more information than yours. But maybe you sign yours 'officially'? So far I haven't handed any money over to anyone to get my work officially certified. I hope it won't be necessary.

[Clifton]

Some google searches on this topic indicate that Microsoft security has a bug which causes it to "sometimes" flag "some" .js files as malicious. Not all users report the same experience and behavior.
Nowadays, it is unwise to allow anti-virus software to run without intervention. Otherwise, these programs can really mess up an otherwise working computer

[Andy]

I am also seeing this. Besides the PGSD_PP_a.js and classes.js files, some of my page js files are also being flagged. I can find no pattern to it. For example, of several pages with identical logic and differing only in text content, only one of the js files is flagged. Furthermore, that file is often but not always flagged under each of the different target platforms.

I have actually had some success by turning *off* the LZW compression. I think I will next try to sign the troublesome files to see if that helps. Although I think it's technically possible to sign js files, I don't know if it would make a difference. But if it did help, I would want to sign every js file to protect it from some future "bug".

Clifford, my question on either of these possible solutions is how to patch the large body of content already installed. Is it feasible to remove the LZW compression from already-published js files? And if I go the signing route, I think the size increase will be less than uncompressing these files, but what will happen to the load times? I guess I'll do some experimenting to find out.

Clifford and John, if you know of another possiblilty I would appreciate your thoughts. I will likewise share what I find. Thanks, Andy

[Clifton]

Can you provide the path to the js files that are being flagged?

For example:
The PowerPac installation includes js files but they never get flagged. But if your flagged files are in your users/documents folder, then the secuity software may trigger an issue because generally such files are not assumed to exist in that location. I have ToolBook/PowerPac exports all over my system, but most all of these are in drives other than drive C where development files are kept.

I've also not had anyone indicate that files are being flagged or quarantined which are part of an installed application that contains js files. That application gets installed into the "Program Files (x86)" folder.

As a test, I let Windows Defender scan an external drive which contains hundreds of js files. Windows Defendee did not flag a single one. NONE were considered malicious. This leads me to think it is not so much the js files as it is the location of them on your system that makes Windows Defender hiccup. It this test case, there was a mix of LZW compressed js files and uncompressed ones.

As another test, I let Windows Defender scan the installation folder for the PowerPac (C:/Program Files (x86)/PGSD ToolBook Plugins/). Again, NO THREATS were detected. Both this and the prevous test were performed with normal Windows Defender settings.

I must admit, I then copied several ToolBook/PowerPac exports to the users/documents folder and then ran a scan. However, on my system the scan still says NO THREATS found.

It would be good to actually find the test scenario that triggers js files as being flagged as a threat. Any help you can provide certainly appreciated. If the real problem is with 3rd party anti-virus, then anything is possible as the scan results from such programs may be "all over the page."

[Andy]

Hi Clifton,
These files are in a directory structure of ToolBook modules and not in any of the Windows system locations. But I think I need to more thoroughly describe what I see instead of saying a file is "flagged".

This is on a Windows 10 PC with the standard Microsoft security, no third party. When the book is published, in the final processing after the pages have been built, I see a few messages from Windows Security saying that the Trojan was detected. The files remain in their directories and scanning them with Defender shows nothing.

If I launch the book from the publishing dialog, the files do get quarantined. If I instead zip up the file structure using 7zip for installation on my test server, again the files are quarantined. But if I use the Windows pkzip the files remain.

So I finally get all the files onto my test server. Now when I reach a page with a problem js file I get a 404 error, so the js file does not make it to the browser. This seems to happen with a PC (different than the one used to build) and Chromebook, so the file might be stopped on the server although I have not checked the log files.

As I mentioned earlier, removing the compression seems to solve the problem. I makes me think that the compressed files might accidentally match some signature used by the Security program.

Let me put together a small book that includes one of these problem pages. ~Andy

[Clifton]

As hard as I try, I cannot reproduce this behavior on any of my exports.

Currently, I'm working on an app that will install to a folder in "C:/Program Files (x86)/[install folder]"
As I develop this, I'm simulating the installation as I go and Windows Defender has no once popped up a message indicating a problem with any of the js files in the application. In addition, non of the files are being quarantined.

I know John is located in France. I'm not sure where you, Andy, are located. But I wonder if Windows security functions a little differently in other countries or geographies. Not sure why that would be the case, but I'm trying to figure out what makes my systems behave "as expected" and your systems generate messages and quarantine operations.

Of course, your comments will continue to be appreciated. I'm running Windows 10 2004 with latest updates installed.

[Andy]

Hi Clifton, I am in the US and have Windows 10 2004. I never was able to pare down the book to something that still showed the problem; it seemed to move from page to page on each build. However, I just installed the latest Windows Update that was downloaded overnight and now it builds without incident, just like it had before this past week. Makes me want to scream.
Anyway, thanks for looking into this for me. I hope Windows settles down for a while.
Regards, Andy