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?
Sounds logical, but it doesn't seem to be the case. The backup options are "Photos/Videos" "phone data" and "both". I don't think phone data includes all app-local data. Contacts, calendar entries, and such, get synced but that isn't due to a global backup process that is the Google apps syncing with your Google account. Other apps could do that with the right integrations, but not all have the option and either have no backup or backup by syncing to their own service or an external option like an S3 compatible store.
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.
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.
Linux has containers for this - firejail, flatpack and others have support for this.
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.
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.
It is - and there are other ways to make that shortcut appear even without an app. But that app also got nerfed some time ago, and in general, even when file managers can access Android/data, that folder is missing many subdirectories, and most of those that can be seen, are empty. For some reason, you can get at some more files and folders in this structure if you plug the phone to your PC (this is apparently intentional). But none of that gives you access to any of the interesting/useful data applications store, and then applications also have a special super-private folder elsewhere. You can learn that and more through an app like https://github.com/MuntashirAkon/AppManager running in ADB over Wi-Fi mode (no-root).
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.
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.
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.
This is terrifying to me, and part of the reason I've kept the little authentication calculator instead of moving to the app. Also the app won't work on root and has a fairly narrow range of Android versions it's compatible with.
I travel a lot and I would benefit from opening a "global money" account. However this requires the app, so I've never done it.
If they ever drop support for the physical authentication calculator, I will move to a different bank that doesn't require an app. Which is increasingly difficult these days.
Well, they're also an app that relies (at least on Android) on Google's Play Integrity DRM to "keep it safe" from those pesky root users. And like clockwork, this false sense of security leads developers into stupidly trusting the client.
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.
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”
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
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.
This is why I always find it weird that in the US (and a lot of other countries) the stoplights are on the end of the intersection, instead of at the entrance. If they're at the entrance, there's no dillema - you can't cross the light if it's red. If it's yellow, you brake if you have time, but if not, it's fine to keep going - the opposing light is going to wait a few seconds before turning green specifically to avoid this.
This also encourages drivers to actually stop in the right place (since they can't see the light otherwise), and it's friendlier for pedestrians since it avoids drivers stopping on top of the crosswalk.
(I've also never heard of the turn-right-on-red rule anywhere other than the US. Over here in Portugal if it's fine to turn right while the light is red, there's just going to be a separate green/flashing light to turn right. A lot clearer!)
But if we were to modify signal positioning to make it impractical to stop past the white line, fewer people would overshoot and wait.
We do this kind of thing in many other places in life. Imagine if we didn’t use barriers anywhere and only used painted lines to tell people where to be - don’t walk to this side of the line, that’s where the valuables are “stored” (no walls, just markings.)
We use ‘guardrails’ all over the place. Sometimes to nudge people (one can jump a literal guardrail), sometimes to prevent injury (you simply cannot physically access the active industrial robot without intentional effort), and all kinds of inconvenience in between to suggest where to be.
Place the lights so that they’re only visible further back, and people will stop further back.
When I stop past the while line, it's almost always because I thought the way was clear, but then something happened, and I had to stop, and then the light changed, and I was stuck past the white line.
If you implement your plan I would never even see the light become red!
And that's fine, because you've _already crossed the line_ and therefore you can (and should) go through. You're no longer running a red light at this point, since it's behind you, you're just crossing the intersection like normal.
Do you drive much in cities? I'll lay out something that happens all the time:
I cross the line slowly, and some pedestrian darts out, so I stop, by the time they cross, the opposing traffic has a green, I however (in your scenario) do not know this because I can't see that the light is red for me.
So now I'm driving forward, thinking I'm good and some car comes flying through because it's green for them, and they can't see me because of the layout of the block.
I need to see and know that the light is red and just stop and wait there.
Similar things happen when the car in front of me wants to turn left, but didn't bother with a blinker - I'm in the intersection, past the line, and suddenly I need to stop because he's turning. He turned, but now it's red for me and I better wait right there, and not go forward, because other cars are about to drive.
You also aren't taking into account the varying heights of cars. If I'm in car behind a van, I won't be able to see the light because it's directly above the van so I can't see it.
Also:
Your goal is to keep cars from going too far into the intersection after a red, right?
The problem is you are assuming this happens due to incompetence, but it actually happens because of driving conditions like I mentioned.
There's usually two - one suspended above the stop line, and one lower, on a pole on the side of the road, usually around eye level. This way both the driver in the front and drivers in the back get a clear view.
This is not a hypothetical "if", pretty much every country in Europe has traffic lights set up like this. Just take a look at Lisbon or Amsterdam in street view to see what I mean.
Jesus Christ the victim blaming in this thread is insane. This is why deepfake laws are needed. Sure OP used Meta AI, and consented, but if I did that I'd probably be consenting to using the picture _for that one session_, where I'm in control. Definitely not for this, they shouldn't be able to put this in their ToS.
Absolutely. The public doesn’t care what word games you play or what rights you allocate yourself in a terms of service if you pull off something shady you deserve all the bad publicity you get
> but if I did that I'd probably be consenting to using the picture _for that one session_, where I'm in control.
You mean you you'd be wanting to consent to one session, while actually affirmatively consenting to something else. On one hand I agree there would be nothing wrong with limiting the scope of what is legally allowed in a ToS. On the other, I also think it's good that single parties can't just spontaneously wish away conditions of business agreements they don't like (although I imagine with a modicum of effort, you could modify that consent with Meta at any point).
There's a comment in the reddit thread about how consent to Meta is invalid because Meta is essential to participating in modern society - basically saying that being a Meta user is a civil right. Bonkers.
Companies need to be reminded that their operation is subject to our own ToS, the law, and it supercedes theirs. We can change it at any time and the sycophants defending any legal behavior aren't winning any favors. The behavior you see on HN playing defense for violations of privacy is disgusting, but I'm glad it's out in the open for everyone to see how far they'll go.
I don't think it's victim blaming to say that the linked Reddit post is missing critical details (and indeed any details) about what precisely is going on. I agree that it's quite bad if Meta did this without the user specifically asking them to do so.
Also, people speak languages other than English, and things like Unicode normalization mean that identical characters can be encoded differently depending on what's being used to type the password in, and I'd be willing to bet most websites don't handle that properly. Not to mention non-latin alphabets, which can be even messier. Good luck explaining to someone that the reason their bank's website isn't matching their password is due to there being two ways to encode "olá" (and there isn't a good way to use a specific one, or know which one was used to set the password!)
The Kindle's light is much more diffuse than the iPad's though, much closer to just having a reading light on, which you'd need anyway for a physical book.
The Kindle's light comes from a ring of linear LEDs that goes through a plastic sheet called a diffuser -- same as the light from an iPad. In the iPad the diffuser is behind the image whereas in the Kindle, it is in front of it, but why is that better or "more diffuse"?
>much closer to just having a reading light on
First of all, that contradicts the evidence from my eyes, but second of all, even if it were true, you'd have to persuade me that reading an old-fashion paper book with a reading light is any better at helping me get to sleep at night than reading from an iPad. I'm not buying that one either mainly because a reading light is going to throw more light onto the ceiling, where of course it gets reflected down again, and neuroscientists know (and the Scandinavian tradition "knew" in practice decades ago) that light from the top of the field of vision is more disruptive to sleep than light coming straight into the eye or from the sides or bottom of the visual field.
The eReader manufacturers have done a great job of marketing the alleged benefits of their front lights, even though they’re simple LEDs like everything else. I look for any actual studies on the subject every couple of years and come up empty.
(I do prefer an eReader over a tablet, but I don’t think the light is magically better.)
Everybody knows that the modern scholar obtains information from the world through papers, either from google scholar or from the latest libgen domain.
Missing from the graphics API list is WebGPU - which is not really just for the web. I've not used Metal, but from what I've heard, the API resembles Metal a good bit, which is a good thing since it's supposedly the nicest of the low-level graphics APIs (and having used both Vulkan and WebGPU, I definitely agree WebGPU has a way nicer API). The libraries backing WebGPU implementations in the browser can be used standalone (Dawn[1] is written in C++ and wgpu[2] in Rust), which means that they can be used on an otherwise native application that would have used some native graphics API.
Easily is the operative word. Blockbuster was easy but you had to drive there -- netflix is easier. Libraries similarly require driving (unless you use overdrive / similar) but piracy is easier for many as well. Books just haven't found their spotify/netflix; the kindle store is basically 2009 itunes.
I don't think many realize how much libraries have via internet ("overdrive / similar") these days. You don't even have to show up in person to sign up at my local library.
Libgen and the like tend to just have more on hand though, and that's the big differentiator in usability IMO. There are things your local library just isn't going to have a copy of but libgen will. After that happens once, why bother with the library again? Outside of "it's legal" or "I find more moral" type concepts there tends not to be a strong reason.
Nowadays I don't bother with Reichelt or Conrad and just get must of my stuff from Mouser. They offer leaded solder in all kinds of forms. I have to say that I have not tried out if they will actually deliver it to Germany though.
Not true, e.g. in Portugal: https://www.nos.pt/movel/esim (though you need to go to a store to pick-up the QR code, I think to avoid people from other countries using it?), https://www.meo.pt/servicos/movel/tarifarios-telemovel/e-sim same thing
reply