[kovac]

I think this is the right place to start.

A free OS will empower developers to implement technical workarounds that could trick these apps into working there. If the OS is tightly controlled, we have no recourse.

Even in the worst case scenario, we could use a cheap big-tech-approved phone for these applications (a glorified digital token) and use the free phone for everything else. When there's enough adoption and trust in the new phone, non-technical avenues are available to influence these organizations to accept the alternative.

[BLKNSLVR]

I've kinda migrated to the worst-case scenario already and it's really not that bad - for my use case.

I have an old phone (actually running LineageOS rather than stock) that works as you perfectly describe as a glorified digital token. This device doesn't come with me. There's no banking I need to do, on a day-to-day basis, requiring said token, that has to be done right now or the world will end. It can wait until I get home (and I usually use the bank's web interface from a desktop). This device has minimal other apps installed, which limits bank app accessibility of other app data, and other app accessibility of bank data.

Then my GrapheneOS daily driver serves my day-to-day needs with minimal data leakage, tracking, ads, other general paranoia-inducing modern-life shit.

I pay for things on a day-to-day basis with a physical debit card due to an existing habit of not wanting to depending on a single device for "all the things", so GrapeheneOS wasn't a downgrade, but it should be noted to others that whilst Google Wallet can run on GrapheneOS, NFC payments through the Google Wallet will not work due to Full SafetyNet requirements that GrapheneOS can not pass. Non-NFC items such as tickets and boarding passes have been reported to work (and I'm pretty sure I've used it for that, although Google Wallet is no longer installed on my device).

[aidenn0]

I see a trend of banks pushing people off of their websites onto the mobile app.

[BLKNSLVR]

That is a slight concern, but I don't see it happening, at least in Australia for the big four banks, in the near future.

If that became the case, then the 'glorified token device' would become the dedicated banking device, and not much else would change (ie. I still wouldn't be doing 'banking' while I'm out and about).

[glitchc]

It sounds utopian except you still have to pay for a cell plan on said device, no? How else to obtain a phone number for MFA?

[BLKNSLVR]

No, just connected via wifi. I don't use it outside the house. The MFA token comes via the banking app itself, not via SMS.

If it came by SMS my daily driver would receive it.

[efreak]

You already have a cell plan. It doesn't have to be attached to the same device.

[NetMageSCW]

Hopefully by not using MFA that depends on SMS.

[NoGravitas]

Unfortunately there are non-SMS MFA that are still tied to a phone number, and you may be forced into using them for some context. Duo Mobile is one.

[NetMageSCW]

To me that sounds like sacrificing living for a principle and missing the point.

[BLKNSLVR]

I hadn't migrated my life to any of the (tiny, possibly zero) convenience improvements that "mobile banking" may offer me, so none of what I've described has been any kind of downgrade in 'living'.

(I don't mean this in a sarcastic way) are you able to make tangible what 'living' I may be sacrificing?

[praptak]

Having a separate phone as a "glorified digital token" is probably within the top 3 things you want to do anyway if you are serious about digital security.

See the recent discussion about pixnapping: https://news.ycombinator.com/item?id=45574613

Also, if your bank uses SMS for verification then the phone should have its own phone number which you keep secret. Otherwise it's one data leak and one sim swap attack (https://en.wikipedia.org/wiki/SIM_swap_scam) from breaking your SMS verification.

[NoGravitas]

> A free OS will empower developers to implement technical workarounds that could trick these apps into working there.

Not if they require something like hardware-backed remote attestation, and only accept such attestation from Google or Apple.

I'd love a practical Linux phone, and being able to run a deblobbed close-to-mainline kernel on a new-ish phone would help with that, but that doesn't really solve the most user-facing problem of mobile phones, the ecosystem lockdown.

[r283492]

And FSF has a history of creating important OS level software.

[pjmlp]

Like they have been doing for Desktop Linux?

[hnuser123456]

And I feel like it undermines any effort to make free, featureful applications if the hardware itself can't be trusted.

[munchlax]

You can trust hardware and software that's easy to inspect.

If you can't be sure what's going on and unable to inspect or debug the hardware and software, how can you trust it's doing what you want?

Proprietary hardware and software is already known to work against the interests of the user. Not knowing exactly what's going on is being taken advantage of at large scale.

Let's put it this way: if you can choose between making your own lasagna with a good recipe vs ready-made microwave lasagna. What would you choose? How about your suit? And would you trust an open known to work well pacemaker vs the latest Motorola or Samsung pacemaker? Would you rather verify the device independently or pay up for an SLA?

[Arainach]

No software is "easy to inspect". Only a tiny fraction of users will ever even try. When things are inspected and problems are found, you need a way to revoke the malicious bits. You'll never notify everyone, which is one of the roles app stores play.

You trust hardware and software by establishing boundaries. We figured this out long ago with the kernel mode/user mode privilege check and other things. You want apps to be heavily locked down/sandboxed, and you want the OS to enforce it, but every time you do you go up against the principles of open source absolutists like the FSF. "What do you mean my app can't dig into the storage layer and read the raw image files? So what if apps could use that to leak user location data, I need that ability so I can tell if it's a picture of a bird"

For sensitive information - such as financial transactions - the rewards for bad actors are simply too high to trust any device which has been rooted. The banks - who are generally on the hook if something goes wrong, or at least have to pay a lot of lawyers to get off the hook - are not interested in moral arguments, they want a risk-reduced environment or no app for you - as is their right.

[seszett]

> For sensitive information - such as financial transactions - the rewards for bad actors are simply too high to trust any device which has been rooted

In practice, that just means you trust a Chinese black box Android ROM from a random manufacturer, but not a fresh Lineage OS. To run some banking apps there, one has to root it and install all kinds of crap to hide the fact that your phone is running an OS you actually can trust.

I don't think it's right, I don't think non-manufacturer provided ROMs are a real danger in practice, or rooted phones, and I think this is all just security theater and an excuse to control what people do on their own devices.

[lmm]

> The banks - who are generally on the hook if something goes wrong, or at least have to pay a lot of lawyers to get off the hook - are not interested in moral arguments, they want a risk-reduced environment or no app for you - as is their right.

If they pay for the phone and ship it to you then I agree. Otherwise, they have an obligation to serve their community (part of their banking charter) and that may include meeting their customers where they are, rather than offering an app with unreasonable usage requirements.

[Arainach]

No charter requires allowing access from any device. The charters don't even require banks to be open during hours most of their customers are off work.

[lmm]

The charters aren't that specific (nor should they be). But they do oblige the banks to serve their customers to a certain extent.

[yjftsjthsd-h]

> You trust hardware and software by establishing boundaries. We figured this out long ago with the kernel mode/user mode privilege check and other things. You want apps to be heavily locked down/sandboxed, and you want the OS to enforce it, but every time you do you go up against the principles of open source absolutists like the FSF. "What do you mean my app can't dig into the storage layer and read the raw image files? So what if apps could use that to leak user location data, I need that ability so I can tell if it's a picture of a bird"

Well, no. The objection isn't to sandboxing apps, but to sandboxing the user, as it were. On my laptop, I run my browser in a sandbox (eg. bubblewrap, though the implementation of choice shifts with time), but as the user I control that sandbox. Likewise, on my phone, I'm still quite happy that my apps have to ask for assorted permissions; it's just that I should be able to give permission to read my photos if I choose.

[Arainach]

Users can't be trusted. They don't read. You can put a popup that flashes in all caps saying "THIS WILL GIVE ACCESS TO YOUR BANK ACCOUNT" and users will blindly click OK to get to whatever they think they want, be that an Instagram feed, a game, or whatever.

https://devblogs.microsoft.com/oldnewthing/20030901-00/?p=42...

It was true 22 years ago and is even more true today.

[munchlax]

That's not a good example. My bank issued a token device which scans their code, asks me my pin, prompts me what's going to happen and asks for confirmation. Then I can enter the digits to proceed.

This is reasonably secure. If you hijack my account, you still don't have the hardware device and the random secret that was set up between the device and the bank.

You need to actually hack into the bank itself to transfer my money elsewhere.

Meanwhile, I only access the bank with my own computers. That means I installed them and have root. Not a problem at all.

[munchlax]

Not really.

If their security depends on enslaving the user, their security sucks.

Real security, be it your financial transactions or keeping your bird pictures safe, doesn't depend on any secret algorithm. Because it's secure.

[Arainach]

The threat models aren't secret algorithms, they're apps reading the contents of the screen, stealing keystrokes, MITM attacks against 2FA, and much more.

[munchlax]

Apple, Google and Microsoft created that problem.

I don't have this problem on my computers, they run free software. My wifes thinkpad runs free software. The friends I gave a computer with various GNU+Linux distros don't have this problem.

Add Google Chrome with its spammy extensions to the mix and they start getting problems.

[yjftsjthsd-h]

So, things that can be exploited on a stock Pixel with no user root? This is a weird argument to make at the same time as https://news.ycombinator.com/item?id=45588594 is on the front page.

[NetMageSCW]

There’s no way I’d trust open source anyone with my health. And I am not sure there is one open known to work well project, let alone a pacemaker that couldn’t possibly be funded in the open source world. What open source hardware is actually more usable than the closed source alternative for most people?

[HexDecOctBin]

Trusted to do what? Work against user's interests? Prevent user from even expressing their interests?

[kiratp]

Should the app builder’s ability to “trust” that the hardware will protect them from the user supersede the user’s ability to be able to trust that the hardware will protect them from the app?

In other words, should the device be responsible to enforcing DRM (and more) against its owner?