That was to be expected. In the days before a CDN when we kept track of downloads there were over 500 per day. Probably more now. If you hit a red alert page it will be less
Seems we are blocked again, now all three download pages I can’t do much as my internet connection is really slow
Does it make sense to delete all the *.EXE files and point to another site (swi-prolog-win.org) containing them (with an explanation that some virus scanners incorrectly flag them)?
This will kill swi-prolog. Is there any way others can help with this?
It doesn’t block the whole site, just the folders pointing at the .exe files. Using a new domain will leave the Windows users in the same position. Only the Mac and Source downloads will be unaffected. We get the same by reorganizing the download folders, providing one explicitly for Windows. But, about 80% of the downloads concern the Windows binaries as Mac users tend to use Macports/Homebrew and Linux users PPA/GIT.
This, in the end, needs to be resolved by Google. The best we can do is probably signal as many as possible false alarm signals with Google, so they start to understand what they are doing and provide a way for vendors to get EXEs whitelisted before they are published
A post was split to a new topic: Post being marked as spam
(and the email from swi-prolog.discourse.group that mentioned the download site was marked as spam by gmail)
FYI, I just downloaded SWI 8.15. binaries for Mac, and Safari raised a red flag, too.
Really annoying, to see how Google wants to take control on us.
Hi new commenter, I just wanted to say that I am seeing it blocking the downloads page in both Chrome and Firefox and it is blocking the downloaded files until you choose to enable them. In order to get the files I had to click to get past the block, download the file and then go to downloads and click through a second warning.
Thanks for reporting. It seems most browsers implement the Google Safe Browsing API, which is at the root of these reports. They base themselves on a number of virus/malware scanners. Such beasts look for patterns in binaries to identify malware. As there are so many of these patterns this leads to false positives for arbitrary safe binaries. Virus reports on the SWI-Prolog binaries were common before this and so far all have proven to be false. Just, this new way of browsers to warn is a bit offensive
@jan have you tried the google webmaster account? as described on the stopbadware site:
- If Google is the only data provider blacklisting your site, you can request a malware review in your Google Webmaster Tools dashboard. No account? You can sign up for free. A malware review from Webmaster Tools is the fastest way to remove your site from Google’s blacklist.
Could this be the solution?
The other links in the source code point to the www version, the “working one”
Until the nginx server is fixed this could be the solution.
The anti malware software could be setting an alert on the failing url.
This change should probably be done anyway, since the non www url does not work,
so it could be worth a try
Today I went to download the latest swipl-devel for mac. Got this same thing when I went on the Development version page. OK, ignore warnings go to page. Click the mac os package, it downloads and then
"swipl-8.1.15....dmg" is dangerous, so Chrome has blocked it. Ook, let me try downloading the source and building it. I download the source, it downloads and then “swipl-8.1.15.tar.gz is dangerous, so Chrome has blocked it.” Well! So I used
wget to download the mac binary. But that is scary! Also very weird that it says the source code tar is dangerous
It seems to be getting worse The party to blame is Google though Best we can probably do is make noise and report (see Parts of website blocked by Google Safe Browsing?)
I’ve returned from holidays. Found a beautiful owl See below. Resolving the safe browsing issue is quite high on the priority list. I checked the site with Google SearchConsole, which currently only triggers on swipl-8.1.15-1.x86.exe. I’ve reported this file and asked how we should tackle this.
So far, besides trying to fix this with Google we have these suggestions:
Host Windows downloads elsewhere. I think this is rather undesirable as we can’t make direct links to this location without being trapped by the same problem, indirect links make the process less transparent and may not fix the problem anyway as the externally hosted download pages probably get flagged as well. After all, the issue is that an arbitrary binary often gets flagged as a false positive by a couple of virus and malware checkers and SWI-Prolog is not a top-5000 website in the world (I’ve read these sites have special status).
Create an indirection on our website, hosting Windows binaries from a separate page. This too doesn’t make the experience any better
While considering to implemented the second anyway it also crossed my mind that we can have an intermediate page/popup that Google cannot follow before the actual download. I might do that as a first step. The biggest disadvantage is that this hinders another popular anti-malware measure: if a binary changes or appears on the internet with the same name but different content this (used to be) flagged as suspicious.
Opinions? Other options?
It may help to link to virus scan results for the Windows installers. For example, the current stable version is available as a Chocolatey package and it’s page provides links to those scan results:
The scan results use the SHA256 checksum as a tag providing a way for the user to confirm that the downloaded installer is the same that was scanned.
Thanks! Didn’t know about choco. It only has the stable versions though It shows how to call virustotal for a package. I’ll try to add that.
Implemented and pushed that. This doesn’t remove the red flags on the download pages for now. I hope to get that resolved with Mozilla and/or Google. Changing the download location is of course an option, but breaks a lot of links out there. The new policy is this:
Any .exe is linked from the pages as
*.envelopeopens a page like this:
s/therefore classify our binaries often as malware/therefore often classifies our Windows binaries as malware/
s/large number of antivurus softwares/large number of antivirus programs/
or “software” - the plural of “software” is “software”.
Also, an owl for you: https://twitter.com/ccroucher9/status/1191447962850750465
Thanks. Fixed. Also added the SHA256 to the actual download as well as a direct link to the virustotal analysis. At this moment both Chrome and FF open the download pages without issues! With these changes we hopefully bypass Google Safe Browsing, but in the case of failure only a single file should be blocked rather than the entire download pages. Fingers crossed!
Real owls are not that cute though
Right now it seems we are back in business again. I’ve reported several more files at
https://safebrowsing.google.com/safebrowsing/report_error/?hl=en. It typically takes about half a day before the file is considered safe again. It seems most (all?) files in the download area are currently ok.
If you find another blacklisted file, please report using the link above. It is just a copy/paste and click. No explanation seems to be needed.
I don’t know how a reported file is processed. Possibly there is something in our sources that causes a too generic malware signature to trigger and they fixed the signature. Possibly they just whitelist the individual file.
The interesting thing is what is going to happen in the future. Will new signatures at some point cause most of our old downloads to be blacklisted again? Will we only have accidental issues with new releases? The latter seems bearable, especially when they are fixed in half a day or so. The former is not as it takes a long time to gather and report all the files and in the meanwhile we suffer badly
The extra download indirection should prevent the entire download site from being blacklisted and the link to a virus scanner is a nice addition IMO.