111–120 of 166 posts
Earlier quoted context omitted.
Isn’t that significantly on the Linux kernel not having stable driver ABIs?
They could also contribute to the Linux kernel like normal companies instead of shipping half broken binary blobs.
This is a very myopic view of the industry.
I still buy devices based on the likelihood that they will be supported by LineageOS. Good to see them continuing along.
Out of curiosity, what do you buy? I had Xiaomi last and bought another one recently and they have made it pretty much impossible to unlock the bootloader. Apparently limited number of unlocks at 12am Beijing time. I have tried a few times, read through all the complaints and the community forums, and Xiaomi can very kindly just fuck off. It used to be really good value for money as the hardware is great. But without…
But their sandboxed GApps service is truly how a mobile OS should work!
How's LineageOS with WhatsApp, Signal and random banking apps these days? Or let me put it another way: anyone running LineageOS but struggled to run any essential apps? (I don't care about games or whatever, I mean the apps you need to get around in life).
they work fine if you don't root the install. if you do root, banking apps and Disney plus won't work, everything else is fine.
It's completely absurd, but it's how it works today.
Love to see the ongoing progress here, but I'm really starting to worry that the growth of attestation on Android will make using custom ROMs like LineageOS impossible in future. Is there any way we can fight this? Feels like there must be some EU/US consumer rights or digital market legislation somewhere that could be used to more directly object to organizations like banks saying "your phone works just fine but we…
Yeah, running GrapheneOS, this has been a big headache for me. And it's incredibly stupid too. The app won't work natively due to a lack of attestation, so I have to fire up the browser and user the service.... Exactly how is that more anti-abuse than just using an app without attestation? It's security theater and has no basis in reality.
The second reason though I can think a bank would want attestation is as an anti-piracy measure. With a website, you have HTTPS verifying the identity of the domain. With an app, a pirated app or a 3rd party app from any source could hypothetically intercept user's banking information, their scanned checks, or even attempt to cash their scanned checks itself. It's not about making sure the device is secure, as it is killing attempts at 3rd party, modified, or malicious clients. The last thing I want, or the bank wants, is some grandmother downloading the "Wells Fargo Bank Plus with Giant Legible Accessible Text" app she saw in an ad as an APK, installing it, and being a victim of silent fraud for years.
The third reason a bank might want it, is also just simple stupid litigant America. If such a scheme similar to the above were to occur, the bank would likely be sued by victims arguing that the above circumstance was preventable. The victims would also be correct, it was preventable. The bank is then in the unenviable position of telling the jury that supporting the rights of 0.1% of phone modders was more important than victimized grandmothers.
Or, as a bank lawyer would say, just turn on attestation, it costs basically nothing, and then none of the above could happen. Better safe than sorry. After all, is the grandmother not also a customer, and preventing malicious clients in her best interest? Sure, some customers will be inconvenienced, but this is America, where anyone depositing more than $10K is subject to an interrogation.
Earlier quoted context omitted.
> Google trying new tactics to move Android from open-source to "source available, lol"? It seems to be the opposite - more of AOSP internal development moving out into the open. QPR's are getting more frequent releases than the old AOSP code-drops. (Tbh I do think that AOSP has always had way too much churn for a sensible system. A Linux phone should just work, and share as much of its codebase as possible with Linu…
Or maybe the Linux Desktop (used by a couple of people) should use more code from the android project (which is the biggest OS on the Earth) The latter has sane sandboxing, proper IPC, an app lifecycle that makes sense for embedded devices (an app in the background should only ever take CPU time if it has an explicit service with permission for that) etc.
> an app in the background should only ever take CPU time if it has an explicit service with permission for that
You can run your services in a cgroup and use "freeze" and "thaw" support for that purpose.
Earlier quoted context omitted.
Or maybe the Linux Desktop (used by a couple of people) should use more code from the android project (which is the biggest OS on the Earth) The latter has sane sandboxing, proper IPC, an app lifecycle that makes sense for embedded devices (an app in the background should only ever take CPU time if it has an explicit service with permission for that) etc.
Plain old Linux has these features. For example: > an app in the background should only ever take CPU time if it has an explicit service with permission for that You can run your services in a cgroup and use "freeze" and "thaw" support for that purpose.
Sure, the Linux kernel is very capable, but the "gnu" userspace doesn't make good use of its features. Android makes much better use and has a bunch of software that could be re-used on the former as well.
Earlier quoted context omitted.
Or maybe the Linux Desktop (used by a couple of people) should use more code from the android project (which is the biggest OS on the Earth) The latter has sane sandboxing, proper IPC, an app lifecycle that makes sense for embedded devices (an app in the background should only ever take CPU time if it has an explicit service with permission for that) etc.
Plain old Linux has these features. For example: > an app in the background should only ever take CPU time if it has an explicit service with permission for that You can run your services in a cgroup and use "freeze" and "thaw" support for that purpose.
Android userland is actually better designed in some ways
Earlier quoted context omitted.
Just buy a separate low-cost device and use that only for your banking. It's a total non-issue, there are way more nefarious uses of SafetyNet/the attestation API's.
You'll have to change it often if you're worried about safety at all. Lineage has been keeping my phone alive for five years now, and although it only updates the upper layers and there are definitely unfixed vulns in the firmware, it's much better than if I'd used the stock OS that hasn't been updated since the beginning of 2020. Banks don't or won't understand this.
They are not interested in that. They want attestation because they can "outsource" the responsibility to Google.
Earlier quoted context omitted.
> Google trying new tactics to move Android from open-source to "source available, lol"? It seems to be the opposite - more of AOSP internal development moving out into the open. QPR's are getting more frequent releases than the old AOSP code-drops. (Tbh I do think that AOSP has always had way too much churn for a sensible system. A Linux phone should just work, and share as much of its codebase as possible with Linu…
Android is not "a Linux phone", it just happens to use Linux kernel under the hood. What you're saying was always an explicit anti-goal.
Earlier quoted context omitted.
Plain old Linux has these features. For example: > an app in the background should only ever take CPU time if it has an explicit service with permission for that You can run your services in a cgroup and use "freeze" and "thaw" support for that purpose.
It doesn't have it, because this is like security. You either have it everywhere, or it doesn't matter. Sure, the Linux kernel is very capable, but the "gnu" userspace doesn't make good use of its features. Android makes much better use and has a bunch of software that could be re-used on the former as well.