New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows Defender VS. Squirrel apps #1204

Open
hatton opened this Issue Nov 15, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@hatton
Copy link

hatton commented Nov 15, 2017

We longtime squirrel users are by now used to telling users how to turn down their over-active third party antivirus products. Personally, I always tell them "just use Windows Defender already". Alas, no more.

A recent Windows Defender feature, "Controll Folder Access" (also known as "Controlled Folder Exploit Guard") is designed to stop ransom-ware from messing with your files. It seems to be opt-in for now, but to me it actually looks like a pretty good idea, something I'd turn on for my mom, at least. Except for one thing: it locks out our app from, you know, working with its own files. when this happens, there is no indication of the cause, no mention of Windows Defender, just... your program's File.Write will fail. If you don't see this coming, you have a huge support headache.

Once they somehow divine the cause, the user is supposed to whitelist their apps. Nevermind that my mom wouldn't have a clue how to find the app. The problem for squirrel apps is that you have to whitelist the specific exe, the name of which changes with each update. At least it does for us, but maybe we're behind.

We have mitigated this by checking for blocked write access to our own files on startup; we talk to the user about how to disable this otherwise helpful protection, or how to move their files somewhere non-protected. And we feel bad about it, like we did something wrong.

Has anyone else dealt with this in a better way?

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Nov 16, 2017

I don't know any way to deal with this, ClickOnce apps will be hit by this too :-/ Seems like this feature was kind of thrown over the wall without much thought to how apps will deal with it in real life - asking users to navigate through the filesystem to choose explicit paths to EXEs In General doesn't seem super practical. It really seems like a wedge to drive people to use Store apps

@hatton

This comment has been minimized.

Copy link
Author

hatton commented Nov 18, 2017

I was wrong about one thing: after a few seconds, there is a notification from Windows Defender:

image

@Peewixle

This comment has been minimized.

Copy link

Peewixle commented Mar 16, 2018

Hey guys :) We've run into the same issue.... any updates? workarounds you've tried/found/worked?

@lukeskinner

This comment has been minimized.

Copy link
Contributor

lukeskinner commented Mar 16, 2018

Getting a code signing certificate is the easiest way to fix anti virus issues including this Windows Defender issue. You'll have to pay for a certificate but in my opinion it pays for itself in time saved from fixing/assisting users blocked by their AV.

https://github.com/Squirrel/Squirrel.Windows/blob/master/docs/using/application-signing.md

@hatton

This comment has been minimized.

Copy link
Author

hatton commented Mar 16, 2018

@lukeskinner I don't see evidence that code signing is enough with this particular situation. Our apps are all signed. I'm just guessing here, but it could be that apps that work in a normal way involving Open/Save dialogs are allowed, while apps (like ours) that are touching dozens of files in rapid succession are flagged.

@sopelt

This comment has been minimized.

Copy link

sopelt commented Mar 16, 2018

@hatton is that something you can reproduce? What do your access (write?) patterns look like?
Have you tried if having a regular (e.g. MSI/program files) installation makes any difference?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment