Live data from Hacker News

FSF announces Librephone project

fsf.org

181–190 of 669 posts

Re: FSF announces Librephone project

#181

Earlier quoted context omitted.

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 betwee…

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…

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.

Re: FSF announces Librephone project

#182

Finally! It took the FSF long enough to catch up with the overwhelming usage of mobile devices, but it's better late than never. I like that this project is trying to tackle something much more challenging that can't be done with just software: reverse engineering device firmware and binary blobs, the pieces of software that actually make hardware components interface with an OS. Understanding how this stuff function…

> the results can hopefully be used by non-Android [GNU/]Linux distros

That was stated as a goal at the FSF 40 event, videos of which should be online in the next few days.

Re: FSF announces Librephone project

#183
post #49

Ultimately, I don't think the most important challenge is in binary firmware blobs, but the software which people depend upon to run their lives. What does it matter if you can run a completely free software stack on your phone, if your bank software (or your required government ID, as is looking depressingly likely) requires you to run a Big Tech approved phone OS? Perhaps the FSF can't do much about that, but that…

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 t…

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

Re: FSF announces Librephone project

#184

Earlier quoted context omitted.

You seem to be part of the problem. As long as people like you are happy to run spyware on their phones for the sake of convenience or a meager discount, companies will be empowered to make such software and devices a requirement.

Do you think the same for using credit cards in general or is using the phone somehow worse?

I use cash whenever possible, but carrying cash for larger transactions has its own risks and those risks need to be balanced against the privacy benefits it offers. The way I see it, carrying a credit card in addition to my phone when I might need it is a minor inconvenience relative to that of allowing Google complete control over my phone.

Re: FSF announces Librephone project

#185
post #6

Earlier quoted context omitted.

Do you really NEED to be forced to attest if you can make your phone look like any damn PC using a browser?

My bank doesn't let me do anything in the browser without 2FA, and the only 2FA they offer is their smartphone app. My other bank offers 2FA via chip reader as an alternative. I guess that's somewhat viable for an alternative phone OS, if you want to carry the reader around with you That might just be European banks though

That could be nice on the Librem 5 which has an integrated smartcard reader.

Re: FSF announces Librephone project

#186

Earlier quoted context omitted.

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 betwee…

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…

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

Re: FSF announces Librephone project

#187

Earlier quoted context omitted.

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 betwee…

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…

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

Re: FSF announces Librephone project

#188

Earlier quoted context omitted.

I think it's time to look for a new bank.

In my country we have a large religious community that eschews smartphones. Due to this no company or government agency requires a smartphone for service.

This is a very good thing. I don't think many people here on HN reject technology, but sometimes no technology is better than one that is not controlled by the user.

Re: FSF announces Librephone project

#189
post #49

Ultimately, I don't think the most important challenge is in binary firmware blobs, but the software which people depend upon to run their lives. What does it matter if you can run a completely free software stack on your phone, if your bank software (or your required government ID, as is looking depressingly likely) requires you to run a Big Tech approved phone OS? Perhaps the FSF can't do much about that, but that…

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 t…

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

Re: FSF announces Librephone project

#190

Earlier quoted context omitted.

That is true. I guess one of the main differences is the bank app can run a faceid check when you open the app and before you make a transaction while websites don't have access to these apis. So they are forced to make you approve the action via your phone.

Every banking phone app I've used auto-logouts after being idle or unused for a bit, and my primary bank's app requires 2fa using an app that exists on the same device -- a second factor that secures nothing. They probably are not explicitly considering the phone more secure than a computer, but rather a good 80% of this is security theater or a checkbox on some baseline security checklist that was implemented withou…

> 2fa using an app that exists on the same device -- a second factor that secures nothing

If I steal your device, and you didn’t have faceid, I have both factors. But if I steal your password, or find it in a leak of another site because like most people you re-use passwords, then I only have one factor. It still provides a fair bit of security because of that.

Post reply on HN