markhowe

Setup a honeypot page to log the ‘users’ IP. Keep hitting it via their domain and you’ll build up a list of IP’s to block?

As an aside, I’ve fought credential stuffers by returning real looking but actually false data, and initiating password resets... start serving different data on each hit, you may need to be annoying enough that they give up.

Take a nosey at Slaughterbots, a fictional 7min video; https://www.youtube.com/watch?v=9CO6M2HsoIA

There’s no link styling, at least on mobile Safari, they’re kind of essential to understand the article.

...sorry to be that guy.

Nothing wrong with a personal tone, it has clearly made a lot of people read it.

Assuming the restaurants margin's are large enough to take the hit, delivery service's provide access to a perceived new market - people who wouldn't would have visited the restaurant in person, but would like a delivery.

Since a customer pays the same usual prices (+ a delivery fee), the brand has the same value on their next in-person visit.

The services are cut throat, they push for massive %'s and expect the retailer to push a 'Get delivery through xxx' message. I know of one service with an EPOS integration, they must be waking up to it now their business is proven.

Bank transfers maybe, but Card processors are rarely that quick - merchant account's are rarely same day into bank, at least from what I've seen.

There's one field in the app's request that's still unknown. It's a header of seemingly encrypted data, along with a varying number of encrypted blocks (all the same length).

In those blocks could be anything, detailed gps co-ords, device details, there's a fair chance they can ban all these API users at the push of a button based on whatever's in those blocks.

Everything else is unencrypted - sent back and forth using the protobuf format, the formatting of the protobuf's were dropped on pastebin a few weeks ago.