You say that, but they're discontinuing it because they didn't sell enough of them. It may be the device we need, but it's not the device we're buying.
I never had a PinePhone Pro but I did buy an earlier model and the user experience was very far off what we have come to expect from modern phones. I'm sure the Pro was better but still probably not that close to an Android or Apple phone. That's not a sleight on the company at all, they faced some very high barriers and I respect what they did. But I don't think this is entirely on consumers for not putting their money where their mouth is. It's just yet another example that it's really hard to create something (in the phone space, at least) that is affordable, open and highly functional.
The product was never really attractive by itself. You had to be extremely patient and willing to overlook the serious problems with their software to even try to use it.
I would like to see some other company take a real swing at this product space but with a less strict approach around the hardcore open-everything ideals. They’re good in theory, but in practice people want a phone that works and you have to get to that stage first.
> I would like to see some other company take a real swing at this product space but with a less strict approach around the hardcore open-everything ideals
That... kind of was what happened. Purism released the Librem 5, and people were shocked they pushed so hard to get the FSF's "Respects Your Freedom" certification.
The Pinephone (and Pro) used a less Free modem, resulting in much lower power draw, but the UX was still, well... Alpha-quality is putting it gently
So if you come out with a typical android phone, you have to do X amount of work yourself and some Y amount you can just buy.
If you are doing something like a PinePhone, there's a multiplier on the X of work you have to do yourself ... a significant multiplier and that's the problem.
That's why if you have a something like a Pine phone that has the sales of say something like this: https://www.bluproducts.com/android-phones/ you're going to bleed money - you won't survive - it's too much of a lift.
That's also why almost all phones (that are financially viable) look and feel almost the same.
NB: Attestation has no security value here because if the phone isn't compromised then the owner having root isn't a security problem and if the phone is compromised then the user is entering their bank login into a fake scam app that doesn't require attestation regardless of what the real one does.
But because the banks that require this are cargo culting some nonsense, they require iOS or Google Android but don't really care how old the phone is. Which means you can transfer your cellular plan to the phone you actually want to use and then just keep your existing phone indefinitely to run the bank app over WiFi or tethering.
The first is that your phone is not compromised. In this case there is no other app trying to steal your bank's authentication token. This is true regardless of which OS you use or whether you have magisk installed or what other code you put on your phone that isn't trying to steal your bank's authentication token.
The second is that your phone is compromised. Then what prevents the device from capturing your bank credentials is the same as if you use a compromised phone running Google Android: Nothing. If you enter your bank credentials into a compromised phone, the attacker gets them. Attestation can't prevent this because the phone is compromised, so the login screen isn't from a bank app that requires attestation, it's from a scam app which is exfiltrating your credentials.
This is far from the truth assuming by compromised you mean that the user has installed a malicous app. Android has proper sandboxing which means that other apps can't read the token owned by the bank app. This is part of the Android security model and attestation is evidence that the Android security model is being enforced. Phishing apps are different from an app that steals existing authentication tokens on the device.
> Android has proper sandboxing which means that other apps can't read the token owned by the bank app.
Let's consider this alternative as well:
Scenario 1: Device has no malicious code at all; same as scenario 1 before.
Scenario 2: Device has a malicious app but the malicious app doesn't have root and the OS (regardless of whether it's Android or something else) enforces proper sandboxing. The malicious app can't extract the bank authentication token regardless of attestation.
Scenario 3: Device is fully compromised; malicious code has root. Same as before, if you enter your credentials into this device the attacker gets them.
The problem is that the only useful thing for attestation to do is to distinguish between 1 or 2 vs. 3, but that's the thing it can't do because if the malicious code is privileged it can replace the bank app with one that exfiltrates the credentials without requiring attestation, so the only cases where attestation is happening are the ones where it isn't needed.
You aren't responding to the scenario that was posed. You're assuming an isolated compromised app on an otherwise clean device. GP is assuming a compromised device.
Of course attestation does nothing to improve the "single compromised app" case since (assuming Android) that goes nowhere either way. The only thing attestation does is meddle in end user affairs.
What's protecting me when I do online banking in the browser, which I can do using more or less any device? The answer is that targeted attacks against the average middle to lower class individual are rare enough that there are far more worthwhile things to worry about. Such as the vast majority of banks (at least in the US) not supporting hardware tokens.
Not in the US, at least so far. If that were ever to come to pass I would be in danger of becoming unbanked. I flatly refuse to install third party proprietary software on my phone (I grudgingly accept firmware blobs for lack of a realistic alternative).
Here the majority continue to use SMS based 2FA rather than supporting TOTP or hardware tokens.
Note that TOTP can be handled by any app of the user's choosing, doesn't facilitate attestation or any other user hostile practices, and in practice means that an attack requires physical theft of the device. While the theory might differ, in practice the effective security level is equivalent to other (objectionable) schemes.
And what does that buy you? The user goes to the bank website in a compromised browser, attacker gets their password. Bank sends a code to their phone, user types the code into the compromised browser, attacker gets the code.
Then tell your banks they have to support the PinePhone or they'll lose you as a customer. The PinePhone folks don't have access to the source code of whatever interface your banks provide on Android/iOS, so they can't do anything about it.