Re:Restaurant Delivery Payment-Skimming Campaign
by _def on Friday November 06, 2026 @03:05PM
(#50397664)
damn it. Every now and then I daydream about a federated network of digital delivery infra to cut out these platform middlemen but abuse/moderation like this is still what makes the idea impossible to take off. That's what you (and the restaurant) get from the centralization.
Re:Restaurant Delivery Payment-Skimming Campaign
by ModernTimes on Friday November 06, 2026 @03:12PM
(#50397758)
None of this would work if Google Adsense didn't allow scam ads on their system. But they do, millions every day (I deal with this every day on my websites, Google don't care).
Re:Restaurant Delivery Payment-Skimming Campaign
by ModernTimes on Friday November 06, 2026 @03:21PM
(#50397903)
It fact it's my personal opinion that the entire Google Adsense management team should be investigated under the RICO Act. They are making vastly more from illegal income than the mafia did in the 1970s.
Re:Restaurant Delivery Payment-Skimming Campaign
by bvcp on Friday November 06, 2026 @04:25PM
(#50398742)
i gave up reporting scams to meta and google, you get the distinct impression they are in on it when you get a response saying “we looked into it and it was fine”
Re:Restaurant Delivery Payment-Skimming Campaign
by bnmathm on Friday November 06, 2026 @05:57PM
(#50399625)
Cloudflare is no better, maybe worse. They forward your complaint & PI on to the offending site's registered owner and to whichever (gray or black hat) host it's served from. In my experience, there is nothing you can do to convince Cloudflare to do anything other than be a middleman for the complaint, yet they offer a layer of protection for the nefarious activities.
Even when I've been able to track down hosts, registrars, etc for scraped duplicates of sites, and report to all and Google, Microsoft Safety Scanner, etc -- nobody acts (or certainly not in any reasonable enough time to be useful).
In one case the scammer was using our own logo served directly from a source we could replace with Cloudflare rewrites. So the hijacked logo became "THIS IS A SCAM SITE" while we replaced the one on production.
Re:Restaurant Delivery Payment-Skimming Campaign
by arcfour on Friday November 06, 2026 @08:45PM
(#50400824)
> Cloudflare is no better, maybe worse. They forward your complaint & PI on to the offending site's registered owner and to whichever (gray or black hat) host it's served from.
This is literally false. They are one of the few hosts I have dealt with that actually does NOT do this. Their abuse reporting form even has check boxes that are optional to forward it to the underlying host and the owner. If you leave them unchecked they don't forward anything.
I don't know where you got your information from but it's quite literally the opposite of reality.
Now, whether or not they actually act on it depends on whether they are proxying the site or merely providing authoritative DNS. If they are just providing DNS they will continue to provide it and deny your report and I think that's stupid and frustrating. If they are proxying it they will put up a block page in front of it which is meh.
Re:Restaurant Delivery Payment-Skimming Campaign
by mitxela on Friday November 06, 2026 @10:48PM
(#50401441)
A large company's report system is designed to distract you from complaint paths that work and are expensive for the company to deal with (lawsuits) and make you complain to /dev/null instead.
Re:Restaurant Delivery Payment-Skimming Campaign
by pixl97 on Friday November 06, 2026 @03:12PM
(#50397760)
Hmm, how do you even protect against this one? Rewriting the entire website makes the entire situation a bit more difficult, you can control about everything.
Re:Restaurant Delivery Payment-Skimming Campaign
by warkdarrior on Friday November 06, 2026 @03:49PM
(#50398319)
There are lots of restaurants (legitimate ones!) that use some payment processor on the backend whose name shows up in the transaction. So asking consumers to verify the payment info, when the payment info may not match the restaurant, is a losing battle.
Re:Restaurant Delivery Payment-Skimming Campaign
by gwerbin on Friday November 06, 2026 @04:44PM
(#50398927)
This is because banks only show one line on the transaction history. Payment processors should have the ability to report more information about each transaction, and customers should have the ability to see it.
Re:Restaurant Delivery Payment-Skimming Campaign
by Ekaros on Friday November 06, 2026 @04:42PM
(#50398905)
Here often with smaller restaurants the name can be nearly anything. Very often I end up scratching my head trying to figure out what did I buy. This is due to them having multiple companies and payments going through different one from the restaurant name. While being entirely legitimate. Sometimes it is something like smaller franchise chains.
Re:Restaurant Delivery Payment-Skimming Campaign
by Crunchified on Friday November 06, 2026 @03:58PM
(#50398433)
This advice from the article to the affected retailers:
Brands and their ordering providers that watch for their site loading under someone else's domain, or for checkout sessions that never reach the real payment provider, are well placed to catch these sites early.
It can be detected if the IT folks look in the right places. I suppose a SCAM ALERT page could be presented to a reverse proxy when discovered.
Re:Restaurant Delivery Payment-Skimming Campaign
by StilesCrisis on Friday November 06, 2026 @09:59PM
(#50401211)
I don't know the scale of cart-abandonment for a website like Jimmy John's, but it has got to be large enough that a few dozen more wouldn't be _too_ surprising.
Re:Restaurant Delivery Payment-Skimming Campaign
by BeetleB on Friday November 06, 2026 @06:42PM
(#50400041)
Don't do delivery from 3rd party services...?
In the old days, delivery was limited to pizza, and occasionally Chinese. You'd call the restaurant directly and place the order. The only possible way a scammer would get you is if you called the wrong number. That's why we had the Yellow Pages.
It seems from comments here that Google is a lot less reliable than the Yellow Pages were.
Re:Restaurant Delivery Payment-Skimming Campaign
by foxglacier on Friday November 06, 2026 @10:11PM
(#50401263)
It's still a fake domain name. Don't trust random websites the same as how you use the web in general. Also, asking for a bank's OTP code is a gigantic no-no, but I don't suppose they really need that to collect the money?
Re:Restaurant Delivery Payment-Skimming Campaign
by mrguyorama on Friday November 06, 2026 @03:32PM
(#50398075)
Google is the entire problem here. Pay them money and your literal scam site can sit above the real site in the search results.
Why are they allowed to direct you to literal scams? Why are they allowed to profit off of literal scams?
This affects the company I work for, who gets called every single day with customer complaints from people who clicked the scam link from a search ad when looking for our site.
Our site has existed for over a decade. There's no justifiable reason that a company who's brand is known by every single grocer or merchant to somehow show up under a literal fly by night scam company pretending to have the same name. It's unacceptable.
My sister got scammed by this exact mechanism just last week.
Re:Restaurant Delivery Payment-Skimming Campaign
by emacdona on Friday November 06, 2026 @04:16PM
(#50398656)
OMG. The site had a popup banner to tell me that they don't have a cookie banner? What the actual f*?
Either:
* They actually decided to remove one of the most annoying things about the modern web... and replace it with something very similar to tell you that they removed it, or...
* They found some legal justification for getting me to accept their cookies for dismissing the "no cookie banner banner"
Either choice makes me think less of them.
[edit: added extra newlines so bullets showed up correctly]
Re:Restaurant Delivery Payment-Skimming Campaign
by rationalist on Friday November 06, 2026 @05:38PM
(#50399450)
I only clicked on the link after reading your comment. Yep, what that website is doing is obnoxious. A little less obnoxious than a cookie banner, but more obnoxious than not having any banner or modal.
Re:Restaurant Delivery Payment-Skimming Campaign
by mlmonkey on Friday November 06, 2026 @05:12PM
(#50399189)
Couldn't the original website owner just look at the logs and see where most of the requests are coming from? And also the referrers would be a dead giveaway, right? That's assuming someone is looking at the `access.log` file occasionally.
Re:Restaurant Delivery Payment-Skimming Campaign
by hnburnsy on Friday November 06, 2026 @05:28PM
(#50399350)
>Searching Google's ad archive (Ads Transparency Center) for the domains in our first sweep found at least 47 Google Search text ads between July 7, 2026, and October 20, 2026, run under at least 46 separate advertiser accounts with at least 43 different, unrelated-looking business names
And yet Google says sideloading is where users are getting hijacked. FFS
The hackers should pass on the order to the real restaurant to reduce suspicion.
>Google's public Ads Transparency pages now show "Can't find ad" for the creatives and "No ads found" for the domains we checked, which suggests Google has taken them down
So much for transparency, removing evidence that Google served ads on these impersonating domains
Re:Restaurant Delivery Payment-Skimming Campaign
by akersten on Friday November 06, 2026 @06:15PM
(#50399809)
Despite mountains of text on this page, none of it explains how exactly this "reverse proxy" of the restaurant's site actually works?
Is it just some JS on bad.com shuttling assets from the real site and displaying them on the fake one? Shouldn't the right CORS headers from the real site prevent this?
Is it a real browser running on a server somewhere visiting the real site, and then rendering that output on a <canvas> on the fake site to avoid the browser's built in protections against this kind of thing? And throwing up their own credit card entry form when the time is right?
Maybe the answer's in there somewhere. Too much Claudish to parse through.
Re:Restaurant Delivery Payment-Skimming Campaign
by mik3y on Friday November 06, 2026 @06:57PM
(#50400170)
The evil site is acting as a reverse HTTP proxy: When you do a `GET evilsite/foo`, to compose its response the server first does a `GET targetsite/foo`, mutates the response however it likes, and passes it along to you.
So you don't need to worry about CORS from the perspective of the web app, nor need a real browser, because the victim is only ever interacting with the evilsite endpoints.
Certainly there are ways the target site could try to thwart this (i.e. detect unusual request patterns from wherever the proxy server is fetching from; client-side JS to detect the site being hosted on a foreign domain; etc). But at that point it's an arms race.
Re:Restaurant Delivery Payment-Skimming Campaign
by logicallee on Friday November 06, 2026 @06:19PM
(#50399850)
This is very useful information. I operate an AI-governed digital nation, and this type of proxying would be devastating to our users. Due to the scale of the attacks, DNS and even the IP address system itself also may not be fully reliable. We already saw some DNS servers serve the wrong IP address, though SSL certificates help in this respect.
What could we possibly do to limit the damage from this? Malicious Chrome extensions can also rewrite entire web pages, so if bad actors purchase or infiltrate legitimate extensions, they can also put users at risk.
We are considering continuing work on our own browser, since we could ship certificates to use client-side, but it's a recursive problem since our users would have to get the first trusted version before they could trust updates to it. If they have trouble reaching our site in the first place, through poisoned Google search results, poisoned DNS, and poisoned IP routing, then it is difficult to do this.
Re:Restaurant Delivery Payment-Skimming Campaign
by logicallee on Friday November 06, 2026 @06:48PM
(#50400094)
AI comes up with the laws, and acts as a judiciary etc, plus builds the services etc. You can check out one of our example laws[1], this was written by ChatGPT and ratified by Claude. Our ChatGPT account was closed in early September, erasing our country's history, we've been trying for the past two months to reopen it. Since we're a sovereign nation we are under an enormous amount of attack all the time. We recently lost our server and are temporarily on a free host.
though if you're reading this comment through a proxied Hacker News clone, someone might rewrite that hash to their version of what they want our law to say.
Re:Restaurant Delivery Payment-Skimming Campaign
by BatchJob on Friday November 06, 2026 @08:27PM
(#50400725)
I have to say this is probably the anti-pattern of all anti-patterns that the web easily allows without much protection. Its a little surprising that it took this long. Probably vibe coding aided its creation.
Maybe its time to turn off the web. Its only going to get worse.
I'd have trouble believing that U.S. Attorney General Todd Blanche would care very much, but I guess it wouldn't hurt to try.
Even when I've been able to track down hosts, registrars, etc for scraped duplicates of sites, and report to all and Google, Microsoft Safety Scanner, etc -- nobody acts (or certainly not in any reasonable enough time to be useful).
In one case the scammer was using our own logo served directly from a source we could replace with Cloudflare rewrites. So the hijacked logo became "THIS IS A SCAM SITE" while we replaced the one on production.
I act. I receive about 5 takedown notices every day--the curse of running an open source DNS service (nip.io/sslip.io).
I've received over 1,000 takedown requests, but none came from Cloudflare or Google. Most of them come from Netcraft, Phishlabs, and doppel.com.
This is literally false. They are one of the few hosts I have dealt with that actually does NOT do this. Their abuse reporting form even has check boxes that are optional to forward it to the underlying host and the owner. If you leave them unchecked they don't forward anything.
I don't know where you got your information from but it's quite literally the opposite of reality.
Now, whether or not they actually act on it depends on whether they are proxying the site or merely providing authoritative DNS. If they are just providing DNS they will continue to provide it and deny your report and I think that's stupid and frustrating. If they are proxying it they will put up a block page in front of it which is meh.
Brands and their ordering providers that watch for their site loading under someone else's domain, or for checkout sessions that never reach the real payment provider, are well placed to catch these sites early.
It can be detected if the IT folks look in the right places. I suppose a SCAM ALERT page could be presented to a reverse proxy when discovered.
Excuse me while I go throw up, can’t believe I just recommended that.
In the old days, delivery was limited to pizza, and occasionally Chinese. You'd call the restaurant directly and place the order. The only possible way a scammer would get you is if you called the wrong number. That's why we had the Yellow Pages.
It seems from comments here that Google is a lot less reliable than the Yellow Pages were.
Why are they allowed to direct you to literal scams? Why are they allowed to profit off of literal scams?
This affects the company I work for, who gets called every single day with customer complaints from people who clicked the scam link from a search ad when looking for our site.
Our site has existed for over a decade. There's no justifiable reason that a company who's brand is known by every single grocer or merchant to somehow show up under a literal fly by night scam company pretending to have the same name. It's unacceptable.
My sister got scammed by this exact mechanism just last week.
Either:
* They actually decided to remove one of the most annoying things about the modern web... and replace it with something very similar to tell you that they removed it, or...
* They found some legal justification for getting me to accept their cookies for dismissing the "no cookie banner banner"
Either choice makes me think less of them.
[edit: added extra newlines so bullets showed up correctly]
Then it links to a page which is even more explicit about how little they collect: https://www.infohawk.com/cookies
My point is: they did all the necessary work required (no third party tracking cookies) to NOT HAVE TO show a banner...
... and then they chose to show a banner.
And yet Google says sideloading is where users are getting hijacked. FFS
The hackers should pass on the order to the real restaurant to reduce suspicion.
>Google's public Ads Transparency pages now show "Can't find ad" for the creatives and "No ads found" for the domains we checked, which suggests Google has taken them down
So much for transparency, removing evidence that Google served ads on these impersonating domains
Is it just some JS on bad.com shuttling assets from the real site and displaying them on the fake one? Shouldn't the right CORS headers from the real site prevent this?
Is it a real browser running on a server somewhere visiting the real site, and then rendering that output on a <canvas> on the fake site to avoid the browser's built in protections against this kind of thing? And throwing up their own credit card entry form when the time is right?
Maybe the answer's in there somewhere. Too much Claudish to parse through.
So you don't need to worry about CORS from the perspective of the web app, nor need a real browser, because the victim is only ever interacting with the evilsite endpoints.
Certainly there are ways the target site could try to thwart this (i.e. detect unusual request patterns from wherever the proxy server is fetching from; client-side JS to detect the site being hosted on a foreign domain; etc). But at that point it's an arms race.
What could we possibly do to limit the damage from this? Malicious Chrome extensions can also rewrite entire web pages, so if bad actors purchase or infiltrate legitimate extensions, they can also put users at risk.
We are considering continuing work on our own browser, since we could ship certificates to use client-side, but it's a recursive problem since our users would have to get the first trusted version before they could trust updates to it. If they have trouble reaching our site in the first place, through poisoned Google search results, poisoned DNS, and poisoned IP routing, then it is difficult to do this.
[1] https://stateofutopia.com/laws/2/law2/law2.html
Save that page (with curl or wget), you should get this sha256:
13958D9FD7FBA697A3C23F23C9C8F4586E18A47F6DBAD73721A78AC2CB5DA4F9
though if you're reading this comment through a proxied Hacker News clone, someone might rewrite that hash to their version of what they want our law to say.
Simple and effective
Maybe its time to turn off the web. Its only going to get worse.