Earlier this year, Mel posted a video saying they are making a sequel.

Just in time for the sequel!

Not impossible, just more difficult to guess.

"Security through obscurity" isn't really good enough.

Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.

Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?

Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?

With HMAC, you can still ask for some sequential IDs

SipHash128(0, KEY) = k_0

SipHash128(1, KEY) = k_1

You get the same number of bits as a UUID.

You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.

The writeup never claimed that 123456:123456 were default credentials?

They use this site for hiring globally. The number of privacy regulators they will have to notify and deal with is going to make this messy.

Which is 1,615 applicants per US franchise.

Seems totally reasonable to me.

2 shifts of 12 employees is 24 employees per day. Assume they all work there for 6 months on average, then if the system's been up for 10 years, that's 480 employees per franchise over a decade. Which means for every employee they hired, 2 were either rejected or chose not to work there.

Working at McD's is something a lot of people do for a few months when they're young.

I have no idea... maybe they store their "coupons" locally and are afraid you'll clone them? Don't know, I eat there twice a year and it's not worth it :)

suhide in magisk makes my banking app work, but not mcdonalds :)

My theory is they store payment information on the mobile app. The app connects to the store wifi automatically, even when going through the drive thru. And processes the payment then. I theorized it so they don’t store credit card info on their servers, simplifying their PCI audits. Presumably they think all that is better than preventing the app from running on rooted phones.

The UI is atrocious.

I do computers for a living and can barely navigate and figure out what’s going on.