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.
AOSP is open and is a much better starting place than anything else.
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.
There's no great reason for these to be Android/Apple specific. I'm just offering examples as requested.
Allows you to have a digital copy of your ID and sign in to government sites/services (there are alternative methods).
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.
> 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.
FWIW the default phone app on GrapheneOS supports recording phone calls.
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.(Linked from the post: https://forum.syncthing.net/t/discontinuing-syncthing-androi...)
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. :)
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?! :)
Edit: apparently the /s is obligatory on this one
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.
Rock solid. Every few year feature updates, only security fixes otherwise.
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?
Common people don't care about the OS, they care about apps.
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.
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
My bank requires me to authenticate all online transactions via the phone app. Without it, it's not possible to make online payments.
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)
What if all banks require it?
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.
It can't emulate hardware attestation though, which most bank apps now require, so good luck with that.
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).
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.
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.
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.
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.)
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.
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'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.
>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.
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...
Remote Attestation and the Play Integrity API will soon make that stop.
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.
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.
The greatest issues facing mobile computing are:
1. The lack of any open firmware
2. Locked bootloaders
3. Obnoxious security "features"
a. Security attestation that is out of the owners control.
b. One time burn out resistors when you do unlock a device.(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?
Alas, this is a rather large set of elephants nobody in power cares to acknowledge.
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.
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.
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.
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.
> Long story short: it's not something the market wants.
Who knows. Maybe this could change?
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.)
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?
That will never happen. Governments are invested in people depending on surveillance technology. Black mirrors are a tool for controlling the masses.
Say one, rather than making the entire phone modular, adds just one cartridge slot. Have it span the bottom half of the back of the phone and be a few mm deep. Cartridges can have 4 form factors. 1) flush with the back of the phone. 2) stick out from the back. 3) increase thickness of the entire phone. Or 4) like 3 but comes with the same slot as the phone so that one can stack cartridges.
The first base phone should be functional by it self but have really low specs. A slow cpu, little memory, little storage, small battery. It may even run on android and have a ton of preloaded apps no one wants. Ideally the most expensive component should be the cartridge connector.
And then, here it comes, you've already guessed it! The entire linux computer goes on the cartridge.
Have a similar dock that turns the cartridge into a desktop computer and a dock that connects it to your PC.
Software development would be glorious.
In the initial demo it should run Windows! This will send a strong signal to other otherwise uninterested parties that this is a real computer... finally...
While official builds should probably exist let other vendors go wild building their own proprietary closed source cartridges.
There should be infinite possibilities. People will make things we cant imagine. Stuff we will never see on flagship phones because 99% doesn't need it.
Some might simply but badly want usb ports.
Stupid example: I have a digital camera, I have to plug it into a computer and do all kinds of things before they may appear on my server, like booting the machine, opening apps and figuring out where the hell folders are. The pictures are great but not that much better than my phone which can conveniently send them places. But what I really need is to just plug in the camera and have the technology figure out which are the new images and upload them. It should require zero screen time.
The next guy might want an ethernet port, hdmi, serial, scan barcodes by pressing a real button that also unlocks and opens the correct app. You might even have a bulky cartridge that prints receipts. A large antenna and/or a week worth of battery. I'm not at all sure if people want it but a cassette player would be possible. A boom box with atx drive bays. etc etc
Then when you buy the next generation or are bored playing with it, the screen is cracked and the battery is worn out you turn it into a security camera that works when the power is cut and can send [picture] sms, make phone calls and play threatening messages to intruders.
I 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. )
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.
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.
... 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.
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.
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.
(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.
Settings > Apps > select the app > Storage and cache > Clear storage.
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.
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.
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.
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.
Maybe Palm Pre's had it right all along with the html/js based OS in WebOS at that time. Just a little ahead of their time for OS, and missed challenging the iPhone by a bit.
The 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.
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.
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).
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.
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 respected the rules, I would starve to death!
https://grapheneos.org/articles/attestation-compatibility-gu...
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…
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.
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.
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.
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
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...
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.
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.
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?
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.
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.
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? ...
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.
- 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!
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.
(We're not in Denmark, but I wonder how it is going in our jurisdiction ...)
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.
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.
> 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 applicationsUser 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.
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.
So many committees - so little progress.
I hate that banks use this proprietary "standard" for NFC payments
It is already here.
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.
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.
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.
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.
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?
People want a "Linux Phone" but have trouble explaining what software stack they want and how Android is not already it.
I understand that it would be cumbersome on Apple devices with all their efforts to lock down the system, isn't Android different?
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.
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.
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.
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.
I ran this with a custom fork to expose the device screen as a VNC server for years, no problems
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: >>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.
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.
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.
I've never heard Belgium as a stand-in-for-Brussels-as-a-stand-in for EU.
> ... because just saying "state" could mean a subdivision, such as a US state ...
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.
1: https://www.belastingdienst.nl/wps/wcm/connect/nl/intermedia...
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.
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?
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. :(
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.
It's possible that this one random rom that you mentioned passes it today, but it might not pass tomorrow.
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
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.
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.
[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.
The Penny supermarkt app on android disables both screenshots and text selection with the error that it is disabled by admin.
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?
Are there well-known good practices?... Or, do they need to be rediscovered as they are perhaps proprietary know-how?
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.
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).
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.
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.
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!
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).
Or will that munch your battery?
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.)
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.
but nobody will care and continue to think only bsd/mit/Apache will make their project be successful commercial enterprises. sigh.
https://gpdstore.net/product-category/gpd-handheld-gaming-pc...
https://www.usnews.com/insurance/auto/how-do-those-car-insur...
Only a question of time until it becomes mandatory
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.
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.
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)
On security, your lovely propietary NT based kernels had so many CVE's and attacks that you could fill gigabytes of text with these.
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...
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.
I must admit, I don't do banking on the phone and keep all sensitive data off my mobiles.
And, yes, I often turn off wifi. I never go over my Data limits and 4G/5G is much more efficient for some reason.
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.
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
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.
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...
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.
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!
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 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.
https://github.com/microg/GmsCore, so basically you cannot. It's monopoly in daylight.
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.
Tbf it is 2025, not 2010, it isnt that hard
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.
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.
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.
It's worse. An app author can even be notified if a screenshot was taken.
> 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: >>45208925 ). Nevertheless GOS on Librem 5 or Pinephone would be a nice idea, except the GOS developers are against that: >>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.
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 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.)
See also: https://puri.sm/posts/closing-the-app-gap-momentum-and-time/
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 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.
These seems a bit like a scam. Why can't they ask the recevier?
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).
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.
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.
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.
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.
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.
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?
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.
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...
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.
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.
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.
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.
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.
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.
If you're only doing banking at home, why would you do it on such a tiny little device?
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...
Password fields are inputs. Screens are bi-directional.
It's ridiculous the EU allows this.
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
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.
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
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 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)
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.
Doesn't the EU want encryption backdoors and such too?
They no longer believe in owner control. Either that or they consider themselves the device owner, which is even worse IMHO
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 a failed legislation already.
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
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
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.
People will go to great lengths to bypass annoyances. Excessive false alarms is even called "alarm fatigue"
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.
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 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.
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.
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.
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.)
Very impressive.
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.
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...
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.
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.
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.
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.
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.
This is not an argument against web apps, which work on the phones just fine.
I'm assuming (hoping) it's Android letting me know and not the app passive aggressively side eyeing me.
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.
This is about being able to pay your bills at all.
respecting rules is more important that saving your life. /s
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.
> 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
- …
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?
The claim free speech is under threat in Europe just demonstrates you are easily led by rabble rousers.
- 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.
However Walloon people definitely feel Belgian and have a Belgian pride.
Also, i don't know if a nation state is defined by having a national identity?
MitID is different from the proposed app-based solution for age verification which is designed to not leave a trail. The age verification app will initially be enrolled using MitID (or perhaps by a physical visit to a citizen service point where you can show physical credentials and answer security questions), but subsequent presentations of age verification proofs to service providers will be done without involving a central party.
All in all it is a good design from a privacy perspective. The major issue with it is that ONLY a smartphone based solution is planned, and that there is a high likelihood that it will depend on Play Integrity attestation. This will force everyone to be customers of Google or Apple if they want access to the full internet. I think it is technically possible to also offer alternative solutions based on secure hardware tokens which would still enable people without smartphones to verify their age in a privacy preserving way, but this is not planned.
Then again, this is also what makes me almost throw my Android phone against the wall when I try to do the same on that phone.
Mobile web apps are a very good solution (plus you can use Kotlin/Compose Web!). It's not adapted to all kinds of apps of course...
Bilions of emails? No, it cannot, not even store it, let alone process it fast enough to make usable
Maybe, but this is what I managed to gather through a 30-year career in tech, in three huge companies, from IT management to SVP.
Meanwhile, you can use it in termux if you are on android right now.
https://developer.android.com/privacy-and-security/security-...
This works by signing an attestation using a hardware-backed key (which is in turn signed by Google). So, there is no way to emulate this in software, because your ROM simply does not have the private key to do so. Part of the attestation is information on whether the booted operating system was signed:
https://source.android.com/docs/security/features/keystore/a...
Again, since this is all hardware-signed, you could only fake this information if you were somehow able to extract the private key from the secure element. The primary weakness is that you could try to patch out the part of the application that asks for this attestation. But they found a solution to that, remote attestation. Instead of the app asking for the attestation, e.g. Google's servers or your bankcan ask for the attestation and for the reasons outlined above, your custom firmware is not able to fake this. If your bank, etc. implemented remote attestation, you can simply do not do banking on your phone anymore.