[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!