Desktop app updates vs. browser warnings

Discussions
#1

I create desktop apps and update them fairly frequently with new features. I sign the setup and all included files with an EV Code Signing certificate.

The problem that I have is that when I release a new version, browsers warn the user that the setup file is “not commonly downloaded and may be dangerous”. This warning disappears after a while, once enough users have downloaded the new version, however the first ‘x’ number of users (hey Google and Microsoft, what’s the value of ‘x’???) see the warning message.

In addition, although I test all files with VirusTotal to ensure that no users see any false positives, there seems to be some anti-virus vendors (McAfee’s enterprise products, not their consumer products, and Avast) sometimes display a false positive to users, even though the versions of their products on VirusTotal don’t flag any issues.

McAfee and Avast want me to send files to them for whitelisting every time a new version is published, but their approval process takes a few days, so this is really sub-optimal.

An approach I’ve been contemplating is to create a thin installer that never changes but instead downloads the latest files from the website every time it runs. This means that the version will remain stable.

Has anyone used this approach? Any tools to recommend? Anything else to keep in mind?

An MSI installer is preferable, but I’m open to all suggestions or alternative solutions - thanks!

#2

I’m using a cheaper non-EV certificate, and I get these warnings only after renewing a certificate, not after each release. I think I’ve read somewhere that browsers or Microsoft are vetting a certificate, not each executable. But EV certificates shouldn’t have even that initial period, that’s their main selling point.

Of course, maybe there are some other factors they use for flagging executables that we don’t know about. Could you share your typical download link, and a new one that should trigger warnings?

#3

their approval process takes a few days

Tip: You don’t send for approval after release; you do it a few days before release. This means your customers get a release that’s been pre-approved. :wink:

#4

@grujicd Thanks. Unfortunately I can’t recreate the issue with my installed browsers - I think that some users have an interesting environment. Also, my suspicion is that the alerts are from other security components, such as anti-virus browser extensions or something. I’ll post a URL to a new version shortly.

I still feel that a different approach to installing from the web would solve these issues and any like it in the future.

#5

@Paul1970 Thanks. Yes, true, but approval takes up to a week. I often prefer to get bug-fixes into users’ hands faster than that.

#6

So submit it two weeks before the official release. Your users don’t know a bug-fix release is coming until you tell them.

#7

Well, you usually fix bugs after they’re reported by user, not 2 weeks before that :slight_smile:

#8

If problem is caused by AV then it will most probably scan your other download as well. Real time file system monitoring is a standard AV thing.
But sometimes you spend a lot of time overanalyzing, thinking whether you should build something or not, evaluating, estimating, and then when you decide to do it it’s finished in few hours. I suspect this downloader could be built very quickly, maybe even to just download from fixed url, not asking server about the latest version, etc. Complications are always possible though - failed downloads, elevating user permissions when you install downloaded part, etc. But even the simplest version should show whether this approach makes a difference for your problem. If so, then it’s not a big deal to invest additional time in downloader afterwards.

#9

you usually fix bugs after they’re reported by user, not 2 weeks before that

You’re misunderstanding. :slight_smile: I do it like this: users report a bug. I tell them a fix is being made, fix it, and then submit it to the major AV companies for white-listing. When that’s done (say a week or two later), it’s only then that I publically release the fixed version. My customers are none the wiser of the delay and just assume the fix took a week or two to happen.

#10

I try to fix bugs in hours or days, not weeks, if possible. It looks to me that customers appreciate that.
I only had a single issue with a single AV product for the 15 years I’m running the business, so I never bothered with white-listing. However, if your builds tend to trigger AV heuristics more often, then I understand why you have to do it that way. In my case, it’s a better service for customers to get new releases asap.

#11

I try to fix bugs in hours or days

I agree with this when it’s for show-stopping bugs. But for lesser bugs with or without temporary workarounds, I don’t like that kind of timeframe and pressure, and feedback from my users is that even one update per month or two is more than enough (it avoids update fatigue for them).

#12

I am about 3 years into my latest authenticode cert (Sectigo, was Comodo) which I use on 3 different desktop products. I can’t remember the last time I saw a "not commonly downloaded and may be dangerous” in testing. And they are very rarely reported by users (which doesn’t mean they don’t happen, of course). But I know other people are plagued by them. Not sure why the apparent difference.

NB/ I use Inno Setup for the installer and sign both the installer and the exe.

#13

Thanks everyone for your thoughts. I’m going to try this out and report back in the future.

#14

I don’t really like the idea of having to delay the releases because of overly paranoid AVs.

From my experience with certificates, new certificate gets a warning for the first week or so, after that any releases with this certificate are not flagged.