← Back to context

Comment by kovac

4 months ago

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.

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).

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

    • 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).

  • 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?

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

    • 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?

> 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.

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

  • 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?

    • 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.

      11 replies →

    • 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?

  • 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?