I have made some experiments with P2W, my experimental Python (subset) to WASM compiler. Initial figures are encouraging (5x speedup, on specific programs).
It is a disgrace how Google has managed this situation.
To recap the storyline, as far as I understand it: last August, Google announced plans to heavily restrict sideloading. Following community pushback, they promised an "advanced flow" for power users. The media widely reported this as a walk-back, leading users to assume the open ecosystem was safe.
But this promised feature hasn't appeared in any Android 16 or 17 betas. Google is quietly proceeding with the original lockdown.
The impact is a direct threat to independent AOSP distributions like Murena's e/OS/ (which I'm personally using). If installing a basic APK eventually requires a Google-verified developer ID, maintaining a truly de-Googled mobile OS becomes nearly impossible.
If this finally pushes adoption of truly open Linux phones, then this will end up being a good thing, and the greatest favor that Google could do for the open source community.
Tragically, Linux phones have languished and are in an absolute state these days, but a lot of the building blocks are in place if user adoption occurs en masse. (Shout out to the lunatics who have kept this dream alive during these dark years.)
It won't though, because there's a ecosystem of banking/insurance/whatever apps that have bought into the android/iphone lockdown mindsete that people will simply be locked out of. Open alternatives can grow when there is a viable means of slow growth, and cutting off the oxygen to such things is the implicit intent.
I know banking apps are the typical example, but I've always wondered why. I use my bank's app maybe once or twice a year when I need to Zelle someone, which I only need to do when they don't have Venmo. (Unless we consider Venmo a banking app.)
I only have one bank's app installed, the rest of my banks I only interact with over their website, on desktop.
As for insurance, I've never had an insurance company's app installed.
Am I just an outlier here? Honestly, if I switched to a non standard OS, I'd be more annoyed about losing, say, Google Maps, Uber/Lyft, or various chat apps. Banking and insurance just don't come to mind at all as something I need my phone for.
I can get alerts in email or messages, no need dedicated app for that, I can track there also my balance, so only useful thing app provides are easy wire transfers from phone, which I never do, if I wanna transfer money is much more convenient work big display, proper keyboard and mouse than from phone.
We've cultivated a tech culture that can't stand the slightest inconvenience. People will give up nearly everything if it means avoiding the least bit of effort.
If 80% of adults worldwide somehow became unable to tolerate the slightest inconvenience, then yes, I'd say they would be morons, but I doubt they are. I'm unsure where you're getting the 80% statistic from.
Yes, because “bigstrat2003” said so. I work for a 1000+ consulting company and no one uses email for internal communications. Even for company wide messages leadership uses Slack.
Heck even when we first start a project we either federate (or whatever you call it) the client’s Slack workgroup with ours or we ask to be on their Teams channel.
Before working where I worked now, I worked for the 2nd largest employer in the US, even there most communication happened over Chime or Slack.
On a personal level you actually email personal contacts - in 2026?
I email my dad documents and photos I need printed (and he uses his work office's laser printer). I forward the billing statement I receive monthly from my family's ISP to my mom via email. And I'm "Gen Z"
And I’m 51 and far from a Luddite. I’ve moved with every technology transition since learning how to program in AppleSoft BASIC and 65C02 assembly. My 83 year old mother is less of Luddite some people commenting here.
She is a retired high school math teacher - been retired for 30 years - and she has used every popular word processor/suite from the original AppleWorks for the Apple //e and she was tutoring friends kids and helping them use GSuite and PowerPoint until 5 years ago.
She uses her phone for everything and she has up to date computers a couple of printers on her network and two ISPs just in case one goes out. She kept the legacy DSL account that’s not available to new subscribers and she has cable internet.
No, it's cool tho, worry about being "hip" and enjoy the authoritarian surveillance state that you are enabling because you've been indoctrinated to want "new thing" and to reject "old thing".
I use email corner with push, so I have emails instantly with notification to my smart watch, all my clients send me tasks through email
yes, especially the 4th point, the entering all the recipient's banking details on real keyboard is much more convenient than switching the windows and checking some microscopic numbers in PDF document on smartphone same copypasting them one by one between different fields (and yes, there are many companies which still don't provide QR code in their invoice)
The overwhelming majority of the population of the developed world now considers the mobile phone as their primary (and often only) computing device. It's always with them, it's more accessible and intuitive than a laptop, and it's how they communicate with everyone. It doesn't matter if you prefer to do this or that on a "real" computer - most people would just do everything through the phone if they could.
It's surprising how we still see posts like these in 2026 on what should be a "future-friendly" forum.
You're definitely not alone. I just checked the list of installed apps on my phone and found three different banking apps that I completely forgot about because I never use them. I installed them because I thought it would be convenient for checking things on the go, but I actually just end up using the computer whenever I need to do real banking business. The only finance-related app I use with any regularity is Venmo for e.g. paying back a friend for covering dinner.
Another commenter mentioned needing to get alerts for fraud, but none of the financial institutions i'm currently doing business with have any trouble sending me text messages. In fact I have the opposite problem, I can't get them to stop using text for 2FA codes...
It is in the specific case that you don't have biometric or PIN login set up on the device and you use a password manager that doesn't require authentication. In that case, the only factor is "something you have". Otherwise, it is still a multi-factor authentication because the device itself still represents "something you have", and your device unlock represents "something you know" or "something you are".
The "app" is probably a web page written in JS. Rarely its a native app in either Kotlin or Swift but then you have to maintain 2 different apps in 2 different languages with 2 different OSes for the devs. So unless the app really specifically requires something special, its just a web page. Even (and especially) your banking app.
I would stop using bank requiring phone app to do banking, simple as that, both my main EU accounts use sms verification codes and extra password, which is fine with me. If they will require an app, they will lose customer.
I haven't had issues with the mobile apps of 3 of the most major US brokerages. They run fine on rooted phone. They do everything I'd want a bank to do anyway.
Ditch your bank if they have issues. If their retention department asks why you're leaving, tell them their app doesn't work.
This is what I was thinking as well, TBH. I'm not particularly tied to any of my banks, I already did mostly switch off of BoA because their website was so bad.
Good to hear everyone's responses in the thread though, some stuff I definitely didn't consider.
No. The "banking app doesn't work" argument against non-corporate mobile OS, raised incessantly is HN comments, is bogus
I want a "phone", i.e., small form factor computer, that can run something like NetBSD, or Linux. But I have no intention of using it for commercial transactions. Mobile banking is not why I want to run a non-corporate OS
I want to use it for recreation, research and experimentation
NB. I have more than one "phone". The choice is not corporate mobile OS versus non-corporate mobile OS, i.e., "either-or". I can use both, each for specific purposes
> I want a "phone", i.e., small form factor computer, that can run something like NetBSD, or Linux. But I have no intention of using it for commercial transactions. Mobile banking is not why I want to run a non-corporate OS
> I want to use it for recreation, research and experimentation
I am a firm believer that phones are personal computers and should have all the end user freedom we have come to expect from personal computers. I am totally behind what your saying. (The amount of irrational anger that wells up in me when I hear someone make the argument that phones are somehow not general purpose personal computers and shouldn't provider their owners software freedom would astound you.)
Personally, I opt out of services that require the use of phone "apps" and any potential attestation they provide. Unfortunately, I just offload those needs onto my wife and her iPhone.
Want to go to a concert in a TicketMaster venue? You have to have a phone. Pay to park in some places requires a phone. Mobile ordering for some restaurants requires a phone.
I don't think it should be this way, but it is. I think we need consumer regulation to insure software freedom on phones and curtail awful user hostile "features" like remote attestation.
Until that happens (if it ever does) there is a realpolitik with needing corporate phones for some activities that can't be denied.
"There are venues that provide tickets exclusively via mobile applications, for instance."
Turns out Ticketmaster still has ticket printing machines at such venues
Was at a game at one of them, claimed I had a problem with the app and after some negotiation at the ticket window a millennial printed me a ticket
Why do they still have the printers
The "I'm having a problem with the app" strategy can work in other contexts too. The phone can be configured so that a young person trying to help gives up
"Modern" software is highly fallible and everyone knows it
When people have problems using apps, alternatives are often available
Perhaps this is why, e.g., venues that "require" apps still have ticket printing machines and still print tickets when there are problems with using the apps
The situation is not so "cut and dried" that no one ever attends an event at these venues using printed tickets instead of displaying the ticket on the phones they bring to the event
There are alternatives to apps that are sometimes used, e.g., when customers have problems, even when businesses try to "require" apps
As such, businesses do not always succeed in collecting the same amount of data from every customer
This is not to say customers who try to avoid unnecessary data collection always succeed, either
Generally, trying is a prequisite to succeeding
If most customers do not try it does not mean no customer succeeds. There are some who do, at least some of the time
Ticketmaster is it's own particular problem that needs to be dealt with, even if it is emblematic of a bigger issue with companies demanding users to run proprietary software.
I have recent (October and November, 2025-- venues in Indianapolis, IN and Cincinnati, OH) personal experience with this. With one venue I was able to play the "confused old man" card (via phone) and get the box office to print my tickets and hold them at will call.
At another venue I called prior to my show and tried the same tactic. They told me flat out "no phone, no admittance, tough luck for you" and cited the warnings and terms on the Ticketmaster website that I'd already agreed-to. I didn't want to chance losing out on $300 of tickets I bought so I knuckled under and loaded the Ticketmaster app on my wife's iPhone.
I don't think it's as cut-and-dried as you say it is, and I don't have the stomach to risk being denied access to events I bought tickets for-- particularly at the pricing levels of today's shows.
Well fuck those venues. It's a small percentage. I've never run into one and I live in LA, a city with hundreds if not thousands of venues.
So you only get 98% of the world instead of 100%. That 98% is far more than the the 100% of 10 years ago. Everyone wants perfection when they've already got abundance.
It has been reported that Ticketmaster has exclusive agreements with 70-80% of US venues. It's great that you have all the choices you do. For me, in western Ohio, every major venue for hundreds of miles in every direction is an exclusive Ticketmaster venue. You can't gain admittance to any show in those venues without a phone that can run their proprietary app.
Ticketmaster is bullshit, for sure, but they're just one example of the problem of being forced to use proprietary user-hostile software.
> So the world should cared to your needs when literally almost every adult has a phone even in third world countries?
The assumption that everyone has a "smart phone" running locked-down Android or iOS is unreasonable. Just as race, sex, religion, national origin, etc, are protected classes, the "phoneless" should be a protected class. Denying people who choose not to use a locked down phone basic interaction with your business should be legally equivalent to posting a "No blacks allowed" sign on your door, and the consequences should be the same.
> Also see: no I’m not going to waste development time di you can get to a website I develop with JS disabled or so you can use lynx
I don't see what this non-sequitur has to do with the exchange. I didn't bring anything up about Javascript.
Oh please, really? As a Black guy whose still living parents grew up in the segregated South. Comparing not being able to use a Linux phone to segregation is really taking it too far. You have not a single clue what it was like growing up in the Jim Crow South.
He's referring to his activity ON THE DEVICE. We know you can't stop the location tracking from the carrier. But that doesn't mean give up on everything else.
Worrying about random app tracking you - which is a boogeyman in and of itself on iOS - and nog worrying about the government tracking you is like being concerned about a mosquito bite when you have a bullet hole.
> I know banking apps are the typical example, but I've always wondered why
My bank uses the app for 2FA, and that became a sort of a standard in Brazil, AFAIK. Mine at least gave me the option of using an RSA SecurID or sth alike when I asked, but I don't know how much it would cost me.
My stock broker on the other hand does 2FA exclusively on mobile (and only Android and iOS). The same for the health insurer.
My car insurer didn't force me to so far, which I find strange, given their interest in tracking my location and speed.
These were some of the major factors leading me to give up on using a feature phone when I tried, a few years ago. It was a good experience, especially at those times of pandemics and political instability, but the inconveniences were many.
My main bank is Commonwealth aka CBA (one of the "big 4" banks here in Australia). For a long time, I held out against installing their mobile app (on Android), and managed fine with their web UI (and with 2FA codes via SMS). Then, 2 or 3 years ago, I needed to start using PayID (sort-of Australia's version of Venmo, ie free instant transfers, except it's supported directly by all the major banks here). And I discovered that CBA had (deliberately?) only added PayID support to their mobile app, you absolutely can't use it in their web UI (last I checked). So I had to finally relent and install the mobile app. I started out only opening it on the rare occasions when I needed to send money to someone via PayID.
Then, a while later, CBA pretty much phased out SMS-based 2FA (or they said that if you had the mobile app installed then you can no longer use it?). Only other supported option is in-app 2FA (no support for third-party TOTP apps). So I had to start opening the mobile app every time I needed a 2FA code. Then, within the last year or so, they made a new rule, that in order to log in to the web UI at all (just initial login, I'm not talking about sending money or any other high-risk action), you had to receive a push notification via the mobile app and tap "allow". So now I literally can't log in to the web UI without also logging in to the mobile app!
So, unfortunately, "just keep using the bank's website on desktop" is increasingly and deliberately becoming not an option. I assume there are many similar stories with other banks around the world.
I paid someone via payid via the web ui. Was via an email address. It was a while ago though and haven't used it since.
Also I've never used the app since the blocked rooted devices, magisk stopped working (cause of safetnet) and moved back to sms "security". I just logged in then without having to enter a code.
I do note you need to allow browser fingerprinting to allow the login to work. Otherwise it's some generic error.
I've made a lot of noise about it so maybe they've "unblocked" me to shut me up. Email the CEO so it registers a complaint. Make some noise.
Definitely have another bank though as you can't just depend on one.
So, leaving aside the discussion about whether someone wants to use their bank's application or not, what's the bank response if their application just doesn't work in your phone? That you must purchase a new phone or be locked out of using your account?
I hope, now that the debate about our excessive reliance on American tech is on the table, that we also put limits on those essential services, like banks, imposing the usage of products from only two companies (Google or Apple) in order to operate. I think that goes at least against the spirit of the European Union.
> I hope, now that the debate about our excessive reliance on American tech is on the table
LOL, you couldn't even place a phone call in Australia without some US technology connecting the call. I should know, we setup the app that calculates your bill. That's from the US too.
Country dependent of course, but recently i observe steady push from banks to adopt mobile app. Some have webui neglected and glitchy, some openly announce sunsetting, some already killed web access only allowing app.
And this tendency will prevail as bank can collect way more data this way. Just a month ago one of banks that is often praised here sent me a letter saying “your IP activity doesn’t match your residence” (and i am not even installed their app, they pulled data from web ui usage. Imagine what happens when they get access to data mobile app can supply
Fair point - but then take national eID apps instead.
Take Denmark, for example: most banking apps use eID for login, so that problem translates 1:1. But other apps who do the same include the national school communications platform (which is pretty much mandatory for a huge chunk of the adult population, who need to look at it almost daily). Also: social security card (including health portal/doctor booking/comms), driver's license, bus pass, parking app, used-stuff-marketplace, ... eID is _everywhere_ because it's a good idea.
Sure, all of this can be done on a computer. If you're near one. Or you can have separate and physical cards, like we used to have. That still works, mostly: more and more services (eg. bus pass) are going digital-only.
Really, what we need is a top-down embrace of open-source-based platforms as being _as_ (or more) secure than the established tech giants. From governments down, organisations _should_ move away from locked-down (foreign) commercial interests.
That's true, but the notion that we're still using paper checks in 2026 is so crazy. And yet they remain the cheapest way to handle many transactions in the US financial system. Like a lot of small healthcare providers still prefer to receive paper checks from insurance companies because the electronic payment processors take a 3% fee.
Yes, it is completely insane and stupid. Direct bank-to-bank transfers require significant administrative work to set up, and may still incur bank fees. For individual consumer accounts most people can use Zelle but it's not universally available.
The best solution for this is to buy a $30 burner phone at Walmart and use it unactivated, tethered to your main de-Googled device. You can use the burner for only tasks requiring Play Integrity.
Make sure to leave one star reviews on all such apps that you run into.
Yes. However, I already carry a tethered hand-me-down quarantine phone where I install my work apps and undesirable apps like Whatsapp (for those loved friends and family that can't or won't install Signal). Carrying a third phone for "Play Integrity" starts being a bit much.
Anything movement that requires people to routinely acquire a second phone is doomed to failure (in the “this will never become a mass movement” sense)
Complain. Mine wanted that, but after complaining they offered me SMS. If not, I'd have closed my account there. At least here in Spain there are plenty of banks that don't force you to use apps. I also leave bad ratings for banking apps from time to time, and bad comments on X.
In my country there are regulations in effect too that mandate the use of MFA; however, using an application is not the only way to implement MFA, as I said, in Spain banks can use SMS, coordinate cards, etc., and they are all valid MFA methods.
I think what these laws are missing is the obligation for the service (the bank in this case) to provide a MFA device if the user doesn't have one.
In theory, it's possible to have a third party (other than Google or Apple) to provide attestation on third party hardware.
You can have a separate core and kernel to run such code. They don't have to be powerful, but they'll need to be small enough to be verified by the said provider. For most of the code that doesn't need attestation, they can be executed on normal hardware.
The provider also has to convince the regulator or banks to trust them. However, if that's solved, the user should feel no difference between pure Android and alternative platform plus attestation.
In that case a two phone approach makes sense. I was willing to try that out, to give Ubuntu Touch a trial on my main phone. This might incentivise it even further for an off-ramp of the Google/Apple duopoly.
I’m old enough to remember the days that banking apps required Internet Explorer and didn’t work on Firefox. Eventually, they were dragged kicking and screaming to support all modern browsers.
In EU/UK, some are sadly app only. I avoid those. Many others are pushing apps as a 2FA, even if you use their website. You need to insist to get another authentication system, like TAN. Some governments are also pushing mobile IDs.
The best Linux for phones, SailfishOS, has a fairly good Android compatibility layer that runs many bank apps well. But despite that, it's an uphill battle. The network effect of the duopoly is gigantic.
There's no point. Remote attestation means your device needs to be corporate owned to be trusted. Even if you had your own linux phone, it wouldn't be able to interface with institutions such as banks and governments. They trust Google's keys, not yours. This doesn't quite end free computing, it just kills it for normal people and ostracizes us hackers who insist on owning our systems.
Some banks have added their verified boot keys. I think it helps that GrapheneOS is well-known by now for great security practices (most likely more secure than all vendor phones out there).
Credit unions, at least in theory, are known for caring more about their customers. It'd be worth explicitly giving them the feedback that you use them via their website or via an app that works on an Open Source phone, and telling them that that's one reason you're a customer.
Fraud prevention. If they lock things down, they lose less money to fraud. I think they should just have to suck it up and eat the cost but obviously they don't think that way. Only a small minority even understands and cares about these issues. The money they save by trampling over our freedom is no doubt much higher than the value brought in by us. They will no doubt sacrifice us for increased profits if we force the issue. We have no leverage.
There is no reason whatsoever for a major corporation to not use remote attestation technology. Banks will use it because fraud. Streaming services will use it because piracy. Messaging services will use it because spam, bots. If you're the corporation, the user is your enemy and you want to protect yourself from him.
Governments want this too. Encryption. Anonymity. They need to control it all. Free computers are too subversive for them. They cannot tolerate it.
> If they lock things down, they lose less money to fraud.
[Citation Needed]
I see this kind of claim made often, but never backed up with evidence that remote attestation of consumer devices has any real-world impact on fraud. It sounds like it could be true because it would detect compromised devices, but it could just as easily be false because people with devices that don't pass are usually technically sophisticated.
I got downvoted heavily about a year ago saying we need to abandon Android and the industry needs to pivot back to just putting GNU/Linux on a phone already.
Of course, now Google is doing what Google was always going to do.
For me as a desktop linux poweruser, I find this potential transition pretty intimidating, I've never flashed a phone with a custom rom let alone switch to a completely different OS, and I am not sure if the phone can even be reset to its original OS, if things go south.
/e/OS at least has a browser based installer[0] for quite some supported phones.
I definitely recommend trying it out, installing a custom os on my phone gave me the same feeling when I first ran debian on a laptop struggling under windows (even though the performance gains aren't that apparent in my opinion).
The /e/OS installer is terrible though and often fails, even on their officially supported phones (like Fairphone). The standard recommendation in their forums is nah, just install /e/OS through the command-line.
Also, /e/OS has pretty bad security practices (shipping very old kernels, very old vendor firmware, and missing most AOSP security patches).
Also, be careful to follow the instructions really carefully. For some devices it's really easy to get the phone in a boot loop, where the only resort is to get your vendor to repair it. E.g. Fairphone 6 has downgrade protection and will become a brick if you relocked the phone when the old system's Android SPL is newer than the new system's.
I flash phones almost every other week. And tablets. I have been flashing since Androids came out. But never bricked. But maybe that is why I don't have any problems.
Lots of people brick their phones by relocking the bootloader when the Android SPL before flashing was newer than the newly flashed OS when the phone has downgrade protection (e.g. Fairphone 6). The Fairphone/e Foundation forums are pretty full of people making this mistake. Then the only solution is paying Fairphone to fix it.
"flashing" a phone is largely the same as any OTA update. There's of course always a risk of it going wrong, disk failures are always possible, but it's exceptionally hard to do so accidentally. Especially with custom ROMs where they basically never include a new bootloader, so "flashing" is no different than installing an OS on a desktop system - it's just writing to the boot partition. Which you can always do again since the bootloader is still available.
It is not 'largely the same as OTA' on phones with downgrade protection. Once you lock the device again, it's game over because the bootloader refuses to boot an older version of the OS, and you cannot unlock the phone anymore. Happens all the time in the /e/OS and Fairphone forums.
It really depends on the device. E.g. Pixel is quite hard to brick. Though they do sometimes increment the anti-rollback version:
In that case you have to be careful to not flash an older version to both slots and lock the bootloader, which is possible, because many non-Google/GrapheneOS images are often behind on security updates.
It is still largely the same, those downgrade protections apply to OTAs as well. Those anti-rollback don't brick the device, either. It might not boot to a working OS, but you can still get back to the bootloader to flash something newer. Unless you blindly lock the bootloader without testing if it boots first and the bootloader can't be unlocked again I guess, but that's quite a sequence of bad choices all around
It is still largely the same, those downgrade protections apply to OTAs as well.
But the Android SPL versions of OTA updates from Android vendors monotonically increase.
It might not boot to a working OS, but you can still get back to the bootloader to flash something newer. Unless you blindly lock the bootloader without testing if it boots first and the bootloader can't be unlocked again I guess,
This is false. As long as the boot loader is unlocked, many phones will boot the downgraded image fine. It stops booting it when you lock the boot loader and on many phones, you cannot unlock it again. You need to boot the OS to enable OEM unlocking again, but you cannot boot the OS because the bootloader refuses to.
The Fairphone community is full of people who though 'oh it boots, so I can lock', locked it and they were in a boot loop and had to send their phone to Fairphone to get it repaired for 60-70 Euro (I don't remember the exact price, but that is the ballpark).
There is an adb command that can fairly reliably detect whether the boot loader can be locked. But I'm not going to post it here, because people have to read the full flashing manual, plus in the past there was a bug where the anti-rollback would trigger even with a newer SPL.
At any rate, flashing is not for most people and it was much easier when there was no rollback protection. Of course, rollback protection does make phones much more secure.
---
I wonder if your experience is based on Pixel or older/other Android devices that do not have rollback protection.
> Are you seriously implying that flashing phones doesn’t risk bricking them or you’re not aware of that risk are you serious?
Yes, that is generally the case. As a general rule with an Android phone reflashing the OS itself or the bootloader carries no risk of bricking the device (meaning making it impossible to recover without specialized hardware and/or opening up parts that were not intended to be opened).
There are plenty of ways to "soft-brick" a device such that you might need to plug it in to a computer, and adb/fastboot can definitely be a pain in the ass to use (especially on Windows), but if you have a device with an unlocked bootloader it's very rare to be able to actually brick the device while doing normal things.
Now, if you're doing abnormal things like reflashing the radio firmware you can absolutely brick some devices there, but you don't have to do that just to boot an alternative OS and generally shouldn't be doing it without very good reason and specific knowledge of exactly what you're doing.
I'm not going to say there are no devices where the standard process to flash an alternative OS is dangerous, but none of the relatively common ones I've ever owned or used have been built that way because OEMs don't want their own official firmware updates to be dangerous either.
tl;dr: It is sometimes possible to brick a device by flashing the wrong thing incorrectly, but the risk of doing that if you are just installing an alternative OS through a standard process is basically zero.
The challenge I've found when looking for instructions for flashing one of my old phones is the assumption of knowledge some rom builders have, or perhaps an assumption about their audience. This seems like it has the potential to bit someone in the ass because if they're relying on other sources like the lineageOS wiki or forum posts elsewhere for example there's no guarantee it'll stay available, complete, or relevant to their variant over time. It's an added burden for what is a gracious volunteer role, but it's a handicap if they want more people using the fruits of their labor.
I can't be bothered to change my phone's default ringtone and yet I've had very little issue installing LineageOS and GrapheneOS on the various phones I've owned over the years.
Expecting Google to give up control of one of the only alternative operating systems is right up there with believing in the tooth fairy.
What you're saying should happen, but it will only happen when the government legislates it happens; which frankly they should be doing (along with nationalizing a few other software projects to be fair).
A trillion dollar transnational corporation with massive monopolistic tendencies will never ever do the right thing. Expect to force feed it down their throats.
In general, governments seem to be much more invested in making it illegal to have anything that is too open and too free. Even EU is lusting for draconian control features like chat control where you don't own and operate the software you installed on your device even if, at the same timem, they're trying to gnaw on the influence of Big Tech.
> Even EU is lusting for draconian control features
Even the EU??? Huh? Did you misspell 'especially' there? Because when your governments want to spy on your own citizens more than the big tech companies want to collect data for advertising, you probably have a problem.
In the 90s, you would have said the exact same thing about linux on the PC.
Free software ultimately has time on its side. As long as a project has enough mindshare to keep its momentum, it really is unstoppable in the long run.
Where Linux shines is the absolute for-profit cloud/server world.
Open source has places where it works really nice, bazaar is better at "wider" stuff (having an active community, etc), while cathedral is more deeper/better at vertical integration, etc.
I don't care about specs, I care about functionality and price. The camera on the pinephone doesn't practically work because it is too slow and the quality sucks. You basicially cannot record videos whatsoever. I can't use the device for GPS navigation. I can run whatsapp within waydroid, but it isn't practical due to the battery life and startup limitations that imposes. The GPU on the pinephone sucks, is underpowered, doesn't support OpenGL ES 3 or vulkan, and the user interface is always slow as hell to navigate.
So practically I cannot use it as a daily driver.
Librem 5 does have enough GPU horsepower, a functioning camera, and good pmOS support. But $800 is a lot to ask to test out switching to linux with no guarantee that my workflow will work or I will have enough battery life. It looks like the librem 5 can't record videos or do GPS navigation yet.
I am looking at the librem 5 specs again. The EG25-G is probably a better starting point for the modem now that it has been better documented and reverse engineered as a result of the pinephone project. It is interesting that the L5 has a generic smartcard reader though.
Adoption would mean that orgs like the European Payment Initiative behind Wero would adopt Linux phones even other AOSP ROMs. Not seeing that. Banks and streaming platforms that require DRM are keeping most (non-activist type) users locked in.
It may push a minority of users who really care about open source to Linux phones. I expect the majority of users will grumble but cave and re-adopt mainstream Android or Apple.
Even if you have linux, there are still third parties that have control over your hardware. Even if you're using graphenos, you can't block the sim or the cellular radio stack, and likely other modules on the SoC, from at-will access to every sensor on the device. You can at least protect your files, unless there's a mitm or other vector that graphenos can't cope with. And at worst, they can simply clone all your encrypted bits and wait on Moore's law or sufficient cubits to go back and crack the copy, on the off chance there's anything they want with your data in the first place.
What a lame and useless doomer POV. Do you refuse to go outside because a lightning strike could kill you at any instant? Why let things that aren't in your control (yet) stop you from taking control of the things you can now?
If it's got a sim card, it's still phoning home and providing location data. You can't escape the panopticon. A faraday bag gets you mostly there, though, but the point isn't that you can maneuver against it, it's that the device and its operation is fundamentally compromised by design.
There's a whole lot of shady crap underlying the infrastructure and the hardware that consumers cannot touch, pinephone / librephone or otherwise. It's not designed for consent. At best you can gain ephemeral relief, but even that is illusory, because by simple process of elimination, differential analysis allows fine grained ID and tracking of people even if they don't have accounts, phones, interact with websites, etc.
It's not a shady cabal of lizard people, it's just the grubby natural alignment of interests by a wide ranging set of companies and regulators and groups who allow it to happen without imposing any accountability, and ensuring that the system remains structured such that no effective accountability can be imposed.
Extorting constant streams of data for adtech is too valuable and the entire thing is too complex for silly things like ethics to interfere.
For sure - and you can use WiFi only, set yourself up with a HaLow rig and give yourself a ~10mbps connection anywhere up to 10 miles from your home, suitable for voip and low rate streaming, throw in VPN, and remain completely off-net as far as cellular networks go. I'm actually planning on using a wireless touchscreen and mobile halow/raspberry pi network/storage stack to completely replace my phone, but the bigger issue is automated tracking of everything - if you're the only blank spot in a sea of known individuals, it's just a matter of seconds to id you, since everything everywhere about everyone is tracked online.
We should be enforcing informed consent regulation of network infrastructure, treating privacy and anonymity as synonymous with liberty and freedom. Allowing the system to operate as it does is a choice; those with lots of money get to make it grow by exploiting a constant invasion of privacy with no concurrent return to the society being exploited.
Phones aren't built to be privacy respecting, and kill switches are a mitigation of a symptom, they don't do anything to address the disease.
The impact is a direct threat to independent AOSP distributions like Murena's e/OS/ (which I'm personally using).
I don't think this is true, right? An AOSP build can just decide to still allow installing arbitrary APKs. Also see this post from the GrapheneOS team:
You can’t really do that long-term as Google will change code that will not match however you are not enforcing this policy
So at the very least you’d have to keep patches up to date.
Long term divergence could be enough that’s it’s just a hard fork and/or Google changes so much that the maintainer can’t keep the patches working at the same pace
I couldn’t read your link as it asks to join mastodon.social
But that just sounds the big community demanding this has to put together a proper KDE-like team to maintain Android in the way they want instead of waiting on Google's code?
The enforcement mechanism is in Google Play Services, not AOSP. To laypeople the difference doesn't matter but to folks looking for alternatives it does, so the discussion is often muddied and imprecise. This is like when YouTube removed public dislike counts and it turned into "they're removing the dislike button!"
There is an implicit shame in disgrace but faceless entities have no shame. They'll just put out another press release written in corporate newspeak by an LLM and move on withe the plans anyway. This is standard Google behaviour. They do it with Chrome, they do it with Android, they'll keep doing it with all their captive markets. I fear that in practice even having an "advanced flow" will make little difference as some applications will refuse to work if you have it enabled anyway (in the same vein if debugging is enabled, for example).
Nothing about Android is open except the absolutely minimum amount of linux kernel that's required to boot the thing. Then it's blobs and restrictions all the way to the screen.
Good thing restricting side-loading isn't legal in the European Union! Not a problem here. Apple had to enable side-loading on their EU-based phones and so will Google if they restrict it.
Yes it is, and no they didn't. Apple has to allow (heavily restricted) alternative app stores, and I'm not clear on whether any actually exist right now.
What Apple restricts and is legal are not the same. Apple is doing malicious compliance and the legal system ain't buying it. But it takes some time and iterations to shake out.
They have moved much faster on much more complex plans though. If this is a case of Apple breaking the law then surely they wouldn't need over two years to tell them to stop it? The EU regulations seem largely to be, you need to do X and you need to figure out how to comply by Y date. They aren't gently guiding these corporations to compliance.
So I'm leaning more towards Apple is in compliance and the common perception is incorrect. Which is fairly common when it comes to laws and regulations of any country.
The kind of "side-loading" of notarized apps outside the manufacturer's app store that Apple allows in the EU is exactly what Google proposed to do for all its Android builds. We don't want that.
If a lawsuit tackles this problem in the EU, will we finally also see somebody go after MS for their obnoxious code signing certificates?
While MS code signing certs are more circumventable for power-users than Android's new approved developer program, their pricing is far more prohibitive for independent OSS developers and hobbyists, costing hundreds of USD per year.
Good news: You (as a community) can now finally wake up from your dreams and get some things right!
It's really a shame that you always wait until you really get forced. Particularly in situations when every individual's inability has consequences for the others as well. I really gave up all ideas of a better world. With this community, the best you can hope is that the decay will be slow.
So everyone who would describe himself/herself as a FOSS enthusiast, or at least a friend of a somewhat open system where the user has some actual rights beyond sole consumption, put some pressure towards having actually de-Googled systems. A system that mostly comes from Google, would not fit my definition of that term at all! Even if they removed some parts of it. It's an euphemism. And it's dangerous because you constantly get trapped by these euphemisms. Ever. Single. F'ing. Time.
The only reason I was sticking to Android for years is this. And I think there is no moat for Android. I would rather switch to iOS if both platforms are same restrictive.
I did this last year. Reluctantly. And using iOS still hurts. But it’s better than that Google crap.
I developed my own Android ROMs from 2009-2011, complete with my own tuned kernel. I ran the local Android developers MeetUp group and evangelised Android development. When Honeycomb launched I helped OEMs test their beta firmware. For free.
But as Google has become certified Evil, the direction of Android has been very clear. In practice I honestly can’t say it’s now any more open than iOS. Except it has a lot more avenues for Google to mine your data to sell ads. And the quality of third party apps on it is decidedly worse.
I thought long and hard about getting a Linux phone. But I need a good camera on my phone to take random snaps of kids/pets/etc. And the Linux phones just aren’t there.
I hate the shitty duopoly we have ended up with. But I now realise that the openness of x86 and pc as platform really was an accident of history.
Why does there seem to be a growing push to tie real-world identity to nearly everything we do online? The justification is almost always "safety". I know this trend has been developing for years, but over the past couple of years it feels like it's accelerated globally.
I think people in power have realized the impact of misinformation campaigns. And to be fair, western countries have proved to have the resilience of a wet paper bag against foreign influence and private interests.
I honestly can’t imagine a good solution here. A move back to the early 2000s internet would be the ideal middle ground, which requires separating social stuff from informational stuff, and both from engagement algorithms. I have no idea how we’re supposed to put that genie back in the bottle.
And to be clear I’m not saying this as vouching for the current push, I hate it as well.
Yeah, propaganda works, and the US wants to stop foreign propaganda, but the problem is they still want to push their own brand of US biased propaganda so they can't put in any sort of useful journalistic standards requirements upon media conglomerates or it will tie their own efforts up in court and lawsuits.
Yes, misinformation is a problem. Deanonymization is a bigger problem. If you can't say anything anonymously, it becomes much more difficult to fight entities bigger and more powerful than you.
I agree, but that isn’t a good argument to offer to the entities bigger and more powerful than me.
Governments and companies feel a pressing threat of a trump-like populist overtake in each country. They need the bots, fake socials and slop stopped yesterday. An abstract degradation of freedom of speech isn’t going to cause pause.
There is a national security argument that I think is more likely to help, at least for non Americans. Do you want a foreign power to have control over your citizens phones being functional?
The irony in this line of thought is that by stifling anonymous speech and enabling censorship, countries will usher in their own reactionary movements as dark money is globally spent on platforms to push paid advertising advancing reactionary rhetoric. It's already happening in the UK, Germany, France and Spain.
Right-wing populism isn't what's being banned here, it's dissent. Platforms are happy to take domestic and foreign fascists' money and push their agendas no matter where they are globally because it benefits them, too. Those paid placements aren't being banned, your ability to disagree with them and not be identified is.
That’s a very good point, it’s another hole in the sieve.
This “fix” just routes people through official channels but those channels aren’t exactly proving to be worth the term walled garden. My YouTube adverts lately border the quality of early 2000s piracy sites, it’s honestly baffling how little they value their own product in their willingness to take anyone’s money.
I think one major issue is the shortening of people's attention spans. People consume snippets of information that show a tiny fraction of the full story. They don't spend 10 minutes reading an article or watching a video, with a few exceptions. More people probably watch clips of Jon Stewart than actually watch his show. I think we ought to start addressing that issue, and see how it affects the efficacy of misinformation campaigns.
Strong disagree. Linux, its permission system and its (barely existent) application isolation are lightyears away from the security guarantees that Android brings.
Desktop OSes and their derivatives are woefully behind in this regard, and unfortunately the will to bring them up to par is incredibly weak. Of those in mass use (Qubes OS is neat but its user base isn’t even a rounding error), macOS probably does the most, but it’s still lagging behind iOS and what’s been implemented has come with much consternation from the technically inclined peanut gallery.
I understand some amount of reticence with commercial OSes, but there’s no justification for being against it on open Linux based desktops and mobile OSes. We really need to get past the 90s-minded paradigm of everything having access to everything else all the time with the only (scantly) meaningful safeguards coming in the form of *nix user permissions.
> We really need to get past the 90s-minded paradigm of everything having access to everything else all the time
I do agree with that, and I strongly believe that the iOS and Android security model is way ahead of Desktop Linux. But what I observe is that nobody seems to care about the security model. A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.
But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical.
As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you will be running untrusted applications as one: on the contrary, if you assume an administrator role and run an untrusted application, naturally, all bets are off. But even as a power user, I'd love to be able to safely run programs I do not necessarily trust, feeding it only data it needs and no more.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.
What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc.
Sandboxing also protects against external attacks.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them.
The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).
I think you are mistaken. Just like neither Windows nor MacOS have really solved the desktop app sandboxing story, so neither has Linux.
Because, as I said in a sibling comment and cosmic_cheese notes further below, this requires rethinking the usage model altogether: files and folders, and even file types, don't work anymore.
If an app needs to access any related files, it basically needs access to my entire $HOME, and once that is granted, well, any sandboxing is out the window.
I think Linux community is well aware of that, and basically what we get from sandboxing of desktop apps is all the nuisance with no benefit.
Android model is also broken from a usage perspective: having files "owned" by an app is just as wrong, and precludes there being multiple apps operating on the same file. Example of VLC with subtitles is a common one, but if you've never used multiple apps on the same file, this is the challenge that is unsolved by any sandboxing approach today, because it is more of a UX problem, than a sandboxing technical problem.
I don't fully agree with cosmic_cheese's comment. If we take music as an example, you could put your music in a Music folder and open that folder using your music player/manager and that folder gets added to your sandbox. This is how macOS sandboxing works and it works fine. Moreover, you can protect certain directories by default, even for unsandboxed apps, as e.g. macOS does, where a random app that is not sandboxed cannot read your Mail, address book, documents folder, etc. unless you allow this.
All these things make security substantially better than the Linux model of every app gets access to your full home directory.
Sure, a capabilities-based OS or whatnot would work better, but would even be harder to implement in the current desktop Linux. Instead of gradually improving security, you are basically throwing away the baby with the bathwater.
You get exactly that with snaps/flatpaks which are not given access to your $HOME.
But even with your example, you might need access to cover art from your graphics editing app, and very quickly you get to the same state. How about lyrics file from your text editor or a dedicated one? And wait, I'd like to mix in some music into Audacity too. File portals are actually a decent solution there, but they only work for files with supported software.
Yes, you can adapt your workflow, but it's going to be adapting and you will lose some things you might love in your workflow.
> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside.
The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)
So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?
Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.
I think had the problem is that the toolbox we can deploy to solve these problems is so empty.
For example, it’s useful for a music player with metadata editing features to have read/write access to the whole filesystem, but that constitutes a significant risk since all we can do is wholesale allow or prevent access to the whole filesystem. What if the system could allow it to access only music files, though? That’d scope the risk back down to almost nothing while also allowing the music player to do its job.
This is the kind of thing I’ve been getting at in the other replies. Nobody has really sat down and given system level security controls a deep rethink.
I think Apple's implementation in macOS is the only one that offers some slightly more advanced features, but even those don't get you that far
(Some sort of way to store permission references with relatives paths in a file, but which most probably wouldn't work with files being exchanged cross-platform, and other than that mainly being able to get automatic access to 'related' files, i.e. same file name, but a differing extension – that solves some sidecar files, like video subtitles, or certain kinds of georeferenced images, but large capability gaps still remain – even the video subtitle example stops working if the file name is no longer 100 % the same, like if you have multiple subtitle files for differing languages, where VLC for example supports prefix-matching the video file name with the subtitle files.)
And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
> And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
I could very well be wrong, but my inclination is that it's possible, but it's going to take the sort of fundamentals R&D that desktop operating systems haven't seen in decades. It can't just be tacked on, everything to be designed with this new system in mind.
Agreed. I want to "own my device" as in "being able to install the system I want on it". Not as in "I want it to behave exactly like Desktop Linux", or whatever it is that people complain about AOSP.
On my Desktop I love Linux. But on my smartphone, I want AOSP.
Largely agreed, though I think on the desktop I’d also want AOSP in desktop mode with a traditional Linux distribution in a VM pretty much like Android 16’s Linux VM.
But then on desktop/laptop-class hardware, since the thermal constraints are different and it’s nice to have extensible storage and RAM. Of course, all this on the phone is also nice for when you only have your phone with you.
Then one could use fully sandboxed apps for banks, instant messaging, etc. and the VM for development.
Yes I can totally imagine that in a few years, most people will only need a smartphone and a dock station. At home, they will plug their phone (iOS, Android, whatever) to their dock station and it will behave as a Desktop. And it will be good enough for everything they do.
Allowing the owner of the device root access doesn't necessarily break the security model. It just means that the user can grant additional privileges to specific apps the owner has decided to trust. Every other app still has to abide by the restrictions.
The fact that Android complains and tells any app that asks whether the owner actually, you know, owns the device they paid for is an implementation detail.
A Linux distribution that adopts an Android style security model could easily still provide the owner root access while locking down less trusted apps in such a way that the apps can't know or care whether the device is rooted.
IMHO, I should be able install the OS I want on the hardware I paid for. What should be illegal is to technically prevent me from installing a different OS, because I paid for that hardware and I should own it.
But that does not mean that all OSes should be open source. I think it's fine for iOS to be proprietary, but there should be enough information for someone to write an entire alternative OS that runs on iPhone. I think it should be illegal to prevent that (is it called tivoisation?).
All that to say, I don't believe that having root on my Android system is a right. But being able to install a system that gives me root should be one. If that system exists, that is.
> A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".
I want to be able to do what I want with my PC or phone. I don't want every app on my PC or phone to be able to do whatever they want, without me agreeing first.
I want to be able to install what I want on the hardware I own. And I should be able to leverage the hardware to its full capacity. Preventing me from adding custom keys and relocking the bootloader should be forbidden, because I own that hardware.
But that does not mean that I should be able to do whatever I want with any OS I install. If I am not happy with Android, I can install LineageOS and modify it the way I want.
I am obviously not a big fan of Google, but I do believe that AOSP is actually a good deal (a lot better than iOS which is proprietary). Google is doing a lot of work on AOSP. That I cannot unlock/relock the bootloader on some devices is not Google's fault.
It's important to keep separate the parts of the security model mobile did well from the parts it got wrong. Declaring that app developers can decline end user access to app files is unacceptable. I get final say on my device. I get to run as root. Hell, I get to run as ring 0 if that's what I want to do.
IMO, the developers choose what software they want to write. If Microsoft Word decided to remove the "export to PDF" feature, that would be their right. And it would be your right to stop using Microsoft Word. If you want to be root on your system, you are free to install a system that gives you root access.
And that's the part that I believe should be a right: if you buy a smartphone, you own that piece of hardware, and you should be able to install the system you want. But if you are not the one developing that system, you don't get to decide what this system does. Just like you don't get to decide whether Microsoft Word can export to PDF or not.
You're saying that the Android security model shouldn't be illegal. I agree.
I'm saying that despite all they get right, the Android and Apple security models, when foisted on the mass market, are socially and ethically flawed. I'm saying that the end user has a fundamental right to tamper with the software on his own system. Those designing an OS that intentionally thwarts the user's will are in the wrong.
Just because something is legal that doesn't mean doing it is a good thing.
I may be biased, but I have never seen anyone who would want to tamper with the software on their own system and would not be capable of installing an alternative OS, given that their device allows it (e.g. allowing unlocking the bootloader, etc).
For "normies", it feels like the existing security model is actually not that bad. I can't imagine what would happen if everybody was running something without any sandboxing.
You have to install a different OS in advance though. Even when the bootloader can be unlocked doing so wipes all the data (as it should). It's no help if you start with a stock phone and then later discover that a particular app you've been using doesn't support data export (for example).
> I can't imagine what would happen if everybody was running something without any sandboxing.
I don't think anyone implied that? Having root or signature spoofing or even the ability to install kernel modules doesn't imply anything about the rest of the security model.
I guess my point is that it is a bit of a gradient. You say you want Stock Android to allow you to get root access, others will say that Stock Android should not allow a normie to be tricked into getting root access and shooting themselves in the foot. Truth is, none of those is a "right": there is a product (Android) that tries to do well for the vast majority of its users. It seems totally reasonable to me that Google doesn't want to invest a lot of resources into making an extremely small minority happy. I am pretty sure that the number of people who want root on their smartphone is a rounding error.
Second thing is: if you have root and change something on the system, you break the secure boot. So you fundamentally cannot have full access, can you?
That's why my opinion is that it's not Google's role to make everyone happy. They should just not be allowed to prevent alternatives. So that the rounding error minority can install the system they want and be happy with it.
Do you have any source for that claim? That would be a pretty serious security issue even unrelated to any security hardening (eg. on a multi-user system, one user could read out the password from another user — even with desktop usage, second user could be SSHed in).
As a datapoint, everything in /dev/input/* is owned by root:input on my Debian Bookworm install, and my main user is not a member of the "input" group either.
Biggest problem with most security hardening for Linux desktop is that it breaks the natural usage pattern: I store my files by their content, not by their format (eg. I might have a folder for my project containing image files, spreadsheets, FreeCAD files, maybe even some code or TeX/ODF files). If programs are restricted to access the entirety of my $HOME though, there is not much benefit to that protection since that's where my most valuable data is. If they are restricted to per-program folder, I need to start organizing my data differently and unnaturally.
Android mostly does not use the "files" metaphor and basically does exactly that (per-app data): coming up with a security model and file management UX that does both is where the challenge is.
It's the same reason I choose to keep my front door unlocked basically all the time - I know my neighborhood, the risk is really low and the convenience is high.
Further... practically everyone agrees that they don't need bank vaults as front doors. It makes zero practical sense: The cost is incredibly high, and the convenience is very low.
There are ALL sorts of wonderfully cool things you can do on a system where applications are allowed to trust each other, and the system is permissive by default.
You can customize behavior more easily, you can extend software more easily, you can add incredibly detailed & functional accessibility support, you can create incredibly powerful macros and commands.
This is so important that fundamental OS design from the early 90s actually prioritized and catered to exactly this style of open, trusted, platform (ex - all of COM in windows...). This is what made personal computing a reality...
All of those fall flat when you try to impose "well funded" security efforts.
Those efforts have a place, in the same way that bank vaults have a place. Whether that place is a personal computer is a different question.
Implying those folks are hostile for no reason is... at best a woeful misunderstanding of the situation, and at worst a malicious mischaracterization.
Flatpak and Snaps are built to solve this. They do conflict with some expectations from users to be able to play around with things, though, so they do not have the penetration one might want.
They only cover the user-facing app part of the story. The rest of the system needs isolation and safeguards, too, including things like the desktop environment and whatever random daemon.
A solution that's integral to the system and not just loosely taped on is required.
Docker style containerization technically works, but for desktop use I think is a rather heavy kludge and not really a solution.
It would be much more nice if e.g. daemons could have their privileges pared down to only exactly what they need to function and nothing more with a config file somewhere. This can somewhat be achieved with the user system, but that really doesn’t scale well and doesn’t suit the purpose all that well in some ways.
Letting everything I install have access to everything is the core feature I want out of a platform. If I can't have that might as well just use android
This might be a strange take in these times, but I feel like the browser largely solved the "I need to run potentially adversarial application code in a sandbox". For native applications, stick to stuff that's vetted and in well-maintained repositories, or well-known open source projects that you trust. All of this technical work just to be able to run hostile native code ignores that you don't have to, and probably shouldn't want to, run sketchy code on your device. Installing random untrusted software is bad, even with the most advanced security model in the world. At the very least it will probably abuse whatever permissions it has to spy on you to any degree it can (which is a lot, even for web pages) and to send you advertising notifications.
This assumes that the mentioned systems are the only security considerations on a Linux system. Clearly this is not the case so I am unsure why you omit other security-related aspects of Linux here.
Android, being based upon the Linux kernel, has all those and its own app permission system built on top. Linux on its own comes nowhere close to this.
The security of Android doesn't mean much to me as long as the front door is left open by design for Google, and therefore the government, to directly spy on you.
I.. don't think it will happen. For several reasons too. It is not that I don't think Android will change substantially, but the following constraints suggest a different trajectory:
- AI boom or bust will affect hardware availability
- there is a push on its way to revamp phones into 'what comes next' -- see various versions of the same product that listens to you ( earing, ring, necklace )
- small LLMs allow for minimal hardware requirements for some tasks
- anti-institutional sentiment seems to be driving some of the adoption
I understand why mobile/tablet OSs are so crappy compared to desktop; in the past these devices had no resources cpu and ram wise and had to heavily watch battery consumption (the latter is still true mostly, but that should be up to the user), but my phone is more powerful than my laptop and yet runs crap with no real usable filesystem and all kinds of other weirdness that's no longer needed.
However, I have 2 Linux phones and Linux on phones is just not there. Massive vendors (Samsung, Huawei, etc) would need to get behind it to make it go anywhere. Also so banking etc apps remain available also on those phones. We can already run android apps on Linux, Windows apps, so it would be a bright future but really it needs injections and support for large phone makers.
I hope the EU/US mess will give it somewhat of a push but I doubt it.
FWIW, Nokia did develop a pretty good Linux phone back in the day (Maemo/Meego) with Nokia N9 (it even received rave reviews from consumer tech sites like engadget), but it did get killed off as they got absorbed into Microsoft (we all know that didn't age well).
Similarly, Palm Pre, and especially HP Pre 3 was a wonderful WebOS incarnation.
Ubuntu Touch did seem like it had a future, but it was a massive sink for Canonical so it was defunded as well.
The user experience was there on all of these: the apps, not so much.
Ubuntu Touch is not dead though, I use it happily on my primary device for 8 years. It's working like a charm. And waydroid allows you to run APKs, even if some bank apps may not work.
This is one of the most naive things I see people repeat.
The reality is that we're lucky to have mostly-good things at all that align with most of our interests.
Yet people get so comfortable that they start to think mostly-good things are some sort of guarantee or natural order of the world.
Such that if only they could just kill off the thing that's mostly-good, they'll finally get something that's even better (or rather, more aligned with their interests rather than anyone else's).
In reality, mostly-good things that align with most of our interests is mostly a fluke of history, not something that was guaranteed to unfold.
Other common examples: capitalism, the internet, html/css, their favorite part of society (but they have ideas of how it could be a little better), some open-source project they actually use daily, etc.
If only there weren't Android, surely your set of ideals would win and nobody else's.
Agreed that there is a ton of baby in this bathwater.
Also, the open nature of AOSP gave Google its advantage during the early days. Since then, Google has morphed into a company that would likely not make the same decision to create an open-source OS free for others to use and contribute to.
So in the end, what we as consumers actually get, in 2026:
- Google encourages application developers to use hardware attestation to prevent themselves from running on non-blessed, third-party AOSP distributions.
- Google builds basic functionality people care about (including passkeys!) into Play Services, a closed mega-application that happens to require a Google account for most features, and is a moving target for open distributions to mimic.
- Google has closed AOSP contributions to themselves and OEM partners only. AOSP releases are now quarterly source dumps.
- OEMs which traditionally allowed bootloader unlocking (and thus actual ownership of the hardware) have removed it as a matter of policy.
So what exactly is open about Android anymore? Does "source-available OS you can see and not touch" align with your interests? Because it's increasingly not aligned with mine.
I like it, because more and more people see Google as what it is: a ruthless, selfish and extremely greedy mega-mega-corporation. The less we depend on it the better.
>The impact is a direct threat to independent AOSP distributions like Murena's e/OS/ (which I'm personally using). If installing a basic APK eventually requires a Google-verified developer ID, maintaining a truly de-Googled mobile OS becomes nearly impossible.
I have trouble understanding why this is a threat to AOSP distribution. I would have said quite the opposite actually, I don't see why they would not remove the verification and that's an incentive for people to use their project instead of Google Android.
Who could Android be possibly recommended to at this point?
I know iPhones aren't affordable for the layman in many countries. But for anyone with an option, why would you buy an Android? All the "customization" things I cared about when I was on Android are either doable on an iPhone now with better implementation, or something I don't care about.
I was a die-hard until I went through enough cycles of Google deprecating and reinventing their apps and services every year, breaking my workflow/habits, that I got sick of them and moved to Apple everything. And all the changes I've seen since then are only making me happier I got out of the ecosystem when I did. Unlimited Google Photos backups with Pixels are gone, Google Play Music is gone, the free development/distribution environment is gone, etc.
If people can't even develop for the thing without going through the Google process, they're really just a shitty iOS knockoff.
But this thread is about the option to install apps on your device regardless of OS vendor approval, and that's not possible either with iOS nor is iOS open source. And that's what this is all about. If you don't care about open-source and user freedom, then this change wouldn't matter to you anyway.
I switched back to Android in large part for KDE Connect. You can get continuity esque features that work with any desktop operating system. I also get to use real Firefox instead of a Safari wrapper. I still use as few Google services as possible, pretty much just Maps.
It "works" but it is significantly less useful. Notification mirroring doesn't work, you can't read/respond to text messages, it can't reliably run in the background.
These are all due to limitations imposed by Apple.
Regarding notifications, both iOS and android doesn't support reading and responding to text messages. The feature works on android because of a workaround: apps create a global notification listener and they can also interact with notification - read UI contents and respond.
I know it's still better than not having a workaround at all like in iOS. But just pointing out that Google probably never meant to let others access notification mirroring.
As someone who hates both android and iOS but currently has to use iOS, I definitely hate it more. It lacks so many things one can take for granted on android. Even a usable keyboard is missing from iOS.
I love the Java/Kotlin userspace, even if it is Android Java flavour, and the our way or the highway attitude to C and C++ code, instead of yet another UNIX clone with some kind of X Windows into the phone.
In the past I was also on Windows Phone, again great .NET based userspace, with some limited C++, moving into the future, not legacy OS design.
I can afford iPhones, but won't buy them for private use, as I am not sponsoring Apple tax when I think about how many people on this world hardly can afford a feature phone in first place.
However I also support their Swift/Objective-C userspace, without being yet another UNIX clone.
If the Linux phones are to be yet another OpenMoko with Gtk+, or Qt, I don't see it moving the needle in mainstream adoption.
They only share a brand and a subset of filter lists - the implementation and functionality of uBlock Origin Lite and uBlock Origin are entirely different.
When UBOL was released for Safari I switched to it from 1Blocker in hopes of getting a closer experience to the full uBlock Origin, but actually switched back after a few weeks - the filter lists in UBOL were letting through more ads than 1Blocker - and both of them are notably deficient compared to uBlock Origin in Firefox.
At this point, I wouldn't recommend Android other than enjoying the much steeper discount with the headset. For me, the only thing that is keeping me on Android is easier access to commas on the keyboard.
70 propositions from the European Alliance for Industrial Data, Edge and Cloud, written in part by yours truly (in early 2025, i.e. before the "Trump effect" was in full force) and published by the Commission in July 2025:
Here is the complete list of proposals from the roadmap, translated into English and organised by pillar.
### Pillar 1: Technological Development
- Define technical specifications as open standards for European Open Source cloud, edge and IoT environments.
- Fund interoperability pilot projects that prioritise the use of European Open Source technologies.
- Require all EU-funded digital infrastructure projects to adhere to these interoperability standards.
- Promote and enforce the implementation of open standards throughout the EU.
- Create a ‘European Open Source Sovereignty Fund’ (EOSSF) dedicated to essential projects. [NB: this would now be called the EU-STF].
- Offer targeted grants for the security, maintenance and strengthening of the sovereignty of Open Source projects.
- Foster in-depth collaboration with European academic institutions and Open Source Programme Offices (OSPOs).
- Develop a practical guide for public procurement managers to evaluate European Open Source solutions.
- Create sector-specific reference architectures based on European Open Source technologies.
- Launch large-scale demonstration projects to illustrate the practical benefits of European Open Source solutions.
- Produce and distribute comprehensive ‘playbooks’ for the deployment of European Open Source solutions.
- Implement policies to actively encourage the adoption of these reference implementations in public procurement.
### Pillar 2: Skills Development
- Organise industry-focused training workshops with a European emphasis on Open Source tools and platforms.
- Offer targeted training grants to SMEs and public sector organisations for European Open Source skills development.
- Launch certification programmes for mastery of European Open Source technologies and standards.
- Establish EU-funded retraining programmes to help professionals transition into European Open Source roles.
- Collaborate with industry partners to create hands-on learning and placement opportunities in Open Source.
- Offer financial incentives to companies that participate in retraining programmes and use European Open Source.
- Develop a European Open Source resource platform that brings together training materials, best practices, and case studies.
- Integrate European Open Source principles into STEM (Science, Technology, Engineering, and Mathematics) curricula from secondary school to university.
- Support the creation of European Open Source ‘centres of excellence’ in universities.
- Develop EU-wide coding competitions and hackathons focused on European Open Source solutions.
- Introduce training on European Open Source business models into vocational training.
- Create vocational training modules for European Open Source project management.
- Establish certification for mastery of European Open Source business skills.
### Pillar 3: Public Procurement Practices
- Launch a consultation with public sector bodies and Open Source providers to identify challenges related to public procurement.
- Make ‘Public Money, Public Code, Open Source First, European Preference’ policies mandatory in public procurement.
- Develop comprehensive guidelines for public procurement to evaluate and select European Open Source solutions.
- Fund demonstration projects showing the success of replacing proprietary systems with European Open Source.
- Establish clear criteria for defining what constitutes a ‘European’ Open Source solution.
- Provide a practical guide for public procurement managers to evaluate Open Source solutions.
- Collaborate with industry and standardisation bodies to develop accessible evaluation criteria for Open Source.
- Create a public directory of recommended European Open Source solutions.
- Encourage public sector organisations to adopt solutions developed under the Next Generation Internet (NGI) initiative.
- Launch cross-border pre-commercial procurement (PCP) projects focused on European Open Source.
- Create knowledge-sharing platforms for feedback on PCP initiatives and Open Source best practices.
- Actively involve European Open Source providers in the co-design of solutions in the PCP process.
- Publish guidelines to help public sector organisations manage and support European Open Source.
- Promote the active participation of public sector representatives in European Open Source communities.
- Support training programmes for public sector staff on project management and Open Source compliance.
- Engage stakeholders to collaboratively refine and simplify procurement practices for Open Source.
### Pillar 4: Growth and Investment
- Create a European Open Source Investment Platform (EOSIP) to centralise information on funding.
- Organise information workshops for European SMEs and start-ups on how to obtain investment.
- Establish partnerships with private investors to form a network of venture capital funds focused on European Open Source.
- Expand the Next Generation Internet (NGI) initiative with a focus on Open Source cloud, edge and IoT.
- Regularly assess the impact of funding programmes on community growth and market adoption.
- Allocate dedicated funding to high-impact European Open Source projects that meet strategic needs.
- Develop co-investment models that combine public funds with European private sector investments.
- Launch accelerators and incubators specifically designed for European Open Source technologies.
- Develop an EU-wide branding strategy to highlight the quality and sovereignty of European Open Source.
- Showcase European Open Source successes on international platforms through marketing campaigns.
- Form strategic partnerships with European industry organisations to increase project visibility.
- Establish public-private R&D consortia on European Open Source for high-priority projects.
- Offer incentives for private sector contributions to critical European Open Source initiatives.
- Develop platforms for knowledge exchange and cross-sector collaboration within the European ecosystem.
### Pillar 5: Governance
- Conduct vulnerability assessments for critical European Open Source projects.
- Collaborate with European cybersecurity agencies to develop threat models for Open Source environments.
- Publish findings and best practices from security assessments to the European ecosystem.
- Offer tailored compliance advice to help European Open Source projects navigate EU regulations.
- Facilitate accessibility to Cyber Resilience Act (CRA) certification for European Open Source projects.
- Provide resources and support for the documentation and auditing of European projects.
- Ensure stable, long-term funding for core European Open Source infrastructure.
- Establish mentoring programmes focused on developing European talent for critical projects.
- Create a European Open Source Advisory Board to oversee project funding and direction.
- Require EU-supported European projects to adhere to transparent governance and accountability practices.
- Support European community involvement in Open Source project governance.
- Facilitate community input into European Open Source policy development.
- Publish guidelines on best practices for managing the lifecycle of European Open Source projects.
- Provide resources for responsible maintenance and end-of-life support for European projects.
- Encourage comprehensive documentation and knowledge sharing within the European ecosystem.
Initiated by the city of Munich, LiMux aimed to migrate public administration systems from Windows to a Linux-based OS to increase control over IT infrastructure and reduce costs. Despite initial success (announced at LinuxTag in 2014, I was there for the announcement), the project faced intense political lobbying by Microsoft leading to a reversion to Windows.
The political climate is completely different. The US is no longer an ally but a fascist regime actively supporting far right and nazi movements in Germany. What made sense 8 years ago probably doesn’t make sense today.
(I studied schemes 10 years before, but I quit maths in 2000 so this book wouldn't have helped me. It seems like a good introduction, looking at the TOC. Grounded on actual geometry, not just category theory like other textbooks).
in reality, neither of them make any such claims. And they are not html-like - they're literally html. Especially datastar, which doesnt add any non-html-spec attributes.
Yeah, yeah, they "literally add nothing" except these small things like "custom Javascript-like DSL" (datastar), custom DSL and custom HTTP-headers (htmx).
But it's "just html", so it's all fine
Edit: Oh, don't forget that " Especially datastar, which doesnt add any non-html-spec attributes" in reality ads two custom DSLs. One in the form of HTML attribbutes, and the other in the form of a JS-like DSL:
the spec is literally just data-* (hence the name): you can add whatever you want to it and remain in spec. And they're meant to be read by javascript (like datastar)
https://github.com/abilian/p2w
NB: some preliminary results:
reply