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???
The HSBC UK app will not run if you have any apps installed from outside play store. I cannot log into the website without the app. Luckily all I have with them is a lightly used credit card with a low limit so I have just stopped using it and rely on paper statement.
I find it disturbing that any app can examine your device in this much detail.
When I did a tiny bit of Android development a few years ago, I was astonished how free the app I made was to just examine the file system. I assumed it would be like the web, where each website can have its own little SQLite database and cookie store equivalent, but that's it. I don't know if it's changed, or if it was just because I was in a "dev mode" somehow, but that was very surprising.
I 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.
It is somewhat disjointed.
When I last changed phones, between phones from the same manufacturer both running recent Android versions, the "copy apps, settings, and data" process didn't include all app data either so I need to take extra steps.
I don't think there will be any big push to address the matter, because for the vat majority of users it isn't a big issue: most of their data is synched to various services anyway and that which isn't wouldn't be particularly missed if lost. There are very few app dealing with important data that are local-only.
From what I can tell, Google intentionally broke Android’s backup subsystem in order to force people on to their non-E2E encrypted cloud storage.
It makes me sad that, in practice, Android somehow manages to give people less control over their devices than iOS.
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.
Older software tended to be less obnoxious about it. I have never had a desktop app refuse to run for this sort of reason.
Desktop software installers do not claim to offer this security. Mobile OSes claim to be sandboxed so your expectations are different.
The sorts of applications you install are different too. Many mobile apps are things you would do using a web browser on a desktop. They should therefore be locked down the way webapps are.
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
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.
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.
I have at least a dozen apps installed on my phone that are not from the Play Store - a mixture of other stores (Samsung/Epic) and apps that are not from any store but I've compiled myself, or downloaded APKs directly from the developer website.
This isn't true.
I travel a lot and I would benefit from opening a "global money" account. However this requires the app, so I've never done it.
If they ever drop support for the physical authentication calculator, I will move to a different bank that doesn't require an app. Which is increasingly difficult these days.
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.
And the idea that this kind of check can't be defeated.
Never trust the client. Anything the client has access to, whether "protected" by Play Integrity or not, should be considered compromised.
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/....
I can 100% guarantee that’s what happened here.
To you, you mean, right?
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
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
I haven't eaten food from McDonalds in years and have never even considered installing their app, but if inspecting and reverse-engineering Android apps was my thing, theirs would have almost certainly caught my interest.
Honestly, it’s amazing it’s not worse!