6 ms·

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.

by kovac 1y 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.

hnuser123456 1y ago
And I feel like it undermines any effort to make free, featureful applications if the hardware itself can't be trusted.
- HexDecOctBin 1y ago
  Trusted to do what? Work against user's interests? Prevent user from even expressing their interests?
- munchlax 1y ago
  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 1y ago
    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.
    - munchlax 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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 https://news.ycombinator.com/item?id=45588594 is on the front page.
    - seszett 1y ago
      > 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.
  - NetMageSCW 1y ago
    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?
- kiratp 1y ago
  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?
r283492 1y ago
And FSF has a history of creating important OS level software.
BLKNSLVR 1y ago
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).
- glitchc 1y ago
  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?
  - NetMageSCW 1y ago
    Hopefully by not using MFA that depends on SMS.
    - NoGravitas 1y ago
      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.
  - BLKNSLVR 1y ago
    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.
pjmlp 1y ago
Like they have been doing for Desktop Linux?
praptak 1y ago
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 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 https://en.wikipedia.org/wiki/SIM_swap_scam) from breaking your SMS verification.
NoGravitas 1y ago
> 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.

by kovac 1y ago

hnuser123456 1y ago

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

HexDecOctBin 1y ago
Trusted to do what? Work against user's interests? Prevent user from even expressing their interests?
munchlax 1y ago
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 1y ago
  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.
  - munchlax 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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 https://news.ycombinator.com/item?id=45588594 is on the front page.
  - seszett 1y ago
    > 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.
- NetMageSCW 1y ago
  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?
kiratp 1y ago
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?

r283492 1y ago

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

BLKNSLVR 1y ago

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

glitchc 1y ago
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?
- NetMageSCW 1y ago
  Hopefully by not using MFA that depends on SMS.
  - NoGravitas 1y ago
    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.
- BLKNSLVR 1y ago
  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.

pjmlp 1y ago

Like they have been doing for Desktop Linux?

praptak 1y ago

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 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 https://en.wikipedia.org/wiki/SIM_swap_scam) from breaking your SMS verification.

NoGravitas 1y ago

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