3 ms·
As 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 ma
by gunal2 3y ago
As 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.