I'm about 90% sure that for some inane reason, McDonalds outsources and creates separate apps for each country/region with these disastrous security flaws, except that at HQ they universally demand horrifically counter-productive "anti-root" measures for every locale, to a larger extent than even finance apps.
Why am I so sure about this? I live on the other side of the world, the app is almost certainly an entirely separate codebase from the Polish one the article is about, and yet here too it has the worst anti-root measures of any app by any remotely large company, including finance, healthcare and government apps. Enormous numbers of false positives. Even for those with the most mainstream Android models around.
This will all just come down to one person at McD's HQ who is forcing through these ridiculous ideas and costing their company a bunch of money in the process. No other multinational employs this strategy to any similar degree.
I’ve worked on apps like this for companies like this. What happens is that their IT department mandates an expensive pen test for suppliers, anti-root requirements are on the pen-tester’s generic checklist, and most companies won’t push back on the pen test results. If you do, they normally fold and admit it’s not required.
Pen-testers? People do it for auditors as well! $OLD_JOB literally took one of the auditor’s questions to heart and decided that the question meant they needed to separate the databases physically for each client, they didn’t realize they could have just said “logically separated”. People are more scared of these checklists than they really should be.
It's literally only McDonalds though who goes to this degree and does so across different codebases in locales across the world. The departments you're talking about exist in many places, but no other big company has their apps be like this so consistently.
If an app tries to detect that I have root or a non-stock OS, I will give it a 1-star review on Google Play 100% of the time. Everyone who has a rooted device should do this.
One good reason why "honest" app vendors do this is because providing tech support for custom OS's (in addition to the wide variety of popular handsets) is more costly. They also might not want the responsibility - in case something like your banking app gets pwned by random malware, they want to blame the OS vendor. CYA is always a good strategy.
But if someone is seriously thinking client-side security works, yeah the app deserves your review - and probably some reversing, just for fun.
It's not hard to think of reasons that are rational and not otherwise nefarious that an app developer would want to restrict an app to certain verified operating environments, but I think creating a world in which people have less control over devices they own is bad in and of itself. I don't run a government or a VC firm so I don't have a lot of power to stop it, but I'll make what small contribution I can.
> One good reason why "honest" app vendors do this is because providing tech support for custom OS's (in addition to the wide variety of popular handsets) is more costly.
I am reasonably confident that some almost-AOSP aftermarket ROM is a less weird operating environment than the weird hacked-up things official vendors are shipping.
What percentage of rooted/non-stock OS users do you think are people like you, vs bots? I'd love to see the numbers if anyone has them but I suspect it's pretty lopsided these days.
Ick. That turned my stomach. Sure it's bad for end users that
corporate mobile app development is a swamp. In this case it only
affects the vendor who lost out on users and reputation. But cavalier,
reckless engineering equally causes harm to the client device or end
user - if only in wasted time.
Given the audience here, I hope many would agree it's pitiful that
developers are wasting their time building this junk. Some poor sap
had to make this, probably sighing and shrugging at the end of each
line of code.
Unions or professional body membership is becoming more important for
programmers. People need to be able to say "I studied what you asked
me to make, and refuse to work on this illegal, insecure, depressing
cruft, and if you fire me for having professional ethics my lawyers
will empty your company bank account." Otherwise technologists become
just tools of destruction.
> People need to be able to say "I studied what you asked me to make, and refuse to work on this illegal, insecure, depressing cruft, and if you fire me for having professional ethics my lawyers will empty your company bank account."
This only works if everyone or the vast majority join unions. Otherwise, those who join will get penalised with lower offers or no offers at all.
> This only works if everyone or the vast majority join unions.
This is a common objection but I think it's wrong. Putting aside the
huge differences between US (at will) and global employment law, the
idea of a fluid, frictionless workforce is quite the myth. Keeping
wages down and conditions poor very much relies on the propagation of
that myth that ethics will work against you. so please be careful not
to do yourself a disservice (if indeed you are a developer).
In reality quite small minorities have a disproportionate impact on
change. Some accounts claim it's as low as three percent. I'm
sceptical of that, but the fact remains; if only a handful of people
object but with severe consequences by the force of law, employers
will play it safe. I find it unlikely that any employers would survive
long if it transpired they were disfavouring members of IEEE, ACM, IET
or whatever.
> professional body membership is becoming more important for programmers. People need to be able to say "I studied what you asked me to make, and refuse to work on this illegal, insecure, depressing cruft, and if you fire me for having professional ethics my lawyers will empty your company bank account."
I think this might be an interesting one to consider, other than the "depressing" bit of course. The problem is, I think, if you have the accreditation and you develop an insecure application, do you lose the accreditation? What's the tradeoff?
And who's the "you" in that case? If you're on a team of ten developers working for a shoddy company - because your family can't eat lofty principles - and a bad piece of software is released, who loses their accreditation? Is it the whole team? Do we go through the commits one by one? Is it just the tech lead, or the PM, or the engineering manager?
Entry-level jobs? Sure. Senior level and above? You must have been living under the rock for the past year.
Then again, mobile apps are like this tend to be junior work, outsourced to software mills that just burn through juniors cranking out garbage assembled 10% of polyfills and 90% of advertising SDKs. Yes, at this point of your career, you can still say "no" - the company will happily replace you with some other junior, while you replace some other junior somewhere else.
> [the extensive anti-reverse engineering measures are] more annoying than any financial app I've had, and I have 5 of them on my phone
Ah, this reminds me of the Tuya app.
I've done some ssl unpinning and mitm to see requests going in and out of my phone, it's pretty fun and there's often really nice and easy to use restful APIs underneath. Among them I've also done a couple of banking apps and they weren't particularly defensive either. That's great; as a user I'm empowered by it and like TFA says, it's totally fine from a security standpoint if you just don't trust the client to do anything they shouldn't be able to do. It shouldn't be your form validation that stops me from transferring a trillion dollars, and though I haven't tried, I'm sure that's not the case for those apps. All it does is allow me to get my monthly statements with a for loop rather than waiting for a laggy UI and clicking through each month.
Now, Tuya is a Chinese company offering a bunch of cheap IoT devices like smart power switches and IR motion detectors. You can interact with everything through their app. That app for some reason has spent by far the most resources on anti-RE of any apps I've seen. I already bought your hardware, mate. Please let me use it on my local network. My smart home infrared motion sensors were meant to turn lights on when I enter a room. But they don't feel very smart when I'm standing in the dark for 4 seconds while they check with a server in China. I don't even need a clean API; just let me see what you do, and I'll do something similar, no support or documentation necessary. But they go through extensive measures to prevent you from interacting with the hardware you bought and which is sitting in your home.
This was a while ago, but I think for the motion sensing in particular, I managed to just put them in a subnetwork with blocked internet access, and snooped on the network to catch their DHCP requests when they tried to call home. This would happen every once in a while presumably for settings/update checks, but crucially also when there was motion detected, and I didn't mind a few false positives. So in the end they were very quick, locally functioning, privacy-friendly little devices!
The problem with Tuya is that they don't manufacture the devices themselves. Instead, they provide a standardized interface for all those low-cost manufacturers and get paid by them. If it were easy to fake Tuya requests or set up your own account (trust me, I tried this to integrate a Fingerbot into Home Assistant, but you have to jump through countless hoops, and the developer account keeps expiring every few weeks), those manufacturers would simply automate this process through their own apps.
> they provide a standardized interface for all those low-cost manufacturers and get paid by them
As far as trends in IoT goes, I feel like Tuya is mostly positive. I bought some cheap smart plugs at Costco and the default app was worthless. When I learned that they were Tuya-compatible, I managed to get a half-decent (relative to cost) experience out of them. It seems to me that the alternative are a bunch of unmaintained one-off apps for each fly-by-night manufacturer. With a standard protocol and app I think old devices will live a bit longer at least.
Perfect (better) world it's all open source, but c'est la vie.
This sounds somewhat backwards to me but maybe missing something... We got a bunch of Tuya devices and was barely aware they even have an app. They paired out of the box to a zigbee2mqtt gateway on the local airgapped network without fuss. No apps, online servers, api keys, vendor signature checks, or such shenanigans at all. I don't think the motion sensors we have from them have the capability to send dhcp over ip even if they wanted.
The Fingerbot also seems to operate over zigbee? Why would you need a developer account in the first place? And why would anyone but Tuya themselves want to hook into their cloud?
This is like the fifth article I've read about the McDonald's app not having any sort of server-side validation. How do they keep getting this wrong???
This sort of things happens a lot. A few years ago a British bus company put certificates in the app to sign tickets.
The HSBC UK app will not run if you have any apps installed from outside play store. I cannot log into the website without the app. Luckily all I have with them is a lightly used credit card with a low limit so I have just stopped using it and rely on paper statement.
I find it disturbing that any app can examine your device in this much detail.
> I find it disturbing that any app can examine your device in this much detail.
When I did a tiny bit of Android development a few years ago, I was astonished how free the app I made was to just examine the file system. I assumed it would be like the web, where each website can have its own little SQLite database and cookie store equivalent, but that's it. I don't know if it's changed, or if it was just because I was in a "dev mode" somehow, but that was very surprising.
You could try getting them to give you a physical security key, they used to supply them and I think still will if you can't use the app (just say it doesn't work on your phone). I have one and the website still works with it.
The HSBC UK app runs perfectly well on my Android phone, including full biometrics, 2FA for the website and for major functionality like transferring money.
I have at least a dozen apps installed on my phone that are not from the Play Store - a mixture of other stores (Samsung/Epic) and apps that are not from any store but I've compiled myself, or downloaded APKs directly from the developer website.
This is terrifying to me, and part of the reason I've kept the little authentication calculator instead of moving to the app. Also the app won't work on root and has a fairly narrow range of Android versions it's compatible with.
I travel a lot and I would benefit from opening a "global money" account. However this requires the app, so I've never done it.
If they ever drop support for the physical authentication calculator, I will move to a different bank that doesn't require an app. Which is increasingly difficult these days.
Well, they're also an app that relies (at least on Android) on Google's Play Integrity DRM to "keep it safe" from those pesky root users. And like clockwork, this false sense of security leads developers into stupidly trusting the client.
As a contractor who works building apps (and their server backends) for big clients: I don’t give a fuck. I just do the minimum so the app works. The worst that can happen is that the client asks me to fix the flaw later on, for which I will bill more hours.
Can't the client sue for damage though? Especially in a courtroom-happy country like the US, perhaps causing financial trouble to a corporation the size of McDonald's would not exactly lead to a happy, carefree livelihood
I assumed there is always some technical documentation/app architecture and some mandatory (server side) security you have to follow, but reading this I'm being too optimistic.
More importantly, why would anyone care? Is this some 5th dimensional chess marketing strategy by McDonald's? I hear more about their app these days than ever, and more than about any other security issue anywhere else.
I think it's the combination of trying very hard to usurp the user's control over their device, the lack of obvious reasons to do so, and the size of the brand. It doesn't surprise anybody when a bank does this, and nobody cares when some crappy pay to win game does, but McDonalds?!
I haven't eaten food from McDonalds in years and have never even considered installing their app, but if inspecting and reverse-engineering Android apps was my thing, theirs would have almost certainly caught my interest.
> I thought not trusting clients was already security 101?
Of course it is. Always has been.
The security field is riddled with complete nonsense. Much of it even couched in terms of "best practices". It's the perfect field for people with zero specific knowledge or experience to be trusted with management or engineering - since it doesn't matter until it did matter, at which point a mild non-apology is usually sufficient.
Security field isn't about security, it's about managing liability. "Best Practices" don't need to result in actual security - what matters is that, if you follow them and a security incident happens, you can say you followed the Best Practices and therefore It's Not Your Fault.
McDonald’s is seriously the strangest company when it comes to the way they push your app at you. They literally ask you if they’ve installed their app as the first question when you show up at a drive-thru. I don’t trust them at all and there is no way I’m installing their stupid app.
Regarding what I see as a common thread between this example and the ongoing TikTok saga in the US -- why the hell do apps even have access through these parts of the API in the first place? Shouldn't iOS/Android be restricting these permissions? It seems insane that only a minority of people seem to find the current situation insane.
Readit News
Why am I so sure about this? I live on the other side of the world, the app is almost certainly an entirely separate codebase from the Polish one the article is about, and yet here too it has the worst anti-root measures of any app by any remotely large company, including finance, healthcare and government apps. Enormous numbers of false positives. Even for those with the most mainstream Android models around.
This will all just come down to one person at McD's HQ who is forcing through these ridiculous ideas and costing their company a bunch of money in the process. No other multinational employs this strategy to any similar degree.
Dead Comment
But if someone is seriously thinking client-side security works, yeah the app deserves your review - and probably some reversing, just for fun.
I am reasonably confident that some almost-AOSP aftermarket ROM is a less weird operating environment than the weird hacked-up things official vendors are shipping.
Ah, it's the same with supporting browsers other than Internet Explorer!
https://github.com/chiteroman/PlayIntegrityFix
Given the audience here, I hope many would agree it's pitiful that developers are wasting their time building this junk. Some poor sap had to make this, probably sighing and shrugging at the end of each line of code.
Unions or professional body membership is becoming more important for programmers. People need to be able to say "I studied what you asked me to make, and refuse to work on this illegal, insecure, depressing cruft, and if you fire me for having professional ethics my lawyers will empty your company bank account." Otherwise technologists become just tools of destruction.
This only works if everyone or the vast majority join unions. Otherwise, those who join will get penalised with lower offers or no offers at all.
This is a common objection but I think it's wrong. Putting aside the huge differences between US (at will) and global employment law, the idea of a fluid, frictionless workforce is quite the myth. Keeping wages down and conditions poor very much relies on the propagation of that myth that ethics will work against you. so please be careful not to do yourself a disservice (if indeed you are a developer).
In reality quite small minorities have a disproportionate impact on change. Some accounts claim it's as low as three percent. I'm sceptical of that, but the fact remains; if only a handful of people object but with severe consequences by the force of law, employers will play it safe. I find it unlikely that any employers would survive long if it transpired they were disfavouring members of IEEE, ACM, IET or whatever.
I think this might be an interesting one to consider, other than the "depressing" bit of course. The problem is, I think, if you have the accreditation and you develop an insecure application, do you lose the accreditation? What's the tradeoff?
In my experience it’s a symbolic political power that management has effective ways of limiting.
Then again, mobile apps are like this tend to be junior work, outsourced to software mills that just burn through juniors cranking out garbage assembled 10% of polyfills and 90% of advertising SDKs. Yes, at this point of your career, you can still say "no" - the company will happily replace you with some other junior, while you replace some other junior somewhere else.
In 2025? Haven't you noticed the massive layoffs by the big companies. Check r/cscareerquestions and read the posts from seniors unable to find a job
What if they didn't know and it's just incompetence?
Ah, this reminds me of the Tuya app.
I've done some ssl unpinning and mitm to see requests going in and out of my phone, it's pretty fun and there's often really nice and easy to use restful APIs underneath. Among them I've also done a couple of banking apps and they weren't particularly defensive either. That's great; as a user I'm empowered by it and like TFA says, it's totally fine from a security standpoint if you just don't trust the client to do anything they shouldn't be able to do. It shouldn't be your form validation that stops me from transferring a trillion dollars, and though I haven't tried, I'm sure that's not the case for those apps. All it does is allow me to get my monthly statements with a for loop rather than waiting for a laggy UI and clicking through each month.
Now, Tuya is a Chinese company offering a bunch of cheap IoT devices like smart power switches and IR motion detectors. You can interact with everything through their app. That app for some reason has spent by far the most resources on anti-RE of any apps I've seen. I already bought your hardware, mate. Please let me use it on my local network. My smart home infrared motion sensors were meant to turn lights on when I enter a room. But they don't feel very smart when I'm standing in the dark for 4 seconds while they check with a server in China. I don't even need a clean API; just let me see what you do, and I'll do something similar, no support or documentation necessary. But they go through extensive measures to prevent you from interacting with the hardware you bought and which is sitting in your home.
This was a while ago, but I think for the motion sensing in particular, I managed to just put them in a subnetwork with blocked internet access, and snooped on the network to catch their DHCP requests when they tried to call home. This would happen every once in a while presumably for settings/update checks, but crucially also when there was motion detected, and I didn't mind a few false positives. So in the end they were very quick, locally functioning, privacy-friendly little devices!
As far as trends in IoT goes, I feel like Tuya is mostly positive. I bought some cheap smart plugs at Costco and the default app was worthless. When I learned that they were Tuya-compatible, I managed to get a half-decent (relative to cost) experience out of them. It seems to me that the alternative are a bunch of unmaintained one-off apps for each fly-by-night manufacturer. With a standard protocol and app I think old devices will live a bit longer at least.
Perfect (better) world it's all open source, but c'est la vie.
The Fingerbot also seems to operate over zigbee? Why would you need a developer account in the first place? And why would anyone but Tuya themselves want to hook into their cloud?
The HSBC UK app will not run if you have any apps installed from outside play store. I cannot log into the website without the app. Luckily all I have with them is a lightly used credit card with a low limit so I have just stopped using it and rely on paper statement.
I find it disturbing that any app can examine your device in this much detail.
When I did a tiny bit of Android development a few years ago, I was astonished how free the app I made was to just examine the file system. I assumed it would be like the web, where each website can have its own little SQLite database and cookie store equivalent, but that's it. I don't know if it's changed, or if it was just because I was in a "dev mode" somehow, but that was very surprising.
I have at least a dozen apps installed on my phone that are not from the Play Store - a mixture of other stores (Samsung/Epic) and apps that are not from any store but I've compiled myself, or downloaded APKs directly from the developer website.
This isn't true.
i wonder what caused the change
as others have said, you can ring them up and get a physical security key, it works for the website
I travel a lot and I would benefit from opening a "global money" account. However this requires the app, so I've never done it.
If they ever drop support for the physical authentication calculator, I will move to a different bank that doesn't require an app. Which is increasingly difficult these days.
I can 100% guarantee that’s what happened here.
To you, you mean, right?
Deleted Comment
I haven't eaten food from McDonalds in years and have never even considered installing their app, but if inspecting and reverse-engineering Android apps was my thing, theirs would have almost certainly caught my interest.
Honestly, it’s amazing it’s not worse!
secure enclaves, secure virtualization, trusted execution environment, trusted platform, confidential computing, protected execution, LaGrande, protected launch, hardware attestation, ..
Of course it is. Always has been.
The security field is riddled with complete nonsense. Much of it even couched in terms of "best practices". It's the perfect field for people with zero specific knowledge or experience to be trusted with management or engineering - since it doesn't matter until it did matter, at which point a mild non-apology is usually sufficient.
If enough customers order with the app, the drive through line moves quicker. Probably still not as fast as when they used to premake food.