3 ms·
To be less indenciary with the title: Google marked the website as harmful for hosting harmful content, which it was, but which has now been removed, and the re
by danpalmer 3y ago
To be less indenciary with the title: Google marked the website as harmful for hosting harmful content, which it was, but which has now been removed, and the recognition has not been updated.
It could be caching, or it could be a policy thing. Websites that once hosted harmful content are probably much more likely than average to host it again. I do hope this can be reverted of course, I understand that the intention was not to be harmful (not that that would prevent a bad actor from pointing people to your download).
Have you made sure your robots.txt allows Google to scan and properly identify that the files have disappeared?
Also, how long have you waited? I wouldn't be surprised if it takes a few days for these sorts of things to make it through all the relevant systems. I do realise that's not very comforting when users are unable to use a website!
As an aside, to prevent this in the future perhaps, you mention that the files were encrypted. This should have prevented this because Google shouldn't be able to decrypt the file to understand that it is malware. Did you do the encryption from scratch or did you distribute the same encrypted file that might have been previously known about publicly, where Google might be able to pattern-match to known bad files? I would imagine you should be safe zipping and then encrypting the zip with your own encryption.
Disclosure: I do work at Google, but not on anything related to this, this is all just personal opinion based on work outside of Google.
- beardedscotsman 3y agoJust because it was encrypted doesn’t mean google can’t run some processing. For example encrypted zip files still can show the file names. These file names could be specific or malware or a collection of matching file names.
- danpalmer 3y agoThis is why I said zipped then encrypted, yes any pattern matching like filenames could be used to identify malware. Plus encrypting then zipping removes any compression opportunity so that's just a bad idea.
- anotherhue 3y ago> Plus encrypting then zipping removes any compression opportunity so that's just a bad idea. Not always! https://en.wikipedia.org/wiki/CRIME https://en.wikipedia.org/wiki/CRIME
- gunal2 3y agoAs i mentioned before, i know hosting these files on our local server is not the best practice. There are other businesses doing this thing and Google is not marking them harmful. All files are zipped with a password, we provide the password to users. Also, the filename is not a unique indicator the identify a file as malware. I can put the filename as "Google Chrome.exe" and that doesn't mean this is a malware. The second issue is, we just changed the our domain name and when i try to add it to "Authorized redirect URIs" for Oauth getting this error: "The request has been classified as abusive and was not allowed to proceed". So, i have no idea about what is going on about my domain.
- danpalmer 3y agoZip password encryption is trivially broken and should not be trusted for anything more than basic obfuscation. I'd recommend: - Using AES directly yourself with a strong password. - Hosting behind authentication - Using a different password per user. This should a) make it effectively impossible to detect the malware, b) make it clear that the intention is for research and education only, and c) prevent bad actors from maliciously using your hosted repository of malware. > when i try to add it to "Authorized redirect URIs" for Oauth getting this error: "The request has been classified as abusive and was not allowed to proceed" Is this for Google OAuth? I don't know anything about this system, but I wouldn't be surprised if the data lags behind the up to date safe browsing database. Maybe try again tomorrow?
- gunal2 3y agoYes, for Google Oauth. I'll try again, but the domain is completely new. We just moved another domain.