My Android phone prevents me from taking screenshots if an app author doesn't want me to.
My Android phone prevents me from recording phone calls at the request of my carrier, even though it's totally legal for me to do so in my jurisdiction.
> prevents me from taking screenshots if an app author doesn't want me to
The most frustrating part about this "feature" is that you don't know it's enabled until the screenshot is taken and you're left with a picture of nothing.
That and some app authors thinking they're protecting you with this (referring to banking apps in particular)
In some sense they are. But being protected either from a consequence of my own stupidity or a consequence of their lack of security. I think the worst part of all is that these "bandaids" are being used in place of actual security. I don't need to be protected from my own stupidity nor do I need security theater.
I think the threat model here is that a different, malicious app (compromised, installed accidentally or by the means of social engineering) might take screenshots of your screen and forward them to take advantage of you. You can file this under one's "own stupidity" as well, sure, but in the end they're not protecting you, they're protecting themselves, because banks might be liable for these kind of things, and by imposing these restrictions, they're reducing the amount of fraud and thus improve their bottom line.
Are you implying that Google is unable to distinguish whether a screenshot is triggered via a combination of hardware buttons vs via a software call from another app that isn't even on the foreground in their own ecosystem? That's a quite sad state of affairs, isn't it?
I see this argument everywhere and I've never heard of a case where a bank was liable because a customer was phished. I've even asked for examples and nobody ever provided them.
It's one thing to argue in court that they should be liable because they didn't provide you with the necessary security tools (like MFA), but they all provide at least SMS 2FA these days and their apps run on iOS and Android, both of which have plenty of security features.
In reality what happened is that some security auditor put it into a checklist for the mobile app "Security ISO certificate++" and now everyone implements it for compliance.
Fighting against that is insane paperwork and professional exposure for software engineers that do it (since if people get phished, the C-suite will point a finger at a tech lead which went against the "professional security audit").
Most of other posts here are just post-rationalization and victim blaming.
The theory here is that it provides a marginal security improvement if there is malware on the phone, but if there is malware on the phone then there are a hundred other things it can do to the same effect and you're likely screwed anyway. And by doing this, you also block the user from taking screenshots, which is bad, because screenshots are harder for computers to parse, and that's a marginal security advantage. If the user is going to send e.g. their account number to someone else (for a legitimate reason), it's better that they do it as a screenshot than that you force them to type it as text, because text is machine searchable. Which is worse when that messaging system gets compromised and then the attacker can do a text search for a pattern matching a bank routing number and be more likely to discover that message than if it was only there in a JPG.
Meanwhile the primary consequence of preventing screenshots is to inconvenience customers, which is an actual cost to the bank, because there is only a threshold amount of BS customers will put up with before switching banks and banks are constantly pushing up against that line already with all of their other BS.
But then the lower-quality banks do it anyway because there is a box they can check which sounds like it's locking something down, so they check it without thinking. Which is a great canary for customers who want to know if their bank is dumb -- if they require this then they probably do all kinds of other dumb stuff and it's a strong indication you should switch banks before you get screwed by them doing some other foolish nonsense.
>because screenshots are harder for computers to parse, and that's a marginal security advantage. If the user is going to send e.g. their account number to someone else (for a legitimate reason), it's better that they do it as a screenshot than that you force them to type it as text, because text is machine searchable. Which is worse when that messaging system gets compromised and then the attacker can do a text search for a pattern matching a bank routing number and be more likely to discover that message than if it was only there in a JPG.
I want to send my new IBAN to my company, I can, no screenshot allowed on the screen with banking information. So I need to log on their website to do it.
At least my new bank allows such screenshot and to copy account information directly from the app.
Modern life is full of these tiny inconveniences. It usually involves some sort of "smart" devices, like light switches, stoves, elevator buttons, etc. Each one of which could be forgivable, but in sum it's like death by a thousand paper cuts.
User hostile UI in the name of security is particularly bad: we are supposed to type unique and complicated passwords in text fields without being able to see what we type, and if we get it wrong, we are put in timeout for two seconds. Citrix Netscaler nowadays apparently wants to be extra secure and shows you the most generic error message if you have a typo in either your password or user name and just tells you to "try again later", so you do until you lock yourself out. It's madness.
It's amazing how many "little" things there are like this. Like I honestly can't remember the last time I filled out a form which required something like my country and I didn't have to scroll to find it. All the information's there to make a good guess. But this is just one example of a million. There's just too many papercuts.
The other day I wanted to send someone proof that a transaction has gone through. A screenshot would have been the obvious choice, but of course, my banking app wouldn't let me do it.
A screenshot would also be trivial to counterfeit. That being said, I am not aware of any banks that provide any actually tamper-proof, shareable transaction confirmations.
Perhaps true, but some modern OSes (like macOS and iOS) allow you to copy text from screenshots. And since the text quality of screenshots is typically good, it works well.
Who are the product designers of the present with these single-minded attitude not checking how the implementation affects the life of paying customers< Children?! Most take pride - on paper! - about what one can do 'so easily' with their product, just to raise barricades getting there, using it, or those pop up suddenly while using it, bumping into it like into a bollard ona highway. Or just chain them to it against will! I am not aiming at Android only here as this is a generic attitude I found from organization being so self obsessed about what THEY want that no-one else benefits, no-one else have real benefits - only mixed ones with sizeable drawbacks -, defying the purpose of having modern technology. When the life becomes differently complicated, then that is no progress at all, just messing around. I am thinking three, four, or more times nowadays buying any technology, which is sad, as I was so enthusiastic only one but especially two decades ago, discovering advances and gadgets. Not anymore. I spend my money - and TIME! - on things bringing benefit or joy instead, or on those I am FORCED into. Yes, this obsession of providing non-technology services (banking, bureaucracy, identification, ...) apps first (sometimes only, at least to various, sometimes important details of the use/access) which is a hugely demanding matter on users (choose, purchase, pay, setup, learn, re-learn, update, maintain, subscribe, know and accept terms, charge, protect, both physically and data wise, click away suggestions and self promotions while busy with something important) that it is a very bitter pill to swallow.
Now consider the fact that an arbitrary other app can take a screenshot clandestinely, via API. Would you like it to happen when you're looking at the summary of your accounts? your list of credit card numbers?
The problem is that certain actions should only be acceptable if initiated by the user, physically. Think of the way Ctrl+Alt+Del works in Windows. This, of course, is not possible if you don't have enough fingers for the action, or something; here comes the loophole of assistive technologies, widely (ab)used for that on most platforms.
You're tech savvy enough, you're not the target for such a feature. The target is the grandmas and grandpas, and other people who have no idea about such things.
It's not just phones. Try asking ChatGPT/Gemini anything the hive mind in SV doesn't want you to ask. Try asking it anything the hive mind as decided has only one possible answer. It's only going to get worse
At least with LLMs you have more options (Deepseek, Grok, offline models, etc.). It's still far from perfect, but it's not as bad as phones where you basically only have a choice of Android or iPhone if you don't want to have to live with major inconvenience (such as being unable to do online banking or pay for parking). It's also a lot easier to launch a competitor in the AI market: you just need capital. With phone OS's it's essentially impossible. The barriers to entry are too high.
Google Pay requires SafetyNet verification, which means it only works with a Google-approved hard & software combination, so not with GrapheneOS for example...
I hate that banks use this proprietary "standard" for NFC payments
I get where that one is coming from though - tap-to-pay is considered second-factor-authenticated, aka no PIN entry is necessary at the PoS terminal because the user already entered their PIN or presented biometric credentials to the smartphone.
If a malware were able to snatch the key material that represents the credit card outright or it could (by running as root) act to the TEE like it were Google Pay's NFC controller app, it would enable the actor controlling the malware to spoof the credit card on their own phone... and since tap-to-pay is considered authenticated, chances are next to zero you can dispute the payment.
>If a malware were able to snatch the key material that represents the credit card
I'm pretty sure that data is stored in the secure enclave, which is impossible to access by design, root, no root, bootloader unlocked, google approved or not.
My government (Denmark) refusing to let me use their digital identity app because I don't want to accept Google's or Apple's TOS, and Google helping them enforce that via remote attestation services.
Luckily there are alternatives in the form of code displays and NFC chips. However, next year I won't be able to watch porn unless I verify my age using a smartphone, no alternatives are planned. Or rather, I have the "free choice" to choose between a privacy preserving ZKP solution operating in the kingdom of Google or uploading my face to a porn site.
The amount of things you can't do in Denmark without a smart phone is terrifying. Technically you can still manage, but it's becoming increasing difficult. Way everything needs to be a fucking app is beyond me. Accessibility and alternatives for the elderly, or just people who doesn't want a smartphone is pretty much just ignored.
I'm glad to know that I'm not the only one who hates MitID. I really don't think that any software that has so much trust in the user has a good security model. What are they protecting against exactly? If someone else wanted to impersonate you with your consent you could just tell them your login credentials!
LOL, what? My (teenage) kids use my phone all the time, especially in the car, when I'm driving, but also at home. It's not like I have porn or banking apps on it, but what is the age verification going to help there? If the kids would install an app or used browser to see naked people, then my face would be available to these services, right? Better mine than the kids', I suppose!
(We're not in Denmark, but I wonder how it is going in our jurisdiction ...)
The Danish MitID identity "service" is actually pretty clever, except for the app used to approve actions or requests on your behalf. It's designed in a way that ensure that it can verify your age, but reveal nothing else about you. It isn't going to be used for "Porn ID" though. Instead it will provide your age information, basically 15+ or 18+ (I think those are the options), to an identity wallet, which in term will validate your age to the porn sites. Unlike the UK version there's no reason to have your face scanned, because the Danish government already knows your age and can provide that information via a trusted channel, MitID.
That's probably the issue the other post aludes to. The identity wallet will only be available via Google Play or the Apple App Store (as far as we know). So without a phone and a Google or Apple account, you're won't be able to provide your age information to e.g. PornHub.
Exactly this. Except the new service is not released as part of MitID but as part of the new digital wallet app (den digitale tegnebog). This is a separate and "voluntary" app which is meant to be offered as a convenience. Except it isn't really voluntary when the app is introduced together with new regulation that requires you to verify your age in places where you were previously anonymous, and the only way to actually stay anonymous and retain access is via the app.
I assume that in the pornography you've decided to consume, the participants are not clad in balaclavas.
They're showing their faces to everyone, in perpetuity, which many may no longer want to, and - considering the exploitative nature of the pornography industry, where rape is endemic - some didn't consent to in the first place.
So maybe consider that when you're complaining that your own face may be linked with pornography. Is what you're doing ethical? Do you reasonably have any right to complain?
Yes I do, and you argument is ridiculous. First of all, porn actors are operating legally and consent to what they are doing. There are real problems with the industry, but the fact that porn actors have their face shown does (of course) not mean that consumers of porn should logically have to also disclose theirs to online services.
Second, porn is just the beginning. This will also be rolled out to social media, and I wouldn't be surprised if in a few years this will be required in lots of places where children could be exposed to something that politicians find offensive.
What kind of argumentation is this? Just because someone decides to show stuff, everybody else is also required to show themselves?
e.g. If I go to a theater where the actors are clearly identified, I have to be okay to get a facial scan as well?
Some people tend to demonize porn, and it might be unethical in their eyes, but fact is: it is not illegal (in most countries).
I don't argue that there are issues in the porn industry, but this is an issue with the platforms, that they don't allow the upload of non-consentual material, or and have processes to take it down. This is a 'THEIR' problem (the platform not the victims).
There some of these issues also exist in the standard movie and music industry as well. Hell, it even goes up to company executives and politics. But this is up to law enforcement do their job and to remove the illegal stuff and prosecute the involved persons, not by branding everyone as a suspect.
It's not a full solution. I've seen UK sites that, following the Online Safety Act, simply require all users to verify their age rather than bother to figure out whether you are actually a UK customer or not. I guess it's easier to implement and many sites mainly rely on domestic customers anyway so they don't care if international users are affected.
Also, this isn't just about porn. For example, I can barely use Reddit now if I connect with a UK IP address: the merest hint that there might be some NSFW angle to a post is enough to trigger their algorithm into requiring age verification.
It's a temporary solution though. It's only going to get more draconian. Next thing you know the talk is about punishing VPN users, because now they can be painted as evading the law.
> i mean yeah but you cannot do shit all about a vps
Of course you can. The AS numbers of major hosting providers are well known and it is already common practice to ban associated IP addresses for stuff that should only be done by legitimate users.
My friend, your phone might snitch on you depending what pictures or files you save. Your messages and calls can be saved at will without your knowledge. Even your notifications are being watched.
Your apps have backdoors to spy on you.
It does have a particular meaning, but it is one that's not relevant in this context, and it's probably narrower than what the poster intended. For example, Belgium is not a nation state, but I'm sure the GGP would be surprised by an answer like "no, it wasn't a nation state, Belgium asked them to do it".
They probably mean that Belgium consists of French-speaking and Dutch-speaking (and German-speaking) groups, which the person counts as separate nations, hence Belgium not being one nation.
This is mostly a language confusion for non-native English speakers. Nation, country, state, a people, nationality, ethnicity, citizenship etc. are used in confusing ways for speakers of other languages.
For many, "nation state" just means an independent state (roughly speaking, a UN member, note also that the UN is called United Nations), because just saying "state" could mean a subdivision, such as a US state. And "country" can be confused with the subdivision of the UK (they call, e.g. Scotland a "country").
In more precise contexts of political history, "nation state" mostly refers to modern (post-World War I) countries that more or less correspond to a people speaking the same language and having the same ethnic identity. It delineates nation states from the previously more common multi-ethnic empires and kingdoms, such as Austria-Hungary or the Holy Roman Empire etc.
Similarly, in English, nationality is often an exact synonym for citizenship, while speakers of other languages expect it to mean ethnicity, e.g. an ethnic Hungarian in Romania with Romanian citizenship would be considered a "Romanian national" in English-language news. This often makes people confused/angry. Also, in some contexts in English, "ethnicity" is more like a euphemism for something like "race", but not quite (e.g. in the US "Latino" is considered an "ethnicity" but not a race). In that sense "Hungarian" would not count as an "ethnicity" at all, but still phrases like "ethnic Slovak" refer to a minority group in a different country than Slovakia. But also "ethnic" can also just mean with "exotic foreign origin", e.g. "ethnic food" or "an ethnic woman" (this was really weird when I first read it). But I digress.
I think the author of the post was referring to the fact that Belgium is a multinational state, comprised of Dutch-speaking Flanders and French-speaking Wallonia.
But it isn't, here. The state of Belgium created itself by secession from the United Kingdom of the Netherlands, and its populace generally comprises two nations, Flanders (Flemish) and Wallonia (French), neither of which are continguous with the state, nor particularly interested in sharing a national identity with each other.
In short, a state is about turf, and a nation is a people, and you need them both to look similar on a map to make a nation-state.
Why not two people share a device, and when passed from one person to another, delete applications and install all apps and profiles from scratch using verified checksums saved on a blockchain. An OS which could do that is something like Nix. When passed to the previous person same thing, delete and install everything from scratch.
Using smartphones in a smart way, not a dumb way, like timesharing mainframes of the past. Same procedure could be applied to cars and other devices.
Android's Multiple Users feature does exactly this. Multiple users accounts with all user data completely sandboxed and restricted to each user. All user data is cryptographically protected on storage devices.
The actual SE filesystem available to a logged in user is pretty complicated. But the short story is that user-data is completely isolated. Presumably application binaries (which require digital signatures by default) are shared; although the "installed" state is not. Successive releases of Android have restricted access to any legacy "shared" data on the device (media folders particularly; pictures and video taken by the camera device have been strongly protected since Forever).
Verified checksums on a blockchain are only useful if they are verified by some provider who associates a blockchain ID with a real-world identity. Not sure what "blockchain" really adds. If anyone can create a blockchain ID, then "verification" doesn't really provide useful information.
> Multiple users accounts with all user data completely sandboxed and restricted to each user.
User data and user programs. Clean installation kind of user programs.
> Verified checksums on a blockchain are only useful if they are verified by some provider who associates a blockchain ID with a real-world identity.
Nix associates a unique id to each program version or package or config file. The verification happens on the Nix package manager.
The user uploads his exact config of OS somewhere, in his own home server, at a goverment server, at AWS, on a blockchain, somewhere. A blockchain seems like the best solution to me.
This assumes that these two persons will never need to use a smartphone at the same moment, which is a bit of a logistical puzzle.
Installing apps is the trivial part; isolating, or removing / reinstalling user data is much harder. Especially a few gigabytes of it. An SD card could work maybe.
This all goes against the grain of the smarthpone UX, the idea of a highly personal device that you can use for anything, and might need (or benefit from) at an arbitrary moment.
If the point is reducing e-waste, the solution would rather be opening up the hardware enough to provide long-term software support, LineageOS-style.
> This assumes that these two persons will never need to use a smartphone at the same moment, which is a bit of a logistical puzzle.
In general no one wants to share anything with anyone, but when two people cannot afford a device individually, but it is within reach when they buy it together, time-sharing becomes a totally acceptable solution.
> Installing apps is the trivial part; isolating, or removing / reinstalling user data is much harder. An SD card could work maybe.
Checksums might overlap by quite a bit. No need to remove programs installed by both users. If the total installation of each user is 10 GB, but the installation diverges 300MB only, not a big deal in most cases.
The first part also happens on desktop thanks to DRM, unfortunately. Like on Android, it can be worked around, but it's a massive pain to do so.
I'm curious about the second part, though. How do carriers influence the call recording feature on your phone? Is it because you run a carrier ROM or is there some kind of integration with the mobile network/SIM card that I'm not aware of?
I think this might be a longstanding "bug", but I have also not had any luck on my android using the screen recorder to record device audio from a browser (either chromium or firefox). It used to partially work using the mic to record the speakers, but currently it sounds like it does processing to subtract away the original signal; I hear mostly silence with occasional garbled artifacts resembling the original audio.
Maybe this depends on the site? I have definitely recorded video with audio off YouTube and other popular video sites, on a stock Samsung phone, even yesterday.
These petty measures are as self damaging to reputation as futile: one can easily make screenshot or do recording with an other device, which is soooo commonplace nowadays. It is just ruining user experience with small-minded measures, driving people away.
My next phone will almost certainly be two phones. One cheap and super standard Android phone to just run banking apps and similar that insists on Google Play etc. Locked down and boring, turned off most of the time. Then a second phone for everything else (terminal with sshd, emacs, emulators, media players ... the stuff that allows a phone to be the general purpose computer it should be).
Looks increasingly unlikely that there will be convenient ways to have the best of both those worlds in a single device. For now it is somewhat possible with Android, but the experience keeps getting worse.
I am starting to do that but I still find that will be annoying to keep up. The dumb device will need to be kept up-to-date because that's important for e.g banking apps so that automatically excludes "old" devices (usually 3+ years old) because most stop getting updates that fast. Even LineageOS isn't an option because it does not pass Google's integrity checks so I am afraid I will need to buy a new dumb phone every couple of years..
Official Android with Google Play and all the things some apps require will almost certainly refuse to run if a hypervisor is detected. Maybe someone could get it to work, but it would be a struggle to stay ahead of whatever new security checks are added to the OS and apps. The point of having one perfectly normal phone would be to not have to worry about any of that.
Yeah, you second phone sounds like a laptop. I have a boring phone that I don't care about with basically factory settings and perhaps 3 apps. MyGov, Dropbox and something else I can't even remember right now.
And I also carry a super cool small laptop that can tether to the phone and actually do stuff with.
I sometimes bring a bt keyboard to use my phone as a tiny almost-laptop, but mostly happy with something just the size and weight of a phone.
Used to have two phones ~10 years ago. A Jolla Phone was my primary phone with a sim card and ran most non-Google apps. Then I carried around a cheap Motorola Android phone that had no sim card but could run Google Play apps and when it needed wifi I shared that from the Jolla and otherwise it was fully offline and most of the time turned off.
So the phone that was closer to a small laptop was the one I actually used as a phone. Not sure if that is the setup I would go for again or if I would do it the other way around with the Google phone being the phone. If I do the latter I guess something like a very small Linux netbook would work as a second device, it such a thing exists.
As someone willing to put up with all manner of nonsense (overpriced/underpowered hardware, clunky UI, endless troubleshooting), battery life on mobile Linux devices alone prevents me from using them in the real world.
Is there a single Linux phone/tablet that can last an 8 hour day of actual use? Librem/Pinephone/Juno can't. My uConsole can't. Different category, but my MNT mini laptop lasts like 4 hours and can't be left in standby for too long or it drains to zero.
Meanwhile, it's been 10+ years since I've worried about daily battery life on mainstream mobile devices, even my 3-5 year old ones. I can fall asleep with Youtube playing and it's still playing when I wake up. I'm certainly not here to dunk on Linux phones. I want one! But if someone willing to put forth above average effort to use these devices can't realistically daily drive them, who can?
N hours of actual use, in isolation, is just the matter of calculating average power draw[W] by runtime[hr] and buying the battery with Wh figures comfortably bigger than that.
e.g. your device consumed 1 Watt on average, you wanted 8 hour runtime, then you need a battery with 8 Watt-hours, or 2,162.162162162162 mAh at 3.7V of capacity, before factoring in buffers of various kinds. But it's also roughly the datasheet nominal capacity of a single 18650 cell.
You don't worry about daily battery life on mainstream mobile devices and you can fall asleep with YouTube playing and it's still playing when you wake up because manufacturers know consumers do that and optimize the phone to make that work. They probably reduce display brightness, cut powers to mics and P cores, ask 3M to make the pouch films 1% thinner so battery could be few more percent bigger inside, fudge battery gauges so you would be nudged correctly to have enough charge before you fall asleep, the list goes as far as your imagination could possibly go.
The fact that same behaviors don't happen on Linux devices, even with something like four of fresh 18650s, means the list ends before it begins. They probably don't do ANY power profiling AT ALL. I'm sure they don't do ANY environmental testing, either.
Would I accept that as a consumer? No. Would I if I was the manufacturer? ...
This is a big part of why Android was developed in the first place. The operating system and application architecture that makes sense on desktop just doesn't make sense on mobile. Despite the many problems Google's restrictive APIs which you are forced to use can cause for developers, they are also highly optimized for power usage.
The architecture can work if enough smart people are put to work on it. That's how Apple managed to turn macOS into a mobile operating system.
I think UBPorts and Sailfish prove that Linux for phones is practical if you're willing to rely on Linux applications that stick to mobile friendly APIs.
You need to configure and compile your Linux kernel for aggressive power saving, of course. Seeing how Linux currently struggles to effectively do power management on laptops without S3 sleep, there's plenty of work to be done if you want to use it with a phone.
It's not just about app developers either, Qualcomm's modifications to the Linux kernel are public thanks to GPL but most phone kernel modifications haven't made it into the upstream kernel so far. Projects like postmarketOS are trying to make things better but it's not easy to port practical code that works into code that's acceptable for the maintainers of the broader Linux project.
SailfishOS also came (at least back in the day of the first Jolla Phone and Tablet) with an excellent terminal app and built-in sshd that made it work great with pretty much every Linux command-line and TUI application (only exception was of course those with hardcoded minimum screen size support). Termux for Android is maybe half that good, not as well integrated, but still good enough that I use it every day, much more than I use other apps other than the browser.
With the right kernel drivers, configuration, and tweaks, with a well-configured userland on top of that, you can run the "normal" Linux stack in a mobile device.
Getting applications to conform with an API that won't let them drain the battery in the background to make sure notifications don't arrive two seconds too late is much harder. Desktop applications don't really like being suspended/resumed the way mobile applications do.
>Is there a single Linux phone/tablet that can last an 8 hour day of actual use?
What's "actual use"? Furi FLX1 has the best battery life I've seen on a Linux phone. Idling, it last 3+ days. I'm sure it could survive 1 whole day of "actual use". I also think almost any (official) SailfishOS device would last a day of actual use.
I have a Sony Xperia 10 III with SailfishOS and it easily does 48 hours on a charge when I'm not doing a lot of screen time. Also on days when I use it for tracking / navigation on 6-8 hour bicycle rides it easily lasts for the entire day and then some. I think this is not bad for a device that has been in daily use for almost three years and still has the original battery.
I'm running a couple of messenger clients and a web browser (Fennec under Android App Support as the native one is sadly a bit behind the times currently) all the time. The only thing I've noticed to eat a ton of battery is having wifi enabled when outside the range of my own networks, it seems the scanning the phone does in the background to look for known wifi networks is not energy efficient at all.
I also have this setup and SFos on Gigaset GS5. Similar battery performance. I did a roadtrip last week with navigation (starting with about 90% battery) and after 5&1/2 hours navigation was down to 65% or therabouts. Works for me.
And, yes, I often turn off wifi. I never go over my Data limits and 4G/5G is much more efficient for some reason.
SailfishOS is quite efficient. On Sony devices, I experienced maybe 15% extra battery life compared to stock Android, which is quite good given that Sony ROMs are excellent. Sony is known for their Sony Open Devices Program.
I genuinely think if Sony offered a Linux phone and didn't lock it down too bad, they could serve as the catalyst for the whole market. I don't think I would trust any other company at this point to execute the platonic "Linux phone" we need. The uncompromising vision on building a fantastic product for the technically minded make them an obvious choice.
I get the impression they shut it down, but Sony had/have the Xperia Open Devices program. They were close to having their devices running purely on the mainline Linux kernel:
Sony tries out so many different types of products too across their entire lineup. They have made some memorable handhelds over the years, even their eink readers were special.
I've been considering this as my Android exit plan (as part of a slow rolling de-googling effort, even before the recent "sideloading" news). Are you using it as a daily driver? I'm sort of surprised it doesn't get brought up more.
Yes, I used SailfishOS as a daily driver since ~2014 until last year when I moved to the Furi FLX1. The FLX1 has been my daily driver since. SailfishOS is much more polished, but it's not fully FOSS, and it follows upstream much less closely. FLX1 is basically in-sync with Debian testing, with the exception of kernel.
Interesting. I had a poke at postmarket, which wasn't ready in comparison with SFOS. Would you say the FLX1 is at better stage in development than postmarket?
> FuriOS allows for running apps inside a container running Android codenamed Andromeda. This container has complete integration with the host and makes all Android applications work like native applications
The only detractions on the software side that I ever see are about it being a “hack” via Hallium, but to be frank, the device actually ships and is usable today. Linux purists probably need to stop complaining.
It does seem like there’s been a backlog with the latest orders though - maybe due to tariff hell? I keep wanting to order but their forum has a few people being thrown for a loop on the order side, so…
With my, atypical maybe?, use, I get up to 2 days on a 4KmA battery (Gigaset GS5, SailfishOs). Sometimes I'm down to 1 day if I do social media scrolling.
I think certain "Apps" that you need to do "X" keep this from happening. You can have a super lean, private and secure linux phone using super clean, fast OSS software to do what you need to do, but what happens if you need one of the mainstream apps (Uber, etc..) to function in society with the rest of the normies. Maybe a linux phone that can dual-boot into android? I doubt we will ever see companies pulling out of the app stores and offering browser-based solutions that will work on any device or OS.
While I share the concerns about Android, it feels silly to me to go back to Linux's (nonexistent) security model and bad mobile UI/UX. Why not try to fork AOSP or GOS (for broader device compatibility, even if it means giving up some its sexy security properties)?
Note that this could include packaging Linux GUI applications as Android APKs (with some additional glue code and Wayland/DBus integration of course), so it's not even an either or.
(Warning: Am only a software/product engineer, playing dilettante here, not an actual marketing/business expert.)
Awhile back, I was thinking that one pragmatic way to get this viable Linux smartphone moving might be for hobbyists to focus on getting one easily available, affordable device working fully with pure Debian or PostmarketOS (no closed drivers or other modules, and preferably no blobs) and with Purism's Phosh.
Then that would boost contributions to, and demand for, Purism's open source platform/components for Librem 5 (and whatever the successor hardware would be).
If the cheap hardware is something like PinePhone, I'm just going to handwave that maybe this device won't cannibalize much sales of Purism's premium devices, but instead the community investment into the platform will effectively generate much higher net demand for Purism's premium products. With higher volume, Purism could maybe also hit more accessible price points.
If the Purism hardware demand happens, then there may be competing hardware entrants. And they will have to compete partly on being trustworthy and aligned with the interests of the kinds of customer who want to run a non-Apple, non-Google device. Where Purism should have a head start in credibility and goodwill. The new entrants will have to contribute engineer time (possibly: pay community contractors) to getting their device to work well with this platform, and be expected to upstream all of it as open source to the platform mainline, if they want to be attractive to these customers.
(I'm not saying the cheap device has to be PinePhone; that just seemed the most likely one at the time. It could even be something like an older popular Pixel model, with many unlockable-bootloader units available cheap on eBay, for which people are able to assemble/develop open source drivers. Or maybe GrapheneOS will get their own device built, and it can also be used for this non-Android-based open Linux platform.)
> to focus on getting one easily available, affordable device working fully with pure Debian or PostmarketOS (no closed drivers or other modules, and preferably no blobs) and with Purism's Phosh.
I'm not sure how viable this is. Linux phones already opt for hardware that's as open as possible, i.e. they use parts with the most open documentation and drives, but the trade-off to that is that those parts are functionally already end-of-life when they're in the phone, either because it's an old design that's been opened up to squeeze a bit more money out of an old design, or the design was third-rate to begin with. Not to mention that the baseband side of things is closed no matter what, so the phone that's completely true to the FOSS ideals seems impossible to make no matter what. And who would buy a phone with a third-rate chip and battery life? And since very few people buy them, prices aren't able to drop any significant amount.
I understand why people aren't willing to make a devils bargain in order to make a decent phone first, and then put Linux on it second, but I can't see any other way for this to happen, other than the phone market magically becoming more open somehow. If you could install Linux on any phone, since all the drivers are already out there, then we wouldn't be in this pickle, but every single Android phone out there has a different set of drivers and very few of them are open and possible to implement without an enormous amount of work, unlike the PC world, were at this point, only the really weird stuff (and Wifi from certain vendors) doesn't have some form of Linux driver.
IIUC, there have been some efforts to compartmentalize/isolate closed baseband, when you can work on the hardware.
Separate from baseband, the (sub)device closed firmware blobs are non-ideal, and eventually you'd want open source even for those, but maybe don't have to be a high priority. Mainlined open source for corresponding drivers are much higher priority. Even Debian now tolerates such blobs.)
It doesn't have to be, the PinePhone's modem runs a proprietary Linux distro, which you can replace with an open source Linux distro. That is only the ARM processor of it though, the Hexagon one is all proprietary.
A bajillion reasons, including that carriers basically white list basebands they're willing to interact with, and the patent situation means you only have a handful of baseband OEMs and they view their whole business model as building as big of a moat around their IP as possible.
Ultimately, it all stems from two things - for one, it's illegal to emit radio waves without a special permit. And secondly, it's also extremely hard to process radio signals at the kind of rates we expect today.
Together, these facts make it so that (competitive) wireless modems require organized businesses to create, and organized businesses don't want to share their code with competitors. A foundation dedicated to creating open hardware and software for a competitive wireless modem would face giant hurdles both in regulatory terms, and in hiring people who can actually work on this extremely difficult technical challenge.
Also, building an open source software for controlling wireless modems that complies with the law is probably not fully possible. Per law, to sell a wireless device, you as the manufacturer are responsible for taking reasonable precautions against users misusing it to emit in reserved bands, or to not respect military device priority in the allowed bands. If every user is extended the rights and documentation for modifying the software as they see fit, you're clearly not taking reasonable precautions to prevent them from breaking the law.
I would honestly just prefer that they use some semi-crap Chinese phone that is running on well-documented stuff a generation or four behind. If you could get Linux on a $50 phone, whoever was shipping them would sell 100K units. People would buy them just out of curiosity.
I'm behind though: aren't the UIs for mobile Linux still bad? I still can't get the experience I got out of my N900 that had only 256M of RAM, right? Every project I remember to bring the Maemo experience to Linux seemed to wither because there was ho hardware.
In one of my Linux handheld attempts, I looked to evaluate Maemo for the vintage Nokia N810 and N900 as a starting point, but much of open source artifacts (code, docs, forums) had mostly disappeared, even from where there seemed an effort to preserve/migrate.
(But someone's copy of some of it might have resurfaced now; I haven't looked recently.)
Usually things like this disappear because whoever was paying for hosting for them (company, accounting unit within a company, or some random techie's basement) gets shut down. And maybe no one who had the interest and ability was able to preserve it in time, and archive.org hadn't picked it up. But occasionally, things get deleted with intention to suppress them.
I think it's an unintended effect of Europe regulations. Google saw Apple exploring what's the bare minimum to comply with EU regulations regarding openness. And Google is setting their bar there.
More money. More power. Greed. Don't ever underestimate human greed. It doesn't matter what people have or where they are, they will always want more. We only have what we have now because of a few very peculiar people like Richard Stallman, but now it's just a bunch of normies in control.
I'm guessing immortality I'm not joking. We may be the generation that has the right escape velocity to escape death. Vladimir putin mentioned it in his recent china summit
It's not sudden, and it's about control. You probably don't remember a time when you could switch/remove batteries from your phone. All manufacturers removed this ability.
That was one very good reason for me to choose a FairPhone. (Almost?) everything is user replaceable. It has been in my pocket for a could of years and I have not needed to replace anything yet. But I do like having the option.
Samsungs Galaxy S21 is also really simple to fix stuff. The back is made of relatively flexible plastic connected via glue, which you can easily get under by blowing into the charging/speaker port. Once your inside its all just a lot of screws.
Had to reattach the battery ribbon cable after my phone fell one too many times (I could have also just fixed it by pressing on the back in the right place, but I only really figured that out after I disassembled the phone).
I have a Volla Phone running Ubuntu Touch. In order to insert my SIM and SD cards I had to take off the back cover (which is intended and I just had to pull on a small gap in a corner of the device) which also made it very obvious that it's easy to take out the battery should I have the need to swap it out.
It's actually not happening all of a sudden. The dam-breaking moment is more that Samsung, the number #1 Android vendor, decided to stop supporting it.
The vendors stop maintaining bootloader-unlocking methods because the cost/benefit profile to develop/maintain/support that feature and its consequences is simply not sufficient, all while several of the biggest customers explicitly require unlock to NOT be supported.
Supporting this is not just about the unlock itself, it's about allowing this unlock (required as some carriers explicitly forbid this, so a unlock needs to be requested), then performing the procedure (using a shared secret between the device and the vendor) and then the OS continuing to boot in this untrusted state with all components gracefully handling this broken trust-chain.
The commercial incentive for this feature isn't there for a device-vendor, it actually never was. It was built, defended and fought for by passionate people (mostly within the R&D) of those companies. Companies which managed to implement it early (in times of higher product margins) were able to keep it longer, others simply couldn't get the budget to implement bootloader-unlock in the first place. Today, devices are shipped with commitments of several years of upgrades, without the vendor actually knowing yet how the OS-upgrade in 2 years will look like. Keeping his custom security-implementation is a risk-factor here
The 3rd party OS developer community was always small, and became even smaller in the past years. The footprint of alternative OS users was shrinking since Cyanogen (the leading "universal kernel" developers for Android and predecessor of LineageOS) dissolved (or tried to become a for-profit).
However, the events around Cyanogen were more of a public symptom, The main driver for people to stop using 3rd party OS's was:
1.) The increasing fragmentation of devices in the market: When the community started, the majority of the market was Samsung, Motorola, LG, Sony. Samsung was leading, but each of them had quite healthy parts of the Android market, competing with each other in an "almost-stalemate" situation. Today Samsung is leading with a huge margin, all others are basically fighting for scraps. So naturally, most of them try to go for the lowest common denominator and find a distribution channel.
2.) Android itself became more competitive: At the height of the OS community, people switched to alternative OS's to get a newer OS, new customization options and convenience features. Today, vanilla Android checks most of the convenience options already, sufficiently that most people don't want to bother researching alternative options, maintaining them, etc.
Devices of major vendors are receiving upgrades for several years (back then it was ONE major-OS Upgrade, a YEAR after Google's release, if at all)
3.) Device-integrity became more important: At the height of the OS-community, there was no Device Integrity check by Google to give a flag on whether the device can be trusted or not, so all apps kept working (with minor exception of some streaming services restricting their service/resolution, as the DRM keystore became unavailable on unlock). Today, most banking and entertainment apps rely on those Google integrity checks to decide whether they should even start. This introduced another reason for users to consider their actual need for an alternative OS.
--
How to change that: If it's not possible to create a commercial incentive for the vendors, a regulatory incentive could be an option.
It's crazy to think how much computing power is just added to a drawer or landfill every day, just because there is no reason for the vendor to allow you to repurpose it.
I think this could be a path, to legally require device-vendors to provide a common SW-layer with respective documentation to utilize features of underlying hardware (optional without the shipped OS on top, disconnecting the device from the shipped ecosystem).
This would prevent e-waste and put this old hardware to better use. A community OS could then be built on top of this common SW-layer and be maintained for a wider range of devices.
I would e.g. LOVE a "Browser on everything" OS which just provides a Browser OS for outdated hardware, but the only way this could work on scale would be if the device-vendor would be mandated to provide and document the lower layer...
Someone would have to make the economic case for such a regulation as well, i.e. demonstrate the benefit for society if that is in place. The chances for this are razor-thin, especially in today's public/political climate.
Yeah well, not in the way it progressed after the carriers started to take control over it (I was actively involved in a Firefox device-project back then).
What I sketched out here with a "Browser on everything" OS would be a concept for a aftermarket OS, where the device-vendor is not required to have his OS support the unlocked HW (because he can't be forced to do that), but he will have to provide components and documentation up to a certain layer to make use of the hardware. This could then be the layer for a generic "Browser on everything" OS to work on.
Very much thanks for this text. This makes much sense.
I don't think regulation would help ... only ppl who show their raised middle finger to this vendors.
I mean this scenario is the scenario ppl thought of when TPM came up ... a fcking closed up device and you are in the hands of the vendors.
People showing their middle finger won't be enough, because the vendors are torn between two groups of interests here:
1. Building a HW/SW product which works within controlled boundaries to provide warranty, support, repairs, future maintenance, Google-compliance, regulatory compliance,...
2. A subset of Customers wanting the HW to be separable from the SW, for product to be open in a way that they can use it differently than intended (potentially creating "Group#3", a HW/SW product with a different SW).
To create a product for Group#2, alot of the aspects of Group#1 still apply, but in a more-complicated, more-expensive manner. If there is a viable business-case for Group#2, it will be a separate more-expensive product with lower volume.
But in reality, the only way a vendor could meaningfully resolve the needs of Group#2 is if ALL his devices support this feature (including customers who don't want a unlockable "open" device now), allowing everyone to become member of Group#2 without having to buy a new separate product.
For this, the economic incentive doesn't exist.
Explicit example: The Fairphone is a great device, but it will never sell more volume than a Samsung Flagship, because it's a device satisfying the conscious needs of a niche of customers, without the chance of reaching comparable volume to compete in all other areas.
That's why the only chance I see is to create a regulatory incentive by making the requirements of Group#2 a part of Group#1, to have the "unconscious needs" of the majority also satisfied.
Because only THEN the mainstream-customer can be converted to *users* of this potential "Group#3" product, and market-forces have a chance to flow freely again, if you see what I mean...
The government is also keen to have these devices controlled more tightly. Now with the help of the big companies so much data is on the device and in the cloud about you that policy enforcement, tax evasion or anything else that the people in the government deemed crucial for them is much more easily done.
Check how China controls the Uyghurs phones and will they be happy to have "unlocked bootloaders".
It's not profitable for the companies to lose total control of "your" device you "bough", nor for software developers who sell you the software to have "ReVanced" versions of their apps. Just a small minority of people who understand what is freedom and ownership are aware of the dangers of this.
Basically, not enough people care to have this as a priority and make it an election issue. And sadly we're walking into more and more control, ads, and enshitification. :(
> The government is also keen to have these devices controlled more tightly.
Not to oppose what you wrote, but let me try to give you a different view on the same picture to support a different conclusion:
In the eye of most governments these devices play such a minor role that they practically don't even exist.
What governments see is messaging services, finance services, digital marketplaces, and so on. They used to regulate telecom providers, financial institutions, marketplaces in the past, and they are now catching up realizing that the carrier is no longer the messaging provider, banks are not in control of all finance flows, marketplaces exist beyond the classical physical markets, etc.
If you look at detailed regulation and laws, Governments still have little interest in the explicit devices, they still look at those new variants of classical services and try to adapt to them.
But what the PROVIDERS of those services do, is creating pressure on the devices to help them reach lowest-effort compliance for their SERVICE-requirements (--> "let's make the end-user device bulletproof trusted, so we can offload our responsibilities to his device").
This is in most cases why the devices evolve the way they do. Because they are a merge of product and services (often from the same vendor), and the product is evolving to satisfy the needs for those services.
That's why fighting for "ownership of your device" is mostly futile, because the assumed opponent in this fight doesn't even feel addressed.
You need to bring the fight to their topics, to the topics relevant for governments:
On how a citizen ID should be verified, how financial services should be realized, how a competitive market should be ensured also on digital markets, etc.
Less conspiratorial answer (better late than never):
Google services, integrity hardening:
From outside it might be difficult to understand the distinction, but Google is acting here as the owner and maintainer of a services ecosystem, which is the entire Google service-package provided to end-users. For them, Android is provided as a foundation for that package, and they increasingly experience difficulty to contain issues within that ecosystem and prevent them from spreading (piracy, malware, hacking,...).
The logical way out for them to contain those issues is to ensure that members of this ecosystem (=Devices with Google Services, Developers) are vetted more strongly.
Now Android has a history to be an open ecosystem, which allowed it to grow to the size it has now. But similar to the bootloader-unlock situation of device-vendors, the economic incentive of an "open ecosystem" keeps shrinking in comparison to the risks and issues it's causing Google in governing their services-ecosystem.
They obviously decided now that the price they have to pay for that "open ecosystem" (less control over the services ecosystem) is not justified anymore.
Now they have little room to move. In order to preserve that "open ecosystem", they would have to provide the user an option to disable Google Services entirely. But Google services are such a integral part of the OS-experience already that it which would turn the device almost into a completely separate product, different from the product the vendor initially built and the consumer initially purchased.
--
I don't expect this to be properly resolved for the sake of "pleasing the community". Products and Services are already so tightly combined in the Smartphone-space that it's hard for most to even understand what it is the user actually purchased when he bought the device.
Now Google the service provider starts to change the users' device in order to maintain his services, and there is no up-to-date definition to what degree he is actually allowed to do this.
How to change that: The underlying customer-protection framework is missing. A solution would be a general legally binding definition of what functions a customer owns if (and when) a device is stripped of any services on top.
If my car loses functions once it loses connection to the manufacturer, this bare set should be communicated as the purchased value ("in exchange for your money"), separately from any on-top ("in exchange for your data") business-model.
In theory this could create competition on the actual purchased value again, instead of continuing to offload the value from the device to some service provided by the vendor/service-provider...
But that's such a complex topic, the implications should be studied much deeper. Also, I don't expect political bodies to fully understand it for years to come, leave alone create a proper case to get the required voting and decision...
It's not "gotcha", just... there are many clones of Android that work without Google Play, because Android (AOSP) is based on Linux. Why not just use that? What does "linux phone" add?
Nobody actually cares about the kernel. They care about having control of their phones instead of the company that sold it to them, and they care that the userspace is normal, rather than weird and constantly changing according to the whims of the company that sold it to them. They do not want to carry conmen, swindlers, and spies in their pockets.
People mocked Stallman for saying GNU/Linux. Turns out it's important to specify what you're talking about, or people will misunderstand you. I use Debian. If Debian rebased to BSD (forked and relicensed to GPL, with gnutils) I'd probably still use Debian. If iOS rebased to Linux, I still would never consider touching it.
My opinion is that people actually want the political protection offered by the GPL and the people and projects who stick to it, like Debian (and others.) They do not acknowledge this to themselves. They usually want to be able to layer a few proprietary toys on top, but those are visitors who will be ejected for bad behavior, and they want an OS that will rat on that bad behavior when it sees it. They are afraid of this political project because they are afraid of politics (or because their professed meatspace politics turn out to be the opposite of what they actually want in their own lives.)
I'm a very happy Sailfish OS user, since 2016, before that Meego, Maemo (Nokia N900, N9). I do have an android phone for one App (Deutsche Post) which I use only when I need to ship stuff. Running on a Gigaset (made in Germany, 4KmA battery) I generally get two days of usage, 1 day if I'm stuck on Mastodon.
From being able to do SDL2 stuff (Godot 3.5 for instance) with a wayland compositor to just not having f'ked UI, I'm happy. The challenge of getting more apps is certainly a challenge. But that's good, gives me lots to do.
Linux on Mobile has already long been here to stay.
Oh, hello, i recognize your username from the jolla forums :-)
I do have two Gigasets here (GX290 and GX4 pro) waiting to be flashed, but I still need to finally set up a windows machine to make a proper backup of the stock android images and generate the scatter files. Like with most of the SoC-Vendors, the MTK tools are quite a PITA. I have to download some weird binaries from some weird websites. How can it be that there are no official tools available for things like this?!
And there is one more Question I have since you're already here ;-)
I'm already doing embedded Linux development in my day job, so I would say I have quite some knowledge in that area.
However I haven't found a good introduction to this whole "porting" topic. Do you have some advice on how to get started in that direction?
What exactly happens when I flash (say) sailfish onto some (specific) Android version?
Why do I even need this? How does the whole libhybris thing work and why don't people just use the binary drivers from some Android image?
It's all very confusing to me. Especially since people from the android corner seem to use different terminology that the embedded Linux crowd...
anyway, thanks for your work so far. I hope I can join the SFOS users (again) soon!
> apparently it needs to be said that I am not suggesting you switch to Linux on your phone today; just that development needs to accelerate. Please don’t be one of the 34 people that replied to tell me Linux is not ready.
I smell a "no true Scottman" here. Because people always say "common people do what I say" and when someone says "hey, I am common people and I disagree", the same people usually answer "well, then you're not common _enough_". Which is a huge fallacy.
> Common people don't care about the OS, they care about apps.
My statement is based on 25 year as an IT professional where I migrated people and businesses from Windows to Linux, from iOS to Android, from old Unixes to Windows/Linux and the list goes on.
Just give to people the apps they need or want and the rest is easily managed.
I absolutely hate that government and bank apps are only available on the Play Store. You are legally required to have a Google account and accept their ToS to use them. I am aware of Aurora, but some banking apps check their origin and refuse to run if not downloaded from the Play Store.
I had to deal with this for government apps specifically related to immigration. I don't mind banks requiring it, I don't have to use that bank. I do mind governments requiring it if my only recourse is having to leave the country entirely.
They are required for just about everyone in a lot of countries. In the Netherlands a bank account is actually a right¹, and as far as the tax authority is concerned, required.
Companies can choose what product to offer and what customers to serve. I can choose what products I'm willing to spend my money and time on.
My problem is when I am compelled to use something despite my opposition to it, such as the immigration app I mentioned being force to use under threat of being kicked out of the country.
Cash salaries are banned in some European countries. You can't have any income without a bank account. Welcome to the dystopian future, enjoy your stay.
IIRC Payment Services Directive aka PSD2 in EU for banking sector mandated verification of users and transaction and one of such ways is verification through mobile app.
When I login to my bank on desktop, after passing thru standard flow of login+password (plus silly "pick the avatar you once selected placed at random on this grid") page shows a modal to approve once, approve and add to trusted devices or log out (which never works on dynamic IP). Then I need to approve in app with secondary PIN aka "mobile password" in my bank terminology. Operations on both desktop and within app require that secondary PIN; transactions up to a specified limit do not but mobile payments done with temporary 6-digit codes need a confirm
I've heard this argument before and yet I've never understood it.
What government apps do people run? Why do you need to access your bank account on your phone? Is this some payments model that's just not common in my country where we still use physical credit cards for everything?
My bank doesn't yet require the mobile app (quite), but all interactions are significantly more annoying without the app. My 2FA options all require a phone, either for the insecure method of texting me the code, or else an app-only option (they don't allow generic 2FA apps, but instead require a specific app, that almost definitely won't exist for a linux phone). Even verifying my identity on the phone is better with the app (the app generates a code that they just accept, it can be done without but it's slower and more inconvenient).
So no, my everyday interactions don't require the phone app. But any interaction that is novel enough to require direct communication with the bank has been rendered annoying without the phone app.
I'm someone for whom I'd probably be willing to deal with all these inconveniences to make my statement about ownership over my hardware and software, but I doubt that very many average consumers would.
I work for a bank. There is a strategic focus on the mobile banking app over the web app. Younger generations are doing everything through their phones. Including applying for home loans. Many banks are moving towards being digital only as contactless payments means people are using cash a lot less to the point that physical bank branches don't make sense anymore.
I had to use government apps as part of their immigration process, the apps were only available in the official app stores. If I remember right they had am all for immigration services, though I know for sure they had a digital ID app that was absolutely required.
The major banks in that country also required apps from official app stores, though I don't think I was technically required to have a bank account. I was in the country under a program based on owning my own consulting business. I did have to prove financials to the government as part of that, but maybe there was a way I could have technically done that without a bank account which required a mobile app.
> Why do you need to access your bank account on your phone?
Many banks require you use their app to do anything, e.g., make transfers, approve debit card transactions, register your biometrics to unfreeze your account, etc.
And no, choosing a bank without these requirements isn't possible in some countries.
Public transport ticket app, government ID app, drivers licence app.
I do believe all of these specific examples run fine on rooted Android without too much hassle (unsure about the second one), so they should be emulatable or whatever on a Linux phone, but that assumes that experience holds up decently well, which I would be surprised if it did for apps like this.
> Why do you need to access your bank account on your phone?
Because the app is a whole lot better than the web interfaces my previous banks had. Plus the added convenience. I'd prefer that the web interface was just as good as the app, but I'd still use the app even if that existed, just due to the convenience.
So continue to use a physical licence instead. Most are credit card size so they're not inconvenient to carry.
At present, governments and banks are freeloaders piggybacking on the popularity of the smartphone. If these entities end up mandating access to their services via this route (or making them nigh on impossible to access by other more traditional means) then users should demand they be issued with phones specifically for the purpose, as owning a phone is not prerequisite or mandated requirement to live in society—although if trends continue it likely will be.
Moreover, as phone technology easily lends itself to location tracking any mandatory requirement for phone vehicle licences would soon lead to mandatory location tracking (and easy to implement and impossible to disable with government/bank-issued phones).
That's the logical endgame, and it'd be showdown time. The question is does the citizenry have the guts and resilience to resist such authoritarian impositions.
Frankly, I'm horrified at how easily users of these essential services have been bought off by online conveniences, they've not only become careless and blasé but by default they've also conceded to the withdrawing—and in many cases—actual withdrawal of traditional services in favour of ones that both governments and banks have more control over—and in the bargain they've chucked privacy to the wind.
They're rarely completely mandatory (Grandma still needs to be able to access her bank too), but the alternative is usually a whole lot more inconvenient (sometimes for bad reasons, sometimes just because that's how life is).
> (Grandma still needs to be able to access her bank too)
In some countries they are mandated if not by law then by implementation, a relative or a social worker is tasked to get grandma equipped with a "smart device". She can even borrow it for a few months from municipality services until she can afford to buy it
This might be an extreme example, but with Saudi Arabia's Absher app you can do almost everything related to government services, IDs and passports, car and driving licenses, visa, all kinds of permits etc. Other countries may have similar apps.
There are a bunch of them here in Australia, and there were several in the UK.
Here there's a secure ID app for government services which is used as 2FA on the web interface, and various apps to access state and national government services directly. There's a tax one that allows you to scan receipts to collect them up for your annual tax return. In the UK I had an NHS app, can't remember what else.
They aren't mandatory, you can live without them, but they are often convenient.
> Why do you need to access your bank account on your phone?
Because it's many people's primary computing device? Why would you not want to access your bank accounts on your phone?
And because if you want to log on to some banks websites you need to have a 2FA security code which can either be generated by a dedicated security device, which has become less common now, or by an app on the phone which is then usually biometrically protected. There is sometimes a second code-generation method for higher value transfers.
So it is convenient to be able to send payments in the bank app, though less common than using my phone instead of the physical card through apple/google pay (those don't require the bank app to be installed).
Linux can emulate android. Most banks have websites, and the only real blocker for banking apps I've seen is the photo verification due to hardware issues connecting to the emulated android system.
You can do pass through attestation with access to kernelspace. There are a few things that don't pass (play protect/wildvine, but that's by design, not a limitation of linux)
And do you think that will matter in the near future? Because every app developer will just set their apps to use the highest attestation requirement by default and every normal android phone will pass that test. The few percent of people that use something else can just fuck off.
I think the only viable solution is going to be to have 2 devices: one for government and financial services and one for everything else, where you still have some hope of privacy.
This is what I'm thinking. Android supports multi-user, right? So a cheap Android POS shared with the family that gets left at home most of the time.
I also think just not using a phone as much is a viable solution. People are addicted to their phones so it would feel like intercision at first. But freedom is worth it. Never sacrifice freedom for convenience. You actually don't need to look up stuff on Wikipedia at any time while you're outside. Just be outside. Be offline. It's fine. It's better even.
I'd be happy just going back to a dumbphone for the phone bit and having a portable GNU/Linux device for travelling. I still have a 15 year old Dell netbook but sadly the battery is shot and it's no good for the wonderful "modern" web. But something like that would be fine.
> I also think just not using a phone as much is a viable solution.
Most European banks force you to use your phone for 2FA if you want to pay your bills, no matter if you're sending the transaction from your computer or your phone.
Yeah the point of this subthread is having a shitty device just for that crap. I don't need to pay my bills at a moment's notice from anywhere in the world. In fact, I refuse to.
My bank's mobile app no longer supports my 2017 Android phone. I thought it would be a big deal but honestly I forgot about it until you mentioned this, it's been 6-12 months.
I don't agree. They're useless until they can call, text, and do video / camera reliably. With enough adoption, the rest will come, but they won't ever get adoption without nailing those basics.
And those apps get developed only if there are enough users. Catch 22.
Microsoft didn't manage to make Windows Phone a viable competitor against Android & iOS, and they're about an order of magnitude bigger than any Linux-focused company. I hope the conditions shift and an open phone OS can take off, but I don't know what would enable it.
Not to mention why specifically government apps? Would those not be covered by general compatibility with web standards?
Wouldn’t well designed mobile web-apps suffice for that use case? I have several web-app site shortcuts linked on my Home Screen which behave just like the native apps. In most cases I don’t see why that would not be sufficient, including most “government apps” use cases
I've had the same (US) bank for 20 years, it's a small one, they have a nice web interface (and I can deposit checks through it on my laptop) but I've never run into a situation where I needed to have some smartphone app to do my banking. (I also don't have a smartphone.) Is this common with major banks? Do they not have web interfaces anymore?
At least with my CU, mobile check deposit is the only function I need a mobile phone for; everything else is equally available on the web interface. (I could go to a physical branch, in lieu of mobile, I suppose.)
They do, but some seem to be gradually removing functionality (like check deposit via scan + upload) in favor of using their amazingly convenient (/s) app.
A lot of major banks worldwide have apps, and they usually require un-rooted phones.
People here seem to think this is some sort of Orwellian attempt to control them, but the reasons are more mundane and technical - many of them (mine included, from two countries) use security facilities on the phone to secure your accounts.
For example, my HSBC UK app has replaced the little calculator thing they used to ship, and uses iOS face recognition to secure the generation of log-on codes which you need in order to use the web interface, as well as for secure access to the banking app directly.
With a rooted phone they don't have the guarantees that these aren't being exfiltrated, or the app being subverted in novel ways, so they don't want to support it.
You may not consider this a good enough reason, and I have heard it said on HN that 'the banks shouldn't get to control what I do on my computing device!', and that attitude is absolutely fine, but then you'll most likely end up with either less secure banking (meaning more fraud, higher fees etc) or going back to having to have a dedicated security device.
> I can deposit checks through it on my laptop
American-like banking detected... who uses checks in 2025?!
:)
> American-like banking detected... who uses checks in 2025?! :)
Yeah, fair. :-) I live in a small town, the only check I write is my rent check, which I literally walk across the street to deposit. But I still on rare occasions receive checks as well.
Ha. Fair enough. That sort of thing is almost exclusively done using bank transfers here in Aus.
I did receive one check this year, a refund from a company who had screwed up billing on a medical scan. For some reason they couldn't just refund it to my debit card. It was really annoying to have to get to a bank during opening hours to deposit it, but my bank here doesn't offer mobile check scanning. Some do, my old UK bank did ... oh well.
> going back to having to have a dedicated security device.
... and ...?
There are ways to implement security without tying it to one of two app stores. Companies might even get creative and figure out hardware standards for secure verification that are portable, open, and give the user control. They figured out sim cards, and are worried about GAI they created taking over the entire world, they could figure this out.
Personally I prefer the device convergence rather than having to have another thing to keep track of. Plus the added factor of biometrics over pure hardware 2FA.
But you do you, as they say, the point is there are tradeoffs.
> There are ways to implement security without tying it to one of two app stores.
It's not just about the app store - people want to be able to run these on rooted devices, which is an end run around the security guarantees these apps currently rely on.
> Companies might even get creative and figure out hardware standards for secure verification that are portable, open, and give the user control.
I wish you the best of luck in this endeavour.
I hope that they already aren't relying on client-side security any more than they have to. I'm afraid I'm not familiar enough with the APIs around biometrics to know if there's a useful way a server can use the onboard devices to verify a user's identity without relying on client-side security in one way or another though.
It's true on desktop we have stuff like FIDO2 authentication using hardware tokens, which are supported on open systems like firefox on linux. I'm sure it's not insurmountable or unthinkable to do similar on phones. At the least there would need to be a system of remote attestation for the biometric hardware, and a way for it to provide a verifiable response to a remote server. Far from insurmountable, but someone will need to actually do it.
Goes against FOSS still though if there are processors in the system which can't be user-controlled, and biometric chips which perform remote attestation (see the recent discussions on how passkeys are fundamentally OSS-hostile).
I had to enable secure auth to access some features. This works only with the mobile app, even when logging on the web I need the mobile app.
Some functions are available only in the app as well. Now I’m stuck with the app because I need those and needed secure auth to access those functions.
It’s evil but I has no choice (no choice of other banks either for reasons I won’t go into here, just accept it and don’t tell me to change banks. Other banks are no better anyway. )
apparently it needs to be said that I am not suggesting you switch to Linux on your phone today; just that development needs to accelerate.
Please don’t be one of the 34 people that replied to tell me Linux is not ready.
The authors largest bullet point is on author identification. What are the arguments against this and do people really feel they outweigh the benefits?
My view: I would think given how many code supply chain attacks we've see recently this would be be regarded as (at worst) a necessary evil. How much software used by large numbers of people does the open source community think will be done by anons?
Sidenote: The author implies SyncThing development was stopped due to author ID but the post linked does not say this and gives a completely different reason (forced updates)
A couple of last years were quite impressive in how mobile linux improved.
Still, people claim:
- open-source phones are low-end devices - but we (also) write our DTS for phones like Xiaomi, Samsung, OnePlus, etc. Personally, I've written dts for my Xiaomi 12 lite and packaged postmarketOS for it. for devices like Fairphone - there's already a good level of support in mainline
- mobile linux is slow and laggy - this comes from the 1st point. modern smartphones works quite smooth, and mine xiaomi phone running on sm7250 (mid level soc from qcom) feels very snappy. hell, even desktop browsers works quite good on more or less modern phones (chromium is especially smooth)
- UI is trash - please check out gnome-mobile. it's an impressive piece of work and feels very much like modern mobile UIs
- my bank/government/etc forces me to use ios/android app - we have waydroid! so, you can run any android app from your launcher (which will be running inside a container with lineageos). the integration might not be super complete right now, although it closes the gap for me.
Of course, there are many gaps (like camera works on very few devices and photo/video quality cannot be compared to android; some apps are still not adaptive) but many enthusiasts continue to improve on all the directions. Kudos to all of them!
Personally, I wait for VoLTE and immutable systemd-based pmOS.
Apologies if the idea is absurd, but wouldn't a Linux handheld without a cell modem be easier to build and distribute? Think something of an analogue to iPod Touches, which were iPhones sans the the phone part.
This would skip a lot of the regulatory red tape, bring down costs, and make the devices more accessible so they’re in more developers’ hands. They’d have to tether from your primary phone which isn’t ideal, but workable.
The main question, current smartphones are nearly 100% camera-phones, and people just used to camera-phone world and don't want anything else.
But unfortunately, tiny camera is hardest thing and it is not coincidence, that nearly all whales of smartphone industry regularly show outstanding camera on their presentations.
Other things except camera are mostly accessible for Linux community.
Did you choose a KaiOS phone specifically because other current non-smart phones lack support for Bluetooth tethering (a.k.a. PAN profile)?
As far as I can tell, all currently available models from all manufacturers are based on some Unisoc platform and offer no indication of support for this feature in their manuals. Did you happen to come across any alternatives?
I'm not very keen on KaiOS given the ubiquitous advertising baked into it (which is apparently their business model).
What about all these raspberry pi hats with cell modems? Are they missing anything like usable IMEI numbers or proprietary stuff? What's stopping an RPi compute module 3G/4G/5G DIY linux phone?
By "linux" -- I guess I mean using a phone that runs a valid linux distribution that gives me freedom of control as well as software freedom.
I know people have a love/hate with environments like GNOME, but I don't mind it and happy for it on my phone.. as long as it adapts nicely on smaller screens.
My only issue is applications. Like many, I am using an Android/IPhone - and have installed various applications. Will any/most of these exist if/when I move over to a proper GNU/Linux phone?
This is the biggest hurdle. While I would find ways around it, I think this is where most people would stick to what they are familiar with... even if it is impacting rights, legalities, and other things we are slowly losing control over, etc.
What's the hardest part about an open phone? Cellular support? App support?
Maybe I'm unique, but nowadays 99% of my phone time is spent in a browser. If anything, it seems easier now to get something like this going because all you'd need is a bare bones UI and a good web browser.
Sure, it's not competitive with a Samsung foldable, but he I've gotta start somewhere...
I do sort of wonder if an x86-based phone is at all a reasonable prospect. It seems a bit weird to go backwards but at least they've sorted out the generally open ecosystem part XD. Power consumption is 99% about the software anyway.
Very good question; what's holding us back really? If we want an open phone there should be more discussions on this. Some thoughts aided with chatgpt:
Easy: get display, sound, cellular, sensors, inputs working
Proprietary hardware drivers: how do you get the hardware manufacturers' commitment to allocate their engineers to write drivers for the open phone system? Reverse engineering requires more effort and is not very sustainable.
Carrier requirements: Supporting and testing emergency services, lawful interceptions, certifications, possibly differing requirements for each carrier and regions.
Regulatory compliance: Constantly changing requirements by nations and geographical regions.
--
Reading from the other comments, power management seems very hard to get right.
The non-tech reasons seem to be the most challenging; it introduces the most complexity and it's not exactly something that can be achieved by a passionate person in an evening
I almost exclusively use the browser as well. I think the reason for that is simply because the software landscape is that bad. I hate the Playstore or Apple Store with a burning passion. They are all adware/malware nightmares that aren't worth the effort, never mind developing for them.
We have really interesting and good hardware, but it is all moot because the software landscape is plain hell. I really puts me off to ever use a Apple or Google platform.
I would immediately jump to x86 regardless of power consumption. Would probably still run better than my current phone with a sizeable battery because 95% of CPU time is crappy routine you didn't even want running, so that is a software problem as well.
With the power usage of screens, I doubt an x86 processor would be noticeably worse.
Sorry for the rant, but I don't understand how anyone could react differently if they hear the word Android or iOS. Why did we end up with this crap?
A simple WIFI/bluetooth only device like the iPod Touch but with Linux, combined with a modem puck would actually be enough. You separate the untrusted part from your own device.
Why don't we have an Android fork patched to fix all these "annoyances"? Android phone is just a computer, it should not be hard to unlock bootloader and flash it with anything.
I understand that it would be cumbersome on Apple devices with all their efforts to lock down the system, isn't Android different?
Manufacturers can prevent you from unlocking bootloader. Whether they are Apple or not. Samsung used to have a hard fuse that broke when you unlocked, it seems they now forbid it entirely.
Apps developers can decide to require Play Integrity so your Android fork cannot be used to run their apps.
Google can decide to not support or explicitly exclude your custom fork. Due to Play Integrity used on their own products, you cannot run Wallet on most forks where Google is not running as root.
Google can decide to delay or not publish source code so your Android fork cannot be maintained anymore.
Manufacturers, Google and developers can alter that deal at any point in time. Recently:
Those "annoyances" are only one of the attacks made, and not all of them can be easily defended against without having the manpower to actually maintain your own hardware and software stack.
I think it's because the Android latest changes are designed to prevent it. In other words, you can complicate the system to bring it to the place beyond fixing of the annoyances, or fixing would remove features you've entangled into it.
But for a "normal" linux environment on a phone I recommend postmarketOS. They make an effort to support a variety of user interfaces, init systems, devices.
Still, it is important to consider that the hardware and driver support is the limiting factor here. The camera is very bad on the pinephone because it doesn't have the image processing capability to record video in realtime. It also has no OpenGLES3 or Vulkan. Very poor lima GPU.
Maybe I'm misunderstanding this, but what would be the advantage of running straight Linux versus an AOSP-based mobile OS? Like, why not just keep the great apps that do run on there and ignore the Play Integrity ones that don't. Does it have to do mainly with just the governance of AOSP (i.e. Google)?
The mobile app ecosystem has outgrown it's original purpose to run software in a constrained env. Phones today are more powerful than my engineering laptop in university 15 years ago. The app ecosystem appeal today is reach, platform lock-in, and great APIs.
For example. I _want_ to run Linux phones even without all the apps & convenience, except Signal messenger. I am unable to use Signal without first registering through a mobile app. I suspect the desktop version will run fine-ish (proton after all). But at the end of the day, adoption will increase if mobile apps had a compatible desktop version on a Linux phone.
If things keep going in the direction they are, there might not be a LineageOS at some point, and developing a useful alternative before that (Linux based) would be great.
so we fork and continue to work on lineageOS. why start from scratch? (i mean, it's nice to have alternatives, but there is no reason not to continue developing an android fork.
Working on LineageOS doesn't help you if you can't even install it. Fewer and fewer phones come with unlockable bootloaders these days. The grip is tightening.
Yes, but if you are building your own phone hardware to run Linux on it, there is a huge advantage in that Linux flavor being an AOSP fork, since it is already mature.
I think governments funding software development could be a useful counterweight in an industry dominated by a few giant corporations, similar to how lots of countries have state funded media alongside commercial options.
But the EU forking Android is not a remotely realistic starting point. How do you persuade manufacturers to use it? Would Google license its proprietary apps to run on it? How will the small team of devs cope with whatever changes are coming in hardware next year? Forking Android is easy, making your fork a viable alternative is almost impossible.
In theory the EU could throw its weight around and demand that Google & OEMs work with 'EUdroid' if they want to sell phones in Europe. But that would be a massive political fight, much bigger than funding a few developers.
On paper this is a good idea but consider the current chat control issue. This fork would probably have built-in by default content, messages scanning and switching to any other Android would probably be ruled out as illegal.
The EU (and adjacent countries like UK or Schengen countries) loves surveillance and control of their citizens' speech (except if they're partbof their wealthy elite, in which case, there's nothing to see here).
I tried the fantastic DroidVNC-NG (KUDOS to the author) app because I wanted to see if I could stream a whole Android phone left at home at all times.
The idea was attempting to switch to PostmarketOS, so if I ever needed to use a banking app I could do it through this phone via a VNC client. You can't.
Banking apps black the login screen. Even if that is ok for 99.9% of users, I know what I'm doing and I do not absolutely have the fucking choice to disable that. The thing I found out is that every time I come up with something that should be doable, either Android or the fucking app or something else prevents me from moving away.
My biggest drag is banking because almost everything else I can leave it out. And I believe I don't have a choice.
Fair point. I haven't actually tested the banking mobile webapp but I did test it from a regular PC and oh boy, it was like a 1999 web application.
Not just because of the look and feel but everything was just odd and in the wrong places compared to the store app. I should probably try this from a mobile browser but the last time I used Firefox in Postmarket OS it behaved like a desktop browser (in fact I think I read somewhere that it is indeed a regular Firefox resized to be used in PostmarketOS) so I'm assuming that the experience is going to be really bad.
I also strongly felt this when support for sideloading apps got dropped, and from my personal experience of dealing with rooting and working around play integrity. It shouldn't have to be like this.
I have made people mad by saying it, but it remains true: Every developer hour wasted on an Android ROM is an hour not invested in a platform free of Google's control.
Google likes Android ROMs because they pacify the developer community from working on real competitors, while not presenting any meaningful threat to their control of the majority of Android devices. The MADA that prevented OEMs from shipping AOSP is probably dead but what hardware manufacturer is going to risk Google's ire by shipping something.
> Every developer hour wasted on an Android ROM is an hour not invested in a platform free of Google's control.
As it stands, and the way things are devoloping, accurate. But as the relevant systems are an integration of hard- and software, significant work needs to be done on the former as well. And I've yet to come across a Linux phone (or phone-like pocket computer) that ticks most of the neccessary boxes.
Agreed, the Linux phone landscape is far from daily driver ready even for a lot of tech enthusiasts. But that's also why it's so important people spend development time trying to solve that instead of screwing with ROMs. Short of a strong profit motive, Linux mobile needs a lot of volunteer effort.
Total agreement with the article's conclusions. I'm an Android developer who once had about six apps listed in the Play Store. But as time passed, maintenance became more and more baroque, and a simple Android version change required me to rewrite all my apps or lose my listings. Like many developers, I gave up.
Then Google announced a decision to disallow sideloading (not clear when this will take effect) and many tablet/cellphone manufacturers intend to disallow bootloader unlocking. If all this happens, it basically closes the Android platform to anything but "official" software releases.
Consider this from my perspective. My first computer was an Apple II in the late 1970s. I could do anything I wanted with it, and I did. But over the decades I've watched the world of software development -- with the exception of personally owned Linux machines -- gradually turn into a walled garden.
What can I say -- it sucks the joy out of programming.
Makes me think about mobile first web apps that just run out of the browser.
Maybe Palm Pre's had it right all along with the html/js based OS in WebOS at that time. Just a little ahead of their time for OS, and missed challenging the iPhone by a bit.
The only thing that keeps me on Pixel is Google's astrophotography mode. Put the same quality camera (app and hardware), and I'm there. I'll get there faster if there is an Ektachrome and Tri-X film emulation setting. I miss the colors of film, but do not miss the chemistry or expense.
Using traditional cameras (repurposed DLSRs or fancy webcams like ZWO). There is a significant hurdle, of expense, learning how to use them, and setting them up. A Pixel makes sky-wide astrophotography trivially easy with almost no setup required. Depending on how stable the camera mount is, the pixel will allow me to start over on the novice side of the scale. I've been able to take handheld pictures of the Aurora and other large sky images, such as lightning in twilight thunderstorms. If I can rest the camera somewhere stable, I can take longer exposures and even create a time-lapse of the night sky.
There's a lot to be said for pulling your phone out of your pocket and taking pictures of the sky.
Pardon my potentially naive question, but would Samsung ever develop their own OS? I imagine they're not necessarily happy about some of the latest changes to android.
If I recall correctly, Bada was already more locked down from the start, with app distribution only permitted with Samsung's approval. Otherwise I would have been interested in trying a Bada phone.
The market HAD changed to what it is now from what it was. Most handheld manufacturers had garbage mobile app platforms back in 2007. Something happened in January of that year and they all started coughing blood.
If it was just "the market" guiding things, there would be no need to lock things down against consumers, or pulling bait-and-switches with slowly closing down the previously open-source Android, would there?
Please learn to recognize when you are under attack.
Android doesn't even let you access your files. It has famously blocked acess to the subfolders of /Android/data/ - every app has a subfolder there where it stores files. And you can not visit these subfolders since Android 11.
A buggy app accumulates gigabytes (literaly, i am not exagregating) of temp files there, but i cant visit the folder to delete them.
Google explains that "it's for you safety".
I have to call it with the strong word "idiotic".
There are apps now where storing files in a shared, accessible folder is a payed option.
Not only that is outrageous, I belive that violates the existing "right of access" laws like GDPR. I am condidering even submitting Subject Access Request to Google about my /Android/data/ subdirectories.
No, I dont want to clear storage - there is data I downloaded into the app and work with that I dont want to lose. But the app also accumulates some temp files there.
>Banking requiring an Android or iOS Device for 2fa
>My local postal service requiring an Android or iOS Device
to unlock those postal delivery boxes
>My local public transport requiring a Android or iOS Wallet app for my ticket to be used
>My Health Insurance Provider requiring an Android or iOS App to see my own insurance data
This is my daily struggle. All of these companies refuse to engage with you on this topic, you get a canned response from support that's it. How do we even win this fight? As far as I can tell we've already lost.
I was hoping the US becoming more hostile towards Europe would wake them up and allow the relevant legislators to discover that the entire industry is at the behest of two American companies. The same goes for cloud services in Europe, just with different companies, and OSes for that matter.
Alas, this is a rather large set of elephants nobody in power cares to acknowledge.
This won't be solved until politicians and the unthinking masses feel the pain of this stupidity directly. And Google and Apple will make sure that they calibrate the pain for the average Person just high enough that they will accept it.
Yes, the steam deck has ignited the usecase for the portable linux machine for the normal user. Now we just need great linux on arm support and then I can run a version claude code on a portable arm device and have it control my whole device for me all day. I hope this happens sometime soon!!!
Mao said "Let a thousand flowers bloom, a hundred schools of thought contend".
Then he killed off all those naive ones who stepped out.
This is more or less the capitalist/liberalist/colonial/MAGA model from time immemorial: preach "freedom" to put yourself in a indispensable place.
Then impose fascism with long-suspected hierarchies.
Here is an idea I thought long and hard about for the last 3 seconds....
Say one, rather than making the entire phone modular, adds just one cartridge slot. Have it span the bottom half of the back of the phone and be a few mm deep. Cartridges can have 4 form factors. 1) flush with the back of the phone. 2) stick out from the back. 3) increase thickness of the entire phone. Or 4) like 3 but comes with the same slot as the phone so that one can stack cartridges.
The first base phone should be functional by it self but have really low specs. A slow cpu, little memory, little storage, small battery. It may even run on android and have a ton of preloaded apps no one wants. Ideally the most expensive component should be the cartridge connector.
And then, here it comes, you've already guessed it! The entire linux computer goes on the cartridge.
Have a similar dock that turns the cartridge into a desktop computer and a dock that connects it to your PC.
Software development would be glorious.
In the initial demo it should run Windows! This will send a strong signal to other otherwise uninterested parties that this is a real computer... finally...
While official builds should probably exist let other vendors go wild building their own proprietary closed source cartridges.
There should be infinite possibilities. People will make things we cant imagine. Stuff we will never see on flagship phones because 99% doesn't need it.
Some might simply but badly want usb ports.
Stupid example: I have a digital camera, I have to plug it into a computer and do all kinds of things before they may appear on my server, like booting the machine, opening apps and figuring out where the hell folders are. The pictures are great but not that much better than my phone which can conveniently send them places. But what I really need is to just plug in the camera and have the technology figure out which are the new images and upload them. It should require zero screen time.
The next guy might want an ethernet port, hdmi, serial, scan barcodes by pressing a real button that also unlocks and opens the correct app. You might even have a bulky cartridge that prints receipts. A large antenna and/or a week worth of battery. I'm not at all sure if people want it but a cassette player would be possible. A boom box with atx drive bays. etc etc
Then when you buy the next generation or are bored playing with it, the screen is cracked and the battery is worn out you turn it into a security camera that works when the power is cut and can send [picture] sms, make phone calls and play threatening messages to intruders.
I fully think an amazing consumer-targetting device could take over like a storm if done well, if ambitiously done, with an aggressive software stack.
But. I think what we should ask for now should be simpler. Let this be an alpha geek toy, let folks fiddle with some basic devices boards that can do the thing. The work on PinePhone, Mobian, others is good pioneering work, alas largely held back by there just being so few decent devices for folks to play with. The driver situation keeps making hope here impossible.
It's not a high hope, but Qualcomm has a QCM6490 chip is maybe a rare hope. A chip that is somewhat buyable by regular makers, an extended life version of the Snapdragon 778G. It's pretty modern, and comes with very featureful connectivity hardware. We're seeing variants like non-cellular Radxa Dragon Q6A in the field. Particle has a new Tachyon board you can buy with it. https://www.cnx-software.com/2024/07/31/tachyon-business-car...
It's just stunningly rare alas that folks can make systems with vaguely modern cellular chips. The cores are just not available generally. Sure it's be great to have a well produced Linux phone that is super consumer acceptable with a great OS build out, a new or revived Maemo or a Jolla Sailfish: folks who can go sign the NDAs and make a consumer device but have it be Linux. But I think for this dream to really take hold, humanity needs to be afforded some possibility to have an honest shake, some chance to be a little closer to the machine than typical cellphone bargain. The lack of cellular chip availability has been so so damning to this quest. And here is one counter-example, a crack in the wall, where I see flowers and hope grow.
There was some real nice moments where it seemed like maybe some Snapdragon cellphones in general we're getting Linux support to some level, in mainline, just for the base stuff. No cellular. Unclear to me but it seems like maybe those were just the very barest of beginnings; whether any peripherals at all work or whether there was even a screen is unclear. The trickle of releases also seems to have died off. FWIW though, I will note the previous Fairphone 5 does use the above QCM6490. https://www.phoronix.com/news/Linux-6.1-Arm-Hardware
Only issue is it’s so hard to use a Linux phone as a daily driver. I have a librem 5, but I admit it’s just too raw of an experience for me to use as a daily driver.
It was a terrible experience. I bought it with the impression that it had calls, texts etc working fine, and they were looking for developers to come along and add apps, games, whatever to round out the experience.
I couldn't have been more wrong. They had about four different distros. There was the 'old' one, the 'new' one which was already scheduled for deprecation because of the new-new one in the pipeline and there was also a debian distro. Each one used an entirely different UI framework (gtk/efl/qt), and the developers seemed focused on these endless interface rewrites when the unit couldn't reliably receive a call or a text under any of them.
After that I had a Nokia N900, which was a great experience. They'd nailed down the basics perfectly (as you'd expect from a much larger company) and the unit was a capable smartphone with linux under the hood and easily accessible. It's just a shame the app ecosystem never took off, and nokia flushed itself down the toilet shortly thereafter. I guess Sailfish is the successor in this space, though I liked that Maemo was debian-ish rather than rpm-ish :)
I guess what I'm saying is that a linux phone doesn't have to be raw, but for god's sake make it able to take calls and send a few messages...
This might be an unpopular opinion, but I think the raise of vibe-coding can be great for Linux on the phone. The main issue the ecosystem seem to suffer from is lack of apps. Apps building is becoming way easier, especially for simple things. If the cost of making software is going to drop significantly, we might be able to finally fill in the apps gap.
What you want isn't a "linux phone", what you want is a gun to put to the developers' heads so you can scream "let me tamper with your shit".
If you just want "a phone OS", AOSP is still there and worth forking. But you don't want a phone OS, you want apps. And nobody is going to write apps for an AOSP fork (see also: Fire Phone). Actually, nobody is going to write apps for anything other than Android and iOS, just in general (see also: Windows 10 Mobile). App development for two phone platforms is already enough of a pain in the ass. Furthermore, Google will absolutely be anticompetitive and de-Google your phone OS whether you want it or not.
But more importantly, if you do manage to create a third platform that people actually use, you are going to immediately be inundated for requests to lock down the phones in exactly the ways you object to, because a certain subset of app developers want or need that kind of DRM. And you're not going to get those apps without a DRM story that matches Google and Apple's.
Streaming apps want encryption to the monitor.
Games want a kernel the user can't modify.
Banks want your phone to be a credit card you can't do fraud with.
Hell, when macOS got support for native iOS apps, they specifically designed it so that iOS App Store apps won't run if you modified the OS in any way. And even then, a lot of iOS app developers specifically blocked macOS usage. The phone vendors aren't selling an OS, they're selling DRM.
I wonder what an alternate history where Google didn't implement remote attestation and actively made it difficult for apps to snoop on user modifications would look like.
I suspect the Fire Phone is where things changed. If Amazon had iterated on it and done a good job, it might have been a competitive threat to Google's revenue model for Android; that's less likely if it won't run games and banking apps.
Where are the open source planes, trains, and automobiles? Medical equipment? Nuclear reactors? Open source cannot afford the quantity control/verification need for these domains. It’s the same for phones. At best you’re going to get an insecure mess.
Agreed. So get to it and design/built some worthwile ones.
EDIT: That was obviously not an order to the the parent, but more a lamentation about and call to the industry. Sorry kids; I sometimes forget that the binars are allergic to ambiguities. :)
My Android phone prevents me from taking screenshots if an app author doesn't want me to.
My Android phone prevents me from recording phone calls at the request of my carrier, even though it's totally legal for me to do so in my jurisdiction.
I'm not loving where this is all going.
> prevents me from taking screenshots if an app author doesn't want me to
The most frustrating part about this "feature" is that you don't know it's enabled until the screenshot is taken and you're left with a picture of nothing.
That and some app authors thinking they're protecting you with this (referring to banking apps in particular)
In some sense they are. But being protected either from a consequence of my own stupidity or a consequence of their lack of security. I think the worst part of all is that these "bandaids" are being used in place of actual security. I don't need to be protected from my own stupidity nor do I need security theater.
I think the threat model here is that a different, malicious app (compromised, installed accidentally or by the means of social engineering) might take screenshots of your screen and forward them to take advantage of you. You can file this under one's "own stupidity" as well, sure, but in the end they're not protecting you, they're protecting themselves, because banks might be liable for these kind of things, and by imposing these restrictions, they're reducing the amount of fraud and thus improve their bottom line.
Are you implying that Google is unable to distinguish whether a screenshot is triggered via a combination of hardware buttons vs via a software call from another app that isn't even on the foreground in their own ecosystem? That's a quite sad state of affairs, isn't it?
I see this argument everywhere and I've never heard of a case where a bank was liable because a customer was phished. I've even asked for examples and nobody ever provided them.
It's one thing to argue in court that they should be liable because they didn't provide you with the necessary security tools (like MFA), but they all provide at least SMS 2FA these days and their apps run on iOS and Android, both of which have plenty of security features.
If a bank is required to reverse fraudulent charges (and they are), that means they're liable for those charges.
In reality what happened is that some security auditor put it into a checklist for the mobile app "Security ISO certificate++" and now everyone implements it for compliance.
Fighting against that is insane paperwork and professional exposure for software engineers that do it (since if people get phished, the C-suite will point a finger at a tech lead which went against the "professional security audit").
Most of other posts here are just post-rationalization and victim blaming.
> they're protecting themselves
[citation needed]
The theory here is that it provides a marginal security improvement if there is malware on the phone, but if there is malware on the phone then there are a hundred other things it can do to the same effect and you're likely screwed anyway. And by doing this, you also block the user from taking screenshots, which is bad, because screenshots are harder for computers to parse, and that's a marginal security advantage. If the user is going to send e.g. their account number to someone else (for a legitimate reason), it's better that they do it as a screenshot than that you force them to type it as text, because text is machine searchable. Which is worse when that messaging system gets compromised and then the attacker can do a text search for a pattern matching a bank routing number and be more likely to discover that message than if it was only there in a JPG.
Meanwhile the primary consequence of preventing screenshots is to inconvenience customers, which is an actual cost to the bank, because there is only a threshold amount of BS customers will put up with before switching banks and banks are constantly pushing up against that line already with all of their other BS.
But then the lower-quality banks do it anyway because there is a box they can check which sounds like it's locking something down, so they check it without thinking. Which is a great canary for customers who want to know if their bank is dumb -- if they require this then they probably do all kinds of other dumb stuff and it's a strong indication you should switch banks before you get screwed by them doing some other foolish nonsense.
>because screenshots are harder for computers to parse, and that's a marginal security advantage. If the user is going to send e.g. their account number to someone else (for a legitimate reason), it's better that they do it as a screenshot than that you force them to type it as text, because text is machine searchable. Which is worse when that messaging system gets compromised and then the attacker can do a text search for a pattern matching a bank routing number and be more likely to discover that message than if it was only there in a JPG.
Tbf it is 2025, not 2010, it isnt that hard
It doesn't really protect anything though, because you can always just use an external camera to take a picture of your screen.
Its probably meant to try mitigate damage in case bad actor gets remote access to your phone or you have malware.
If your phone is remotely rooted, the screenshot is providing no security.
It protects less proficient users from accidentally taking a screenshot.
I want to send my new IBAN to my company, I can, no screenshot allowed on the screen with banking information. So I need to log on their website to do it. At least my new bank allows such screenshot and to copy account information directly from the app.
There is a special place in hell for people providing non copyable text information in the form of screenshots.
Modern life is full of these tiny inconveniences. It usually involves some sort of "smart" devices, like light switches, stoves, elevator buttons, etc. Each one of which could be forgivable, but in sum it's like death by a thousand paper cuts.
User hostile UI in the name of security is particularly bad: we are supposed to type unique and complicated passwords in text fields without being able to see what we type, and if we get it wrong, we are put in timeout for two seconds. Citrix Netscaler nowadays apparently wants to be extra secure and shows you the most generic error message if you have a typo in either your password or user name and just tells you to "try again later", so you do until you lock yourself out. It's madness.
It's amazing how many "little" things there are like this. Like I honestly can't remember the last time I filled out a form which required something like my country and I didn't have to scroll to find it. All the information's there to make a good guess. But this is just one example of a million. There's just too many papercuts.
At least the days of those screenshot being pasted into a Microsoft Word document are mostly behind us now...
The other day I wanted to send someone proof that a transaction has gone through. A screenshot would have been the obvious choice, but of course, my banking app wouldn't let me do it.
A screenshot would also be trivial to counterfeit. That being said, I am not aware of any banks that provide any actually tamper-proof, shareable transaction confirmations.
Perhaps true, but some modern OSes (like macOS and iOS) allow you to copy text from screenshots. And since the text quality of screenshots is typically good, it works well.
Windows with power toys and android have it too.
The Penny supermarkt app on android disables both screenshots and text selection with the error that it is disabled by admin.
At this point you can just use google lens or something like that to copy text from images.
Do you prefer a voice message instead? /s
They literally had me photocopy the phone screen because of the same issue.
Why not copy it from the App?
Two mirrors will make it allowed.
Pretty sure Twitch on iOS does this now. Screen recording still works though.
Jesus Christ!
Who are the product designers of the present with these single-minded attitude not checking how the implementation affects the life of paying customers< Children?! Most take pride - on paper! - about what one can do 'so easily' with their product, just to raise barricades getting there, using it, or those pop up suddenly while using it, bumping into it like into a bollard ona highway. Or just chain them to it against will! I am not aiming at Android only here as this is a generic attitude I found from organization being so self obsessed about what THEY want that no-one else benefits, no-one else have real benefits - only mixed ones with sizeable drawbacks -, defying the purpose of having modern technology. When the life becomes differently complicated, then that is no progress at all, just messing around. I am thinking three, four, or more times nowadays buying any technology, which is sad, as I was so enthusiastic only one but especially two decades ago, discovering advances and gadgets. Not anymore. I spend my money - and TIME! - on things bringing benefit or joy instead, or on those I am FORCED into. Yes, this obsession of providing non-technology services (banking, bureaucracy, identification, ...) apps first (sometimes only, at least to various, sometimes important details of the use/access) which is a hugely demanding matter on users (choose, purchase, pay, setup, learn, re-learn, update, maintain, subscribe, know and accept terms, charge, protect, both physically and data wise, click away suggestions and self promotions while busy with something important) that it is a very bitter pill to swallow.
Now consider the fact that an arbitrary other app can take a screenshot clandestinely, via API. Would you like it to happen when you're looking at the summary of your accounts? your list of credit card numbers?
The problem is that certain actions should only be acceptable if initiated by the user, physically. Think of the way Ctrl+Alt+Del works in Windows. This, of course, is not possible if you don't have enough fingers for the action, or something; here comes the loophole of assistive technologies, widely (ab)used for that on most platforms.
That’s why taking screenshots should be a runtime permission thing.
You're tech savvy enough, you're not the target for such a feature. The target is the grandmas and grandpas, and other people who have no idea about such things.
It's not just phones. Try asking ChatGPT/Gemini anything the hive mind in SV doesn't want you to ask. Try asking it anything the hive mind as decided has only one possible answer. It's only going to get worse
At least with LLMs you have more options (Deepseek, Grok, offline models, etc.). It's still far from perfect, but it's not as bad as phones where you basically only have a choice of Android or iPhone if you don't want to have to live with major inconvenience (such as being unable to do online banking or pay for parking). It's also a lot easier to launch a competitor in the AI market: you just need capital. With phone OS's it's essentially impossible. The barriers to entry are too high.
I tried to debug a google pay issue with a Bank once:
- Bank told me to go to Google.
- Google support told me to go to the Bank.
- (... few emails later...)
- Google support told me to make screenshots of the banking app and google pay.
So have a second phone ready, or stop complaining :) A few years later and 3 phones later... it works again!
Google Pay requires SafetyNet verification, which means it only works with a Google-approved hard & software combination, so not with GrapheneOS for example...
I hate that banks use this proprietary "standard" for NFC payments
I get where that one is coming from though - tap-to-pay is considered second-factor-authenticated, aka no PIN entry is necessary at the PoS terminal because the user already entered their PIN or presented biometric credentials to the smartphone.
If a malware were able to snatch the key material that represents the credit card outright or it could (by running as root) act to the TEE like it were Google Pay's NFC controller app, it would enable the actor controlling the malware to spoof the credit card on their own phone... and since tap-to-pay is considered authenticated, chances are next to zero you can dispute the payment.
>If a malware were able to snatch the key material that represents the credit card
I'm pretty sure that data is stored in the secure enclave, which is impossible to access by design, root, no root, bootloader unlocked, google approved or not.
Only your carrier is supposed to record the calls.
Edit: apparently the /s is obligatory on this one
Absolute lies, where I live it is one party consent. I can still record with another device on speakerphone.
I think the person you were replying to might have intended sarcasm.
Yes this was sarcastic, I should have put a /s
I also live in a one party consent state.
My government (Denmark) refusing to let me use their digital identity app because I don't want to accept Google's or Apple's TOS, and Google helping them enforce that via remote attestation services.
Luckily there are alternatives in the form of code displays and NFC chips. However, next year I won't be able to watch porn unless I verify my age using a smartphone, no alternatives are planned. Or rather, I have the "free choice" to choose between a privacy preserving ZKP solution operating in the kingdom of Google or uploading my face to a porn site.
Dark times.
The amount of things you can't do in Denmark without a smart phone is terrifying. Technically you can still manage, but it's becoming increasing difficult. Way everything needs to be a fucking app is beyond me. Accessibility and alternatives for the elderly, or just people who doesn't want a smartphone is pretty much just ignored.
During covid I was not allowed to leave house. Permits were only issued to local SIMs, which I did not had!
If I respected the rules, I would starve to death!
I'm glad to know that I'm not the only one who hates MitID. I really don't think that any software that has so much trust in the user has a good security model. What are they protecting against exactly? If someone else wanted to impersonate you with your consent you could just tell them your login credentials!
LOL, what? My (teenage) kids use my phone all the time, especially in the car, when I'm driving, but also at home. It's not like I have porn or banking apps on it, but what is the age verification going to help there? If the kids would install an app or used browser to see naked people, then my face would be available to these services, right? Better mine than the kids', I suppose!
(We're not in Denmark, but I wonder how it is going in our jurisdiction ...)
The Danish MitID identity "service" is actually pretty clever, except for the app used to approve actions or requests on your behalf. It's designed in a way that ensure that it can verify your age, but reveal nothing else about you. It isn't going to be used for "Porn ID" though. Instead it will provide your age information, basically 15+ or 18+ (I think those are the options), to an identity wallet, which in term will validate your age to the porn sites. Unlike the UK version there's no reason to have your face scanned, because the Danish government already knows your age and can provide that information via a trusted channel, MitID.
That's probably the issue the other post aludes to. The identity wallet will only be available via Google Play or the Apple App Store (as far as we know). So without a phone and a Google or Apple account, you're won't be able to provide your age information to e.g. PornHub.
Exactly this. Except the new service is not released as part of MitID but as part of the new digital wallet app (den digitale tegnebog). This is a separate and "voluntary" app which is meant to be offered as a convenience. Except it isn't really voluntary when the app is introduced together with new regulation that requires you to verify your age in places where you were previously anonymous, and the only way to actually stay anonymous and retain access is via the app.
> or uploading my face to a porn site.
I assume that in the pornography you've decided to consume, the participants are not clad in balaclavas.
They're showing their faces to everyone, in perpetuity, which many may no longer want to, and - considering the exploitative nature of the pornography industry, where rape is endemic - some didn't consent to in the first place.
So maybe consider that when you're complaining that your own face may be linked with pornography. Is what you're doing ethical? Do you reasonably have any right to complain?
Yes I do, and you argument is ridiculous. First of all, porn actors are operating legally and consent to what they are doing. There are real problems with the industry, but the fact that porn actors have their face shown does (of course) not mean that consumers of porn should logically have to also disclose theirs to online services.
Second, porn is just the beginning. This will also be rolled out to social media, and I wouldn't be surprised if in a few years this will be required in lots of places where children could be exposed to something that politicians find offensive.
What kind of argumentation is this? Just because someone decides to show stuff, everybody else is also required to show themselves? e.g. If I go to a theater where the actors are clearly identified, I have to be okay to get a facial scan as well?
Some people tend to demonize porn, and it might be unethical in their eyes, but fact is: it is not illegal (in most countries). I don't argue that there are issues in the porn industry, but this is an issue with the platforms, that they don't allow the upload of non-consentual material, or and have processes to take it down. This is a 'THEIR' problem (the platform not the victims).
There some of these issues also exist in the standard movie and music industry as well. Hell, it even goes up to company executives and politics. But this is up to law enforcement do their job and to remove the illegal stuff and prosecute the involved persons, not by branding everyone as a suspect.
route everything through a vps?
It's not a full solution. I've seen UK sites that, following the Online Safety Act, simply require all users to verify their age rather than bother to figure out whether you are actually a UK customer or not. I guess it's easier to implement and many sites mainly rely on domestic customers anyway so they don't care if international users are affected.
Also, this isn't just about porn. For example, I can barely use Reddit now if I connect with a UK IP address: the merest hint that there might be some NSFW angle to a post is enough to trigger their algorithm into requiring age verification.
I would much rather fight this and retain my rights instead of participating in some kind of privacy and censorship arms race.
It's a temporary solution though. It's only going to get more draconian. Next thing you know the talk is about punishing VPN users, because now they can be painted as evading the law.
i mean yeah but you cannot do shit all about a vps. commercial vpns yeah you can ban and monitor. a vps is your own device just elsewhere
> i mean yeah but you cannot do shit all about a vps
Of course you can. The AS numbers of major hosting providers are well known and it is already common practice to ban associated IP addresses for stuff that should only be done by legitimate users.
you cannot ban aws or linenode my dude
Why not?
My friend, your phone might snitch on you depending what pictures or files you save. Your messages and calls can be saved at will without your knowledge. Even your notifications are being watched. Your apps have backdoors to spy on you.
It is already here.
< recording phone calls
FWIW the default phone app on GrapheneOS supports recording phone calls.
Did a nation state ask GrapheneOS to add that feature?
Why is it always "nation state" when this is brought up, do states and nations that aren't congruous not represent a perceived threat?
"nation state" has a particular meaning and it's not just "a smart-sounding way to say country" but it tends to get used that way.
It does have a particular meaning, but it is one that's not relevant in this context, and it's probably narrower than what the poster intended. For example, Belgium is not a nation state, but I'm sure the GGP would be surprised by an answer like "no, it wasn't a nation state, Belgium asked them to do it".
What do you mean by 'Belgium is not a nation state', if i may ask?
They probably mean that Belgium consists of French-speaking and Dutch-speaking (and German-speaking) groups, which the person counts as separate nations, hence Belgium not being one nation.
This is mostly a language confusion for non-native English speakers. Nation, country, state, a people, nationality, ethnicity, citizenship etc. are used in confusing ways for speakers of other languages.
For many, "nation state" just means an independent state (roughly speaking, a UN member, note also that the UN is called United Nations), because just saying "state" could mean a subdivision, such as a US state. And "country" can be confused with the subdivision of the UK (they call, e.g. Scotland a "country").
In more precise contexts of political history, "nation state" mostly refers to modern (post-World War I) countries that more or less correspond to a people speaking the same language and having the same ethnic identity. It delineates nation states from the previously more common multi-ethnic empires and kingdoms, such as Austria-Hungary or the Holy Roman Empire etc.
Similarly, in English, nationality is often an exact synonym for citizenship, while speakers of other languages expect it to mean ethnicity, e.g. an ethnic Hungarian in Romania with Romanian citizenship would be considered a "Romanian national" in English-language news. This often makes people confused/angry. Also, in some contexts in English, "ethnicity" is more like a euphemism for something like "race", but not quite (e.g. in the US "Latino" is considered an "ethnicity" but not a race). In that sense "Hungarian" would not count as an "ethnicity" at all, but still phrases like "ethnic Slovak" refer to a minority group in a different country than Slovakia. But also "ethnic" can also just mean with "exotic foreign origin", e.g. "ethnic food" or "an ethnic woman" (this was really weird when I first read it). But I digress.
I think you're spot on with this:
> ... because just saying "state" could mean a subdivision, such as a US state ...
Belgium may be used as a stand-in for Brussels, i.e. the European Union.
I think the author of the post was referring to the fact that Belgium is a multinational state, comprised of Dutch-speaking Flanders and French-speaking Wallonia.
I've heard Brussels as a stand-in for the EU.
I've never heard Belgium as a stand-in-for-Brussels-as-a-stand-in for EU.
But it isn't, here. The state of Belgium created itself by secession from the United Kingdom of the Netherlands, and its populace generally comprises two nations, Flanders (Flemish) and Wallonia (French), neither of which are continguous with the state, nor particularly interested in sharing a national identity with each other.
In short, a state is about turf, and a nation is a people, and you need them both to look similar on a map to make a nation-state.
TIL
The issue is bigger than that.
Why not two people share a device, and when passed from one person to another, delete applications and install all apps and profiles from scratch using verified checksums saved on a blockchain. An OS which could do that is something like Nix. When passed to the previous person same thing, delete and install everything from scratch.
Using smartphones in a smart way, not a dumb way, like timesharing mainframes of the past. Same procedure could be applied to cars and other devices.
Android's Multiple Users feature does exactly this. Multiple users accounts with all user data completely sandboxed and restricted to each user. All user data is cryptographically protected on storage devices.
The actual SE filesystem available to a logged in user is pretty complicated. But the short story is that user-data is completely isolated. Presumably application binaries (which require digital signatures by default) are shared; although the "installed" state is not. Successive releases of Android have restricted access to any legacy "shared" data on the device (media folders particularly; pictures and video taken by the camera device have been strongly protected since Forever).
Verified checksums on a blockchain are only useful if they are verified by some provider who associates a blockchain ID with a real-world identity. Not sure what "blockchain" really adds. If anyone can create a blockchain ID, then "verification" doesn't really provide useful information.
> Multiple users accounts with all user data completely sandboxed and restricted to each user.
User data and user programs. Clean installation kind of user programs.
> Verified checksums on a blockchain are only useful if they are verified by some provider who associates a blockchain ID with a real-world identity.
Nix associates a unique id to each program version or package or config file. The verification happens on the Nix package manager.
The user uploads his exact config of OS somewhere, in his own home server, at a goverment server, at AWS, on a blockchain, somewhere. A blockchain seems like the best solution to me.
This assumes that these two persons will never need to use a smartphone at the same moment, which is a bit of a logistical puzzle.
Installing apps is the trivial part; isolating, or removing / reinstalling user data is much harder. Especially a few gigabytes of it. An SD card could work maybe.
This all goes against the grain of the smarthpone UX, the idea of a highly personal device that you can use for anything, and might need (or benefit from) at an arbitrary moment.
If the point is reducing e-waste, the solution would rather be opening up the hardware enough to provide long-term software support, LineageOS-style.
> This assumes that these two persons will never need to use a smartphone at the same moment, which is a bit of a logistical puzzle.
In general no one wants to share anything with anyone, but when two people cannot afford a device individually, but it is within reach when they buy it together, time-sharing becomes a totally acceptable solution.
> Installing apps is the trivial part; isolating, or removing / reinstalling user data is much harder. An SD card could work maybe.
Checksums might overlap by quite a bit. No need to remove programs installed by both users. If the total installation of each user is 10 GB, but the installation diverges 300MB only, not a big deal in most cases.
The first part also happens on desktop thanks to DRM, unfortunately. Like on Android, it can be worked around, but it's a massive pain to do so.
I'm curious about the second part, though. How do carriers influence the call recording feature on your phone? Is it because you run a carrier ROM or is there some kind of integration with the mobile network/SIM card that I'm not aware of?
See https://source.android.com/docs/core/connect/uicc. UICC is the software component of a SIM card.
I think this might be a longstanding "bug", but I have also not had any luck on my android using the screen recorder to record device audio from a browser (either chromium or firefox). It used to partially work using the mic to record the speakers, but currently it sounds like it does processing to subtract away the original signal; I hear mostly silence with occasional garbled artifacts resembling the original audio.
Maybe this depends on the site? I have definitely recorded video with audio off YouTube and other popular video sites, on a stock Samsung phone, even yesterday.
Fortunately we still have the analog loophole.
Is not your phone and it probably never will be.
These petty measures are as self damaging to reputation as futile: one can easily make screenshot or do recording with an other device, which is soooo commonplace nowadays. It is just ruining user experience with small-minded measures, driving people away.
run a custom rom. Infinity X (the gsi one) does both
Custom ROMs do not work with remote attestation (typically), so that means saying bye bye to a lot of apps, including some banking apps.
please research before spreading missinformation. the specific gsi rom passes strong out of the box
Saying that custom roms typically fail attestation is not spreading misinformation, it is very correct, and google is closing the door on it fast.
It's possible that this one random rom that you mentioned passes it today, but it might not pass tomorrow.
My next phone will almost certainly be two phones. One cheap and super standard Android phone to just run banking apps and similar that insists on Google Play etc. Locked down and boring, turned off most of the time. Then a second phone for everything else (terminal with sshd, emacs, emulators, media players ... the stuff that allows a phone to be the general purpose computer it should be).
Looks increasingly unlikely that there will be convenient ways to have the best of both those worlds in a single device. For now it is somewhat possible with Android, but the experience keeps getting worse.
I am starting to do that but I still find that will be annoying to keep up. The dumb device will need to be kept up-to-date because that's important for e.g banking apps so that automatically excludes "old" devices (usually 3+ years old) because most stop getting updates that fast. Even LineageOS isn't an option because it does not pass Google's integrity checks so I am afraid I will need to buy a new dumb phone every couple of years..
After just submitting my recent post --- I do like your suggestion.
Maybe 2 phones are the way forward.
Maybe a PAYG phone which stays at home on my network for particular needs like banking.
Then a standard phone which is essentially a GNU/Linux distro.... mmm... Emacs on my phone sounds lovely!
I do have an Android for one app. But daily drive linux and have since the Nokia N9/N900.
I must admit, I don't do banking on the phone and keep all sensitive data off my mobiles.
Could you maybe run a hypervisor with both operating systems? Like one does on a server?
Or will that munch your battery?
Official Android with Google Play and all the things some apps require will almost certainly refuse to run if a hypervisor is detected. Maybe someone could get it to work, but it would be a struggle to stay ahead of whatever new security checks are added to the OS and apps. The point of having one perfectly normal phone would be to not have to worry about any of that.
Yeah, you second phone sounds like a laptop. I have a boring phone that I don't care about with basically factory settings and perhaps 3 apps. MyGov, Dropbox and something else I can't even remember right now.
And I also carry a super cool small laptop that can tether to the phone and actually do stuff with.
One is an appliance, the other is a computer.
I sometimes bring a bt keyboard to use my phone as a tiny almost-laptop, but mostly happy with something just the size and weight of a phone.
Used to have two phones ~10 years ago. A Jolla Phone was my primary phone with a sim card and ran most non-Google apps. Then I carried around a cheap Motorola Android phone that had no sim card but could run Google Play apps and when it needed wifi I shared that from the Jolla and otherwise it was fully offline and most of the time turned off.
So the phone that was closer to a small laptop was the one I actually used as a phone. Not sure if that is the setup I would go for again or if I would do it the other way around with the Google phone being the phone. If I do the latter I guess something like a very small Linux netbook would work as a second device, it such a thing exists.
As someone willing to put up with all manner of nonsense (overpriced/underpowered hardware, clunky UI, endless troubleshooting), battery life on mobile Linux devices alone prevents me from using them in the real world.
Is there a single Linux phone/tablet that can last an 8 hour day of actual use? Librem/Pinephone/Juno can't. My uConsole can't. Different category, but my MNT mini laptop lasts like 4 hours and can't be left in standby for too long or it drains to zero.
Meanwhile, it's been 10+ years since I've worried about daily battery life on mainstream mobile devices, even my 3-5 year old ones. I can fall asleep with Youtube playing and it's still playing when I wake up. I'm certainly not here to dunk on Linux phones. I want one! But if someone willing to put forth above average effort to use these devices can't realistically daily drive them, who can?
N hours of actual use, in isolation, is just the matter of calculating average power draw[W] by runtime[hr] and buying the battery with Wh figures comfortably bigger than that.
e.g. your device consumed 1 Watt on average, you wanted 8 hour runtime, then you need a battery with 8 Watt-hours, or 2,162.162162162162 mAh at 3.7V of capacity, before factoring in buffers of various kinds. But it's also roughly the datasheet nominal capacity of a single 18650 cell.
You don't worry about daily battery life on mainstream mobile devices and you can fall asleep with YouTube playing and it's still playing when you wake up because manufacturers know consumers do that and optimize the phone to make that work. They probably reduce display brightness, cut powers to mics and P cores, ask 3M to make the pouch films 1% thinner so battery could be few more percent bigger inside, fudge battery gauges so you would be nudged correctly to have enough charge before you fall asleep, the list goes as far as your imagination could possibly go.
The fact that same behaviors don't happen on Linux devices, even with something like four of fresh 18650s, means the list ends before it begins. They probably don't do ANY power profiling AT ALL. I'm sure they don't do ANY environmental testing, either.
Would I accept that as a consumer? No. Would I if I was the manufacturer? ...
This is a big part of why Android was developed in the first place. The operating system and application architecture that makes sense on desktop just doesn't make sense on mobile. Despite the many problems Google's restrictive APIs which you are forced to use can cause for developers, they are also highly optimized for power usage.
The architecture can work if enough smart people are put to work on it. That's how Apple managed to turn macOS into a mobile operating system.
I think UBPorts and Sailfish prove that Linux for phones is practical if you're willing to rely on Linux applications that stick to mobile friendly APIs.
You need to configure and compile your Linux kernel for aggressive power saving, of course. Seeing how Linux currently struggles to effectively do power management on laptops without S3 sleep, there's plenty of work to be done if you want to use it with a phone.
It's not just about app developers either, Qualcomm's modifications to the Linux kernel are public thanks to GPL but most phone kernel modifications haven't made it into the upstream kernel so far. Projects like postmarketOS are trying to make things better but it's not easy to port practical code that works into code that's acceptable for the maintainers of the broader Linux project.
SailfishOS also came (at least back in the day of the first Jolla Phone and Tablet) with an excellent terminal app and built-in sshd that made it work great with pretty much every Linux command-line and TUI application (only exception was of course those with hardcoded minimum screen size support). Termux for Android is maybe half that good, not as well integrated, but still good enough that I use it every day, much more than I use other apps other than the browser.
Android is also Linux, so Linux isn't the problem - its the userspace. In terms of wakeups, the systemd/dbus desktop architecture is the worst.
UBports (the maintained fork of the dead Ubuntu Touch project) runs fine with systemd/upstart/wayland.
Hell, my watch runs Tizen and that's running a bog standard Wayland + PulseAudio + systemd setup: https://docs.tizen.org/platform/porting/system/#systemd
With the right kernel drivers, configuration, and tweaks, with a well-configured userland on top of that, you can run the "normal" Linux stack in a mobile device.
Getting applications to conform with an API that won't let them drain the battery in the background to make sure notifications don't arrive two seconds too late is much harder. Desktop applications don't really like being suspended/resumed the way mobile applications do.
That's quite interesting. How would one go about making one's app or services suspend/resume friendly?
Are there well-known good practices?... Or, do they need to be rediscovered as they are perhaps proprietary know-how?
>Is there a single Linux phone/tablet that can last an 8 hour day of actual use?
What's "actual use"? Furi FLX1 has the best battery life I've seen on a Linux phone. Idling, it last 3+ days. I'm sure it could survive 1 whole day of "actual use". I also think almost any (official) SailfishOS device would last a day of actual use.
I have a Sony Xperia 10 III with SailfishOS and it easily does 48 hours on a charge when I'm not doing a lot of screen time. Also on days when I use it for tracking / navigation on 6-8 hour bicycle rides it easily lasts for the entire day and then some. I think this is not bad for a device that has been in daily use for almost three years and still has the original battery.
I'm running a couple of messenger clients and a web browser (Fennec under Android App Support as the native one is sadly a bit behind the times currently) all the time. The only thing I've noticed to eat a ton of battery is having wifi enabled when outside the range of my own networks, it seems the scanning the phone does in the background to look for known wifi networks is not energy efficient at all.
I also have this setup and SFos on Gigaset GS5. Similar battery performance. I did a roadtrip last week with navigation (starting with about 90% battery) and after 5&1/2 hours navigation was down to 65% or therabouts. Works for me.
And, yes, I often turn off wifi. I never go over my Data limits and 4G/5G is much more efficient for some reason.
SailfishOS is quite efficient. On Sony devices, I experienced maybe 15% extra battery life compared to stock Android, which is quite good given that Sony ROMs are excellent. Sony is known for their Sony Open Devices Program.
I genuinely think if Sony offered a Linux phone and didn't lock it down too bad, they could serve as the catalyst for the whole market. I don't think I would trust any other company at this point to execute the platonic "Linux phone" we need. The uncompromising vision on building a fantastic product for the technically minded make them an obvious choice.
I get the impression they shut it down, but Sony had/have the Xperia Open Devices program. They were close to having their devices running purely on the mainline Linux kernel:
https://developer.sony.com/open-source
Sony tries out so many different types of products too across their entire lineup. They have made some memorable handhelds over the years, even their eink readers were special.
They also pulled a bait-and-switch with Linux on PS3...
No doubt.
I was referring more to their variety of electronics in so many areas.
I've been considering this as my Android exit plan (as part of a slow rolling de-googling effort, even before the recent "sideloading" news). Are you using it as a daily driver? I'm sort of surprised it doesn't get brought up more.
Yes, I used SailfishOS as a daily driver since ~2014 until last year when I moved to the Furi FLX1. The FLX1 has been my daily driver since. SailfishOS is much more polished, but it's not fully FOSS, and it follows upstream much less closely. FLX1 is basically in-sync with Debian testing, with the exception of kernel.
Interesting. I had a poke at postmarket, which wasn't ready in comparison with SFOS. Would you say the FLX1 is at better stage in development than postmarket?
Are you able to run android apps aswell? Without whatsapp you're pretty much locked out from most communication around here...
According to their FAQ (https://furilabs.com/faq/), yes
The only detractions on the software side that I ever see are about it being a “hack” via Hallium, but to be frank, the device actually ships and is usable today. Linux purists probably need to stop complaining.
It does seem like there’s been a backlog with the latest orders though - maybe due to tariff hell? I keep wanting to order but their forum has a few people being thrown for a loop on the order side, so…
With my, atypical maybe?, use, I get up to 2 days on a 4KmA battery (Gigaset GS5, SailfishOs). Sometimes I'm down to 1 day if I do social media scrolling.
yeah there are lots of tablets and 2-1 with amd chips that can do 8 hours on light usage.
My HP laptop lasts 2 hours running linux. My macbook air m4 lasts 12 hours.
Your MacBook air has a team behind it ensuring it runs as efficiently as possible. Your HP laptop running linux has... you.
But I'm a good team.
apples to oranges
I think certain "Apps" that you need to do "X" keep this from happening. You can have a super lean, private and secure linux phone using super clean, fast OSS software to do what you need to do, but what happens if you need one of the mainstream apps (Uber, etc..) to function in society with the rest of the normies. Maybe a linux phone that can dual-boot into android? I doubt we will ever see companies pulling out of the app stores and offering browser-based solutions that will work on any device or OS.
While I share the concerns about Android, it feels silly to me to go back to Linux's (nonexistent) security model and bad mobile UI/UX. Why not try to fork AOSP or GOS (for broader device compatibility, even if it means giving up some its sexy security properties)?
Note that this could include packaging Linux GUI applications as Android APKs (with some additional glue code and Wayland/DBus integration of course), so it's not even an either or.
(Warning: Am only a software/product engineer, playing dilettante here, not an actual marketing/business expert.)
Awhile back, I was thinking that one pragmatic way to get this viable Linux smartphone moving might be for hobbyists to focus on getting one easily available, affordable device working fully with pure Debian or PostmarketOS (no closed drivers or other modules, and preferably no blobs) and with Purism's Phosh.
Then that would boost contributions to, and demand for, Purism's open source platform/components for Librem 5 (and whatever the successor hardware would be).
If the cheap hardware is something like PinePhone, I'm just going to handwave that maybe this device won't cannibalize much sales of Purism's premium devices, but instead the community investment into the platform will effectively generate much higher net demand for Purism's premium products. With higher volume, Purism could maybe also hit more accessible price points.
If the Purism hardware demand happens, then there may be competing hardware entrants. And they will have to compete partly on being trustworthy and aligned with the interests of the kinds of customer who want to run a non-Apple, non-Google device. Where Purism should have a head start in credibility and goodwill. The new entrants will have to contribute engineer time (possibly: pay community contractors) to getting their device to work well with this platform, and be expected to upstream all of it as open source to the platform mainline, if they want to be attractive to these customers.
(I'm not saying the cheap device has to be PinePhone; that just seemed the most likely one at the time. It could even be something like an older popular Pixel model, with many unlockable-bootloader units available cheap on eBay, for which people are able to assemble/develop open source drivers. Or maybe GrapheneOS will get their own device built, and it can also be used for this non-Android-based open Linux platform.)
> to focus on getting one easily available, affordable device working fully with pure Debian or PostmarketOS (no closed drivers or other modules, and preferably no blobs) and with Purism's Phosh.
I'm not sure how viable this is. Linux phones already opt for hardware that's as open as possible, i.e. they use parts with the most open documentation and drives, but the trade-off to that is that those parts are functionally already end-of-life when they're in the phone, either because it's an old design that's been opened up to squeeze a bit more money out of an old design, or the design was third-rate to begin with. Not to mention that the baseband side of things is closed no matter what, so the phone that's completely true to the FOSS ideals seems impossible to make no matter what. And who would buy a phone with a third-rate chip and battery life? And since very few people buy them, prices aren't able to drop any significant amount.
I understand why people aren't willing to make a devils bargain in order to make a decent phone first, and then put Linux on it second, but I can't see any other way for this to happen, other than the phone market magically becoming more open somehow. If you could install Linux on any phone, since all the drivers are already out there, then we wouldn't be in this pickle, but every single Android phone out there has a different set of drivers and very few of them are open and possible to implement without an enormous amount of work, unlike the PC world, were at this point, only the really weird stuff (and Wifi from certain vendors) doesn't have some form of Linux driver.
IIUC, there have been some efforts to compartmentalize/isolate closed baseband, when you can work on the hardware.
Separate from baseband, the (sub)device closed firmware blobs are non-ideal, and eventually you'd want open source even for those, but maybe don't have to be a high priority. Mainlined open source for corresponding drivers are much higher priority. Even Debian now tolerates such blobs.)
Why is the baseband closed? That is the question we need to have answered.
It doesn't have to be, the PinePhone's modem runs a proprietary Linux distro, which you can replace with an open source Linux distro. That is only the ARM processor of it though, the Hexagon one is all proprietary.
https://github.com/the-modem-distro/pinephone_modem_sdk/
A bajillion reasons, including that carriers basically white list basebands they're willing to interact with, and the patent situation means you only have a handful of baseband OEMs and they view their whole business model as building as big of a moat around their IP as possible.
Ultimately, it all stems from two things - for one, it's illegal to emit radio waves without a special permit. And secondly, it's also extremely hard to process radio signals at the kind of rates we expect today.
Together, these facts make it so that (competitive) wireless modems require organized businesses to create, and organized businesses don't want to share their code with competitors. A foundation dedicated to creating open hardware and software for a competitive wireless modem would face giant hurdles both in regulatory terms, and in hiring people who can actually work on this extremely difficult technical challenge.
Also, building an open source software for controlling wireless modems that complies with the law is probably not fully possible. Per law, to sell a wireless device, you as the manufacturer are responsible for taking reasonable precautions against users misusing it to emit in reserved bands, or to not respect military device priority in the allowed bands. If every user is extended the rights and documentation for modifying the software as they see fit, you're clearly not taking reasonable precautions to prevent them from breaking the law.
Ask the FCC
https://www.infoq.com/news/2015/07/FCC-Blocks-Open-Source/
I would honestly just prefer that they use some semi-crap Chinese phone that is running on well-documented stuff a generation or four behind. If you could get Linux on a $50 phone, whoever was shipping them would sell 100K units. People would buy them just out of curiosity.
I'm behind though: aren't the UIs for mobile Linux still bad? I still can't get the experience I got out of my N900 that had only 256M of RAM, right? Every project I remember to bring the Maemo experience to Linux seemed to wither because there was ho hardware.
In one of my Linux handheld attempts, I looked to evaluate Maemo for the vintage Nokia N810 and N900 as a starting point, but much of open source artifacts (code, docs, forums) had mostly disappeared, even from where there seemed an effort to preserve/migrate.
(But someone's copy of some of it might have resurfaced now; I haven't looked recently.)
Usually things like this disappear because whoever was paying for hosting for them (company, accounting unit within a company, or some random techie's basement) gets shut down. And maybe no one who had the interest and ability was able to preserve it in time, and archive.org hadn't picked it up. But occasionally, things get deleted with intention to suppress them.
Sailfish is the successor.
Their core is apparently based on Mer which was a reconstruction of Meego, which was what came after Maemo, merging it with Moblin, IIRC.
It's a bit tenuous, but you might want to look at Sailfish as carrying the torch in that area.
What I don't get (plz help me) is why out of a sudden this vendors close up their phones and why is Google going this way? What's their intend?
I think it's an unintended effect of Europe regulations. Google saw Apple exploring what's the bare minimum to comply with EU regulations regarding openness. And Google is setting their bar there.
What does it have to do with the regulations? Does they forbid open phones?
> What's their intend?
Some say it's eSIM and identity integrity
More money. More power. Greed. Don't ever underestimate human greed. It doesn't matter what people have or where they are, they will always want more. We only have what we have now because of a few very peculiar people like Richard Stallman, but now it's just a bunch of normies in control.
I've always assumed that there is some money related intend behind this. But I can't figure out what money reason it is.
I'm guessing immortality I'm not joking. We may be the generation that has the right escape velocity to escape death. Vladimir putin mentioned it in his recent china summit
It's not sudden, and it's about control. You probably don't remember a time when you could switch/remove batteries from your phone. All manufacturers removed this ability.
That was one very good reason for me to choose a FairPhone. (Almost?) everything is user replaceable. It has been in my pocket for a could of years and I have not needed to replace anything yet. But I do like having the option.
Samsungs Galaxy S21 is also really simple to fix stuff. The back is made of relatively flexible plastic connected via glue, which you can easily get under by blowing into the charging/speaker port. Once your inside its all just a lot of screws.
Had to reattach the battery ribbon cable after my phone fell one too many times (I could have also just fixed it by pressing on the back in the right place, but I only really figured that out after I disassembled the phone).
EU is bringing user replaceable batteries back. Starting 2027 all new consumer devices must have user replaceable batteries.
I have a Volla Phone running Ubuntu Touch. In order to insert my SIM and SD cards I had to take off the back cover (which is intended and I just had to pull on a small gap in a corner of the device) which also made it very obvious that it's easy to take out the battery should I have the need to swap it out.
Less conspiratorial answer:
Bootloader unlock removal:
It's actually not happening all of a sudden. The dam-breaking moment is more that Samsung, the number #1 Android vendor, decided to stop supporting it.
The vendors stop maintaining bootloader-unlocking methods because the cost/benefit profile to develop/maintain/support that feature and its consequences is simply not sufficient, all while several of the biggest customers explicitly require unlock to NOT be supported.
Supporting this is not just about the unlock itself, it's about allowing this unlock (required as some carriers explicitly forbid this, so a unlock needs to be requested), then performing the procedure (using a shared secret between the device and the vendor) and then the OS continuing to boot in this untrusted state with all components gracefully handling this broken trust-chain.
The commercial incentive for this feature isn't there for a device-vendor, it actually never was. It was built, defended and fought for by passionate people (mostly within the R&D) of those companies. Companies which managed to implement it early (in times of higher product margins) were able to keep it longer, others simply couldn't get the budget to implement bootloader-unlock in the first place. Today, devices are shipped with commitments of several years of upgrades, without the vendor actually knowing yet how the OS-upgrade in 2 years will look like. Keeping his custom security-implementation is a risk-factor here
The 3rd party OS developer community was always small, and became even smaller in the past years. The footprint of alternative OS users was shrinking since Cyanogen (the leading "universal kernel" developers for Android and predecessor of LineageOS) dissolved (or tried to become a for-profit).
However, the events around Cyanogen were more of a public symptom, The main driver for people to stop using 3rd party OS's was:
1.) The increasing fragmentation of devices in the market: When the community started, the majority of the market was Samsung, Motorola, LG, Sony. Samsung was leading, but each of them had quite healthy parts of the Android market, competing with each other in an "almost-stalemate" situation. Today Samsung is leading with a huge margin, all others are basically fighting for scraps. So naturally, most of them try to go for the lowest common denominator and find a distribution channel.
2.) Android itself became more competitive: At the height of the OS community, people switched to alternative OS's to get a newer OS, new customization options and convenience features. Today, vanilla Android checks most of the convenience options already, sufficiently that most people don't want to bother researching alternative options, maintaining them, etc. Devices of major vendors are receiving upgrades for several years (back then it was ONE major-OS Upgrade, a YEAR after Google's release, if at all)
3.) Device-integrity became more important: At the height of the OS-community, there was no Device Integrity check by Google to give a flag on whether the device can be trusted or not, so all apps kept working (with minor exception of some streaming services restricting their service/resolution, as the DRM keystore became unavailable on unlock). Today, most banking and entertainment apps rely on those Google integrity checks to decide whether they should even start. This introduced another reason for users to consider their actual need for an alternative OS.
--
How to change that: If it's not possible to create a commercial incentive for the vendors, a regulatory incentive could be an option.
It's crazy to think how much computing power is just added to a drawer or landfill every day, just because there is no reason for the vendor to allow you to repurpose it.
I think this could be a path, to legally require device-vendors to provide a common SW-layer with respective documentation to utilize features of underlying hardware (optional without the shipped OS on top, disconnecting the device from the shipped ecosystem). This would prevent e-waste and put this old hardware to better use. A community OS could then be built on top of this common SW-layer and be maintained for a wider range of devices.
I would e.g. LOVE a "Browser on everything" OS which just provides a Browser OS for outdated hardware, but the only way this could work on scale would be if the device-vendor would be mandated to provide and document the lower layer...
Someone would have to make the economic case for such a regulation as well, i.e. demonstrate the benefit for society if that is in place. The chances for this are razor-thin, especially in today's public/political climate.
sounds like Firefox OS would've been right up your alley(?)
Yeah well, not in the way it progressed after the carriers started to take control over it (I was actively involved in a Firefox device-project back then).
What I sketched out here with a "Browser on everything" OS would be a concept for a aftermarket OS, where the device-vendor is not required to have his OS support the unlocked HW (because he can't be forced to do that), but he will have to provide components and documentation up to a certain layer to make use of the hardware. This could then be the layer for a generic "Browser on everything" OS to work on.
Very much thanks for this text. This makes much sense. I don't think regulation would help ... only ppl who show their raised middle finger to this vendors. I mean this scenario is the scenario ppl thought of when TPM came up ... a fcking closed up device and you are in the hands of the vendors.
People showing their middle finger won't be enough, because the vendors are torn between two groups of interests here:
1. Building a HW/SW product which works within controlled boundaries to provide warranty, support, repairs, future maintenance, Google-compliance, regulatory compliance,...
2. A subset of Customers wanting the HW to be separable from the SW, for product to be open in a way that they can use it differently than intended (potentially creating "Group#3", a HW/SW product with a different SW).
To create a product for Group#2, alot of the aspects of Group#1 still apply, but in a more-complicated, more-expensive manner. If there is a viable business-case for Group#2, it will be a separate more-expensive product with lower volume.
But in reality, the only way a vendor could meaningfully resolve the needs of Group#2 is if ALL his devices support this feature (including customers who don't want a unlockable "open" device now), allowing everyone to become member of Group#2 without having to buy a new separate product.
For this, the economic incentive doesn't exist.
Explicit example: The Fairphone is a great device, but it will never sell more volume than a Samsung Flagship, because it's a device satisfying the conscious needs of a niche of customers, without the chance of reaching comparable volume to compete in all other areas.
That's why the only chance I see is to create a regulatory incentive by making the requirements of Group#2 a part of Group#1, to have the "unconscious needs" of the majority also satisfied.
Because only THEN the mainstream-customer can be converted to *users* of this potential "Group#3" product, and market-forces have a chance to flow freely again, if you see what I mean...
The government is also keen to have these devices controlled more tightly. Now with the help of the big companies so much data is on the device and in the cloud about you that policy enforcement, tax evasion or anything else that the people in the government deemed crucial for them is much more easily done.
Check how China controls the Uyghurs phones and will they be happy to have "unlocked bootloaders".
It's not profitable for the companies to lose total control of "your" device you "bough", nor for software developers who sell you the software to have "ReVanced" versions of their apps. Just a small minority of people who understand what is freedom and ownership are aware of the dangers of this.
Basically, not enough people care to have this as a priority and make it an election issue. And sadly we're walking into more and more control, ads, and enshitification. :(
> The government is also keen to have these devices controlled more tightly.
Not to oppose what you wrote, but let me try to give you a different view on the same picture to support a different conclusion:
In the eye of most governments these devices play such a minor role that they practically don't even exist.
What governments see is messaging services, finance services, digital marketplaces, and so on. They used to regulate telecom providers, financial institutions, marketplaces in the past, and they are now catching up realizing that the carrier is no longer the messaging provider, banks are not in control of all finance flows, marketplaces exist beyond the classical physical markets, etc.
If you look at detailed regulation and laws, Governments still have little interest in the explicit devices, they still look at those new variants of classical services and try to adapt to them.
But what the PROVIDERS of those services do, is creating pressure on the devices to help them reach lowest-effort compliance for their SERVICE-requirements (--> "let's make the end-user device bulletproof trusted, so we can offload our responsibilities to his device").
This is in most cases why the devices evolve the way they do. Because they are a merge of product and services (often from the same vendor), and the product is evolving to satisfy the needs for those services.
That's why fighting for "ownership of your device" is mostly futile, because the assumed opponent in this fight doesn't even feel addressed.
You need to bring the fight to their topics, to the topics relevant for governments:
On how a citizen ID should be verified, how financial services should be realized, how a competitive market should be ensured also on digital markets, etc.
Less conspiratorial answer (better late than never):
Google services, integrity hardening:
From outside it might be difficult to understand the distinction, but Google is acting here as the owner and maintainer of a services ecosystem, which is the entire Google service-package provided to end-users. For them, Android is provided as a foundation for that package, and they increasingly experience difficulty to contain issues within that ecosystem and prevent them from spreading (piracy, malware, hacking,...).
The logical way out for them to contain those issues is to ensure that members of this ecosystem (=Devices with Google Services, Developers) are vetted more strongly.
Now Android has a history to be an open ecosystem, which allowed it to grow to the size it has now. But similar to the bootloader-unlock situation of device-vendors, the economic incentive of an "open ecosystem" keeps shrinking in comparison to the risks and issues it's causing Google in governing their services-ecosystem.
They obviously decided now that the price they have to pay for that "open ecosystem" (less control over the services ecosystem) is not justified anymore.
Now they have little room to move. In order to preserve that "open ecosystem", they would have to provide the user an option to disable Google Services entirely. But Google services are such a integral part of the OS-experience already that it which would turn the device almost into a completely separate product, different from the product the vendor initially built and the consumer initially purchased.
--
I don't expect this to be properly resolved for the sake of "pleasing the community". Products and Services are already so tightly combined in the Smartphone-space that it's hard for most to even understand what it is the user actually purchased when he bought the device.
Now Google the service provider starts to change the users' device in order to maintain his services, and there is no up-to-date definition to what degree he is actually allowed to do this.
How to change that: The underlying customer-protection framework is missing. A solution would be a general legally binding definition of what functions a customer owns if (and when) a device is stripped of any services on top.
If my car loses functions once it loses connection to the manufacturer, this bare set should be communicated as the purchased value ("in exchange for your money"), separately from any on-top ("in exchange for your data") business-model.
In theory this could create competition on the actual purchased value again, instead of continuing to offload the value from the device to some service provided by the vendor/service-provider...
But that's such a complex topic, the implications should be studied much deeper. Also, I don't expect political bodies to fully understand it for years to come, leave alone create a proper case to get the required voting and decision...
Isn't Android... Linux?
It's not "gotcha", just... there are many clones of Android that work without Google Play, because Android (AOSP) is based on Linux. Why not just use that? What does "linux phone" add?
> Android that work without Google Play,
https://github.com/microg/GmsCore, so basically you cannot. It's monopoly in daylight.
"Linux" is the name of the kernel but people use the word meaning something else.
People want a "Linux Phone" but have trouble explaining what software stack they want and how Android is not already it.
I have a feeling forking Android is less cumbersome than creating a Linux phone from scratch, and you get to keep compatibility with existing apps.
Android is a modified/patched linux kernel with a different userspace.
Google still controls direction of AOSP development.
Nobody actually cares about the kernel. They care about having control of their phones instead of the company that sold it to them, and they care that the userspace is normal, rather than weird and constantly changing according to the whims of the company that sold it to them. They do not want to carry conmen, swindlers, and spies in their pockets.
People mocked Stallman for saying GNU/Linux. Turns out it's important to specify what you're talking about, or people will misunderstand you. I use Debian. If Debian rebased to BSD (forked and relicensed to GPL, with gnutils) I'd probably still use Debian. If iOS rebased to Linux, I still would never consider touching it.
My opinion is that people actually want the political protection offered by the GPL and the people and projects who stick to it, like Debian (and others.) They do not acknowledge this to themselves. They usually want to be able to layer a few proprietary toys on top, but those are visitors who will be ejected for bad behavior, and they want an OS that will rat on that bad behavior when it sees it. They are afraid of this political project because they are afraid of politics (or because their professed meatspace politics turn out to be the opposite of what they actually want in their own lives.)
I'm a very happy Sailfish OS user, since 2016, before that Meego, Maemo (Nokia N900, N9). I do have an android phone for one App (Deutsche Post) which I use only when I need to ship stuff. Running on a Gigaset (made in Germany, 4KmA battery) I generally get two days of usage, 1 day if I'm stuck on Mastodon.
From being able to do SDL2 stuff (Godot 3.5 for instance) with a wayland compositor to just not having f'ked UI, I'm happy. The challenge of getting more apps is certainly a challenge. But that's good, gives me lots to do.
Linux on Mobile has already long been here to stay.
Oh, hello, i recognize your username from the jolla forums :-) I do have two Gigasets here (GX290 and GX4 pro) waiting to be flashed, but I still need to finally set up a windows machine to make a proper backup of the stock android images and generate the scatter files. Like with most of the SoC-Vendors, the MTK tools are quite a PITA. I have to download some weird binaries from some weird websites. How can it be that there are no official tools available for things like this?!
And there is one more Question I have since you're already here ;-) I'm already doing embedded Linux development in my day job, so I would say I have quite some knowledge in that area. However I haven't found a good introduction to this whole "porting" topic. Do you have some advice on how to get started in that direction? What exactly happens when I flash (say) sailfish onto some (specific) Android version? Why do I even need this? How does the whole libhybris thing work and why don't people just use the binary drivers from some Android image? It's all very confusing to me. Especially since people from the android corner seem to use different terminology that the embedded Linux crowd...
anyway, thanks for your work so far. I hope I can join the SFOS users (again) soon!
Linux phones are useless for common people until they can run government and bank apps.
In giant font at the top of the linked post:
> apparently it needs to be said that I am not suggesting you switch to Linux on your phone today; just that development needs to accelerate. Please don’t be one of the 34 people that replied to tell me Linux is not ready.
Linux is ready, what is not ready is the ecosystem.
SailfishOS is quite polished, and there's an Android emulation API. Lots of common applications, including many banking ones, run without a problem.
It's a chicken-egg issue. The last 10% of polish won't be done till a critical mass of users adopt the platform, and vice versa.
>SailfishOS is quite polished, and there's an Android emulation API. Lots of common applications, including many banking ones, run without a problem.
Remote Attestation and the Play Integrity API will soon make that stop.
Power management and cameras are working and stable on (non-Android) Linux phones? Which ones?
Exactly. The kernel more or less doesn't matter, it's "the stuff on top."
Unfortunately tech people don't understand this.
Common people don't care about the OS, they care about apps.
I smell a "no true Scottman" here. Because people always say "common people do what I say" and when someone says "hey, I am common people and I disagree", the same people usually answer "well, then you're not common _enough_". Which is a huge fallacy.
> Common people don't care about the OS, they care about apps.
My statement is based on 25 year as an IT professional where I migrated people and businesses from Windows to Linux, from iOS to Android, from old Unixes to Windows/Linux and the list goes on.
Just give to people the apps they need or want and the rest is easily managed.
Some tech people don't care what common people want, they just want a cool phone for themselves.
> Linux is not ready
OK, but what steps are being made to make it ready? How do you solve the issue of many apps not accepting rooted Androids (and very rightly so)?
I mean, Linux distros even struggle with Secure Boot on a normal PC - which is a far easier problem to solve...
Reverse engineering those government apps and writing native FOSS replacements would be a start.
I absolutely hate that government and bank apps are only available on the Play Store. You are legally required to have a Google account and accept their ToS to use them. I am aware of Aurora, but some banking apps check their origin and refuse to run if not downloaded from the Play Store.
I had to deal with this for government apps specifically related to immigration. I don't mind banks requiring it, I don't have to use that bank. I do mind governments requiring it if my only recourse is having to leave the country entirely.
> I don't mind banks requiring it, I don't have to use that bank.
What if all banks require it?
Banks aren't required. Its ridiculously inconvenient today to not have a bank account, but you aren't required to have one.
They are required for just about everyone in a lot of countries. In the Netherlands a bank account is actually a right¹, and as far as the tax authority is concerned, required.
1: https://www.belastingdienst.nl/wps/wcm/connect/nl/intermedia...
You should still be upset about it.
What does being upset about it solve?
Companies can choose what product to offer and what customers to serve. I can choose what products I'm willing to spend my money and time on.
My problem is when I am compelled to use something despite my opposition to it, such as the immigration app I mentioned being force to use under threat of being kicked out of the country.
They are required for salary payments in my country.
So so, housing isn't required and no one requires you to buy food either
Cash salaries are banned in some European countries. You can't have any income without a bank account. Welcome to the dystopian future, enjoy your stay.
Do they not have websites to login with?
IIRC Payment Services Directive aka PSD2 in EU for banking sector mandated verification of users and transaction and one of such ways is verification through mobile app.
When I login to my bank on desktop, after passing thru standard flow of login+password (plus silly "pick the avatar you once selected placed at random on this grid") page shows a modal to approve once, approve and add to trusted devices or log out (which never works on dynamic IP). Then I need to approve in app with secondary PIN aka "mobile password" in my bank terminology. Operations on both desktop and within app require that secondary PIN; transactions up to a specified limit do not but mobile payments done with temporary 6-digit codes need a confirm
Some force 2fa with their app only.
I've heard this argument before and yet I've never understood it.
What government apps do people run? Why do you need to access your bank account on your phone? Is this some payments model that's just not common in my country where we still use physical credit cards for everything?
My bank doesn't yet require the mobile app (quite), but all interactions are significantly more annoying without the app. My 2FA options all require a phone, either for the insecure method of texting me the code, or else an app-only option (they don't allow generic 2FA apps, but instead require a specific app, that almost definitely won't exist for a linux phone). Even verifying my identity on the phone is better with the app (the app generates a code that they just accept, it can be done without but it's slower and more inconvenient).
So no, my everyday interactions don't require the phone app. But any interaction that is novel enough to require direct communication with the bank has been rendered annoying without the phone app.
I'm someone for whom I'd probably be willing to deal with all these inconveniences to make my statement about ownership over my hardware and software, but I doubt that very many average consumers would.
I work for a bank. There is a strategic focus on the mobile banking app over the web app. Younger generations are doing everything through their phones. Including applying for home loans. Many banks are moving towards being digital only as contactless payments means people are using cash a lot less to the point that physical bank branches don't make sense anymore.
I had to use government apps as part of their immigration process, the apps were only available in the official app stores. If I remember right they had am all for immigration services, though I know for sure they had a digital ID app that was absolutely required.
The major banks in that country also required apps from official app stores, though I don't think I was technically required to have a bank account. I was in the country under a program based on owning my own consulting business. I did have to prove financials to the government as part of that, but maybe there was a way I could have technically done that without a bank account which required a mobile app.
> Why do you need to access your bank account on your phone?
Many banks require you use their app to do anything, e.g., make transfers, approve debit card transactions, register your biometrics to unfreeze your account, etc.
And no, choosing a bank without these requirements isn't possible in some countries.
> What government apps do people run?
Public transport ticket app, government ID app, drivers licence app.
I do believe all of these specific examples run fine on rooted Android without too much hassle (unsure about the second one), so they should be emulatable or whatever on a Linux phone, but that assumes that experience holds up decently well, which I would be surprised if it did for apps like this.
> Why do you need to access your bank account on your phone?
Because the app is a whole lot better than the web interfaces my previous banks had. Plus the added convenience. I'd prefer that the web interface was just as good as the app, but I'd still use the app even if that existed, just due to the convenience.
The driver's license apps will start requiring a non-rooted phone if they don't already.
So continue to use a physical licence instead. Most are credit card size so they're not inconvenient to carry.
At present, governments and banks are freeloaders piggybacking on the popularity of the smartphone. If these entities end up mandating access to their services via this route (or making them nigh on impossible to access by other more traditional means) then users should demand they be issued with phones specifically for the purpose, as owning a phone is not prerequisite or mandated requirement to live in society—although if trends continue it likely will be.
Moreover, as phone technology easily lends itself to location tracking any mandatory requirement for phone vehicle licences would soon lead to mandatory location tracking (and easy to implement and impossible to disable with government/bank-issued phones).
That's the logical endgame, and it'd be showdown time. The question is does the citizenry have the guts and resilience to resist such authoritarian impositions.
Frankly, I'm horrified at how easily users of these essential services have been bought off by online conveniences, they've not only become careless and blasé but by default they've also conceded to the withdrawing—and in many cases—actual withdrawal of traditional services in favour of ones that both governments and banks have more control over—and in the bargain they've chucked privacy to the wind.
Many drivers already install those apps
https://www.usnews.com/insurance/auto/how-do-those-car-insur...
Only a question of time until it becomes mandatory
I do most of my banking and investments on my phone. I don’t think I’m in the minority here.
People in non-US countries apparently have a litany of government and banking apps which are mandatory at all times.
They're rarely completely mandatory (Grandma still needs to be able to access her bank too), but the alternative is usually a whole lot more inconvenient (sometimes for bad reasons, sometimes just because that's how life is).
> (Grandma still needs to be able to access her bank too)
In some countries they are mandated if not by law then by implementation, a relative or a social worker is tasked to get grandma equipped with a "smart device". She can even borrow it for a few months from municipality services until she can afford to buy it
This might be an extreme example, but with Saudi Arabia's Absher app you can do almost everything related to government services, IDs and passports, car and driving licenses, visa, all kinds of permits etc. Other countries may have similar apps.
Digital ID in Sweden uses BankID - it is used for everything from identifying at government pages, to your bank, to the supermarket, etc.
> Why do you need to access your bank account on your phone?
My bank requires me to authenticate all online transactions via the phone app. Without it, it's not possible to make online payments.
> What government apps do people run?
There are a bunch of them here in Australia, and there were several in the UK.
Here there's a secure ID app for government services which is used as 2FA on the web interface, and various apps to access state and national government services directly. There's a tax one that allows you to scan receipts to collect them up for your annual tax return. In the UK I had an NHS app, can't remember what else.
They aren't mandatory, you can live without them, but they are often convenient.
> Why do you need to access your bank account on your phone?
Because it's many people's primary computing device? Why would you not want to access your bank accounts on your phone?
And because if you want to log on to some banks websites you need to have a 2FA security code which can either be generated by a dedicated security device, which has become less common now, or by an app on the phone which is then usually biometrically protected. There is sometimes a second code-generation method for higher value transfers.
So it is convenient to be able to send payments in the bank app, though less common than using my phone instead of the physical card through apple/google pay (those don't require the bank app to be installed).
Linux can emulate android. Most banks have websites, and the only real blocker for banking apps I've seen is the photo verification due to hardware issues connecting to the emulated android system.
the app for one of my banks which i need for 2FA won't run on my /e/OS phone.
Get Droidify; there are wrappers and root tools to override these checks.
> Linux can emulate android.
It can't emulate hardware attestation though, which most bank apps now require, so good luck with that.
You can do pass through attestation with access to kernelspace. There are a few things that don't pass (play protect/wildvine, but that's by design, not a limitation of linux)
And do you think that will matter in the near future? Because every app developer will just set their apps to use the highest attestation requirement by default and every normal android phone will pass that test. The few percent of people that use something else can just fuck off.
I think the only viable solution is going to be to have 2 devices: one for government and financial services and one for everything else, where you still have some hope of privacy.
This is what I'm thinking. Android supports multi-user, right? So a cheap Android POS shared with the family that gets left at home most of the time.
I also think just not using a phone as much is a viable solution. People are addicted to their phones so it would feel like intercision at first. But freedom is worth it. Never sacrifice freedom for convenience. You actually don't need to look up stuff on Wikipedia at any time while you're outside. Just be outside. Be offline. It's fine. It's better even.
I'd be happy just going back to a dumbphone for the phone bit and having a portable GNU/Linux device for travelling. I still have a 15 year old Dell netbook but sadly the battery is shot and it's no good for the wonderful "modern" web. But something like that would be fine.
> I also think just not using a phone as much is a viable solution.
Most European banks force you to use your phone for 2FA if you want to pay your bills, no matter if you're sending the transaction from your computer or your phone.
Yeah the point of this subthread is having a shitty device just for that crap. I don't need to pay my bills at a moment's notice from anywhere in the world. In fact, I refuse to.
My bank's mobile app no longer supports my 2017 Android phone. I thought it would be a big deal but honestly I forgot about it until you mentioned this, it's been 6-12 months.
Those apps usually require Google's version of Android (or Apple iOS), and block alternative Android builds using attestation:
https://grapheneos.org/articles/attestation-compatibility-gu...
I don't agree. They're useless until they can call, text, and do video / camera reliably. With enough adoption, the rest will come, but they won't ever get adoption without nailing those basics.
Adoption will come only and only with essential apps people use every day.
And those apps get developed only if there are enough users. Catch 22.
Microsoft didn't manage to make Windows Phone a viable competitor against Android & iOS, and they're about an order of magnitude bigger than any Linux-focused company. I hope the conditions shift and an open phone OS can take off, but I don't know what would enable it.
What's an example of a government app
In Australia: Centrelink, Service Victoria, Medicare, myID (formerly MyGovID), ATO (tax) — for a start.
There's no great reason for these to be Android/Apple specific. I'm just offering examples as requested.
And much appreciated - was not aware of these (other than covid vaccine apps really not seen them so far). Have a good day
Portuguese government app: https://play.google.com/store/apps/details?id=id.gov.pt
Allows you to have a digital copy of your ID and sign in to government sites/services (there are alternative methods).
I believe you can still connect to Chave Móvel Digital with only your PT phone number, no ?
Oh João vai-te deitar pah. LMAO
ROeID app, which is required by almost all RO government websites to log in.
Identity apps as well as apps to access government and social programs.
Not to mention why specifically government apps? Would those not be covered by general compatibility with web standards?
Wouldn’t well designed mobile web-apps suffice for that use case? I have several web-app site shortcuts linked on my Home Screen which behave just like the native apps. In most cases I don’t see why that would not be sufficient, including most “government apps” use cases
The BC Service Card app
I've had the same (US) bank for 20 years, it's a small one, they have a nice web interface (and I can deposit checks through it on my laptop) but I've never run into a situation where I needed to have some smartphone app to do my banking. (I also don't have a smartphone.) Is this common with major banks? Do they not have web interfaces anymore?
Outside US lots of banks use apps to generate a token and authenticate website transactions.
custom apps, that allow no alternative.
At least with my CU, mobile check deposit is the only function I need a mobile phone for; everything else is equally available on the web interface. (I could go to a physical branch, in lieu of mobile, I suppose.)
They do, but some seem to be gradually removing functionality (like check deposit via scan + upload) in favor of using their amazingly convenient (/s) app.
A lot of major banks worldwide have apps, and they usually require un-rooted phones.
People here seem to think this is some sort of Orwellian attempt to control them, but the reasons are more mundane and technical - many of them (mine included, from two countries) use security facilities on the phone to secure your accounts.
For example, my HSBC UK app has replaced the little calculator thing they used to ship, and uses iOS face recognition to secure the generation of log-on codes which you need in order to use the web interface, as well as for secure access to the banking app directly.
With a rooted phone they don't have the guarantees that these aren't being exfiltrated, or the app being subverted in novel ways, so they don't want to support it.
You may not consider this a good enough reason, and I have heard it said on HN that 'the banks shouldn't get to control what I do on my computing device!', and that attitude is absolutely fine, but then you'll most likely end up with either less secure banking (meaning more fraud, higher fees etc) or going back to having to have a dedicated security device.
> I can deposit checks through it on my laptop
American-like banking detected... who uses checks in 2025?! :)
> American-like banking detected... who uses checks in 2025?! :)
Yeah, fair. :-) I live in a small town, the only check I write is my rent check, which I literally walk across the street to deposit. But I still on rare occasions receive checks as well.
Ha. Fair enough. That sort of thing is almost exclusively done using bank transfers here in Aus.
I did receive one check this year, a refund from a company who had screwed up billing on a medical scan. For some reason they couldn't just refund it to my debit card. It was really annoying to have to get to a bank during opening hours to deposit it, but my bank here doesn't offer mobile check scanning. Some do, my old UK bank did ... oh well.
> going back to having to have a dedicated security device.
... and ...?
There are ways to implement security without tying it to one of two app stores. Companies might even get creative and figure out hardware standards for secure verification that are portable, open, and give the user control. They figured out sim cards, and are worried about GAI they created taking over the entire world, they could figure this out.
> ... and ...?
Personally I prefer the device convergence rather than having to have another thing to keep track of. Plus the added factor of biometrics over pure hardware 2FA.
But you do you, as they say, the point is there are tradeoffs.
> There are ways to implement security without tying it to one of two app stores.
It's not just about the app store - people want to be able to run these on rooted devices, which is an end run around the security guarantees these apps currently rely on.
> Companies might even get creative and figure out hardware standards for secure verification that are portable, open, and give the user control.
I wish you the best of luck in this endeavour.
I hope that they already aren't relying on client-side security any more than they have to. I'm afraid I'm not familiar enough with the APIs around biometrics to know if there's a useful way a server can use the onboard devices to verify a user's identity without relying on client-side security in one way or another though.
It's true on desktop we have stuff like FIDO2 authentication using hardware tokens, which are supported on open systems like firefox on linux. I'm sure it's not insurmountable or unthinkable to do similar on phones. At the least there would need to be a system of remote attestation for the biometric hardware, and a way for it to provide a verifiable response to a remote server. Far from insurmountable, but someone will need to actually do it.
Goes against FOSS still though if there are processors in the system which can't be user-controlled, and biometric chips which perform remote attestation (see the recent discussions on how passkeys are fundamentally OSS-hostile).
Why not just use the browser?
I need my banking app for 2FA to login with the browser. No, they don't use or allow TOTP.
In the case of my bank:
I had to enable secure auth to access some features. This works only with the mobile app, even when logging on the web I need the mobile app.
Some functions are available only in the app as well. Now I’m stuck with the app because I need those and needed secure auth to access those functions.
It’s evil but I has no choice (no choice of other banks either for reasons I won’t go into here, just accept it and don’t tell me to change banks. Other banks are no better anyway. )
yes, we know. Why do you feel the need to highlight the most negative aspect of the adoption?
> until they can run government and bank apps
That will never happen. Governments are invested in people depending on surveillance technology. Black mirrors are a tool for controlling the masses.
Thankfully neither of those are required in the US.
Not yet.
Curiously the linked discussion begins:
The authors largest bullet point is on author identification. What are the arguments against this and do people really feel they outweigh the benefits?
My view: I would think given how many code supply chain attacks we've see recently this would be be regarded as (at worst) a necessary evil. How much software used by large numbers of people does the open source community think will be done by anons?
Sidenote: The author implies SyncThing development was stopped due to author ID but the post linked does not say this and gives a completely different reason (forced updates)
A couple of last years were quite impressive in how mobile linux improved.
Still, people claim: - open-source phones are low-end devices - but we (also) write our DTS for phones like Xiaomi, Samsung, OnePlus, etc. Personally, I've written dts for my Xiaomi 12 lite and packaged postmarketOS for it. for devices like Fairphone - there's already a good level of support in mainline - mobile linux is slow and laggy - this comes from the 1st point. modern smartphones works quite smooth, and mine xiaomi phone running on sm7250 (mid level soc from qcom) feels very snappy. hell, even desktop browsers works quite good on more or less modern phones (chromium is especially smooth) - UI is trash - please check out gnome-mobile. it's an impressive piece of work and feels very much like modern mobile UIs - my bank/government/etc forces me to use ios/android app - we have waydroid! so, you can run any android app from your launcher (which will be running inside a container with lineageos). the integration might not be super complete right now, although it closes the gap for me.
Of course, there are many gaps (like camera works on very few devices and photo/video quality cannot be compared to android; some apps are still not adaptive) but many enthusiasts continue to improve on all the directions. Kudos to all of them! Personally, I wait for VoLTE and immutable systemd-based pmOS.
Apologies if the idea is absurd, but wouldn't a Linux handheld without a cell modem be easier to build and distribute? Think something of an analogue to iPod Touches, which were iPhones sans the the phone part.
This would skip a lot of the regulatory red tape, bring down costs, and make the devices more accessible so they’re in more developers’ hands. They’d have to tether from your primary phone which isn’t ideal, but workable.
The main question, current smartphones are nearly 100% camera-phones, and people just used to camera-phone world and don't want anything else.
But unfortunately, tiny camera is hardest thing and it is not coincidence, that nearly all whales of smartphone industry regularly show outstanding camera on their presentations.
Other things except camera are mostly accessible for Linux community.
I use a Nokia/HMD KaiOS phone as a 4G/Wifi router for the communications part of your idea.
Did you choose a KaiOS phone specifically because other current non-smart phones lack support for Bluetooth tethering (a.k.a. PAN profile)?
As far as I can tell, all currently available models from all manufacturers are based on some Unisoc platform and offer no indication of support for this feature in their manuals. Did you happen to come across any alternatives?
I'm not very keen on KaiOS given the ubiquitous advertising baked into it (which is apparently their business model).
What about all these raspberry pi hats with cell modems? Are they missing anything like usable IMEI numbers or proprietary stuff? What's stopping an RPi compute module 3G/4G/5G DIY linux phone?
Battery life is probably awful, mainly.
The battery life would suck? It's not about whether you can build a phone, it's about whether you can build a decent phone.
Like Chinese emulator handhelds?
I agree, I don't really need cell service when there is so much wifi. Even would just carry a basic phone for making calls/txts even when needed.
Maybe carrying a hotspot modem with a sim card is enough?
I keep my eye on Linux phones from time-to-time.
By "linux" -- I guess I mean using a phone that runs a valid linux distribution that gives me freedom of control as well as software freedom.
I know people have a love/hate with environments like GNOME, but I don't mind it and happy for it on my phone.. as long as it adapts nicely on smaller screens.
My only issue is applications. Like many, I am using an Android/IPhone - and have installed various applications. Will any/most of these exist if/when I move over to a proper GNU/Linux phone?
This is the biggest hurdle. While I would find ways around it, I think this is where most people would stick to what they are familiar with... even if it is impacting rights, legalities, and other things we are slowly losing control over, etc.
I really do like the idea of Librem 5.
What's the hardest part about an open phone? Cellular support? App support?
Maybe I'm unique, but nowadays 99% of my phone time is spent in a browser. If anything, it seems easier now to get something like this going because all you'd need is a bare bones UI and a good web browser.
Sure, it's not competitive with a Samsung foldable, but he I've gotta start somewhere...
I do sort of wonder if an x86-based phone is at all a reasonable prospect. It seems a bit weird to go backwards but at least they've sorted out the generally open ecosystem part XD. Power consumption is 99% about the software anyway.
> What's the hardest part about an open phone?
Very good question; what's holding us back really? If we want an open phone there should be more discussions on this. Some thoughts aided with chatgpt:
Easy: get display, sound, cellular, sensors, inputs working
Harder: (efficient) Power management, App ecosystem: distribution, SDK, compatibility, (tight) Privacy controls, (robust) Update delivery system, (vast) Hardware support, Backward compatibility, Accessibility, Localization, Customizability, Camera (apparently)
Beyond tech:
Proprietary hardware drivers: how do you get the hardware manufacturers' commitment to allocate their engineers to write drivers for the open phone system? Reverse engineering requires more effort and is not very sustainable.
Carrier requirements: Supporting and testing emergency services, lawful interceptions, certifications, possibly differing requirements for each carrier and regions.
Regulatory compliance: Constantly changing requirements by nations and geographical regions.
--
Reading from the other comments, power management seems very hard to get right.
The non-tech reasons seem to be the most challenging; it introduces the most complexity and it's not exactly something that can be achieved by a passionate person in an evening
I almost exclusively use the browser as well. I think the reason for that is simply because the software landscape is that bad. I hate the Playstore or Apple Store with a burning passion. They are all adware/malware nightmares that aren't worth the effort, never mind developing for them.
We have really interesting and good hardware, but it is all moot because the software landscape is plain hell. I really puts me off to ever use a Apple or Google platform.
I would immediately jump to x86 regardless of power consumption. Would probably still run better than my current phone with a sizeable battery because 95% of CPU time is crappy routine you didn't even want running, so that is a software problem as well.
With the power usage of screens, I doubt an x86 processor would be noticeably worse.
Sorry for the rant, but I don't understand how anyone could react differently if they hear the word Android or iOS. Why did we end up with this crap?
A simple WIFI/bluetooth only device like the iPod Touch but with Linux, combined with a modem puck would actually be enough. You separate the untrusted part from your own device.
Yeah, I always wanted to pink up one of those tiny GDP machines. They would be cool to play with!
https://gpdstore.net/product-category/gpd-handheld-gaming-pc...
Why don't we have an Android fork patched to fix all these "annoyances"? Android phone is just a computer, it should not be hard to unlock bootloader and flash it with anything.
I understand that it would be cumbersome on Apple devices with all their efforts to lock down the system, isn't Android different?
Manufacturers can prevent you from unlocking bootloader. Whether they are Apple or not. Samsung used to have a hard fuse that broke when you unlocked, it seems they now forbid it entirely.
Apps developers can decide to require Play Integrity so your Android fork cannot be used to run their apps.
Google can decide to not support or explicitly exclude your custom fork. Due to Play Integrity used on their own products, you cannot run Wallet on most forks where Google is not running as root.
Google can decide to delay or not publish source code so your Android fork cannot be maintained anymore.
Manufacturers, Google and developers can alter that deal at any point in time. Recently:
- Delayed patch of AOSP unless your are a partner: https://news.ycombinator.com/item?id=45158523
- Wall of shame of manufacturers locking bootloader: https://github.com/melontini/bootloader-unlock-wall-of-shame
Those "annoyances" are only one of the attacks made, and not all of them can be easily defended against without having the manpower to actually maintain your own hardware and software stack.
I think it's because the Android latest changes are designed to prevent it. In other words, you can complicate the system to bring it to the place beyond fixing of the annoyances, or fixing would remove features you've entangled into it.
I deeply want the equivalent of Debian on a phone.
Rock solid. Every few year feature updates, only security fixes otherwise.
You can install debian on a pinephone https://wiki.debian.org/InstallingDebianOn/PINE64/PinePhone
But for a "normal" linux environment on a phone I recommend postmarketOS. They make an effort to support a variety of user interfaces, init systems, devices.
Still, it is important to consider that the hardware and driver support is the limiting factor here. The camera is very bad on the pinephone because it doesn't have the image processing capability to record video in realtime. It also has no OpenGLES3 or Vulkan. Very poor lima GPU.
Plasma Mobile[0] on Mobian[1] is getting pretty decent.
[0] https://plasma-mobile.org/
[1] https://mobian-project.org/
Maybe I'm misunderstanding this, but what would be the advantage of running straight Linux versus an AOSP-based mobile OS? Like, why not just keep the great apps that do run on there and ignore the Play Integrity ones that don't. Does it have to do mainly with just the governance of AOSP (i.e. Google)?
The mobile app ecosystem has outgrown it's original purpose to run software in a constrained env. Phones today are more powerful than my engineering laptop in university 15 years ago. The app ecosystem appeal today is reach, platform lock-in, and great APIs.
For example. I _want_ to run Linux phones even without all the apps & convenience, except Signal messenger. I am unable to use Signal without first registering through a mobile app. I suspect the desktop version will run fine-ish (proton after all). But at the end of the day, adoption will increase if mobile apps had a compatible desktop version on a Linux phone.
I didn't know syncthing-android had been discontinued. I use that app heavily.
(Linked from the post: https://forum.syncthing.net/t/discontinuing-syncthing-androi...)
The fork by Catfriend01 available through F-Droid works great...for now. I too use it heavily and worry about it's future on android.
Use syncthing fork on fdroid
There's a maintained fork.
What is the advantage of a Linux phone over something like LineageOS?
If things keep going in the direction they are, there might not be a LineageOS at some point, and developing a useful alternative before that (Linux based) would be great.
so we fork and continue to work on lineageOS. why start from scratch? (i mean, it's nice to have alternatives, but there is no reason not to continue developing an android fork.
Working on LineageOS doesn't help you if you can't even install it. Fewer and fewer phones come with unlockable bootloaders these days. The grip is tightening.
Yes, but if you are building your own phone hardware to run Linux on it, there is a huge advantage in that Linux flavor being an AOSP fork, since it is already mature.
While that's a viable option as something some people can do, it will be for the few in general, not the many.
You can run normal linux desktop and server programs with no limitations. The development and driver support is not guided by google.
EU should fork Android. Fund a small team of devs, nothing fancy, no major changes just keep it secure.
I think governments funding software development could be a useful counterweight in an industry dominated by a few giant corporations, similar to how lots of countries have state funded media alongside commercial options.
But the EU forking Android is not a remotely realistic starting point. How do you persuade manufacturers to use it? Would Google license its proprietary apps to run on it? How will the small team of devs cope with whatever changes are coming in hardware next year? Forking Android is easy, making your fork a viable alternative is almost impossible.
In theory the EU could throw its weight around and demand that Google & OEMs work with 'EUdroid' if they want to sell phones in Europe. But that would be a massive political fight, much bigger than funding a few developers.
On paper this is a good idea but consider the current chat control issue. This fork would probably have built-in by default content, messages scanning and switching to any other Android would probably be ruled out as illegal.
Quaero was a disaster - https://en.wikipedia.org/wiki/Quaero
So many committees - so little progress.
The EU (and adjacent countries like UK or Schengen countries) loves surveillance and control of their citizens' speech (except if they're partbof their wealthy elite, in which case, there's nothing to see here).
I tried the fantastic DroidVNC-NG (KUDOS to the author) app because I wanted to see if I could stream a whole Android phone left at home at all times.
The idea was attempting to switch to PostmarketOS, so if I ever needed to use a banking app I could do it through this phone via a VNC client. You can't.
Banking apps black the login screen. Even if that is ok for 99.9% of users, I know what I'm doing and I do not absolutely have the fucking choice to disable that. The thing I found out is that every time I come up with something that should be doable, either Android or the fucking app or something else prevents me from moving away.
My biggest drag is banking because almost everything else I can leave it out. And I believe I don't have a choice.
Have you tried scrcpy? https://github.com/Genymobile/scrcpy
I ran this with a custom fork to expose the device screen as a VNC server for years, no problems
I see the banking complaint all the time, but most banks provide a web site too. Is it really such a chore to use the site rather than the app?
Fair point. I haven't actually tested the banking mobile webapp but I did test it from a regular PC and oh boy, it was like a 1999 web application.
Not just because of the look and feel but everything was just odd and in the wrong places compared to the store app. I should probably try this from a mobile browser but the last time I used Firefox in Postmarket OS it behaved like a desktop browser (in fact I think I read somewhere that it is indeed a regular Firefox resized to be used in PostmarketOS) so I'm assuming that the experience is going to be really bad.
Mine no longer allows website login without phone 2FA. Considering finding a new bank.
Are there any efforts being made around this? Any projects we could look at. I wonder if the pine phone was ahead of its time.
I also strongly felt this when support for sideloading apps got dropped, and from my personal experience of dealing with rooting and working around play integrity. It shouldn't have to be like this.
Side-loading was the original loading before app stores. App stores were the option.
I have made people mad by saying it, but it remains true: Every developer hour wasted on an Android ROM is an hour not invested in a platform free of Google's control.
Google likes Android ROMs because they pacify the developer community from working on real competitors, while not presenting any meaningful threat to their control of the majority of Android devices. The MADA that prevented OEMs from shipping AOSP is probably dead but what hardware manufacturer is going to risk Google's ire by shipping something.
> Every developer hour wasted on an Android ROM is an hour not invested in a platform free of Google's control.
As it stands, and the way things are devoloping, accurate. But as the relevant systems are an integration of hard- and software, significant work needs to be done on the former as well. And I've yet to come across a Linux phone (or phone-like pocket computer) that ticks most of the neccessary boxes.
Agreed, the Linux phone landscape is far from daily driver ready even for a lot of tech enthusiasts. But that's also why it's so important people spend development time trying to solve that instead of screwing with ROMs. Short of a strong profit motive, Linux mobile needs a lot of volunteer effort.
Total agreement with the article's conclusions. I'm an Android developer who once had about six apps listed in the Play Store. But as time passed, maintenance became more and more baroque, and a simple Android version change required me to rewrite all my apps or lose my listings. Like many developers, I gave up.
Then Google announced a decision to disallow sideloading (not clear when this will take effect) and many tablet/cellphone manufacturers intend to disallow bootloader unlocking. If all this happens, it basically closes the Android platform to anything but "official" software releases.
Consider this from my perspective. My first computer was an Apple II in the late 1970s. I could do anything I wanted with it, and I did. But over the decades I've watched the world of software development -- with the exception of personally owned Linux machines -- gradually turn into a walled garden.
What can I say -- it sucks the joy out of programming.
Makes me think about mobile first web apps that just run out of the browser.
Maybe Palm Pre's had it right all along with the html/js based OS in WebOS at that time. Just a little ahead of their time for OS, and missed challenging the iPhone by a bit.
The only thing that keeps me on Pixel is Google's astrophotography mode. Put the same quality camera (app and hardware), and I'm there. I'll get there faster if there is an Ektachrome and Tri-X film emulation setting. I miss the colors of film, but do not miss the chemistry or expense.
I'm sure I sound like and ass, but if astrophotography is the only thing tying you to your phone, why not gear for that?
Nah, not an ass. Just not up to speed yet.
Using traditional cameras (repurposed DLSRs or fancy webcams like ZWO). There is a significant hurdle, of expense, learning how to use them, and setting them up. A Pixel makes sky-wide astrophotography trivially easy with almost no setup required. Depending on how stable the camera mount is, the pixel will allow me to start over on the novice side of the scale. I've been able to take handheld pictures of the Aurora and other large sky images, such as lightning in twilight thunderstorms. If I can rest the camera somewhere stable, I can take longer exposures and even create a time-lapse of the night sky.
There's a lot to be said for pulling your phone out of your pocket and taking pictures of the sky.
Throw in Velvia emulation for an even three wishes
We need something other than Linux on phones.
it is not the kernel that is the issue. it is the userland that is the issue
Pardon my potentially naive question, but would Samsung ever develop their own OS? I imagine they're not necessarily happy about some of the latest changes to android.
Bada and Tizen. They've been trying for 15 years. Tizen in particular is as Linux as it gets. Long story short: it's not something the market wants.
If I recall correctly, Bada was already more locked down from the start, with app distribution only permitted with Samsung's approval. Otherwise I would have been interested in trying a Bada phone.
Interesting!
> Long story short: it's not something the market wants.
Who knows. Maybe this could change?
The market HAD changed to what it is now from what it was. Most handheld manufacturers had garbage mobile app platforms back in 2007. Something happened in January of that year and they all started coughing blood.
> it's not something the market wants.
If it was just "the market" guiding things, there would be no need to lock things down against consumers, or pulling bait-and-switches with slowly closing down the previously open-source Android, would there?
Please learn to recognize when you are under attack.
The market doesn't care what it's coded in, its just about end user convenience and usability.
Android is Linux based, and so is iOS. They focused on the UX and what it took.
It leaves it possible for linux to do it again.
Android does not use what we normally call a linux userspace. iOS is not at all linux based, although it is UNIX-like.
Yeah, they could call it Tizen or something.
Please spare me the sarcasm...
They'd almost certainly just fork android like the various Chinese companies and Amazon have done.
Android doesn't even let you access your files. It has famously blocked acess to the subfolders of /Android/data/ - every app has a subfolder there where it stores files. And you can not visit these subfolders since Android 11.
A buggy app accumulates gigabytes (literaly, i am not exagregating) of temp files there, but i cant visit the folder to delete them.
Google explains that "it's for you safety".
I have to call it with the strong word "idiotic".
There are apps now where storing files in a shared, accessible folder is a payed option.
Not only that is outrageous, I belive that violates the existing "right of access" laws like GDPR. I am condidering even submitting Subject Access Request to Google about my /Android/data/ subdirectories.
> A buggy app accumulates gigabytes (literaly, i am not exagregating) of temp files there, but i cant visit the folder to delete them.
Settings > Apps > select the app > Storage and cache > Clear storage.
No, I dont want to clear storage - there is data I downloaded into the app and work with that I dont want to lose. But the app also accumulates some temp files there.
without access - how do you know the files are temp files?
>Banking requiring an Android or iOS Device for 2fa
>My local postal service requiring an Android or iOS Device to unlock those postal delivery boxes
>My local public transport requiring a Android or iOS Wallet app for my ticket to be used
>My Health Insurance Provider requiring an Android or iOS App to see my own insurance data
This is my daily struggle. All of these companies refuse to engage with you on this topic, you get a canned response from support that's it. How do we even win this fight? As far as I can tell we've already lost.
I was hoping the US becoming more hostile towards Europe would wake them up and allow the relevant legislators to discover that the entire industry is at the behest of two American companies. The same goes for cloud services in Europe, just with different companies, and OSes for that matter.
Alas, this is a rather large set of elephants nobody in power cares to acknowledge.
>It works on my phone, whats your problem?
t. Every politician ever.
This won't be solved until politicians and the unthinking masses feel the pain of this stupidity directly. And Google and Apple will make sure that they calibrate the pain for the average Person just high enough that they will accept it.
Yes, the steam deck has ignited the usecase for the portable linux machine for the normal user. Now we just need great linux on arm support and then I can run a version claude code on a portable arm device and have it control my whole device for me all day. I hope this happens sometime soon!!!
Mao said "Let a thousand flowers bloom, a hundred schools of thought contend". Then he killed off all those naive ones who stepped out.
This is more or less the capitalist/liberalist/colonial/MAGA model from time immemorial: preach "freedom" to put yourself in a indispensable place. Then impose fascism with long-suspected hierarchies.
we would have Linux phones already if people paid attention to the gpl war, which we lost with tainted kernels.
but nobody will care and continue to think only bsd/mit/Apache will make their project be successful commercial enterprises. sigh.
Here is an idea I thought long and hard about for the last 3 seconds....
Say one, rather than making the entire phone modular, adds just one cartridge slot. Have it span the bottom half of the back of the phone and be a few mm deep. Cartridges can have 4 form factors. 1) flush with the back of the phone. 2) stick out from the back. 3) increase thickness of the entire phone. Or 4) like 3 but comes with the same slot as the phone so that one can stack cartridges.
The first base phone should be functional by it self but have really low specs. A slow cpu, little memory, little storage, small battery. It may even run on android and have a ton of preloaded apps no one wants. Ideally the most expensive component should be the cartridge connector.
And then, here it comes, you've already guessed it! The entire linux computer goes on the cartridge.
Have a similar dock that turns the cartridge into a desktop computer and a dock that connects it to your PC.
Software development would be glorious.
In the initial demo it should run Windows! This will send a strong signal to other otherwise uninterested parties that this is a real computer... finally...
While official builds should probably exist let other vendors go wild building their own proprietary closed source cartridges.
There should be infinite possibilities. People will make things we cant imagine. Stuff we will never see on flagship phones because 99% doesn't need it.
Some might simply but badly want usb ports.
Stupid example: I have a digital camera, I have to plug it into a computer and do all kinds of things before they may appear on my server, like booting the machine, opening apps and figuring out where the hell folders are. The pictures are great but not that much better than my phone which can conveniently send them places. But what I really need is to just plug in the camera and have the technology figure out which are the new images and upload them. It should require zero screen time.
The next guy might want an ethernet port, hdmi, serial, scan barcodes by pressing a real button that also unlocks and opens the correct app. You might even have a bulky cartridge that prints receipts. A large antenna and/or a week worth of battery. I'm not at all sure if people want it but a cassette player would be possible. A boom box with atx drive bays. etc etc
Then when you buy the next generation or are bored playing with it, the screen is cracked and the battery is worn out you turn it into a security camera that works when the power is cut and can send [picture] sms, make phone calls and play threatening messages to intruders.
I fully think an amazing consumer-targetting device could take over like a storm if done well, if ambitiously done, with an aggressive software stack.
But. I think what we should ask for now should be simpler. Let this be an alpha geek toy, let folks fiddle with some basic devices boards that can do the thing. The work on PinePhone, Mobian, others is good pioneering work, alas largely held back by there just being so few decent devices for folks to play with. The driver situation keeps making hope here impossible.
It's not a high hope, but Qualcomm has a QCM6490 chip is maybe a rare hope. A chip that is somewhat buyable by regular makers, an extended life version of the Snapdragon 778G. It's pretty modern, and comes with very featureful connectivity hardware. We're seeing variants like non-cellular Radxa Dragon Q6A in the field. Particle has a new Tachyon board you can buy with it. https://www.cnx-software.com/2024/07/31/tachyon-business-car...
It's just stunningly rare alas that folks can make systems with vaguely modern cellular chips. The cores are just not available generally. Sure it's be great to have a well produced Linux phone that is super consumer acceptable with a great OS build out, a new or revived Maemo or a Jolla Sailfish: folks who can go sign the NDAs and make a consumer device but have it be Linux. But I think for this dream to really take hold, humanity needs to be afforded some possibility to have an honest shake, some chance to be a little closer to the machine than typical cellphone bargain. The lack of cellular chip availability has been so so damning to this quest. And here is one counter-example, a crack in the wall, where I see flowers and hope grow.
There was some real nice moments where it seemed like maybe some Snapdragon cellphones in general we're getting Linux support to some level, in mainline, just for the base stuff. No cellular. Unclear to me but it seems like maybe those were just the very barest of beginnings; whether any peripherals at all work or whether there was even a screen is unclear. The trickle of releases also seems to have died off. FWIW though, I will note the previous Fairphone 5 does use the above QCM6490. https://www.phoronix.com/news/Linux-6.1-Arm-Hardware
PostmarketOS seems to have decent support for the Fairphone 5: https://wiki.postmarketos.org/wiki/Fairphone_5_(fairphone-fp...
Only issue is it’s so hard to use a Linux phone as a daily driver. I have a librem 5, but I admit it’s just too raw of an experience for me to use as a daily driver.
I had a Neo Freerunner.
It was a terrible experience. I bought it with the impression that it had calls, texts etc working fine, and they were looking for developers to come along and add apps, games, whatever to round out the experience.
I couldn't have been more wrong. They had about four different distros. There was the 'old' one, the 'new' one which was already scheduled for deprecation because of the new-new one in the pipeline and there was also a debian distro. Each one used an entirely different UI framework (gtk/efl/qt), and the developers seemed focused on these endless interface rewrites when the unit couldn't reliably receive a call or a text under any of them.
After that I had a Nokia N900, which was a great experience. They'd nailed down the basics perfectly (as you'd expect from a much larger company) and the unit was a capable smartphone with linux under the hood and easily accessible. It's just a shame the app ecosystem never took off, and nokia flushed itself down the toilet shortly thereafter. I guess Sailfish is the successor in this space, though I liked that Maemo was debian-ish rather than rpm-ish :)
I guess what I'm saying is that a linux phone doesn't have to be raw, but for god's sake make it able to take calls and send a few messages...
Is this the highest upvoted fediverse link on HN?
This might be an unpopular opinion, but I think the raise of vibe-coding can be great for Linux on the phone. The main issue the ecosystem seem to suffer from is lack of apps. Apps building is becoming way easier, especially for simple things. If the cost of making software is going to drop significantly, we might be able to finally fill in the apps gap.
>Android as we know it is dead. And/or will be dead very soon. We need an open replacement.
AOSP is open and is a much better starting place than anything else.
Arguably the OS is the least important aspect.
The greatest issues facing mobile computing are:
1. The lack of any open firmware
2. Locked bootloaders
3. Obnoxious security "features"
right
What you want isn't a "linux phone", what you want is a gun to put to the developers' heads so you can scream "let me tamper with your shit".
If you just want "a phone OS", AOSP is still there and worth forking. But you don't want a phone OS, you want apps. And nobody is going to write apps for an AOSP fork (see also: Fire Phone). Actually, nobody is going to write apps for anything other than Android and iOS, just in general (see also: Windows 10 Mobile). App development for two phone platforms is already enough of a pain in the ass. Furthermore, Google will absolutely be anticompetitive and de-Google your phone OS whether you want it or not.
But more importantly, if you do manage to create a third platform that people actually use, you are going to immediately be inundated for requests to lock down the phones in exactly the ways you object to, because a certain subset of app developers want or need that kind of DRM. And you're not going to get those apps without a DRM story that matches Google and Apple's.
Streaming apps want encryption to the monitor.
Games want a kernel the user can't modify.
Banks want your phone to be a credit card you can't do fraud with.
Hell, when macOS got support for native iOS apps, they specifically designed it so that iOS App Store apps won't run if you modified the OS in any way. And even then, a lot of iOS app developers specifically blocked macOS usage. The phone vendors aren't selling an OS, they're selling DRM.
I wonder what an alternate history where Google didn't implement remote attestation and actively made it difficult for apps to snoop on user modifications would look like.
I suspect the Fire Phone is where things changed. If Amazon had iterated on it and done a good job, it might have been a competitive threat to Google's revenue model for Android; that's less likely if it won't run games and banking apps.
Where are the open source planes, trains, and automobiles? Medical equipment? Nuclear reactors? Open source cannot afford the quantity control/verification need for these domains. It’s the same for phones. At best you’re going to get an insecure mess.
People can and do build their own automobiles all of the time. See: https://www.youtube.com/@GrindHardPlumbingCo
Open source literally drivers ADA compilers, toolkits, DICAM readers and whatnot.
On security, your lovely propietary NT based kernels had so many CVE's and attacks that you could fill gigabytes of text with these.
https://makerplane.org/
(not a plane) https://www.youtube.com/@Ground-Effect/videos
Trains - not so hard, it's getting legit real track time that's the issue - and you can always 'cheat' with a Hi Rail Pickup Truck modification.
Automobiles - .. you are kidding, right? You've never built (or met a builder of) a road certified car, truck, or other vehicle?
> Linux phones are more important now than ever
Agreed. So get to it and design/built some worthwile ones.
EDIT: That was obviously not an order to the the parent, but more a lamentation about and call to the industry. Sorry kids; I sometimes forget that the binars are allergic to ambiguities. :)