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.
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.
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.
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.
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.
This is literally your first and only comment. From your username it looks like you made it specifically for that remark. I recommend you peruse the guidelines, as this type of unsubstantive flamebait is explicitly against HN rules.
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
[dead]
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.
1 reply →
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.
3 replies →
> [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.
1 reply →
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.
10 replies →
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.
2 replies →
The HSBC app runs fine on my rooted phone with a few magisk plugins and 5 marketplaces installed and a ton of sideloaded apps.
1 reply →
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
3 replies →
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.
1 reply →
The app works for me just fine despite having lots of non-google play apps installed, is this an Android 15 thing?
1 reply →
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?
4 replies →
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?
4 replies →
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
1 reply →
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.
McDonalds has historically not put an emphasis on security, imo it's just that simple.
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?
1 reply →
They have money and want to make more money? This seems like a straightforward question to answer.
1 reply →
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.
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.
1 reply →
> 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?
1 reply →
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?
1 reply →
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
1 reply →
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.
2 replies →
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.
[flagged]
[flagged]
This is literally your first and only comment. From your username it looks like you made it specifically for that remark. I recommend you peruse the guidelines, as this type of unsubstantive flamebait is explicitly against HN rules.
https://news.ycombinator.com/newsguidelines.html
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