We corrected an issue in the gateways that was preventing the actual blocking of the urls you provided, even though the requests had been processed as they arrived. Normally the abuse team doesn’t reply and directly trigger blocks, but they were unaware of the issue, so they didn’t raise it up to the infra team. Sorry for the distress it caused and thanks again for raising it up.
The two urls should now appear as 410 (mind your browser might still display cached results).
Every time I get a phishing link hosted by IPFS, it takes me days / weeks for a response by your abuse team. If you are going to launch a product, you need to scale appropriately with a properly staffed abuse team. This has happened about 10 times now for just one of my email addresses. IPFS needs to take this seriously and provide proper monitoring and decent cyber security. It’s irresponsible what I am seeing with IPFS abuse.
I’d like to second this. I work at a CERT and currently, the majority of account phising emails that come to us use either ifps.dweb.link or ifps.io links. A quick and easy-to find shutdown mechanism for these cases is sorely needed! Please also see documentation issue 1458.
Here’s a few I reported yesterday to firstname.lastname@example.org but which still seem to be online (some seem to occasionally give 503 Service Temporarily Unavailable):
I work for a CERT, and the majority of spammed phising messages these days have ifps.io or ipfs.dweb.link links. Here is a bunch of links I sent to email@example.com yesterday and which still seem to be up (replace xx with tt, of course):
FWIW (and maybe you already understand this), the ipfs gateway at ipfs.io is just one of many, and an HTTP gateway is more of just a portal into IPFS. Just like HTTP anyone can make any content they want available though, so it’s an endless task to block every single malicious CID.
With this understanding, the reason ipfs.io isn’t blocked (because it has been in the past), is because some spam lists (like Google’s) can be configured to see the gateway as a gateway, and only block certain CIDs / IPNS addresses.
In this case, the malicious links are of the form //ifps.io/... or //...ifps.deweb.link/ and since it is not immediately obvious they are hosted somewhere else, they have become your problem. Your service is being used by scammers for link obfuscation, since there is no obvious way to “dereference” the links to find the actual hosting site.
PS. I’m glad to see that at least a part of the links I posted above are now “410 Gone”.