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.
> [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.
It has certainly been locked down a bit. This makes easily backing up all your data using some techniques harder/impossible.
I can't include podcasts in the backup I do via rsync via termux anymore, unless I switch to an app that uses a shared storage area instead, as termux can not longer read app directories only its own and shared storage. You have to rely on each app that used app-local storage to have its own backup method. Not that I really care from the podcast PoV, hence I've done nothing about it, but it is a sign of apps being better sandboxed at the filesystem level than they used to be.
That's doesn't make sense either - not an android iser or dev but shouldn't there be a system level backup interface. Even if its storing the app-local storage as an opaque blob with a label?
Is it not the same for computers most of the apps data is accessible by all the apps. Mobile OS came from the paradigm of the past and as the way we use our phones change so do the way how mobile os work. For a long time Android devs have wanted to obfuscate the disk from the user like iOS does but have faced push back from users and developers so in the end they created a permission where an app needs to ask permission to access the disk.
Keeping the file system a black box or allowing user/apps to mess with it is a development question of the times dumb it down or not. Then people here complain children don't know anything about computers these days well yeah because we have dumbed it down so much in the name of security and usablity.
Sure, but all the interesting data is stored in a subtree that mostly won't even show on that list. In fact, there doesn't seem to be a way for a user of non-rooted phone to view this data. This sucks.
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.
If you're near a branch you can also just pop in and ask for one; might be faster. I did that when the battery ran out on my last one. There's no process upfront, you then have to pair it with your account. Well,you will probably have to convince them to switch your account to use a physical key - maybe that means you have to call anyway, I don't know.
In many countries, if the consumer gets defrauded, the bank foots the bill.
I don't think the problem here is consumers getting defrauded by having an insecure rooted device. It's fraudsters using the mobile app APIs for nefarious purposes, and the best way to prevent that is to use SafetyNet and other similar mechanisms.
> and the best way to prevent that is to use SafetyNet and other similar mechanisms.
It's not the best way to prevent it. It's the easiest way for the bank to avoid liability.
The ugly truth of cybersecurity is that, in the real world, most of it is an exercise in shifting liability around and diffusing it. Making systems actually secure is not necessary.
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.
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.
It makes sense, to some degree, that for example some banking apps refuse to run if they detect that the phone has been rooted, or even to go as far as to refuse to run if there are non-Play apps on the phone.
Maybe some apps with DRM media playback do this kind of check too, yes. Haven’t used Android for many years now.
Hopefully iOS stays the way it is where apps don’t get so much info about other apps on device. I prefer it that way.
GPIDRM doesn't protect against much, even if it's perfect [0]. What it gives you is an API your Android app can call into to inspect the device status.
That's not enough because the owner of the phone can just twiddle that memory between you calling the API and using the value. You fully own the code that runs on your devices, and if you don't like it then you can just choose to run different code. The GPIDRM hinders some users who want to fully own their device and also use your app, but it doesn't actually protect your app from being executed in other environments (similarly with any other modification to how the GPIDRM might function, short of it physically decrypting the code/data you intend to run and only ever running in environments that would somehow prevent people from backing up those decrypted bytes -- or, similarly, physically decrypting data unique to a particular instance of using the app and not useful for any reason when somebody else runs the app).
When, then, does GPIDRM make sense to use?
_Arguably_ the thing that banks do isn't terrible [1]. Their servers are authenticated, so it's not a security thing. They're just managing risk (people with rooted phones might be more likely to have root-level malware for example). If somebody has a rootkit leaking banking details and the attacker is also willing to pay $10 to borrow their phone number for the day, the bank account will be fully compromised. When that happens, the bank is on the hook some fraction of the time. The bank server trusts requests to either come from a real user or a user with stolen credentials, and they're trying to reduce the chance of the latter (but not eliminate, even from rooted Android phones).
How does McDonald's differ? There are no server-side checks, no passwords, no logins, no crypto handshakes, no anything. If you send a request pinky promising you're a trusted client then you'll get your free food. The implementation was so bad that the TFA demonstrated compromising it on a phone which _correctly_ passed the GPIDRM check.
[0] No such technique can be perfect. At its core, it relies on a secure hardware enclave. Physical keys are always reversible with enough time and effort, in time _linear_ in the key length. The goal is just to create a constant factor big enough that almost nobody with expensive enough tools to dismantle the chip and go probing is willing to go through the effort (or, ideally, not able to with the current generation of technology, so that rotating keys every few years can keep up with reversing efforts).
[1] I'd be shocked if people with rooted Android phones were actually more likely to be victims of phishing/malware/....
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.
That goes without saying in the software business today. I was in software for decades and I’ve never seen it so cynical. Shameless profiteering seems to be the gold standard strategy. It’s like Gordon Gecko style greed.
That's cause there are people that make the mean girls from mean girls look like the nice girls
Infighting, KPIs, comp packages, weird ass games trying to build something new or try to learn is actually looked down upon. Very medieval with hunt vibes
Actually interested in learning more about the attack surface area?
I've had my SSN stolen learned multiple people are using it lol so I doubt banking info stolen from Mickey Dees would make a difference could something worse be achieved
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
A company doing outsourced dev for someone the size of McDonald’s would have an iron clad statement of work that the would point to and say “show us where you asked for server validation”
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.
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.
> any employers would survive long if it transpired they were disfavouring members of IEEE, ACM, IET or whatever.
I highly doubt most employers even know what those organisations are. Taking it even further, there is probably even a significant amount of devs that are unaware of them as well. I don't think devs have this much power. Unless you are a tech company, devs are likely highly replaceable and in my opinion the trend goes in that direction. Obviously, this excludes skilled FAANG devs
> 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?
The ones who own the firm do. They are the managers.
Also I think you mistook my comment for something about financial success. I am questioning how much power a lawyer has to invoke moral authority (unless they own the firm).
Worth mentioning that the IT jobs crisis is mostly an US thing.
It's still relatively easy to find a dev job in Poland or many other EU countries. It's worse than before, as in bootcamps are no longer enough, but as a mid+ it's still very easy.
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 growth of fake applicants and fake job listings are another issue entirely, but it still is easier to find an entry-level job than senior-level or above.
Wasn't there a public transport app a while back that checked ticket prices on the client? Where you could change the API calls to purchase the same tickets for 0 money (EUR? doesn't really matter).
Games that aren't turn-based at least have the excuse that they can't afford the latency. They have explicitly decided not to be secure so they can pretend to "know" client-side that you ran around the corner and can be sniped by your opponent in a timeframe that's impossible because of the speed of light.
Does anyone else remember the days of bottle cap instant-wins? I don't want these apps. Remember affordablefast food? I spent $14.74 to wait in drive thru for 15 minutes to eat cold fries and a slice of patty with cardboard bacon and solidified cheese whizz? Can't blame the staff, they aren't seeing any of those profits.
If I turn off location, ad tracking, or other permissions on the iOS version the McD's app only shows the breakfast menu and no deals are available. This is on a loyal, active account with 40k reward points. On iOS you do not have the option to root your phone so I just eat there less which is probably a good thing anyway.
Coupons aside, the whole process of eating at McD in PL is demeaning to me every time I'm there. From the clunky app that you basically must have to get anything at a decent price, to the kiosks that work slower that ATMs 20 years ago, to the whole flow of selecting your meal that requires like 15 taps that feels like installing Windows 98, up to the end where it tries to sell you some dessert that you would have selected if you wanted it in the first place.
The app was always useless; I imagine you still can get showered with paper coupons if you ask about them, giving you the same deals without the burden of installing more crapware on your phone.
There used to be an abundance of coupons e.g. for 2 or 3 small burgers at an actually nice price.
Currently all coupons at or below 10 PLN are coffee, and not even cappuccino or flat white - but the "kawa czarna" or "kawa z mlekiem" which is watered down.
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.
In news press about similar nonsensical and costly business decisions some of them end up being an exec getting kickbacks or other self dealing
think of it as each country being its own company, contracting out to a local software house which may have different ideas of what security means
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.
Yes but you have an appreciable number of customers who are running wacky mid-market android devices.
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.
This is not a factor I consider when reviewing my experience using an app.
That's entirely reasonable, but I think it's unlikely to make a difference in most cases.
No, but it's a papercut. You can piss off 1% of your customers and get 1 star reviews, but do that a bunch of times and it adds up.
I'd be happy if the number leaving negative reviews was that high.
> [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.
> It seems to me that the alternative are a bunch of unmaintained one-off apps for each fly-by-night manufacturer
Nah, there are options!
HomeAssistant, zigbee2mqtt, ZHA,deCONZ.
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.
It has certainly been locked down a bit. This makes easily backing up all your data using some techniques harder/impossible.
I can't include podcasts in the backup I do via rsync via termux anymore, unless I switch to an app that uses a shared storage area instead, as termux can not longer read app directories only its own and shared storage. You have to rely on each app that used app-local storage to have its own backup method. Not that I really care from the podcast PoV, hence I've done nothing about it, but it is a sign of apps being better sandboxed at the filesystem level than they used to be.
That's doesn't make sense either - not an android iser or dev but shouldn't there be a system level backup interface. Even if its storing the app-local storage as an opaque blob with a label?
Is it not the same for computers most of the apps data is accessible by all the apps. Mobile OS came from the paradigm of the past and as the way we use our phones change so do the way how mobile os work. For a long time Android devs have wanted to obfuscate the disk from the user like iOS does but have faced push back from users and developers so in the end they created a permission where an app needs to ask permission to access the disk. Keeping the file system a black box or allowing user/apps to mess with it is a development question of the times dumb it down or not. Then people here complain children don't know anything about computers these days well yeah because we have dumbed it down so much in the name of security and usablity.
Definitely the same for computers. LOTS of software rely on saving data on "secret" locations for shareware-style trials.
macOS for one has been asking to allow access to specific folders. Other OSs are possibly starting to do the same, but it used to be a free-for-all.
By default you can `ls` almost anything on an entire drive.
That is how it works. Apps on android and iOS can’t access data outside of their contsiner.
Afaik all apps on android have the ability to list directories across most of the "sdcard" file system even without storage permissions.
Sure, but all the interesting data is stored in a subtree that mostly won't even show on that list. In fact, there doesn't seem to be a way for a user of non-rooted phone to view this data. This sucks.
Do you mean Android/data? This is accessible on a non-rooted device using Marc apps & software's "Files" https://play.google.com/store/apps/details?id=com.marc.files (an easily accessible shortcut to the native Android file manager).
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.
Thanks, I was thinking of phoning and asking, but good to know there is some point in waiting in the queue to talk to someone!
If you're near a branch you can also just pop in and ask for one; might be faster. I did that when the battery ran out on my last one. There's no process upfront, you then have to pair it with your account. Well,you will probably have to convince them to switch your account to use a physical key - maybe that means you have to call anyway, I don't know.
It used to let you use it with a full-on rooted phone, it just popped up a message saying 'it's not our problem if you get robbed'
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 wonder what caused the change
In many countries, if the consumer gets defrauded, the bank foots the bill.
I don't think the problem here is consumers getting defrauded by having an insecure rooted device. It's fraudsters using the mobile app APIs for nefarious purposes, and the best way to prevent that is to use SafetyNet and other similar mechanisms.
> and the best way to prevent that is to use SafetyNet and other similar mechanisms.
It's not the best way to prevent it. It's the easiest way for the bank to avoid liability.
The ugly truth of cybersecurity is that, in the real world, most of it is an exercise in shifting liability around and diffusing it. Making systems actually secure is not necessary.
The app works perfectly well on my device, parent comment is just mistaken.
The HSBC app runs fine on my rooted phone with a few magisk plugins and 5 marketplaces installed and a ton of sideloaded apps.
It used to work on my old phone. Stopped with nee one. May depend on Android version or when you installed.
Do you happen to remember which bus company this was? Is there any article you can link me too as I’m quite interested in reading some more on it.
I think it was Arriva. Defineitely one that operated in Manchester st the time. Cannot find a link.
The app works for me just fine despite having lots of non-google play apps installed, is this an Android 15 thing?
It works fine for me on Android 15 with non-Google Play apps installed too.
Kind of ironic since you can't easily export data as an end user without some friction
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 isn't true.
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.
I don't know much about this. Is this a (possible fundamental) flaw in Google's Play Integrity DRM, or did the developers implement it wrongly?
DRM doesn't protect, it only delays.
Never trust the client. Anything the client has access to, whether "protected" by Play Integrity or not, should be considered compromised.
It makes sense, to some degree, that for example some banking apps refuse to run if they detect that the phone has been rooted, or even to go as far as to refuse to run if there are non-Play apps on the phone.
Maybe some apps with DRM media playback do this kind of check too, yes. Haven’t used Android for many years now.
Hopefully iOS stays the way it is where apps don’t get so much info about other apps on device. I prefer it that way.
What's implemented wrongly is the idea that this kind of client side check somehow removes the need for server side verification.
And the idea that this kind of check can't be defeated.
GPIDRM doesn't protect against much, even if it's perfect [0]. What it gives you is an API your Android app can call into to inspect the device status.
That's not enough because the owner of the phone can just twiddle that memory between you calling the API and using the value. You fully own the code that runs on your devices, and if you don't like it then you can just choose to run different code. The GPIDRM hinders some users who want to fully own their device and also use your app, but it doesn't actually protect your app from being executed in other environments (similarly with any other modification to how the GPIDRM might function, short of it physically decrypting the code/data you intend to run and only ever running in environments that would somehow prevent people from backing up those decrypted bytes -- or, similarly, physically decrypting data unique to a particular instance of using the app and not useful for any reason when somebody else runs the app).
When, then, does GPIDRM make sense to use?
_Arguably_ the thing that banks do isn't terrible [1]. Their servers are authenticated, so it's not a security thing. They're just managing risk (people with rooted phones might be more likely to have root-level malware for example). If somebody has a rootkit leaking banking details and the attacker is also willing to pay $10 to borrow their phone number for the day, the bank account will be fully compromised. When that happens, the bank is on the hook some fraction of the time. The bank server trusts requests to either come from a real user or a user with stolen credentials, and they're trying to reduce the chance of the latter (but not eliminate, even from rooted Android phones).
How does McDonald's differ? There are no server-side checks, no passwords, no logins, no crypto handshakes, no anything. If you send a request pinky promising you're a trusted client then you'll get your free food. The implementation was so bad that the TFA demonstrated compromising it on a phone which _correctly_ passed the GPIDRM check.
[0] No such technique can be perfect. At its core, it relies on a secure hardware enclave. Physical keys are always reversible with enough time and effort, in time _linear_ in the key length. The goal is just to create a constant factor big enough that almost nobody with expensive enough tools to dismantle the chip and go probing is willing to go through the effort (or, ideally, not able to with the current generation of technology, so that rotating keys every few years can keep up with reversing efforts).
[1] I'd be shocked if people with rooted Android phones were actually more likely to be victims of phishing/malware/....
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.
I can 100% guarantee that’s what happened here.
> the worst that can happen
To you, you mean, right?
That goes without saying in the software business today. I was in software for decades and I’ve never seen it so cynical. Shameless profiteering seems to be the gold standard strategy. It’s like Gordon Gecko style greed.
That's cause there are people that make the mean girls from mean girls look like the nice girls
Infighting, KPIs, comp packages, weird ass games trying to build something new or try to learn is actually looked down upon. Very medieval with hunt vibes
It's hardly surprising. Once they smelled cash in the water all the Gordon Geckos packed up their finance bags and moved into tech.
Actually interested in learning more about the attack surface area?
I've had my SSN stolen learned multiple people are using it lol so I doubt banking info stolen from Mickey Dees would make a difference could something worse be achieved
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
A company doing outsourced dev for someone the size of McDonald’s would have an iron clad statement of work that the would point to and say “show us where you asked for server validation”
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.
Is there anything you know about McDonalds as an entity that would lead you to believe they know about, or would prioritize, building a secure app?
Honestly, it’s amazing it’s not worse!
The said root checks for example?
Which indicate that the management wants to feel good, not that the app developers care about actual security.
They have money and want to make more money? This seems like a straightforward question to answer.
Yes, except the answer is opposite to what you think. Shitty and insecure apps make more money than decent and secure ones.
McDonalds has historically not put an emphasis on security, imo it's just that simple.
I thought not trusting clients was already security 101?
We're at something like 116 now and they keep coming up with funny terms for it.
secure enclaves, secure virtualization, trusted execution environment, trusted platform, confidential computing, protected execution, LaGrande, protected launch, hardware attestation, ..
It was, back when I took my intro to security class. And that was back in the day when we talked about domestic and export versions of RSA.
> 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.
You are right. And by now an "it will be fixed next month" seems to be enough. even when nothing is fixed.
sorry we only can install a literal rootkit on your device to detect tampering
I am still surprised by how often this is a problem
It is, but most software doesn't include security.
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.
Employees don't want to ask either, but corporate made it an item in mystery shop inspections.
They're trying to train you to use the app. You're expected to respond with your order code.
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.
Hand them a dumb phone from 1996. Doesn't need to have a subscription, just let them figure it out.
Hilariously well written.
"But the problem with checking if the user is a god, is that the user is a god. They can just tell you what you want to hear."
NISUS: Good. Out of the door. Line on the left. One cross each. Next. Crucifixion?
MR. CHEEKY: Ah, no. Freedom.
JAILER: Hmm?
NISUS: What?
MR. CHEEKY: Eh, freedom for me. They said I hadn't done anything, so I could go free and live on an island somewhere.
NISUS: Oh. Oh, well, that's jolly good. Well, off you go, then.
MR. CHEEKY: Naa, I'm only pulling your leg. It's crucifixion, really.
The author earned a discount on his Big Mac.
As they say in the US "we the people have decreed freedom ain't free" had a headache reading this lmao
If you can get a hot meal for 5 dollars idk as a poor person gotta rep the app even if its badly implemented
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.
> any employers would survive long if it transpired they were disfavouring members of IEEE, ACM, IET or whatever.
I highly doubt most employers even know what those organisations are. Taking it even further, there is probably even a significant amount of devs that are unaware of them as well. I don't think devs have this much power. Unless you are a tech company, devs are likely highly replaceable and in my opinion the trend goes in that direction. Obviously, this excludes skilled FAANG devs
> 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?
The same way it works in engineering. What happens when a building collapses due to not following engineering code?
I think you should study how well such professional posturing helps groups that have it (civil engineers, lawyers, etc).
In my experience it’s a symbolic political power that management has effective ways of limiting.
Uhh... lawyers are doing quite well for themselves, aren't they?
The ones who own the firm do. They are the managers.
Also I think you mistook my comment for something about financial success. I am questioning how much power a lawyer has to invoke moral authority (unless they own the firm).
Why would you want to continue working at such a place as a developer? It's not like it's hard to find another job as developer...
> It's not like it's hard to find another job as developer...
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
Worth mentioning that the IT jobs crisis is mostly an US thing. It's still relatively easy to find a dev job in Poland or many other EU countries. It's worse than before, as in bootcamps are no longer enough, but as a mid+ it's still very easy.
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.
It's easy to find entry level jobs? Where? I was trying for ages and barely anyone even replied to my applications
The growth of fake applicants and fake job listings are another issue entirely, but it still is easier to find an entry-level job than senior-level or above.
This is assuming that the developers who did that knew that it was bad and still chose to do it.
What if they didn't know and it's just incompetence?
The job market since 2022 says otherwise
Wasn't there a public transport app a while back that checked ticket prices on the client? Where you could change the API calls to purchase the same tickets for 0 money (EUR? doesn't really matter).
This applies to games too, and the games have even more ridiculous measures such as putting malware into end user kernels to try to compensate for it.
Games that aren't turn-based at least have the excuse that they can't afford the latency. They have explicitly decided not to be secure so they can pretend to "know" client-side that you ran around the corner and can be sniped by your opponent in a timeframe that's impossible because of the speed of light.
Just probably? Do we still need articles to point that out in ... 2025?
The main problem is not that mcdonald's app, it's what else has the same team worked on...
Does anyone else remember the days of bottle cap instant-wins? I don't want these apps. Remember affordable fast food? I spent $14.74 to wait in drive thru for 15 minutes to eat cold fries and a slice of patty with cardboard bacon and solidified cheese whizz? Can't blame the staff, they aren't seeing any of those profits.
*provably
If I turn off location, ad tracking, or other permissions on the iOS version the McD's app only shows the breakfast menu and no deals are available. This is on a loyal, active account with 40k reward points. On iOS you do not have the option to root your phone so I just eat there less which is probably a good thing anyway.
This article is dated 2023
Like it was mentioned here [1]: nobody cares.
[1]: https://news.ycombinator.com/item?id=42707238
In reality, since COVID, the coupons in Polish McD are so bad the app is almost useless. And the current version loads so sluggishly.
Coupons aside, the whole process of eating at McD in PL is demeaning to me every time I'm there. From the clunky app that you basically must have to get anything at a decent price, to the kiosks that work slower that ATMs 20 years ago, to the whole flow of selecting your meal that requires like 15 taps that feels like installing Windows 98, up to the end where it tries to sell you some dessert that you would have selected if you wanted it in the first place.
Yeah, other fast food chains use M4B kiosks which work much smoother. Although upsells are still there ;)
The app was always useless; I imagine you still can get showered with paper coupons if you ask about them, giving you the same deals without the burden of installing more crapware on your phone.
What did they change if you don't mind me asking?
I haven't notice that, can you elaborate?
There used to be an abundance of coupons e.g. for 2 or 3 small burgers at an actually nice price.
Currently all coupons at or below 10 PLN are coffee, and not even cappuccino or flat white - but the "kawa czarna" or "kawa z mlekiem" which is watered down.
The real surprise to me here is that grown ass adults are choosing to eat at McDonald's
Hey, my inner child needs a (unhealthy) treat every now and then!
In Europe at least the coffee is honestly pretty good if you just need fuel at an airport or whatever