[smtddr]

Hey there, I actually worked for a "competitor" of yours at one time in my career. We had a very similar problem, turned out that one of our users shared(probably unknowingly) a file containing malware and probably posted it to their twitter or facebook(we had that feature built-in at the time). This URL was caught by a very popular anti-virus company, which posted it on their site. I guess the software phones-home to get all copies out there in sync. So for awhile, anyone with this anti-virus software would get blocked on our site's homepage for malware and/or phishing attempt. My somewhat-educated guess would be that a costumer of yours has hosted something that Google(or whatever Google uses to get its info) considers shady. Our solution was first to contact the company to get delisted, then I think we ended up changing domains for the sharing stuff. Similar to dropbox's dl.dropbox.com for any sharing stuff. Or maybe we did some kind of URL-shortener. But somehow, a change to the URL's domain of anything that hosted user-generated content was the solution to the problem, AFAIK.

[Filecloud]

Hi,

Our software is little different. It is a self-hosted software. It is hosted by our customers under different domain names in their infrastructure. So it is not the same domain or URL.

For Example:

Customer 1: fileshare.abcplumbing.com

Customer 2: dataanywhere.peterlawfirm.com

Thats the real problem here. It affects our customer installations under different domains. To some extent, we are fine if google is blocking one domain because somebody in the domain is sharing malware. The issue here is different.

[btilly]

Is it possible that you have a security hole, and malware authors have started actively taking advantage of it? If Google recognized that, your page could be a good signature for malware that they haven't detected yet, and you could get automatically blocked because of it.

This is, of course, just a random guess to throw into your brainstorm.

[smtddr]

Ah, we did have a feature sorta-kinda like that too... if you had your own domain you login on our webUI, enter in your own domain and if no other user had it, you'd get it. Then, you add a CNAME record pointing to us and we'd do certain things when we received the request depending on settings the customer provided during the domain-name setup. I think we used the Referrer in the request-headers. So I could point portal.mypersonaldomain.com -> CNAME -> whateverIchoose.yourcompetitor.com and get a custom page, kinda. If we had a customer use a domain that CNAME pointed to us and had a history of questionable content, I wonder if Google would follow the CNAME direct to see where it's going and incorrectly(or correctly?!) decided bad stuff is happening, thus marking the CNAME target as bad. Just my random'ish guess. Hope you find the issue soon.

[Filecloud]

We are not a SaaS or PaaS business. The software itself is hosted by the end customer in thier infrastructure.

The warning appears even in local IP/debug page.

[grey-area]

Have you tried deleting things from your page till you work out what causes the warning? Just start with a static copy of you page, and gradually delete elements till you find the culprit. It shouldn't take long to go through through the elements of the page and work it out if this is some sort of heuristic triggered by some element on your page and not based on the domain.

Another thing it could be is if you fetch any assets at all from your domain, and the domain is blacklisted, that causes the warning regardless of the page where it is hosted.

[Filecloud]

Yeap. we are doing exactly as you said. Hopefully we can find out.

[smtddr]

Oh! Sorry, I missed that part. So even things like http://192.168.1.19/mystuff makes Google Chrome scream? That's crazy. I can't imagine what would cause that. Wish I could help :( ...but looking forward to a blog explaining how this happened later!