It's always surprising to see this type of comments on HN. Jolla is not Apple, they barely scrunged 10K orders for this phone, they can't afford the economy of scale that other mainstream vendors can.
(I agree with your comment. To add). Fairphone can be gotten with stock Android, but also "/e/OS", which is a fork of LineageOS, and presents itself as both more privacy focused and de-googled than stock Android.
So it also comes down to what kind of OS you want. I find SailfishOS interesting, but I also really like the hardware of the Fairphone.
I'm sure that if you tell Jolla about a relatively modern mobile SOC with mainline linux support, they'll look into it instead of relying on libhybris.
They can rely on libhybris if they want, why should I care - I just object to calling that "a full-stack alternative", especially when alternatives do exist.
That wasn't modern when they released it in 2020. Jolla chose a little more pragmatism for their hardware in the hope that they actually sell phones to other people than 100% open-source purists. I find it funny when dudes like you go all "well awkshwally" on them...
I use my Librem 5 as a daily driver, and I’m certainly not an open source purist.
What I do care about is that my phone isn’t going to run into obsolescence a few years down the road (due to hard kernel forks and YOLO’ed device drivers that are not going to be updated for newer kernels).
Battery: I unplugged it from the charger 10 hours ago, it's currently at 55%. Typically it's up to 22 hours when suspended, up to 12 hours when idling without suspend and about 3-5 hours of active use depending on what you're doing. Could be better, but can be worked with.
What I was trying to tell you with my original reply to you is that Jolla chose a different point on the free/pramatic curve of available SoCs. They selected a phone that's more likely to be used by average people rather than a fully open one. (You can still see in this very thread, complains about the high price for what it offers, showing they haven't fully succeeded, at that.)
Pointing out that they still rely on Android drivers for booting the thing is a little tone-deaf from my perspective when they're basically choosing a different path towards a similar goal to Purism and other alternative mobile vendors: higher availability of non Google, non Apple mobile devices. Perfect is the enemy of good and all that. And like I explained the reason for their choice is not nefarious but a pragmatic one.
I mentioned it somewhere else in the thread, and btw, I'm not affiliated with the company, this is just my charitable interpretation of their intentions: this is not for requiring _every_ consumer linux device to have attestation, but for specific devices that are needed for niche purposes to have a method to use an open OS stack while being capable of attestation.
Personally for me this is interesting because there needs to be a way where a hardware token providing an identity should interact with a device and software combination which would ensure no tampering between the user who owns the identity and the end result of computing is.
A concrete example of that is electronic ballots, which is a topic I often bump heads with the rest of HN about, where a hardware identity token (an electronic ID provided by the state) can be used to participate in official ballots, while both the citizen and the state can have some assurance that there was nothing interceding between them in a malicious way.
- You're just moving your trust elsewhere, this time to a private corporation (whoever makes the CPU / TPM / other "trusted" component).
- This doesn't guarantee voter anonymity the way paper ballots do. Considering the analog hole and the complexity of computers, I can think of a billion ways a motivated and resourceful Mallory could to connect someone to their ballot.
> This doesn't guarantee voter anonymity the way paper ballots do.
You're saying that with a lot of assurance, but in my opinion that's still to be debated. We can build something that will keep at least a degree of separation between the identity that points to a specific individual and the identity that casts the ballot.
> the plan seems to be to replace package management with image based whole dist a/b swaps
The plan is probably to have that as an alternative for the niche uses where that is appropriate.
This majority of this thread seems to have slid on that slippery slope, and jumped directly to the conclusion where the attestation mechanism will be mandatory on all linux machines in the world and you won't be able to run anything without. Which even if it would be a purpose for amutable as a company, it's unfeasible to do when there's such a breadth of distributions and non corpo affiliated developers out there that would need to cooperate for that to happen.
Nobody says that you will not have alternatives. What people are saying, is that if you're using those alternatives you won't be able to watch videos online, or access your bank account.
That's so far down the slippery slope and with so many other things that need to go wrong that I'm not worried and I'm willing to be the one to get "told you so" if it happens.
It's baffling to me that anyone can imagine pipewire has been created from scratch without any lessons learned from pulseaudio and the previous issues the audio stack on linux had, and solved, over the years. Nothing is happening in a clean room bubble, every new project stands on the shoulders of giants...
If the user's device isn't compromised then everything is fine regardless of whether or not it can pass attestation. If the user's device is compromised, the device doesn't need to pass attestation to run a fake bank app and steal the user's credentials. Once the attacker has the user's credentials they can use them to transfer money regardless of whether or not they have to use a different device that can pass attestation.
It doesn't really provide any security.
On top of that, there are tons of devices that can pass attestation that have known vulnerabilities, so the attacker could just use one of those (or extract the keys from it) if they had any reason to. But in the mobile banking threat model they don't actually need to.
It's not a matter of being hard. It's like trying to prevent theft by forcing everyone to wear a specific brand of shoes. The fact that the shoe company insists that it's useful is not evidence that it is.
It's not that you can't solve the problem, it's that you can't solve the problem using that mechanism. Attestation is useless for this.
The thing that would actually work for this is to have an open standard supported by PCs and phones to read the chip in payment/ATM cards, because then you could do "card-present" transactions remotely. You touch your card to the phone/PC and enter your PIN to authorize a new merchant. That actually solves the problem because then instead of the bank trusting every commercially available phone on the market, they only trust the specific card that they mailed to the cardholder, and you can only authorize a new merchant with physical possession of the card because it contains a private key. But that doesn't require attestation because then you don't need the keys to be in the phone since they're in the card, and it doesn't require a third party to sign anything because the bank puts the private key into the card before sending it to the cardholder without any need for Google or Apple to certify anything.
From what I can take from your reply I suspect you might not understand what attestation is for.
Yes you can use a chip that the bank trusts (that's your card), however the bank wants to trust that the hardware you use to read that chip is not compromised and does not try to do things on the behalf of the user that the user didn't authorize. A non trusted device can operate in a different way than the user demands of it, and the user might never know.
That's the use case that hardware attestation can prevent. Or so the theory says...
reply