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)
It is not for preventing you from taking screenshots, if you insist, you can do it with another camera. It is to prevent malware and "helpful" AI tools from doing it for you and then uploading the picture to who knows where. Signal does this too, though I think it is optional.
Beyond preventing screenshots, it blacks out the window content in the task switcher, which is useful if someone is looking over your shoulder. This, by the way, is a good way to check if screenshots are allowed. If the window appears black in the task switcher, screenshots won't work.
So in other words, the developers of Android could not figure out how to design a system that could distinguish a screenshot that was initiated by the user versus one initiated by software.
I mean if the goal is to prevent potential malicious apps from taking screenshots automatically; instead of saving a clueless user from themselves or worse getting in the way of legitimate users I believe that the proper solution is to disallow programmatic screenshots while still allowing screenshots when there is the correct button press (and ensure that this cannot be emulated). Windows reserves ctrl-alt-delete as a direct signal to the kernel for security purposes. Why can't android do the same?
includes the ability from a user to take screenshots programmatically in case of need. You do not want third parties to be able to; you want the User (yourself) to be able to.
It's really stupid idea, that results in photos of sensitive information displayed on my device on other devices that I don't control and sensitive information wrote on paper in random places.
Password fields are inputs. Screens are bi-directional.
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've been unimpressed with Google's commitment to making the fundamentals of Android great. They seem to prefer doing the minimum required there and putting all their efforts into something more sexy, like generating fake photos that look like they were taken with a 2400mm lens.
I don't want my phone to generate fake photos; I do want it to always let me manually take screenshots, but require turning on a permission that's a little awkward to find to allow an app to do so.
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.
So let's have more of these conversations so the idiots making those standards make fewer dumb rules and we can grease the wheels for anyone passionate enough to try to get it changed
Unfortunately the idiots are often the nation's security agency, or a large consulting company.
You will not have them change their policies if they do not have a good person inside, who will slowly move the boat.
I fought for audit findings because they were pissing me off at a personal level and it wirked. But the auditor did not change their procedure, just reverted the finding. Until the next year.
I think you're making the naïve assumption that large organizations are heterogeneous.
The people at the top are idiots because the idiots were able to secure advisory positions. They were able to secure positions because those promoting them were either tricked or idiots themselves. This pattern repeated all the way down.
So I really do mean grease the wheels. And I really mean we won't kill the beast overnight. But we won't make any progress towards fixing things if we won't look at how the problems are created in the first place. We'll only perpetuate the problems if we oversimplify things, as that's exactly what got us into this mess in the first place.
There was a Microsoft Terminal Server "monitoring" application that worked by recording the screen through a series of JPG screenshots. It worked surprisingly well and bypassed all kinds of controls.
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, one could make the argument that there would have been far fewer resources dedicated to computer vision had companies made the data more accessible and had we modified PDFs to make it easier to copy test.
People will go to great lengths to bypass annoyances. Excessive false alarms is even called "alarm fatigue"
Isn't it though? You compromise some email provider so that you have read access to the emails of a million people going back 20 years. Literally many billions of emails with petabytes of attachments. Can you do text search on all of that text? Absolutely, an ordinary PC could do that in a realistic amount of time. Can you search the text within all of those images using some kind of computer vision system? Not without your own power plant.
I think you made bad assumptions. If I installed the APK through a third party, sure, my bad. But then I agree with shmel, that there's still some blame on Google. Like why not have a default where we disable screenshots not performed by a physical action and have an advanced option for API based screenshots? It's not bulletproof but neither is the current implementation.
But if I install via the playstore like most people then no, I don't think it's the user's fault. Testing every single app seems like a big ask but we're also talking about a 3 trillion dollar company. I mean FFS a 1 trillion dollar company didn't even exist 10 years ago and 10 years before that a 500b company barely did. So I think they can stand to lose some profits and do harder work. Really, if we don't hold these companies to high standards then that bar just continues lower and it's a race to the bottom. They'll be as lazy as we let them be
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.
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.
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.
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.
I don't know about your bank/countries, but all of the banking apps in my country I've seen have 1. a "share account details" button that lets you easily paste your IBAN and other details in text form and 2. a "transaction receipt" button that saves a .pdf with the relevant details, that can be sent to the other part (although I agree with the other comment, this .pdf just like a screenshot can be easily spoofed)
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.
And PDF documents in image form. Usually scans of printed copies.
It is fine for historical documents, but doing today means you really want to piss people off. And by the way, PDF files support signatures, both handwritten and digital. There are ways other than printing a 100+ page document and scanning it just so that your signature shows up on a single one of these pages.
> 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's doesn't sound right. On mine, a message is displayed saying that the app does not allow screenshots, and no image is written to the device.
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.
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.
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.
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.
The capital itself isn't going to do anything sitting in the bank. It's used to procure a team of PhDs, an team of SWEs, DevOps, business people, HR, marketing, access to a GPU supercomputer (renting a couple of 5090s off Vast.ai ain't gonna cut it). For, say, $50 million, you could get the blueprints to an Android phone and port your choice of Linux userland and get drivers working, and then do a run of 20,000, sell them for $1100. Compared to training GPT5, $50 million is cheap. If we use an estimate of $1 billion for the whole thing, making a Linux phone running a hypervisor with an Android VM to run banking apps seems not-impossible. (Based on AVF.)
That's not the point I was making. Both operations need capital. But capital isn't the only barrier to entry.
With a LLM, you can spend the money to develop the model, then spend some money marketing it, and if you get enough paying customers to cover your costs and a bit more then you're done. Done in the sense that you're now competing on the same level (roughly) as other LLM providers. Even if it's at a smaller scale, you can offer a similar product with similar features.
With a phone OS, that isn't enough. You need to become big enough that significant numbers of app developers are willing to publish apps on your store, including most major ones (Netflix, Spotify, WhatsApp, social media, banks, government agencies, etc.). Running a VM isn't a full solution: banking apps are already actively blocking usage just based on phone settings that they don't like; unlses your OS does a very convincing job of masquerading as a genuine Android/Apple device you're likely to run into problems (and if you do the latter you might hit legal problems). You also need to convince major manufacturers that it's worth bundling your OS with their phone.
Without those, for a significant segment of the population your phone OS will always be seen as an inferior product to Android / iOS.
You make a valid point, that there are some key apps that are necessary for a new smartphone OS to be viable as a daily driver for the unwashed masses. But that's also just a matter of money. If you roll up to each of the major app's companies with a big enough pile of money, and ask the right person there to port it to your new OS, I bet you could make it happen. (If you don't know the right person, capital also lets your get access to them as well.)
As far as being an "also ran", I mean, that's going to be true for any LLM as well. Your second rate LLM is also always going to be seen as inferior just because it isn't ChatGPT, regardless of any other actual merits. Human psychology is fascinating because they aren't rational. Every time I get fooled into buying some stupid piece of crap because there was an advertisement that tickled my brain in the exact right way, I see just how irrational everybody is, given just the right set of words. Why do I bring this up? We could waste countless hours arguing over the infeasibility of a phone OS vs the infeasibility of an LLM, it's all in our heads, but doing so wouldn't get us closer to the goal, which is dominated by the singular question: can you virtualize enough, and pass through enough of android, to get banking apps to run in a VM on some real hardware, so that dom0 can be debian?
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
SafetyNet works in GrapheneOS. What Google Pay requires is that the attested signature is trusted by them, a lot of apps, including many banking apps (at least in the UK) use safetynet but do not require the signature is trusted.
Netherland used to have its own system for NFC payments, and it worked perfectly. Last year, all banks suddenly abandoned it and forced people to use Google Wallet instead. Of course I refused, because I don't want to share my financial transactions with an advertising company, so no NFC payments for me.
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.
There's already a better way to check whether an Android phone is secure enough and it is independent of any proprietary OS certification: basicIntegrity [1].
Most banking apps in Germany use this API and thus work on GrapheneOS and other non-Google controlled ROMs with a locked bootloader.
PlayIntegrity is unnecessary and mostly offers vendor lock in to Google's ecosystem.
>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.
I don't know if it is geolocked somehow, I wouldn't be surprised if it was. for example, Japanese iphones always make a shutter sound in japan or in airplane mode
There is a waveform thing in the corner you can press during a call. It will say "this call is being recorded" and waits 5 seconds, then records the call.
strangely... the recording doesn't end up in voice memos, it ends up in notes.
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.
I assume you’re talking about another country, because in Denmark there was no general curfew under Covid (attendance to events might have required proof of negative COVID test or vaccination, but shops never did).
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.
Ah, yeah, that actually makes sense: now that the USA no longer shares intelligence information with some countries it previously did (or can't be trusted to do so), they have to implement alternatives.
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.
But in many cases a server operator doesn't expect any legitimate traffic from that half of the internet, or is willing to block traffic from it.
For example, there's generally no reason a customer would use their internet banking app with traffic routed via a datacentre other than for the reason you proposed (masking their IP address), so if the bank wants to prevent people doing that then blocking all data centre traffic is an effective way of doing it.
That's why I explicitly wrote: "for stuff that should only be done by legitimate users".
That means Netflix et al can (and do) ban everything that even remotely smells like a datacenter IP range and not a residential one, because that is a common method of evading regional bans or undermine pricing structure.
And on top of that... if the focus of your website is humans, you might want to cut off all datacenter originating traffic as well. Save yourself the hassle of dealing with AI scrapers.
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.
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 mean that there is no Belgian nation - native Belgian citizens are mostly either Dutch-speaking Flemish people or French-speaking Wallons, and generally don't have any significant notion of a shared national identity.
Note that this doesn't mean that a state with multiple ethnicities/languages can't be a nation state. Indians, for example, generally have a clear national identity, despite being citizens of a huge federal republic with dozens if not hundreds of languages spoken, some of which don't even share a common language family. So, India is a nation state, unlike Belgium.
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.
> 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.
my GrapheneOS phone has the record button. :) though I have to obtain all-party consent to do so legally in my jurisdiction (but that's my responsibility.)
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.
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?
>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.
> 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
Yes, both (official) SailfishOS and FLX1 offer decent/good Android app support. Not every app will work, but when I have needed Android (rarely, for basic stuff), the applications have worked.
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?
You're comparing a Linux OS (postmarketOS) to a device (FLX1). I think you meant to compare postmarketOS to FuriOS : )
FuriOS (and its base Droidian) are at a better stage of development for devices made to run Android using the old Android Linux kernel, whereas postmarketOS is better for devices made specifically for Linux, like the Liberty Phone, Pinephone, etc. Droidian will not even work on them.
I'm not familiar with postmarket, but I imagine it shares a lot of the same phosh+GNOME app ecosystem, in which case, the apps aren't in a better state.
In terms of polish and app/dev ecosystem, I feel SailfishOS still rules, but it's getting harder to justify using/development, with it's increasing divergence from upstream.
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…
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.
But I mean, why not take the 100s of thousands of man-hours that went into making Android this very Linux-Kernel based mobile OS and build on top?
Will you be happy with xeyes and a terminal? Like, even a technically superior solution is completely useless without an ecosystem to make use of it, and desktop GTK/qt apps won't work nicely on mobile without actual porting. Let alone a technically significantly inferior one that is a misfit in this shape for mobile hardware.
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.
By making a soft and then a hard suspend the reality they have to abide by, or otherwise they are killed and users will think they are broken apps.
Mobile apps just had to "grow up" in this environment, plus they have proper APIs for this two-way communication between OS and the app. Android will just ask the app to save its state and then simply unload it from memory (after a while) - but this also makes perfect sense for the desktop scene, you also want to improve energy efficiency there. A spreadsheet app doesn't have to continuously run when it's in the background. You just have to add proper APIs and permissions so that apps can optionally ask for extra background work.
I would argue that the legacy OS and app architecture we have on desktop OSs doesn't make sense there, either.
It's a model that worked fine in multi-user setups where you ran a single executable, so that the security per user was meaningful, but today it just sucks.
Android is quite elegant in reusing the Linux kernel's permission system, but on a granularity that actually makes sense (apps are started as separate users, and they just elevated their concept of user a level higher).
Hi. I have a Google Pixel 3a running PostmarketOS https://postmarketos.org/ and it holds up pretty well. My phone lost 20% today with light usage and will maybe lose 60% if I scroll social media a lot.
I was actually surprised it is this good. I reinstalled recently and before the reinstall I had much worse battery life (Maybe 8 hours with normal usage). I think it was because of Syncthing running in the background.
It is also possible to use s2idle suspend which will improve the battery life even more but you will not be able to receive calls during suspend (though that may also be fixed in the future)
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.
Well, if enough of us paid Apple level prices to Linux vendors, we would have Apple level Linux laptops and phones eventually. Not fair to pay next to nothing and then compare Linux to Apple.
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.
you won't even be able to use the closed phone remotely from your main one since the restrictions wont allow remote software to see or interact with the screen
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..
On my to-do list is to join a local credit union after checking whether all services are available in person. All this mess is not worth simply being able to do stuff from my phone.
The trick is to never, ever install the banking app on your phone. If you only use their web app from the beginning (account creation) and say you don't have a duopoly phone, the app will not be required.
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.
I was going to say that. I carry a laptop and an iphone 13 mini. The iphone is nice in a locked down way and the laptop you can code on etc. I'm not sure I see the attraction of the non locked down phone compared to the laptop for most use cases. I guess I could location spoof pokemon go so there'd be that.
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.
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.
(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.
$50 per phone would not make them enough money to pay developers. You would be left with a worse version of the Pinephone. We can't pay peanuts and expect the situation to improve significantly.
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.
Uhh no? One of the biggest differences probably is that Android applications are heavily sandboxed:
> Applications are security principals. The main difference to traditional operating systems that run apps in the context of the logged-in user account is that Android apps are not considered to be fully authorized agents for user actions. In the traditional model typically implemented by server and desktop OS, there is often no need to even exploit the security boundary, because running malicious code with the full permissions of the main user is sufficient for abuse.
I just confirmed that Android uses a largely unmodified kernel, so in theory it should be possible to just implement whatever extra components make up the Android system. To your points:
- Sandboxing: Android accomplishes this by running each app in the context of a different UID.
- No root access: Like above, user-installable apps are given separate UIDs. The GUI and other system processes probably also get random UIDs. Probably very little of the Android system runs as UID 0. (However, I don't really believe that keeping the user from doing things as root is a valuable security feature, as long as the user is competent)
- Verified boot: There's nothing specific to Linux/Android about this, right? The bootloader handles checking the signature.
- Hardware-backed key store: Isn't this, as the name implies, "hardware"? So it should be OS-agnostic, right? Maybe Linux doesn't use it, and Android does, but someone just needs to write a driver for it (and maybe some bytecode implementation or whatever, if it's some secure enclave thing, which it seems to be).
- User profiles encrypted independently: I don't think the Linux kernel supports encrypting profiles, this is a userland feature of Android, and could therefore be ported to Linux.
GrapheneOS are against using their development resources on a platform that is drastically, significantly worse than the hardware platform they already have, which is quite fair. It is not about Pine64 or Purism's products specifically. They would not be against them if they met 95% of the requirements detailed in https://grapheneos.org/faq#future-devices. It would more sense to explain which of those requirements you think are unreasonable.
But like, it won't matter how many viable Linux phones there are if the government tells you that if you want to pay your taxes you must first buy a piece of hardware blessed by an american corporation and running blessed software which doesn't let you control the device in order to access the tax payment portal.
Because if you don't pay your taxes, the government will insist that you go to prison.
The problem isn't really what google is doing, the problem is that were letting our existence as free citizens in a society depend on a piece of blessed hardware/software we must carry around with us everywhere we go.
We need to strongly resist having software/to become strongly codependant on hardware broadly speaking. But especially software/hardware that we can't control and which is sold by two american companies.
Maybe, who knows. It was an example. All I know is countries like Denmark and maybe soon all of Europe seem completely carefree with regard to making citizenship depend on device ownership so...
Quite a few banks in the UK now require an app, and that's a liability for me as who knows when they'll arbitrarily decide to lock me out of my account because I am not running stock google android.
The bank I'm with uses a hardware token which I can tolerate because, while it does require a codependence on hardware, at least the hardware is provided for free by the bank. I can also manage my account over the phone without the hardware.
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!
Ah, I just abandon the idea of recovery on these phones and use the ubports installer once. Thereafter, I just flash directly. I have done the MTK tools dance, but don't any longer. Sorry :(
Ah, I have to admit I don't know much about porting :) We did put up a community wiki and the HADK is up there: https://sailfishos.wiki/books/hadk/page/hadk so that you might get some idea of the process ... I'm not sure to what extent this is different from that 'halium' builds that piggz makes. It makes sense to ask him directly, since he has a stream lined process that targets, among others, the phones you have.
As to why the hardware adaption layer is needed (ie. the android one) it's where all the binary blobs are :) Among other bits.
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
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.
Because Apple didn't want to open their ecosystem, they invested a bunch of money (and time) into "exploring what's the bare minimum required to comply with EU regulations". Now Google is locking their ecosystem down the same way because they know they are legally allowed to do so.
This is why it's an "unintended side effect" of EU regulations, as the regulations prompted Apple to find out how much user hostile behaviour they can get away with.
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. It was and is their job to do that. 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 they are 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...
> Google is acting here as the owner and maintainer of a services ecosystem...
> they increasingly experience difficulty to contain issues within that ecosystem and prevent them from spreading (piracy, malware, hacking,...)
I wonder if the smartphone app industry is big enough now that allowing just two corporates to govern them is no longer fair or democratic.
It has outgrown the "ecosystem" word a long time ago. It's a genuine industry now.
Apps are such a fundamental part of most people's lives now (whether they like it or not), and these two companies have a disproportionate amount of power over an entire industry.
This is more or less the journey the EU has started with the Digital Markets Act, but in a very agnostic way.
They identified that, among others, Apple and Google are operating a "Digital Market" of significant size within their ecosystem, where they invite others to participate and compete, and it's the role of a government to ensure fair conditions in the markets of its economy so forces can flow freely.
The way they defined that is very smart. They don't define what an "app" is or an ecosystem, they identify in a objective way that their operations constitute a market, and that they have to comply to certain rules in order to ensure fair competition.
I just hope that they can see this through and have those Digital Markets established as proper "markets" in the same sense as physical markets are, before some political "wind of change" is dissolving everything again.
Apple is very much counting on such a wind of change, by actively rallying its users against the EU...
> 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.
Librem 5 is my daily driver. The camera is not amazing, but it works fine. The battery can last one day just fine with a non-heavy use. And you can replace the battery on the go.
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.
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).
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.
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.
> 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.
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.
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.
can you be more specific please? droidify appears to just be an f-droid client. i already have f-droid. in fact, it's my primary source for apps. but i can't find any apps that match your description.
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 don't think so. Google is poisoning the well with their developer policies and play store controls. The time is ripe for a competitor, and if there's a credible competitor that demonstrates the "good because goog says so" model is broken, that will force fully open attestation.
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?
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?!
:)
> 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.
My GrapheneOS phone fully supports such facilities. I trust your app works on it?
I can see how that reads like I'm an app developer! I'm not though, I just meant the apps from my bank that I use.
That looks like an interesting and useful capability.
I don't believe this will satisfy the crowd who want complete control over their systems though, as AFAICT graphene is not rooted by default and will likely fail these attestation checks if you root it. This will also not please the "Passkeys and hardware attestation are evil/non-FOSS by nature" crowd.
Definitely provides more freedom wrt. third-party app stores though.
> 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).
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.
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 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. )
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.)
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.
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).
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.
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?
>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.
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.
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?
Software is what people want and once a software ecosystem settles in place it gets a lot harder to move away later because of all the stuff you have to adapt and fix.
As far as I can tell there's no inherent reason an x86 device would have worse battery than ARM if you use the right processor. Pick up some small Lunar Lake chip, tune it low, aggressively tune the tasks you allow to run in the background etc.
Cellular is a bit annoying, and I can't speak at all to the difficulty of integrating with legacy phone services, but data access seems pretty easy to get with an external modem (maybe power consumption will suck..)
Definitely phone software landscape is abysmal. Everyone trying to lock down their stores and charge egregious prices to developers for the privilege of giving them access to their captive user markets. Makes me appreciate how fortunate we are to have Linux at all, and even Windows is leagues better, although MS is doing everything they can to develop their own little walled garden, albeit thankfully that horse has long bolted.
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
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.
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.
Unrelated question: What is this feddit.org site? It seems like reddit but I have never heard about it! I checked and it appears this is the very first post ever posted here on HN: https://news.ycombinator.com/from?site=feddit.org
Lemmy[1] is a federated Reddit-a-like running on the ActivityPub protocol. feddit.org is one particular instance of a Lemmy server that's hosted in Germany.
Personally, I'm pretty enthusiastic about the whole Lemmy project, and I think it's actually a much better fit to the federated ActivityPub model than Mastodon.
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.
It's my only phone. I gets hard when somebody tries to force an Android app on me. Waydroid works but takes a lot of disk space and is not very convenient (Purism promised usability updates though); the battery life is only enough for a day with light usage (but you can replace the battery without tools); js-heavy websites are slow (but NoScript fixes that). Calls, texts, taking pictures and video recording work. I never tried MMS, but some people made it work, too.
I'm very happy with the desktop Firefox (with Ublock Origin!), full terminal, all Debian packages and the full desktop mode. Also with lifetime updates and independence from the megacorps.
We focus on helping end users adopting "alternative mobile OS", we compiled a list of those alternatives on our website:
https://sailmates.net/actors/
we also provide phones at-cost (aka without making benefits) for users interested in those alternatives but without the technical knowledge to flash one
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.
It's possible to register a Signal account using signal-cli. Available on Flathub, and also Alpine repos. You can use a mobile number or a landline. I use Signal Desktop on a Librem 5 and everything works except the camera (for video calls) unless I plug in a webcam. The camera does work with other apps though.
Minority report: I will likely just switch to an iPhone, despite my typical gripes with Apple.
I've always seen my smartphone as a tool that doesn't do "much" (compared to a "real" computer) but can be relied on to always do what I need, whereas the inverse is ~true for my Linux desktop. (Think "bank app" versus "running Photoshop.")
By this metric, the only thing that historically ranked Android above iOS for me - even despite all the Google concerns - was sideloading and general openness.
Now that that's basically gone, I may as well move to a mobile OS that at least pretends to give a damn about my privacy.
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.
right, but if you can't install a custom android, you can't install anything linux based or anything else for that matter. so that's a different issue entirely.
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.
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.
You can run Android apps with Waydroid. If the app doesn't want to run in a non-approved environment, then you can have a problem with Android forks, too.
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)
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
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.
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...
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.
Thanks for reminding me about scrcpy. I knew it but I've completely forgot about it. Will give it a shot. Why the custom fork? You added the VNC support to scrpy?
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 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.
Does the EU even want you to be able to use government and banking apps on a non-secure device? Or do they want the device to have SafetyNet Attestation?
Doesn't the EU want encryption backdoors and such too?
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).
It would be so much easier to build apps if phones just ran linux, unless I am misunderstanding something? I would love to run my own server on my phone def.
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.
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!!!
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.
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.
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.
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.
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 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.
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.
MacOS reminded me of it's BSD intermixings. Although the BSDs are separate from Linux, both were Unix alternatives. MacOS was downported to iOS. While iOS is not Linux at it's core, it's definitely based on an alternative to unix, similar to linux.
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.
I am surprised that no one criticized kernel architecture as base for a secure mobile OS, yet.
Let me heat up the discussion using this quote
> The Linux kernel has atrocious security. It has an anti-security architecture, implementation and culture. The Linux kernel is not a good base for building any new operating system with a focus on privacy and security
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.
rather than campaigning for open phones, i think we need to actively campaign against the requirements for phones in society.
like, get some laws passed that say "if you require a phone number from someone, that's discriminatory/illegal".
this way we can remove the carriers, remove the population-wide location tracking, and ensure systems such as public transit, government interfaces, finance, etc. are still accessible.
I have started just carrying my laptop around with me more and more.
I increasingly only use my phone to make calls, text people, and take pictures of my kids. Any time I want to use the internet I default to my laptop.
This started as a way for me to reduce screen time and addiction with my phone, but the second order effect is that I don't feel limited by what a phone can do. Despite the fact that our phones are more powerful than ever and can easily run desktop-grade software, phone makers/mobile overlords have decided that they need to be controlled like Fisher Price toys.
My little 13" MBA lasts literally multiple days between charges with a couple hours of daily usage. A Linux laptop would work fine too.
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. :)
Forget Linux phones for a moment, let's start with Linux PDA. As telephony part is probably the hardest to solve due to proprietary drivers and regulations, how about building tiny PDA device that does everything else except "phone stuff" - get a dumbphone for calls and SMS, maybe some will have wifi tether. And after this PDA projects grows traction, it will be time to push for telephony support.
What are you talking about? The telephony part has been solved in Librem 5 and Pinephone. Also, this question has already been asked here: https://news.ycombinator.com/item?id=45257448
Looking at postmarketOS devices page only 20 community supported devices have "Calls" listed as "fully implemented". Clearly this is the main hurdle for true "Linux Phone". And those devices are a bit old, ranging from 2014 to 2020, and that makes them harder to obtain, also battery might be in need of replacing. And Pinephone is currently out of stock. Cannot comment about Librem 5, but its price is quite high. So, ignoring my silly idea of "PDA" - which Linux phone should I buy and how could I contribute to its success?
You realize it's a result of reverse-engineering done by volunteers? To me it looks like a large number actually.
The main hurdle for true "Linux Phone" is the lack of free drivers and specs, such that volunteers must spend tremendous efforts to make basic things work.
> which Linux phone should I buy and how could I contribute to its success?
To help Linux ecosystem on mobile, you could support vendors who intentionally provide free drivers or specs and help improve the software running on their devices. AFAIK only Pinephone and Librem 5 fit here. The former is in stock from time to time.
Also many users of GNU/Linux phones run Phosh developed by Purism. Helping to improve it would help the whole community.
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)
It is not for preventing you from taking screenshots, if you insist, you can do it with another camera. It is to prevent malware and "helpful" AI tools from doing it for you and then uploading the picture to who knows where. Signal does this too, though I think it is optional.
Beyond preventing screenshots, it blacks out the window content in the task switcher, which is useful if someone is looking over your shoulder. This, by the way, is a good way to check if screenshots are allowed. If the window appears black in the task switcher, screenshots won't work.
The idea is similar to the "**" password fields.
So in other words, the developers of Android could not figure out how to design a system that could distinguish a screenshot that was initiated by the user versus one initiated by software.
Very impressive.
i mean, security in depth is a good thing to me.
I mean if the goal is to prevent potential malicious apps from taking screenshots automatically; instead of saving a clueless user from themselves or worse getting in the way of legitimate users I believe that the proper solution is to disallow programmatic screenshots while still allowing screenshots when there is the correct button press (and ensure that this cannot be emulated). Windows reserves ctrl-alt-delete as a direct signal to the kernel for security purposes. Why can't android do the same?
> the proper solution
includes the ability from a user to take screenshots programmatically in case of need. You do not want third parties to be able to; you want the User (yourself) to be able to.
It's really stupid idea, that results in photos of sensitive information displayed on my device on other devices that I don't control and sensitive information wrote on paper in random places.
Password fields are inputs. Screens are bi-directional.
Then ask for my fingerprint after screenshot is made.
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've been unimpressed with Google's commitment to making the fundamentals of Android great. They seem to prefer doing the minimum required there and putting all their efforts into something more sexy, like generating fake photos that look like they were taken with a 2400mm lens.
I don't want my phone to generate fake photos; I do want it to always let me manually take screenshots, but require turning on a permission that's a little awkward to find to allow an app to do so.
When you don’t control the hardware a lot is off the table.
This is a fine excuse for most everyone, but not Google. They can control the hardware significantly and in some cases like pixel, completely.
They no longer believe in owner control. Either that or they consider themselves the device owner, which is even worse IMHO
Sounds like a marketing opportunity to sell more Pixels and get closer to their current dream of becoming Apple
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.
So let's have more of these conversations so the idiots making those standards make fewer dumb rules and we can grease the wheels for anyone passionate enough to try to get it changed
Unfortunately the idiots are often the nation's security agency, or a large consulting company.
You will not have them change their policies if they do not have a good person inside, who will slowly move the boat.
I fought for audit findings because they were pissing me off at a personal level and it wirked. But the auditor did not change their procedure, just reverted the finding. Until the next year.
I think you're making the naïve assumption that large organizations are heterogeneous.
The people at the top are idiots because the idiots were able to secure advisory positions. They were able to secure positions because those promoting them were either tricked or idiots themselves. This pattern repeated all the way down.
So I really do mean grease the wheels. And I really mean we won't kill the beast overnight. But we won't make any progress towards fixing things if we won't look at how the problems are created in the first place. We'll only perpetuate the problems if we oversimplify things, as that's exactly what got us into this mess in the first place.
There was a Microsoft Terminal Server "monitoring" application that worked by recording the screen through a series of JPG screenshots. It worked surprisingly well and bypassed all kinds of controls.
> 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
Tbf, one could make the argument that there would have been far fewer resources dedicated to computer vision had companies made the data more accessible and had we modified PDFs to make it easier to copy test.
People will go to great lengths to bypass annoyances. Excessive false alarms is even called "alarm fatigue"
Isn't it though? You compromise some email provider so that you have read access to the emails of a million people going back 20 years. Literally many billions of emails with petabytes of attachments. Can you do text search on all of that text? Absolutely, an ordinary PC could do that in a realistic amount of time. Can you search the text within all of those images using some kind of computer vision system? Not without your own power plant.
I think you made bad assumptions. If I installed the APK through a third party, sure, my bad. But then I agree with shmel, that there's still some blame on Google. Like why not have a default where we disable screenshots not performed by a physical action and have an advanced option for API based screenshots? It's not bulletproof but neither is the current implementation.
But if I install via the playstore like most people then no, I don't think it's the user's fault. Testing every single app seems like a big ask but we're also talking about a 3 trillion dollar company. I mean FFS a 1 trillion dollar company didn't even exist 10 years ago and 10 years before that a 500b company barely did. So I think they can stand to lose some profits and do harder work. Really, if we don't hold these companies to high standards then that bar just continues lower and it's a race to the bottom. They'll be as lazy as we let them be
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.
Sounds like they need to spend more money on security and their "good enough" solutions aren't actually good enough.
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.
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.
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.
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.
I don't know about your bank/countries, but all of the banking apps in my country I've seen have 1. a "share account details" button that lets you easily paste your IBAN and other details in text form and 2. a "transaction receipt" button that saves a .pdf with the relevant details, that can be sent to the other part (although I agree with the other comment, this .pdf just like a screenshot can be easily spoofed)
Why does a third party want to know the transaction occured?
These seems a bit like a scam. Why can't they ask the recevier?
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.
And PDF documents in image form. Usually scans of printed copies.
It is fine for historical documents, but doing today means you really want to piss people off. And by the way, PDF files support signatures, both handwritten and digital. There are ways other than printing a 100+ page document and scanning it just so that your signature shows up on a single one of these pages.
At least the days of those screenshot being pasted into a Microsoft Word document are mostly behind us now...
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.
I have checked all my mobile banking apps (3 czech, 1 slovak, 1 lithuanian bank) and all of them can copy my IBAN.
Two mirrors will make it allowed.
Why not copy it from the App?
Pretty sure Twitch on iOS does this now. Screen recording still works though.
> 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's doesn't sound right. On mine, a message is displayed saying that the app does not allow screenshots, and no image is written to the device.
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.
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.
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.
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.
> you just need capital
The capital itself isn't going to do anything sitting in the bank. It's used to procure a team of PhDs, an team of SWEs, DevOps, business people, HR, marketing, access to a GPU supercomputer (renting a couple of 5090s off Vast.ai ain't gonna cut it). For, say, $50 million, you could get the blueprints to an Android phone and port your choice of Linux userland and get drivers working, and then do a run of 20,000, sell them for $1100. Compared to training GPT5, $50 million is cheap. If we use an estimate of $1 billion for the whole thing, making a Linux phone running a hypervisor with an Android VM to run banking apps seems not-impossible. (Based on AVF.)
That's not the point I was making. Both operations need capital. But capital isn't the only barrier to entry.
With a LLM, you can spend the money to develop the model, then spend some money marketing it, and if you get enough paying customers to cover your costs and a bit more then you're done. Done in the sense that you're now competing on the same level (roughly) as other LLM providers. Even if it's at a smaller scale, you can offer a similar product with similar features.
With a phone OS, that isn't enough. You need to become big enough that significant numbers of app developers are willing to publish apps on your store, including most major ones (Netflix, Spotify, WhatsApp, social media, banks, government agencies, etc.). Running a VM isn't a full solution: banking apps are already actively blocking usage just based on phone settings that they don't like; unlses your OS does a very convincing job of masquerading as a genuine Android/Apple device you're likely to run into problems (and if you do the latter you might hit legal problems). You also need to convince major manufacturers that it's worth bundling your OS with their phone.
Without those, for a significant segment of the population your phone OS will always be seen as an inferior product to Android / iOS.
You make a valid point, that there are some key apps that are necessary for a new smartphone OS to be viable as a daily driver for the unwashed masses. But that's also just a matter of money. If you roll up to each of the major app's companies with a big enough pile of money, and ask the right person there to port it to your new OS, I bet you could make it happen. (If you don't know the right person, capital also lets your get access to them as well.)
As far as being an "also ran", I mean, that's going to be true for any LLM as well. Your second rate LLM is also always going to be seen as inferior just because it isn't ChatGPT, regardless of any other actual merits. Human psychology is fascinating because they aren't rational. Every time I get fooled into buying some stupid piece of crap because there was an advertisement that tickled my brain in the exact right way, I see just how irrational everybody is, given just the right set of words. Why do I bring this up? We could waste countless hours arguing over the infeasibility of a phone OS vs the infeasibility of an LLM, it's all in our heads, but doing so wouldn't get us closer to the goal, which is dominated by the singular question: can you virtualize enough, and pass through enough of android, to get banking apps to run in a VM on some real hardware, so that dom0 can be debian?
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
SafetyNet works in GrapheneOS. What Google Pay requires is that the attested signature is trusted by them, a lot of apps, including many banking apps (at least in the UK) use safetynet but do not require the signature is trusted.
Netherland used to have its own system for NFC payments, and it worked perfectly. Last year, all banks suddenly abandoned it and forced people to use Google Wallet instead. Of course I refused, because I don't want to share my financial transactions with an advertising company, so no NFC payments for me.
It's ridiculous the EU allows this.
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.
There's already a better way to check whether an Android phone is secure enough and it is independent of any proprietary OS certification: basicIntegrity [1].
Most banking apps in Germany use this API and thus work on GrapheneOS and other non-Google controlled ROMs with a locked bootloader.
PlayIntegrity is unnecessary and mostly offers vendor lock in to Google's ecosystem.
[1] https://grapheneos.org/usage#banking-apps
>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.
iphone now allows phone call recording.
I don't know if it is geolocked somehow, I wouldn't be surprised if it was. for example, Japanese iphones always make a shutter sound in japan or in airplane mode
There is a waveform thing in the corner you can press during a call. It will say "this call is being recorded" and waits 5 seconds, then records the call.
strangely... the recording doesn't end up in voice memos, it ends up in notes.
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.
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 assume you’re talking about another country, because in Denmark there was no general curfew under Covid (attendance to events might have required proof of negative COVID test or vaccination, but shops never did).
>If I respected the rules, I would starve to death!
respecting rules is more important that saving your life. /s
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.
it looks like MitID is basically country-wide SSO, isn't it? then isn't MitID collecting every website you authenticate to via the redirect uri?
Ah, yeah, that actually makes sense: now that the USA no longer shares intelligence information with some countries it previously did (or can't be trusted to do so), they have to implement alternatives.
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.
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?
because half of the internet is there
But in many cases a server operator doesn't expect any legitimate traffic from that half of the internet, or is willing to block traffic from it.
For example, there's generally no reason a customer would use their internet banking app with traffic routed via a datacentre other than for the reason you proposed (masking their IP address), so if the bank wants to prevent people doing that then blocking all data centre traffic is an effective way of doing it.
That's why I explicitly wrote: "for stuff that should only be done by legitimate users".
That means Netflix et al can (and do) ban everything that even remotely smells like a datacenter IP range and not a residential one, because that is a common method of evading regional bans or undermine pricing structure.
And on top of that... if the focus of your website is humans, you might want to cut off all datacenter originating traffic as well. Save yourself the hassle of dealing with AI scrapers.
I would much rather fight this and retain my rights instead of participating in some kind of privacy and censorship arms race.
you fight this by the arms race
> 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.
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 ...
I mean that there is no Belgian nation - native Belgian citizens are mostly either Dutch-speaking Flemish people or French-speaking Wallons, and generally don't have any significant notion of a shared national identity.
Note that this doesn't mean that a state with multiple ethnicities/languages can't be a nation state. Indians, for example, generally have a clear national identity, despite being citizens of a huge federal republic with dozens if not hundreds of languages spoken, some of which don't even share a common language family. So, India is a nation state, unlike Belgium.
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
Why?
I would very much like to record phone calls made by me.
When the company on the other end denies what we agreed a recording would be useful.
> My Android phone prevents me from taking screenshots if an app author doesn't want me to.
It's worse. An app author can even be notified if a screenshot was taken.
The Amazon app does this: "Amazon Shopping detected this screenshot."
I'm assuming (hoping) it's Android letting me know and not the app passive aggressively side eyeing me.
This reminds me of a story of my bank that at some point told me to send them a screenshot.
I told them that their app prevents this. To their surprise.
I told them that I would use the web site and they were happy that there is a workaround for their own limitation.
I had other wild stories with this otherwise good bank.
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.
> 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.
my GrapheneOS phone has the record button. :) though I have to obtain all-party consent to do so legally in my jurisdiction (but that's my responsibility.)
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.
lol that is not how that works. it is client side. they cannot do anything to block it.
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?
>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.
True. Sony is a conglomerate, which explains their business strategy. Lots of divisions and groups operate independently and have little coordination.
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.
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
Yes, both (official) SailfishOS and FLX1 offer decent/good Android app support. Not every app will work, but when I have needed Android (rarely, for basic stuff), the applications have worked.
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?
You're comparing a Linux OS (postmarketOS) to a device (FLX1). I think you meant to compare postmarketOS to FuriOS : )
FuriOS (and its base Droidian) are at a better stage of development for devices made to run Android using the old Android Linux kernel, whereas postmarketOS is better for devices made specifically for Linux, like the Liberty Phone, Pinephone, etc. Droidian will not even work on them.
I'm not familiar with postmarket, but I imagine it shares a lot of the same phosh+GNOME app ecosystem, in which case, the apps aren't in a better state.
In terms of polish and app/dev ecosystem, I feel SailfishOS still rules, but it's getting harder to justify using/development, with it's increasing divergence from upstream.
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…
Why isn't there more information about Furi FLX1 in the internet? Looks like a nice phone.
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.
But I mean, why not take the 100s of thousands of man-hours that went into making Android this very Linux-Kernel based mobile OS and build on top?
Will you be happy with xeyes and a terminal? Like, even a technically superior solution is completely useless without an ecosystem to make use of it, and desktop GTK/qt apps won't work nicely on mobile without actual porting. Let alone a technically significantly inferior one that is a misfit in this shape for mobile hardware.
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?
By making a soft and then a hard suspend the reality they have to abide by, or otherwise they are killed and users will think they are broken apps.
Mobile apps just had to "grow up" in this environment, plus they have proper APIs for this two-way communication between OS and the app. Android will just ask the app to save its state and then simply unload it from memory (after a while) - but this also makes perfect sense for the desktop scene, you also want to improve energy efficiency there. A spreadsheet app doesn't have to continuously run when it's in the background. You just have to add proper APIs and permissions so that apps can optionally ask for extra background work.
I would argue that the legacy OS and app architecture we have on desktop OSs doesn't make sense there, either.
It's a model that worked fine in multi-user setups where you ran a single executable, so that the security per user was meaningful, but today it just sucks.
Android is quite elegant in reusing the Linux kernel's permission system, but on a granularity that actually makes sense (apps are started as separate users, and they just elevated their concept of user a level higher).
macOS grants processes permissions, eg terminal is allowed access to ~/Photos but Whatsapp is not. Seems like a decent evolution of things.
Hi. I have a Google Pixel 3a running PostmarketOS https://postmarketos.org/ and it holds up pretty well. My phone lost 20% today with light usage and will maybe lose 60% if I scroll social media a lot.
I was actually surprised it is this good. I reinstalled recently and before the reinstall I had much worse battery life (Maybe 8 hours with normal usage). I think it was because of Syncthing running in the background.
It is also possible to use s2idle suspend which will improve the battery life even more but you will not be able to receive calls during suspend (though that may also be fixed in the future)
yeah there are lots of tablets and 2-1 with amd chips that can do 8 hours on light usage.
Did you know that you can replace the battery in Librem 5 and Pinephone on the go?
They are just like tiny laptops, so you can certainly shutdown and swap the battery.
With Librem 5, you can even swap the battery without shutting down the phone if it's connected to the power.
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.
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.
Well, if enough of us paid Apple level prices to Linux vendors, we would have Apple level Linux laptops and phones eventually. Not fair to pay next to nothing and then compare Linux to Apple.
apples to oranges
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.
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!
> Maybe a PAYG phone which stays at home on my network for particular needs like banking.
If you're only doing banking at home, why would you do it on such a tiny little device?
They probably mean for TAN apps
you won't even be able to use the closed phone remotely from your main one since the restrictions wont allow remote software to see or interact with the screen
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..
On my to-do list is to join a local credit union after checking whether all services are available in person. All this mess is not worth simply being able to do stuff from my phone.
The trick is to never, ever install the banking app on your phone. If you only use their web app from the beginning (account creation) and say you don't have a duopoly phone, the app will not be required.
FYI, you can get a pixel 8a for $200 or less if you don't care about condition. Support end date in 2031.
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.
I was going to say that. I carry a laptop and an iphone 13 mini. The iphone is nice in a locked down way and the laptop you can code on etc. I'm not sure I see the attraction of the non locked down phone compared to the laptop for most use cases. I guess I could location spoof pokemon go so there'd be that.
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.
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.
(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.
$50 per phone would not make them enough money to pay developers. You would be left with a worse version of the Pinephone. We can't pay peanuts and expect the situation to improve significantly.
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.
What nonexistent security model? Isn't Android just stock Linux with an interface layer on top?
Uhh no? One of the biggest differences probably is that Android applications are heavily sandboxed:
> Applications are security principals. The main difference to traditional operating systems that run apps in the context of the logged-in user account is that Android apps are not considered to be fully authorized agents for user actions. In the traditional model typically implemented by server and desktop OS, there is often no need to even exploit the security boundary, because running malicious code with the full permissions of the main user is sufficient for abuse.
https://dl.acm.org/doi/fullHtml/10.1145/3448609
And then there's also:
- No root access (by default)
- Verified Boot
- Hardware-backed key store and hardware attestation
- User profiles are encrypted independently of each other
- …
I just confirmed that Android uses a largely unmodified kernel, so in theory it should be possible to just implement whatever extra components make up the Android system. To your points:
- Sandboxing: Android accomplishes this by running each app in the context of a different UID.
- No root access: Like above, user-installable apps are given separate UIDs. The GUI and other system processes probably also get random UIDs. Probably very little of the Android system runs as UID 0. (However, I don't really believe that keeping the user from doing things as root is a valuable security feature, as long as the user is competent)
- Verified boot: There's nothing specific to Linux/Android about this, right? The bootloader handles checking the signature.
- Hardware-backed key store: Isn't this, as the name implies, "hardware"? So it should be OS-agnostic, right? Maybe Linux doesn't use it, and Android does, but someone just needs to write a driver for it (and maybe some bytecode implementation or whatever, if it's some secure enclave thing, which it seems to be).
- User profiles encrypted independently: I don't think the Linux kernel supports encrypting profiles, this is a userland feature of Android, and could therefore be ported to Linux.
> I share the concerns about Android
> Why not try to fork AOSP or GOS
Which concerns do you share? Both AOSP and GOS must follow the Google development strategy, they aren't exactly independent on Google (which is a problem: https://news.ycombinator.com/item?id=45208925). Nevertheless GOS on Librem 5 or Pinephone would be a nice idea, except the GOS developers are against that: https://news.ycombinator.com/item?id=45101400
> Linux's (nonexistent) security model
Linux's security model is based on trusting the software you're installing from the FLOSS repositories, and it works very well.
>Nevertheless GOS on Librem 5 or Pinephone would be a nice idea, except the GOS developers are against that: https://news.ycombinator.com/item?id=45101400
GrapheneOS are against using their development resources on a platform that is drastically, significantly worse than the hardware platform they already have, which is quite fair. It is not about Pine64 or Purism's products specifically. They would not be against them if they met 95% of the requirements detailed in https://grapheneos.org/faq#future-devices. It would more sense to explain which of those requirements you think are unreasonable.
> Linux's security model is based on trusting the software you're installing from the FLOSS repositories,
That's not a security model, and we don't live in fairyland.
Just take a look how well this works with npm packages. It just so happens that emacs plugins are not the most worthwhile target for attackers.
> npm packages
This has nothing to do with what I said. npm is not a trusted or a FLOSS repository.
> we don't live in fairyland
When did you see a malware in Debian's repositories last time?
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
It never came to Debian and was a work of a tremendous effort. This almost never happens, and when it does, practically nothing can protect you.
But like, it won't matter how many viable Linux phones there are if the government tells you that if you want to pay your taxes you must first buy a piece of hardware blessed by an american corporation and running blessed software which doesn't let you control the device in order to access the tax payment portal.
Because if you don't pay your taxes, the government will insist that you go to prison.
The problem isn't really what google is doing, the problem is that were letting our existence as free citizens in a society depend on a piece of blessed hardware/software we must carry around with us everywhere we go.
We need to strongly resist having software/to become strongly codependant on hardware broadly speaking. But especially software/hardware that we can't control and which is sold by two american companies.
I agree. Is there any country that requires an app to file your taxes?
Maybe, who knows. It was an example. All I know is countries like Denmark and maybe soon all of Europe seem completely carefree with regard to making citizenship depend on device ownership so...
Quite a few banks in the UK now require an app, and that's a liability for me as who knows when they'll arbitrarily decide to lock me out of my account because I am not running stock google android.
The bank I'm with uses a hardware token which I can tolerate because, while it does require a codependence on hardware, at least the hardware is provided for free by the bank. I can also manage my account over the phone without the hardware.
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!
Ah, I just abandon the idea of recovery on these phones and use the ubports installer once. Thereafter, I just flash directly. I have done the MTK tools dance, but don't any longer. Sorry :(
Ah, I have to admit I don't know much about porting :) We did put up a community wiki and the HADK is up there: https://sailfishos.wiki/books/hadk/page/hadk so that you might get some idea of the process ... I'm not sure to what extent this is different from that 'halium' builds that piggz makes. It makes sense to ask him directly, since he has a stream lined process that targets, among others, the phones you have.
As to why the hardware adaption layer is needed (ie. the android one) it's where all the binary blobs are :) Among other bits.
> Sailfish OS
On what hardware? Jolla C2?
I think Parent is using a Gigaset GS5
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?
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
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?
Because Apple didn't want to open their ecosystem, they invested a bunch of money (and time) into "exploring what's the bare minimum required to comply with EU regulations". Now Google is locking their ecosystem down the same way because they know they are legally allowed to do so.
This is why it's an "unintended side effect" of EU regulations, as the regulations prompted Apple to find out how much user hostile behaviour they can get away with.
The DMA triggered reactions from Google and Apple that is worsening the situation for app developers and alternative app stores.
It's a failed legislation already.
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.
> What's their intend?
Some say it's eSIM and identity integrity
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. It was and is their job to do that. 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 they are 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...
> Google is acting here as the owner and maintainer of a services ecosystem... > they increasingly experience difficulty to contain issues within that ecosystem and prevent them from spreading (piracy, malware, hacking,...)
I wonder if the smartphone app industry is big enough now that allowing just two corporates to govern them is no longer fair or democratic.
It has outgrown the "ecosystem" word a long time ago. It's a genuine industry now.
Apps are such a fundamental part of most people's lives now (whether they like it or not), and these two companies have a disproportionate amount of power over an entire industry.
This is more or less the journey the EU has started with the Digital Markets Act, but in a very agnostic way.
They identified that, among others, Apple and Google are operating a "Digital Market" of significant size within their ecosystem, where they invite others to participate and compete, and it's the role of a government to ensure fair conditions in the markets of its economy so forces can flow freely.
The way they defined that is very smart. They don't define what an "app" is or an ecosystem, they identify in a objective way that their operations constitute a market, and that they have to comply to certain rules in order to ensure fair competition.
I just hope that they can see this through and have those Digital Markets established as proper "markets" in the same sense as physical markets are, before some political "wind of change" is dissolving everything again.
Apple is very much counting on such a wind of change, by actively rallying its users against the EU...
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?
Librem 5 is my daily driver. The camera is not amazing, but it works fine. The battery can last one day just fine with a non-heavy use. And you can replace the battery on the go.
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...
They are required for salary payments in my country.
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.
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.
> 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).
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.
> strategic focus on the mobile banking app over the web app. Younger generations are doing everything through their phones
This is not an argument against web apps, which work on the phones just fine.
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.
> 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
> 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.
> 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.
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.
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.
can you be more specific please? droidify appears to just be an f-droid client. i already have f-droid. in fact, it's my primary source for apps. but i can't find any apps that match your description.
> 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 don't think so. Google is poisoning the well with their developer policies and play store controls. The time is ripe for a competitor, and if there's a credible competitor that demonstrates the "good because goog says so" model is broken, that will force fully open attestation.
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.
This is not about being able to pay your bills at a moment's notice from anywhere in the world.
This is about being able to pay your bills at all.
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.
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.
Librem 5 can do all those things fine. Video is somewhat less reliable, but it works.
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
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
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.
The BC Service Card app
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'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?
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?! :)
> 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.
My GrapheneOS phone fully supports such facilities. I trust your app works on it?
here's all you need to do, if not: https://grapheneos.org/articles/attestation-compatibility-gu...
I can see how that reads like I'm an app developer! I'm not though, I just meant the apps from my bank that I use.
That looks like an interesting and useful capability.
I don't believe this will satisfy the crowd who want complete control over their systems though, as AFAICT graphene is not rooted by default and will likely fail these attestation checks if you root it. This will also not please the "Passkeys and hardware attestation are evil/non-FOSS by nature" crowd.
Definitely provides more freedom wrt. third-party app stores though.
> 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).
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.
Curiously the linked discussion begins:
> 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.
Why not just use the browser?
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. )
I need my banking app for 2FA to login with the browser. No, they don't use or allow TOTP.
yes, we know. Why do you feel the need to highlight the most negative aspect of the adoption?
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?
"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.
> Android that work without Google Play,
https://github.com/microg/GmsCore, so basically you cannot. It's monopoly in daylight.
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.)
Google still controls direction of AOSP development.
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.
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).
I don't really use Bluetooth, it can pair with my car to do hands free calling but have never used that.
Got it because it was a small, low-cost, dual-sim phone that could also act as a router. It replaced an even lower cost Nokia feature phone.
Don't run apps often enough to be bothered by any advertising.
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.
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.
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?
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.
Battery life is probably awful, mainly.
Maybe carrying a hotspot modem with a sim card is enough?
Like Chinese emulator handhelds?
Librem 5 already exists, so there's no need to develop a handheld without a modem.
>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.
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.
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?
Path dependence I guess.
Software is what people want and once a software ecosystem settles in place it gets a lot harder to move away later because of all the stuff you have to adapt and fix.
As far as I can tell there's no inherent reason an x86 device would have worse battery than ARM if you use the right processor. Pick up some small Lunar Lake chip, tune it low, aggressively tune the tasks you allow to run in the background etc.
Cellular is a bit annoying, and I can't speak at all to the difficulty of integrating with legacy phone services, but data access seems pretty easy to get with an external modem (maybe power consumption will suck..)
Definitely phone software landscape is abysmal. Everyone trying to lock down their stores and charge egregious prices to developers for the privilege of giving them access to their captive user markets. Makes me appreciate how fortunate we are to have Linux at all, and even Windows is leagues better, although MS is doing everything they can to develop their own little walled garden, albeit thankfully that horse has long bolted.
> What's the hardest part about an open phone?
https://news.ycombinator.com/item?id=21656355
> 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
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.
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/
Unrelated question: What is this feddit.org site? It seems like reddit but I have never heard about it! I checked and it appears this is the very first post ever posted here on HN: https://news.ycombinator.com/from?site=feddit.org
Lemmy[1] is a federated Reddit-a-like running on the ActivityPub protocol. feddit.org is one particular instance of a Lemmy server that's hosted in Germany.
Personally, I'm pretty enthusiastic about the whole Lemmy project, and I think it's actually a much better fit to the federated ActivityPub model than Mastodon.
[1] https://join-lemmy.org/
born as the federated edition of reddit, gained traction over the mass exodus.
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.
I run Andoid apps on my Librem 5 using Waydroid.
Is Librem 5 you main or only phone?
Interested in your opinions -- good and bad.
It's my only phone. I gets hard when somebody tries to force an Android app on me. Waydroid works but takes a lot of disk space and is not very convenient (Purism promised usability updates though); the battery life is only enough for a day with light usage (but you can replace the battery without tools); js-heavy websites are slow (but NoScript fixes that). Calls, texts, taking pictures and video recording work. I never tried MMS, but some people made it work, too.
I'm very happy with the desktop Firefox (with Ublock Origin!), full terminal, all Debian packages and the full desktop mode. Also with lifetime updates and independence from the megacorps.
Thanks for the info.
Shameless plug for our association.
We focus on helping end users adopting "alternative mobile OS", we compiled a list of those alternatives on our website: https://sailmates.net/actors/
we also provide phones at-cost (aka without making benefits) for users interested in those alternatives but without the technical knowledge to flash one
https://sailmates.net/get_your_phone/
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.
It's possible to register a Signal account using signal-cli. Available on Flathub, and also Alpine repos. You can use a mobile number or a landline. I use Signal Desktop on a Librem 5 and everything works except the camera (for video calls) unless I plug in a webcam. The camera does work with other apps though.
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.
Minority report: I will likely just switch to an iPhone, despite my typical gripes with Apple.
I've always seen my smartphone as a tool that doesn't do "much" (compared to a "real" computer) but can be relied on to always do what I need, whereas the inverse is ~true for my Linux desktop. (Think "bank app" versus "running Photoshop.")
By this metric, the only thing that historically ranked Android above iOS for me - even despite all the Google concerns - was sideloading and general openness.
Now that that's basically gone, I may as well move to a mobile OS that at least pretends to give a damn about my privacy.
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.
right, but if you can't install a custom android, you can't install anything linux based or anything else for that matter. so that's a different issue entirely.
You can run normal linux desktop and server programs with no limitations. The development and driver support is not guided by google.
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 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.
You can run Android apps with Waydroid. If the app doesn't want to run in a non-approved environment, then you can have a problem with Android forks, too.
See also: https://puri.sm/posts/closing-the-app-gap-momentum-and-time/
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)
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...
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.
My Android phone prevents application installation from 3rd party sources
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...
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 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
Thanks for reminding me about scrcpy. I knew it but I've completely forgot about it. Will give it a shot. Why the custom fork? You added the VNC support to scrpy?
I had this old patchset: https://github.com/DavidVentura/scrcpy/tree/dev
Which added vnc support directly onto scrcpy, so I could leave a tablet plugged in to my headless server and access the tablet remotely via VNC
The alternative was to use X11vnc but it was janky and had some issues, plus higher cpu usage
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.
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.
Does the EU even want you to be able to use government and banking apps on a non-secure device? Or do they want the device to have SafetyNet Attestation?
Doesn't the EU want encryption backdoors and such too?
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).
Claiming control of citizens speech when you have a president literally censoring your media is kind of ridiculous.
The claim free speech is under threat in Europe just demonstrates you are easily led by rabble rousers.
It would be so much easier to build apps if phones just ran linux, unless I am misunderstanding something? I would love to run my own server on my phone def.
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
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!!!
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.
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.
https://puri.sm/products/librem-11
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...
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.
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?
I used to delete them on old Android version.
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.
> 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.
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 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.
I went to go check my memory :)
Android is based off, and runs off a linux kernel: https://en.wikipedia.org/wiki/Android_(operating_system). Android being modified in places including userspace is a fair point, but it's linux derived.
MacOS reminded me of it's BSD intermixings. Although the BSDs are separate from Linux, both were Unix alternatives. MacOS was downported to iOS. While iOS is not Linux at it's core, it's definitely based on an alternative to unix, similar to linux.
BSD references: https://developer.apple.com/library/archive/documentation/Ma...
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.
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 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
I am surprised that no one criticized kernel architecture as base for a secure mobile OS, yet.
Let me heat up the discussion using this quote
> The Linux kernel has atrocious security. It has an anti-security architecture, implementation and culture. The Linux kernel is not a good base for building any new operating system with a focus on privacy and security
https://grapheneos.social/@GrapheneOS/114665594121762341
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
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.
rather than campaigning for open phones, i think we need to actively campaign against the requirements for phones in society.
like, get some laws passed that say "if you require a phone number from someone, that's discriminatory/illegal".
this way we can remove the carriers, remove the population-wide location tracking, and ensure systems such as public transit, government interfaces, finance, etc. are still accessible.
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.
I have started just carrying my laptop around with me more and more.
I increasingly only use my phone to make calls, text people, and take pictures of my kids. Any time I want to use the internet I default to my laptop.
This started as a way for me to reduce screen time and addiction with my phone, but the second order effect is that I don't feel limited by what a phone can do. Despite the fact that our phones are more powerful than ever and can easily run desktop-grade software, phone makers/mobile overlords have decided that they need to be controlled like Fisher Price toys.
My little 13" MBA lasts literally multiple days between charges with a couple hours of daily usage. A Linux laptop would work fine too.
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
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?
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.
> 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. :)
Forget Linux phones for a moment, let's start with Linux PDA. As telephony part is probably the hardest to solve due to proprietary drivers and regulations, how about building tiny PDA device that does everything else except "phone stuff" - get a dumbphone for calls and SMS, maybe some will have wifi tether. And after this PDA projects grows traction, it will be time to push for telephony support.
What are you talking about? The telephony part has been solved in Librem 5 and Pinephone. Also, this question has already been asked here: https://news.ycombinator.com/item?id=45257448
Looking at postmarketOS devices page only 20 community supported devices have "Calls" listed as "fully implemented". Clearly this is the main hurdle for true "Linux Phone". And those devices are a bit old, ranging from 2014 to 2020, and that makes them harder to obtain, also battery might be in need of replacing. And Pinephone is currently out of stock. Cannot comment about Librem 5, but its price is quite high. So, ignoring my silly idea of "PDA" - which Linux phone should I buy and how could I contribute to its success?
> only 20 community supported devices
You realize it's a result of reverse-engineering done by volunteers? To me it looks like a large number actually. The main hurdle for true "Linux Phone" is the lack of free drivers and specs, such that volunteers must spend tremendous efforts to make basic things work.
> which Linux phone should I buy and how could I contribute to its success?
To help Linux ecosystem on mobile, you could support vendors who intentionally provide free drivers or specs and help improve the software running on their devices. AFAIK only Pinephone and Librem 5 fit here. The former is in stock from time to time.
Also many users of GNU/Linux phones run Phosh developed by Purism. Helping to improve it would help the whole community.