I like that this project is trying to tackle something much more challenging that can't be done with just software: reverse engineering device firmware and binary blobs, the pieces of software that actually make hardware components interface with an OS. Understanding how this stuff functions is key to being able to write replacement software, so we may have less non-free software to deal with. I don't have any experience in trying to reverse engineer software, so the best I can do for now is cheer on from outside, unless I want to try my hands at this stuff later.
I also like that this project is not intending to produce an Android-based distro, but focusing more on reverse engineering. Although I read that the results are targeted at helping developers of Android-compatible OSes, the results can hopefully be used by non-Android [GNU/]Linux distros and perhaps other *nix stuff, like the BSD distros. The FSF (by way of developer Rob Savoye) recognizing that a project like this is not going to be quick, easy, or cheap, and is a long term effort is good, as that likely means this project isn't going to be easily abandoned just because of not being able to produce quick results.
I hope that this whole effort can eventually let us break free of the Apple-Google mobile device duopoly, as it sure is getting tiring for me to stick with one of these two companies for my mobile computing needs.
That was stated as a goal at the FSF 40 event, videos of which should be online in the next few days.
The Apple Silicon macbooks seem a good example. The M1 came out about 5 years ago now and with a whole project and a lot of work later there is still limited hardware support. Having to put this effort in for all the models of phones seems massive.
And I’m not knowledgeable about this at all, but intuitively I’d expect apple stuff to be much more customized than the average android phone - they’re famous for vertical integration and owning the end to end process.
Then there is everything else that happens to be on the motherboard.
Is this hardware dependent though?
I ask because I’ve seen custom android mods that port the pixel camera, presumably if that works for other devices it’s a good sign that postprocessing can be decoupled from specific hardware.
If you work out a phone from 5 years ago, you're not that far off from a phone of today. Nobody designs it all from scratch, you mostly modify the old one. Getting the foundations going will take years - adapting the foundation to a different phone of the same series will only take months.
The example already given makes the point. Work has been great on the M1 but my understanding is that this has not translated all that well to e.g. M2, M3 and M4.
2) The hope is that the M2-M5 won’t be that different from the M1 models - after all, Apple doesn’t want to spend their money reinventing the wheel without compelling reason. I think that is less likely with phones from different manufacturers, though Android phones typically share a lot of single source components.
From the Asahi Linux website, M2 is sufficiently similar to M1, while M3 and M4 won't likely be supported soon due to significant differences.
Maybe in 2020. Lenovo released an ARM chromebook this summer which has benchmark performance of M1/M2 chips and is perfectly supported by Linux (ChromeOS) out of the box.
If people want open devices they should maybe better explore open hardware. Im not talking about devices, like Librem where the schematics are open but the chips, which are the parts which do all the work, are all closed, but rather devices with open silicon.
Apple Silicon isn't a single SoC. They have support for the M1 and M2 lines across both Macbooks, the Mini, iMac and Studio.
It's the same thing with phones, isn't it? You're not starting over for each individual phone. First you get one device working which uses some popular chip, which is a large undertaking. But then all the other devices that use the same chip are nearly working and it's not a matter of starting over, it's a matter of mapping the couple of changes they made to the base design.
Meanwhile the chip designs themselves are incremental, so the 2026 device is really the 2023 device with a die shrink and a new feature.
The time is right for this project I hope they succeed.
That said, the phone market is huge. They could sell enough devices to fund future development which might be good enough even if it doesn’t slow down Apple or Google. At least then there will be a device for those of us who are not happy with the state of things.
Maybe thats exactly why it can succeed now. The phone tech has plateud to the point where a 5 year old phone performs almost identically as a new one and this is when people can afford to experiment and take more risks.
Also its much easier for free software to catch up now as most problems are already solved and/or easy to copy.
I'm not. Samsung treats my phone like dirt. I'd love to have some actual ownership of a device I spent $900 on last year.
I don't think my wife is happy with her iPhone either. She bought one of those little NFC fridge magnet things that locks your phone out of social media apps. She and I are dissatisfied in different ways, but there's a theme here.
That being said, very low expectations on this project.
They don’t need to replace or even challenge Apple and Google for market adoption, just be there and be a viable alternative used by a noticeable minority of people.
Getting half as far as desktop linux would be a fantastic achievement.
Talked to many iPhone owners this year? The 17 hardware has a bizarre choice of a camera button / pointless physical change, and IOS 26 is pretty much hated by everyone.
I use iPhone, and have happily for years but F if this isn’t the worst OS I can remember. The first downgrade really.
Android does not contain binary blobs because of some evil conspiracy against free software. If they could get away with it, the whole damn thing would be open source.
The problem is those blobs do things that interact with complex hardware for which only blobs are available. Even if you reverse engineer them, you are going to get sued into oblivion because of the patents you are going to need to infringe on to make functional replacements.
But even if you get a blessing from the component manufacturers, your new hippie binary blobs need to be certified to legally operate on cellular and wifi frequencies in most parts of the world. If you decide you don't like something and change it - as is the open source way - that new version with your modifications needs to be certified too. Carriers do not allow uncertified devices on their networks.
If it all was open source, the community could quite easily provide updates - you can run a modern Linux distro on 10+ years old laptop just fine.
Who is "they"? Certainly not Google. Google has been moving open-source Android functionality into the closed-source Google Play Services for many years.
Second, fuck the carriers. Certifications will not persist as soon as real Foss phones are available. Nothing persists against a world of free hardware invading a realm. And even if: freeing everything around a modem blob would still be a big step forward.
It's frankly ridiculous to assume the people working on this and the organisation that already supported replicant knowns nothing about the mobile space.
Cell phones operate in licensed radio spectrum, so they need to have proper testing and certification (https://www.fcc.gov/oet/ea/rfdevice). Any device not properly certified would be illegal to manufacture or import into the US.
Separately cellular networks require PTCRB certification of the devices to ensure they are interoperable with the network (https://www.ptcrb.com/). The FSF could in theory write custom firmware for baseband and wifi chips, but they would need to seek certification as this would be considered a substantial modification. It would likely require cooperation from the chip manufactures to provide samples with various testing/debugging harnesses enabled.
Qualcomm and the like would probably sue to stop the FSF on the basis that it could put their own device certifications into jeopardy.
That isn't even touching on non-transmitting components like GPUs or sensors where the actual functional logic may be split between hardware and software (your blob driver). Even by doing a clean room reimplementation, you risk infringing on software patents, and will have little flexibility to work around them since the hardware will expect things to be done a specific way.
You would think it would be ridiculous to assume the people working on this know nothing about the mobile space, yet their actions do bring that into question.
All that patent and legal business is probably a more important/existential concern and a go/nogo-factor if you want to be a commercial player in a market-driven environment and less so for an entity like the FSF.
Is there survey data available on this? Anecdotally, everybody I know hates their phones. In fact, I think if you asked, "what's the biggest pain point in your life right now?" I think most people will point to their phones.
If you asked normal average people "what's the biggest pain point in your life right now?" they would point to financial, societal, or health issues.
The vast majority of people when asked specifically about their phones probably wish that they were a newer model or had a longer battery life. As long as it communicates with people, lets them access banking and social media, and has a few of their niche hobby/entertainment apps nobody actually cares about the licensing of the modem firmware or the fact you can't install TempleOS on it.
Every single one of these is fixable on any modern phone. Stop using social media, take a hatchet to what apps can send you notifications and when, and be more mindful of what tricks are commonly deployed to steal your attention, time, and money.
But people can't even manage that. They don't even have to do anything, they just have to stop doing certain things, but they can't or won't. Those same people aren't going to go through the effort to switch, and even if they did they would end up re-creating the same thing that makes them miserable currently.
I'm willing to suffer a rough beta or alpha experience, but let me use modern hardware of my choice.
I'm kinda the opposite, I don't want to buy new any more. Currently rocking a 2nd hand Pixel 7a running GrapheneOS and loving it.
If battery life is the issue, that's fair enough. I've bought a couple of wireless charging docks that I spread around the places I frequently spend my time, so if it needs a boost I can charge her up just by plonking it on the dock. Most of the time, though, she makes it through the day from (maximum charge for battery longevity reasons) 80% down to 30%, maybe 25% or 20% if there's lots of interesting news in a day.
But I'm not a particularly heavy user and I don't game on it.
Otherwise, their website suggests you can specify a particular project via the memo line of a check:
Like many folk who’ve been watching Google’s gradual shutdown of AOSP and alignment with Apple in terms of platform lockdown, I think the days of fully open devices are actually coming to a close. Again, I applaud the FSF’s initiative, but you need to get a lot of buy-in for this kind of thing to work—-manufacturers, developers (both OS and app devs), and, of course, users, who will never accept anything that doesn’t let them do things like banking, shopping, mainstream social apps, etc.
And you can’t do a lot of those on an unlocked boot loader (which I think is going to be the logical consequence of replacing bits of the OS) without more hacking. It’s like XML and violence—-it will only lead to more of the same.
I expect the usual amount of “you can do that with web apps” pushback, but let’s be real. Except in markets like India where simpler and vastly cheaper platforms make sense, you either use iOS, Android, or… nothing but voice calls, and I don’t see enough here to make me think this will be something for everyone.
And this is not even always possible. In Ukraine, government app is released as an app, not a web service. Same goes for banking app. You just can't do these things from other devices, you must have (mainstream) Android or Apple phone.
I've been looking into projects like GrapheneOS for a while now, but it is just impossible to use in Ukraine.
I can't find any info on the government app though. It might not work. But still, I can actually consider GrapheneOS now.
[1] https://privsec.dev/posts/android/banking-applications-compa...
Many more, like?
For an individual, almost none. I can boycott a bank (if it's not a government one), I can't boycott my own government, only leave.
An organization can start an initiative, but without an interested party involved it's only an initiative, you can hardly call it "pressure".
With a government, however, you can go through your MPs, use administrative procedures to lodge complaints, etc. They also don't have Visa/Mastercard forcing them into attestation, it's usually just because the contractor thought it made things More Secure™.
We still need open hardware and more companies like fairphone to utilize it, but we primarily need the EU to get it's act together and break the reliance on big tech app stores. I know there are a few companies trying to build app stores with the necessary security compliance and if the EU wants to be serious about digital sovereignty it'll need to support these.
This is a common misconception I see around here, probably because people think Graphene is yet another custom rom like LineageOS, and haven't actually tried it for themselves.
GrapheneOS supports Google Play (it ships with an app that lets you install it in one click), it does NOT give you root access, and it goes through the extra effort of implementing the obscure security features that banking apps require. I won't say 100%, but maybe 99% of apps on Google Play will work on Graphene, including banking apps. This compatibility, along with the added security and privacy features are why it's such a big deal. It's not just hype around the latest shiny custom ROM.
I do appreciate the work the GrapheneOS team puts in toward compatibility, and especially the fact that they just got RCS messaging working. But any time Google or even an app vendor wants to tighten the noose, they can, just by requiring the higher, hardware-backed attestation level.
That page seems to be saying the opposite: hardware attestation would support GrapheneOS, whereas the Play Integrity API would not.
Anecdotally, both of the banking apps I use 'just work', and I haven't encountered any app that doesn't work. The closest thing was the Disney parks app a few years ago which would crash on launch until I disabled the hardened malloc feature for it.
There is a list of apps banning GrapheneOS keys here, including govt apps, ticket apps, and McDonalds for some reason:
https://grapheneos.org/articles/attestation-compatibility-gu...
No? You're adding support for Graphene's keys, not replacing Google's. Obviously, the main barrier is convincing developers of these apps to add support for Graphene's keys. However, this is only a problem for apps that opted to implement the Play Integrity API at all, which doesn't seem to be very common. All the recent monopoly rulings against Google may be deterring devs from implementing this obviously anti-competitive feature, and that's not to mention Google's new responsibility to offer the Play store app catalog to competing stores, thanks to the Epic case.
> The injunction issued last year by U.S. District Judge James Donato requires Google to allow users to download rival app stores within its Play store and make Play's app catalog available to competitors. Those provisions do not take effect until July 2026.
(source: https://www.reuters.com/sustainability/boards-policy-regulat...)
Maybe they'll get away with requiring competing stores to implement Play Integrity API, maybe (probably) not.
Also, that list of incompatible apps is probably out of date since I use the ebay app all the time with no issues.
Also good to make a distinction between the different things you can do in an attestation procedure: bootloader/boot integrity checks, attest a specific key, and ID (imei etc) attestation.
However, I still stand by the idea of having options. Many of us in developed Countries are likely to remain on our IPhones or Androids, but there is still a chance for FSF to shine in other areas.
Also, as someone who was a FirefoxOS user (I think around 2011-2016) I am always open to replacing my Android with FREE (as in freedom) alternatives.
As I mentions in previous comments - the main "fight" is convenience vs freedom.
Either we have the convenience of being able to do things on our devices with little effort of all (with variations of lockdowns and/or less control)... or we run something that respects your freedoms but some things require a few more seconds/minutes to do.
Personally, I would choose the latter. However, I know I am the minority in the world of phones.
Don't get me wrong. I am not some freedom(software) fighter. I accept that there is a convenience I need on phones today. In the workplace, I need MS Teams. If I don't have this, my Company will have to offer me a Work phone. Other than this, I do use it for banking, map navigation, etc. However, these are not deal breakers for me.
Also, we have the convenience with AI, which more and more will adapt like a special friend, will make things ever harder in the freedom world. Be interesting to see how this evolves.
At the end of the day - things change. It's hard to think like this but we don't know what we will be using in the next 10 years. Maybe in this universe, Microsoft Windows might still be king in the OS world. However, in another Universe Microsoft ends up making too many poor decisions even businesses are open to alternatives.
It's the same thing for smart devices. Apple might make a STUPID decision in the next 10 years. Although we still have Android variants on the market, the Librephone might get a big push by ex-Apple users.
We shall see. If this project does well and can do certain types of "convenience" then I would be willing to try it!
It is always a pleasure to have something with convenience but does not cost my freedom.
Plenty of users are now buying feature phones that don't come with these features. Think of a libre phone as a uniquely user-focused, distraction-free device that still allows for a core smartphone/PDA compute featureset.
Hopefully this project will go better than Replicant. Here are my notes on running Replicant on the (then already very old) flagship Samsung GT-I9300:
https://www.neilvandyke.org/replicant/
The hardware was a little difficult to obtain in the US, and WiFi worked only with a blob of questionable provenance.
It looks like Replicant has been stuck for several years, and they recognize that they need to find a new device, funding, etc.
(After Replicant, I spent some time on PostmarketOS with various devices, and then gave up and bought iPhones, and then got ticked off and moved to GrapheneOS.)
I wonder whether the FSF is already collaborating with Purism on this, to leverage their work on the Librem 5 and PureOS, which I believe the FSF is well aware of. If the FSF manages to muster a lot more open source volunteers on a more affordable hardware, but that work is also usable for Librem 5, then it could be a win-win. (And Purism also has something called Liberty Phone, which is a made-in-USA Librem 5 phone, so their lawyers should talk about trademarks in any case.)
Why? There's no Android port for that device and they keep mentioning LineageOS.
Even the PINE64 PinePhone would be more likely, as that has Android support and even some LineageOS 22 support [1]. The Replicant project had eyed it as a target device [2].
That said, I'd expect a different device, and, assuming LineageOS supports one, and I would not be suprised to see a device that's not powered by a Qualcomm, Mediatek or Samsung SoC.
[1]: https://github.com/GloDroidCommunity/pine64-pinephone/releas...
[2]: https://blog.replicant.us/2024/03/replicant-status-and-repor...
The LineageOS folks are working on supporting their OS on Linux-first devices running a close-to-mainline (not AOSP) kernel. So it could go either way. Of course if they do choose an Android-first device, their efforts would ultimately also make it easier to run a mainline kernel on it as shown by projects like pmOS.
Is there any actually relevant alternative to this oligopoly? Apple doesn't sell to third parties, NVDA lacks a baseband and so does (to my knowledge) Broadcom, and it's been ages since I saw anything from Intel in the mobile space.
Has anyone told the FSF that it isn't "GNU/Linux"?
I suspect that Purism has the better idea for a sustainable starting point for an FSF-ish phone.
I'd be curious why FSF is barking up the Android tree again (the massive, intractable Android source code tree).
First line of my pitch is, "When hundreds of millions of people need something, it doesn't make sense to wait for a handful of volunteers to build it for free."
If you go with postmarketOS (good!), and don't want to touch anything that touched Purism, better avoid anything GTK (Phosh, GNOME Mobile and related apps). While Purism did not make a competitive phone, their investments into libre software went great and keep paying off.
A free OS will empower developers to implement technical workarounds that could trick these apps into working there. If the OS is tightly controlled, we have no recourse.
Even in the worst case scenario, we could use a cheap big-tech-approved phone for these applications (a glorified digital token) and use the free phone for everything else. When there's enough adoption and trust in the new phone, non-technical avenues are available to influence these organizations to accept the alternative.
I have an old phone (actually running LineageOS rather than stock) that works as you perfectly describe as a glorified digital token. This device doesn't come with me. There's no banking I need to do, on a day-to-day basis, requiring said token, that has to be done right now or the world will end. It can wait until I get home (and I usually use the bank's web interface from a desktop). This device has minimal other apps installed, which limits bank app accessibility of other app data, and other app accessibility of bank data.
Then my GrapheneOS daily driver serves my day-to-day needs with minimal data leakage, tracking, ads, other general paranoia-inducing modern-life shit.
I pay for things on a day-to-day basis with a physical debit card due to an existing habit of not wanting to depending on a single device for "all the things", so GrapeheneOS wasn't a downgrade, but it should be noted to others that whilst Google Wallet can run on GrapheneOS, NFC payments through the Google Wallet will not work due to Full SafetyNet requirements that GrapheneOS can not pass. Non-NFC items such as tickets and boarding passes have been reported to work (and I'm pretty sure I've used it for that, although Google Wallet is no longer installed on my device).
If that became the case, then the 'glorified token device' would become the dedicated banking device, and not much else would change (ie. I still wouldn't be doing 'banking' while I'm out and about).
If it came by SMS my daily driver would receive it.
(I don't mean this in a sarcastic way) are you able to make tangible what 'living' I may be sacrificing?
See the recent discussion about pixnapping: https://news.ycombinator.com/item?id=45574613
Also, if your bank uses SMS for verification then the phone should have its own phone number which you keep secret. Otherwise it's one data leak and one sim swap attack (https://en.wikipedia.org/wiki/SIM_swap_scam) from breaking your SMS verification.
Not if they require something like hardware-backed remote attestation, and only accept such attestation from Google or Apple.
I'd love a practical Linux phone, and being able to run a deblobbed close-to-mainline kernel on a new-ish phone would help with that, but that doesn't really solve the most user-facing problem of mobile phones, the ecosystem lockdown.
If you can't be sure what's going on and unable to inspect or debug the hardware and software, how can you trust it's doing what you want?
Proprietary hardware and software is already known to work against the interests of the user. Not knowing exactly what's going on is being taken advantage of at large scale.
Let's put it this way: if you can choose between making your own lasagna with a good recipe vs ready-made microwave lasagna. What would you choose? How about your suit? And would you trust an open known to work well pacemaker vs the latest Motorola or Samsung pacemaker? Would you rather verify the device independently or pay up for an SLA?
You trust hardware and software by establishing boundaries. We figured this out long ago with the kernel mode/user mode privilege check and other things. You want apps to be heavily locked down/sandboxed, and you want the OS to enforce it, but every time you do you go up against the principles of open source absolutists like the FSF. "What do you mean my app can't dig into the storage layer and read the raw image files? So what if apps could use that to leak user location data, I need that ability so I can tell if it's a picture of a bird"
For sensitive information - such as financial transactions - the rewards for bad actors are simply too high to trust any device which has been rooted. The banks - who are generally on the hook if something goes wrong, or at least have to pay a lot of lawyers to get off the hook - are not interested in moral arguments, they want a risk-reduced environment or no app for you - as is their right.
In practice, that just means you trust a Chinese black box Android ROM from a random manufacturer, but not a fresh Lineage OS. To run some banking apps there, one has to root it and install all kinds of crap to hide the fact that your phone is running an OS you actually can trust.
I don't think it's right, I don't think non-manufacturer provided ROMs are a real danger in practice, or rooted phones, and I think this is all just security theater and an excuse to control what people do on their own devices.
If they pay for the phone and ship it to you then I agree. Otherwise, they have an obligation to serve their community (part of their banking charter) and that may include meeting their customers where they are, rather than offering an app with unreasonable usage requirements.
Well, no. The objection isn't to sandboxing apps, but to sandboxing the user, as it were. On my laptop, I run my browser in a sandbox (eg. bubblewrap, though the implementation of choice shifts with time), but as the user I control that sandbox. Likewise, on my phone, I'm still quite happy that my apps have to ask for assorted permissions; it's just that I should be able to give permission to read my photos if I choose.
https://devblogs.microsoft.com/oldnewthing/20030901-00/?p=42...
It was true 22 years ago and is even more true today.
This is reasonably secure. If you hijack my account, you still don't have the hardware device and the random secret that was set up between the device and the bank.
You need to actually hack into the bank itself to transfer my money elsewhere.
Meanwhile, I only access the bank with my own computers. That means I installed them and have root. Not a problem at all.
If their security depends on enslaving the user, their security sucks.
Real security, be it your financial transactions or keeping your bird pictures safe, doesn't depend on any secret algorithm. Because it's secure.
I don't have this problem on my computers, they run free software. My wifes thinkpad runs free software. The friends I gave a computer with various GNU+Linux distros don't have this problem.
Add Google Chrome with its spammy extensions to the mix and they start getting problems.
In other words, should the device be responsible to enforcing DRM (and more) against its owner?
Make sure your app has a progressive web app version that has feature parity with the store apps. That way, the app will work on phones like the librephone, and, if Apple or Google decide to kick you off the store, you and your users have some recourse. As a bonus, it’s compatible with open source — users can modify the app and install it without jailbreaks, root or (for now) sideloading.
React Native supports this (and can mostly be bundled with electron for mac/win/linux support).
Are there other stacks people can recommend?
In practice, banks will demand remote attestation of the environment the app is running in.
99% of the code runs fine in electron to. Index.tsx is the main exception.
I’m not saying you can automatically run software for one of these targets across all three. I’m saying it’s straightforward to write portable software that works on all of them.
Also, I can’t think of any apps I use that require any platform-specific APIs at this point. Even if they did, the phone I want would be able to surface those APIs to pwas.
And it will in turn depend on Secure Attestation, Web Credentials, and other recent W3C work to provide proof that you're the registered owner, age of majority and verified by thumbprint or other biometrics, running an unmodified device. Your ID might be escrowed with your OS vendor, email provider, bank, ISP, or even Twitter/X, who knows. Either way, as an end user you'll be mollified that you don't have to provide your ID to the adult site, and the adult site will be happy that they don't have to implement any of this themselves.
And, of course, this will mean that an intelligence service could have ironclad proof of exactly what person visits what website, effectively killing a lot of online anonymity.
Time to donate to the EFF and FSF I guess…
I get warnings from some sites (like radio stations) that DRM is required for the page, but haven’t noticed any breakage.
Using them in that mode adds signal to their web server logs saying that forcing DRM will break their site.
Everyone that cares about this stuff should be doing this.
(And, no, firefox isn’t broken. Also, Firefox doesn’t include the pile of dark patterns and mandatory google spam that chrome does.)
To hack the banks app you have to find an exploit in iOS or Android which would allow you to read the other apps private storage, which is borderline impossible now. To hack the banks website you just have to buy some random browser extension and add malware to it, or break into someones NPM account and distribute it there, or any number of ways to run code on someone else's computer. Something very achievable by an individual.
Does it? The browser doesn't do anything, the person sitting at the computer where the browser is running is what performs the actions. The reauthentication and 2fa is meant to authenticate and authorize the user, not the browser.
The attack vector of someone else using your phone using an app that doesn't require (re)authentication is independent of the browser or the app itself being trusted. That your bank doesn't periodically require some kind of re-authentication for their app is a security hole, but because the device could fall into the wrong hands, not because the code/app/browser used to access it isn't trusted.
2FA on the same device secures against your login credentials becoming known to another party, e.g. by fishing, password reuse, database leaks, etc., which are real threats. It is not meant to protect against someone being in possession or full control of your unlocked device, which is of course also a real threat, though possibly less common.
If I steal your device, and you didn’t have faceid, I have both factors. But if I steal your password, or find it in a leak of another site because like most people you re-use passwords, then I only have one factor. It still provides a fair bit of security because of that.
> I don't think you're the target market for this phone.
My comment is downstream of the entertaining of a possibility of:
> a significant user base that runs alternative operating systems
... which isn't going to happen if you ask your users to give up commonly used features. It will forever be a niche project, at best.
It makes more sense that they're referring to Apple Pay or similar shenanigans (which itself is more annoying than a credit card, to be honest, Face ID goes wrong or the double click closes the wallet app instead of authenticating way too many times, especially if you're trying to do it one-handed).
Get 3% and rebate some to the customer. For the convenience.
It’s kind of sad, really.
My other bank offers 2FA via chip reader as an alternative. I guess that's somewhat viable for an alternative phone OS, if you want to carry the reader around with you
That might just be European banks though
They just use an SMS code instead which is not secure at all.
why not distribute hw tokens for purposes like this? it has the least flaws IMO.
People do proprietary bullshit because they want to do proprietary bullshit. Anything else is made up.
The only supported 2FA is the bank's own dedicated 2FA app.
Bank transfers and I guess direct debit authorisations (if your bank requires you to confirm those) and reauthorisation/confirmation of card payments that were blocked by the bank's fraud detection. I think those are the only kinds of transactions one would ever use a PC for? I mean for me most of my day-to-day transactions are me paying by debit card in a shop, but you can't do that on a PC in the first place; pretty much everything else I do on my PC.
But sending a bank transfer is also a fairly common day-to-day transaction that I do a couple of times a month (and is the only way to pay for some government services like tax certificates short of visiting the tax office in person). Authorising a new direct debit happens occasionally (joined a gym, changed my utility provider, got a new credit card, that kind of thing).
WTF? What kind of shitty banking system are you using?
Stallman had a good idea for free (as in freedom) software, but then "missed the forest for the trees" by focusing on the source code.
RMS is afraid of trees!
What does it matter if you can use any OS you want if your phone is filled with SoCs which are bugged and backdoored by the state and/or who knows who else? The reality is that we need both free hardware and free software. I can always tell my bank to fuck off and move my accounts to one that gives me freedom to use the mobile OS of my choosing, and if there isn't a single bank on earth willing to do that I can always simply refuse to use my cell phone for banking.
I'd much rather keep the phone I control and trust while limiting myself to only having the options of a desktop PC, a laptop, an ATM, a phone call, a drive thru, and walking into my bank's closest branch when interacting with my bank. Not being able to also stab my finger at a cell phone screen to check my balance isn't really that big of a deal.
The only project I know of that really actively addressing the end to end problem is Bunnie Huang's precursor.
Work seems to be going on low-key: https://github.com/betrusted-io/xous-core
Perhaps. But how does this effort from the FSF do anything to solve that? They are (as far as I can tell) producing firmware, not hardware. If the hardware manufacturers are working with the government or whomever to spy on you, they will just not use the FSF firmware in that case.
But the partially wrong part is, we can make our own platform. PCs let you install and run any software you want, because it's an open platform. If we make an open platform smartphone that can compete on features with the closed behemoths, and that then becomes popular enough, then banks may offer apps on that.
But this is tricky too. Linux already has issues getting official support from corporations. We'd need our open platform to be compatible with the closed ones, so that it's easy for banks to run their apps on our open platform. There are already ways around this, like virtual machines to run Android, or other methods. But the closed behemoths may try and end-run around this, like DRM. So we'll still need to advocate for our rights and compatibility.
They have a free kernel not a free OS. Them not having a free OS is precisely what is the issue here.
Does anyone remember having a copy of internet explorer that the bank required (or chrome these days) but using firefox for everything else? Apply that concept to a phone.
Luckily, here in the U.S. this is still possible. I run Graphene on a Pixel without Play Store compatibility layer and everything just works. Most of my apps come from F-Droid, with the notable exception of Whatsapp, for which a standalone APK is available. Unfortunately, it is proving difficult to get rid of Whatsapp entirely because of friends and family.
If not that frequently or unpredictably then you could just plan to use your laptop for banking some time during the day.
I almost do, yes. Life's complicated, I use several bank and credit card services a day. I'm not at home at suitable times for my banking needs. And payments for purchases sometimes require confirmation in real time via phone app.
> If not that frequently or unpredictably then you could just plan to use your laptop for banking some time during the day.
I used to do that years ago back when it was an option.. But these days, 3 banks I use (two for business) require using their mobile app to authenticate login on a laptop browser. There's no other option.
One of the card apps I have to use often won't even run when Android developer mode is enabled, which is quite annoying.
The phone I really want is as uncomplicated and open as possible and beholden to no corporate economic interests or privacy invasions.
Now that I'm retired I'm looking for a project to immerse myself in. This sounds like just the ticket.
I've encountered cases when both behaviours would've been desired (either use the cached version, or the latest version), so I think that's neither a point in favour nor against.
I think real caching is superior because you can manually reload if you actually needed that, but you can't go in the other direction.
People tend to see current world as carved in stone, like it is not going to change. It is, still not easy but, much easier to ask government not to mandate Windows/MacOS only program for essential task, because of couple of users of other systems, rather than asking to imagine that in future there might be other systems.
Given the apparent trajectory of the corporate/government model of organizing society, it seems like they're going to be the ones that will be second-class citizens.
Also many websites are making it remarkably hard to not use the app if they even remotely sense you're not on an actual PC. FB and LinkedIn aren't banks but prime examples.
I like my credit union.
Indian banks provide their full suite of services through WhatsApp. I have opened and closed accounts, completed KYC and authorised transfers through it.
I remember the stagnation of Internet Explorer combined with increased awareness of security exploits in Windows and Internet Explorer led to the rise of Mozilla Firefox and (to a lesser extent) increased marketshare for the Mac. This, combined with the arrival of smartphones around 2007, put pressure on organizations to make their Web sites accessible to a wider range of browsers instead of just IE.
Perhaps if we had a critical mass of people using phones with FOSS software, this would be enough for banks and other organizations to consider people who don’t use Apple/Google products.
The challenge, though, is getting that critical mass. Firefox benefitted from Microsoft’s fumbles in the 2000s. It’s going to be hard for a FOSS project to compete head-on against Apple and Google.
> that is where I feel they could truly make the biggest difference for freedom for the average user.
By doing what exactly? Telling your government to change their ID policies? You seem to be complaining at your health food store about the nutrition of McDonald's food, because most people eat at McDonald's and that's where they would make the most difference.
However, I expect at some point they'll insist on biometric authentication.
That'd exclude people who can't use the biometrics. But one bank (Revolut) told me that they're dropping customers who don't have a passport or driving license in the UK, for KYC reasons that they said they were required to follow, despite there being a large number of people without either.
So I expect banks to have no problem excluding <x% of people in a discriminatory way, if they can find an excuse, eventually.
I tried calling Starling Bank in the UK when my phone screen stopped working. I assumed they would have basic phone banking service.
They told me no. The only service they could provide over the phone was registering a new device to resume access to bank services via their mobile app.
Although they have a web banking service, which can he used on a desktop, that requires authentication via the mobile app too. It's not TOTP, it's their own thing.
As I needed to make a transaction, I had no choice but to buy a new phone in a hurry.to do it.
Several people suggest switching banks and credit card services, but I've found that not so easy. I have accounts with several banks (some for business), and 3 of them require use of their mobile app. Most credit card services I use also require use of their app. Some have websites that hand you over to the app at some point in the flow.
Log in to your bank over the internet, the normal way.
The rest of the time, I will use a free phone.
All the apps that I will not be able to use any more? Doesn't matter. I am now old and grumpy enough to realise that phones are utterly evil and actually useless. Give me a camera, Google Maps (or better a non-Google alternative), Signal and a browser, and I don't need anything else.
1.: https://grapheneos.org/articles/attestation-compatibility-gu...
In a modern smartphone, modem is often a part of the SoC itself - and it runs some of the biggest and fattest blobs you've ever seen.
In most countries, the spectrum that cell phone carriers use is licensed to the carrier, under the condition they only connect devices that are guaranteed to comply with the requirements of using that spectrum. The end user (i.e. the person with the phone) has no license to use the spectrum. So in order to get regulatory certification, basically every modem has to be locked down so that the end user cannot operate it in a way that would violate any rules or regulations for using that spectrum.
So basically, it's illegal to have open source modem firmware. At least, as long as cell phones are operating on spectrum that isn't open for public use.
Ultimately, if you want to open source a modem, you first need to build your own cell phone network.
there are also all kind of open source lte/cbrs projects iirc
https://themodemdistro.com/ https://github.com/the-modem-distro/
PostmarketOS can run on some devices with almost no blobs - but there's no escaping the modem curse.
My thrill is matched in strength by the loathing I have for this Apple device on which I type, whose entire boot process is miserably locked down from the very start. It is like a bicycle made from Mickey Mouse logo bolts where the spanners are proprietary and not for sale. The situation is just as ludicrous.
The two major phone OS companies both stand on the shoulders of IBM PC, openly bootable hardware, and the fantastic software systems nurtured and built on top of these platforms — the BSDs, GNU, Linux, and the long tail of all that run on them. It is very troubling that their own platforms are the antithesis of being openly hackable.
Librephone could be successful in a few ways. Outright, as a device, but also as a carrot to bring open handheld hardware to enough people to drive political change (with a small-p, the politics of society, as well as politics of the big-p kind) such that iOS and Android would have to follow suit. With actual public policy Librephone could also end up being a stick: bringing about legislation that requires computers of any kind to be able to boot software of our choosing. Right-to-repair plus plus, if you will.
With enough Librephone devices in the right hands, either the market or the law will demand that we have the same openness and freedom to use our devices the same way we do commodity x86 hardware today. The same freedom imprisoned and exploited in the core of mine and your phone, right now.
I can kinda see a lineage from the PC to Android, if only by way of Linux being born on the 386. But Apple? They've been doing their own thing since day 1; I can easily imagine a world where IBM never existed and the iPhone is unchanged.
But from scanning through this press release, this seems nothing more than the FSF doubling down on their failed RYF approach, which does absolutely nothing for user freedom. In fact it's a big negative for freedom, as it ties down resources that could be spent doing something useful in doing something completely pointless like putting firmwares in ROM and adding another chip to load the firmware.
The thing is, firmwares are here to stay. And firmwares that can be stored on the filesystem and loaded by the OS during driver initialization increases flexibility and reduces BOM cost. So that's what device manufacturers are going to do, and RYF will not have any effect on that.
https://news.ycombinator.com/item?id=45584498
https://news.ycombinator.com/item?id=45585869
It's heartening.
What I'd really, really prefer is to be able to program the device with the same ease as developing a local Linux application. If I need a UI, I'd rather that be a web front end, and not something that needs GBs and GBs of special IDEs and other bloatware. That way, we don't need specialised "apps" for each and every thing: any service that already has website, should work as it is. Just point a browser at it.
And how do I tweak an "app's" UI if I must, rather than beholden to it? That's right: web extensions.
Purism did a lot of work to build Phosh, based on Gnome, with GTK apps that had fluid layout. on a phone-size screen, the UI was suited for touch; but connect it to a screen and everything seamlessly switches to a standard Gnome UI.
i would rather see this get mainlined into Gnome, and for it to be common-practice to design desktop apps with a fluid layout that can adapt to phone screens.
This is exactly the plan of Purism, https://puri.sm/posts/how-to-be-upstream-first/
Just because pieces are open-source (or "free software") doesn't mean the autonomy and capabilities we want are necessarily present in the overall system.
Not even just "requires a mouse/keyboard", but a lot of things of the form "assumes a reasonable screen size", ...
With Linux, you will need, as I have seen on my pine phone, way too much focus on just basic apps which still are not good compared to their android equivalent: spending time there is not spending time on hardware support...
Trying to build a non-Android Linux phone that is competitive is just not practical at this point. It would require an enormous amount of funding.
Have you seen the attempts of past "Linux phones"? Usability, performance and usually battery life were horrible and progress was also slow.
There have been comments about the race to support recent phones. I hope that Fairphone will looked at as a target device. It would be a good cultural fit and they don't have a yearly device cycle which should also help.
Seems like a smart decision to me since that's what everything phone related builds to as a lowest common denominator anyway.
Doesn't stop you on working from there once that milestone is reached.. I would certainly welcome more alternatives in light of the recently announced changes from do-no-evilG
I like postmarketOS, but it always felt to me more like a pet project than a real OS, for that reason.
Funny, I would have used those exact words had they chosen anything BUT Android as their base.
All the other "freedom" Linux phones are failures (yes I'm sure fsflover will now chime in to but akshually). I know because I bought them all. They all have one thing in common: the software sucks.
And I don't even need apps. Just basic phone functionality (several Linux phones still can't do MMS), a web browser, and no crashes. Unfortunately no Linux phone has been able to give the to me yet. Whereas Android has been delivering for over a decade.
Why do we have to have /e/OS instead of a better supported LineageOS, because /e/ is a 1:1 copy anyways?
Why do we have to have a Librephone project now instead of partnering with say, Fairphone and the Pine64 people?
Open source loses this war because proprietary devices are streamlined. The only thing that comes close to this is GrapheneOS, LineageOS, and postmarketOS.
LineageOS has huge problems since the mandatory eBPF requirements of late Android versions, which postmarketOS and its upstreamed kernel drivers could fix. GrapheneOS has huge problems because of Pixel devices, which LineageOS could help with.
We need a unification of this ecosystem because each on their own is hardly surviving on their own against the megacorporations.
I make a parallel with politics and transparency, a software lead once told me that a completely transparent government was tried in the french revolution and it kind of didn't work. For example, we all would agree that there's some functions of government related to war and security that should not be transparent. I feel that free software would obsess over that private fraction because for all you know it might hold all of the secrets and evil that you imagine.
That said, it is possible that under the guise of reasonable need for private blobs/three-letter-agencies, a lot of other 'evil' things may be hidden. Maybe they say it's due to security or IP concerns, to provide protection against device tampering, to avoid pollution of radiofrequency spectrums, but it's possible that in reality they are hiding spying software in the wifi firmware and hardware keystores?
I feel that if the FSF recognizes that there's some areas that are ok to have closed source, then they could be taken seriously, otherwise they will just be ignored and leave room for precisely the kind of misuse of closed source that they fear. This is especially noticeable when they fight against projects that precisely do a lot for open source, like github (See GitLab/Savannah), or Android, they are 99% of the way there, give them a break.
Extremism begets extremism, if the jails are too full (or too empty), advocating for the other extreme will get you nowhere, the Overton Window doesn't quite apply, in fact it can be harmful as you are providing a real threat to the other extreme.
It rather depends on what that 1% is.
The low-level code is what's most important to be free. If you have free firmware and drivers and operating system but then you still have to run a Windows VM or WINE for an old proprietary app, you can only have problems when running that app.
If you have opaque blobs interacting with the hardware, they can crash the whole system, expose firmware-level security vulnerabilities with persistence and the blobs are specific to a kernel version so when the vendor stops providing updates, you're stuck with an obsolete kernel version with known security vulnerabilities. If anything needs to be free software, it's that.
> This is especially noticeable when they fight against projects that precisely do a lot for open source, like github (See GitLab/Savannah), or Android, they are 99% of the way there, give them a break.
Android is "open source" but then the devices are Tivoized or you run into attestation failures if you actually want to run your own version of it. GitHub literally got bought out by Microsoft. These seem like legitimate concerns.
Open source is just pragmatic and is very happy with the 99% being open source. It’s more corporate and doesn’t generally care at all about the dogma.
Yes, that's what it means to have ideals.
That is the nature of software. 1% is too much. It is Free or it is not
> we all would agree that there's some functions of government related to war and security that should not be transparent
> I feel that if the FSF recognizes that there's some areas that are ok to have closed source, then they could be taken seriously, otherwise they will just be ignored and leave room for precisely the kind of misuse of closed source that they fear. This is especially noticeable when they fight against projects that precisely do a lot for open source, like github (See GitLab/Savannah), or Android, they are 99% of the way there, give them a break.
Does it still count as a cult if they're right? Do they still count as extremists if they're empirically correct? Maybe it's a good thing to have that type of extremist out there, fighting for everybody.
Yeah I don't know that this premise is true. For a lot of examples you might
give WRT war or security, I feel like some will take the approach that "if
you can't do it transparently then you probably shouldn't be doing it at
all".
You could perhaps say "Well then you shouldn't get in a war". But that isn't really under your control. If someone else decides they are in a war with you. You are in a war. It doesn't really matter whether you wanted to be in one or not.
It's not that FSF is proven correct, it's that the FSF disapproves of 99.9% of software, it's easy for them to look back when there's a scandal and say "see? we told you so.". Too many false positives.
It's mainly a libre purity project. A Lineage user won't be able to tell a thing, but the system will be "ethically pure"
https://github.com/u-boot/u-boot/tree/master/drivers/ram/roc...
Any OS "is able" to use anything from any other OS - in theory and given infinite resources. In practice though, it makes a huge difference when something works by default.
But the binary blobs are protected by copyright, so you need a license to use them.
>extracting/copying a firmware blob is not clean-room design
It's stage 1. Clean-room reverse engineering is about working with the nature of copyright, and classically goes roughly like this:
1. You set things up with a "contaminated" or "dirty" side team who have direct exposure to the IP in question, and a "clean" (or "virgin" is another older term) side team that are thoroughly firewalled. The clean side must only have devs who have never ever had any exposure to whatever it is you're trying to clean replicate [0].
2. The dirty side is in charge of producing a "fact sheet"/spec. That side absolutely extracts/disassembles or whatever else to get at the target, which is precisely what "contaminates" them. They are looking at copyrighted code. Then they use that research to a create a purely factual spec, which is then passed across the firewall to the clean side. This must be the only communication.
3. The clean side then uses that to write new code themselves that will handle state per the factual spec they've been given.
The reason it works is that (in the US) purely factual information cannot be copyrighted, there's no "sweat of the brow" doctrine or the like. Copyright, unlike patents, does not cover ideas or methods, it's about the creativity of the person in question. You can't copyright the mathematics of a function, of "when X input is received Y is output", or of general concepts. So if two (or more) people independently create works that happen to cover the exact same subject matter, but can prove they were fully independent, then it doesn't matter even if it happened to be literally identical (however improbable that would be). Each would have their own independent copyright on it.
So clean-room RE avoids all the legal snarls around "how close is this" in favor of the simple binary question of "did the team that wrote this RE'd code have any exposure whatsoever to copyrighted IP?" If the answer to that is "no" that's the end of any legal complaint, because by definition their output cannot be a derivative work. Software patents short circuit that, part of the many reasons they're evil, but as a practical matter the number of really fundamental hard to avoid ones is rapidly shrinking because it's 2025 and by 2005 a lot of the foundations had long since been done.
----
0: Which is not necessarily trivial to hire for, because the kind of person who has the kind of skills you need also is going to tend to enjoy hacking around and reverse engineering stuff for fun anyway increasing the chance they've managed to contaminate themselves.
Or they sue anyways hoping for a favorable ruling that changes the interpretation of the law (Oracle v. Google for a famous example of this)
In your examples you compare Android rebuilds with real Linux distros. The projects also have quite different goals (providing full manufacturer ROM replacement for Android on Lineage OS to reusing any old hardware to basically run servers on PostmarketOS).
Most PostmarketOS devices start out using LineageOS kernels, and many are atill using those.
Why not use PostmarketOS kernels on LineageOS?
The ultimate goals are different, but cooperation on upstreaming kernel work would benefit both.
If we're talking about the mainline Linux, then it this looks exactly like a Lego to me. I hope that FSF will concentrate their efforts on that.
Why partner with Fairphone and Pine64? They already have open hardware, and require zero reverse engineering to get a fully open solution working. In a world with thousands of Fairphones and Pinephones, and billions of corporate smartphones, replacing the proprietary software needed to run those billions of corporate smartphones is a hell of a win for software freedom.
And are you really expecting the argument "open source loses" to be a real argument against a project by the Free Software Foundation? This is like asking a cancer charity why they don't endorse your preferred brand of cigarettes.
What the FSF is doing here isn't about maximizing your experience with your preferred custom ROM, it is about tearing down the proprietary software barriers that prevent the vast majority of smartphone users from fully owning the hardware they purchased. It fits perfectly with the FSF's goals.
Are you aware that all those millions of devices require each model a dedicated reverse-engineering effort? You don't gain the coverage you're implying by concentrating on Android at all.
Once we live in a centrally planned utopia these projects will all be merged with each other and produce the perfect phone/operating system/smart watch.
Even the FSF themselves didn't mention it or provided any reasoning for choosing a Google-controlled operating system - despite recommending Librem 5 earlier [1]. What am I missing?
i'm still pretty tempted to play with one.
How new do you think the chosen Android hardware will be at the end of the promised reverse-engineering efforts?
See also: https://puri.sm/posts/the-danger-of-focusing-on-specs/
It's fast enough and stable enough to serve me (and many other people, including in the HN comments) as a daily driver.
> bad customer service experiences
This depends: Purism is a quite small company, and sometimes they take time to reply, but the community at forums.puri.sm has been really helpful. I'm a happy user.
No bad feelings, fsflover, keep up the good work. I also can’t wait to post on here from a libre phone.
It's a mixed bag. The eBPF requirement makes it harder to support newer AOSP versions on very old downstream kernels (you now need a close-to-mainline port, like what pmOS aims to provide) but because it is a requirement, it will make it easier for newer devices to run a more up-to-date kernel starting from the available downstream sources.
Librephone appears to be taking existing linux approaches, and specifically reverse engineering the SoC blobs to be completely free. I may have mis read, but it doesn't appear they are building another android distro for android phones, as they already have done that in the past.
Just tried to learn the difference between these and it seems like:
- Graphene - For current devices only - An alternative for phones that are supported and updated by Google. Security Patches, etc.
- LineageOS - For devices while they're supported or may not be updated that often. Support can be sometime by community members.
- PostmarketOS - devices that no longer have a maintained Android version for it, can just become a linux computer. Mobile functionality doesn't necessarily.
Some phone chips overtime end up having a hardware security flaw that software can't fix.
I really enjoy using Android. Part of the issue is not all deices get timely security updates, even if they get monthly updates, the updates might be from 6 months ago. Google might release a security patch but sometimes it has to go through the device manufacturer, and maybe even the mobile company. Pixel / Android pure installs seem to improve this a bit, but it's hard to have complete trust.
"Open source" didn't loose because it didn't fight anything. It was exactly "Open source" that enabled Google to dominate the smartphone landscape.
FSF and many other have been warning us for decades that Android been open source didn't matter because firmware, play store and many other components of Android were proprietary.
People gave a shit to them and now do you want to blame them for the results?
The diversity of projects were not and are not the problem. The problem is people that do nothing and only criticize.
The financial interest may have preferred a licensing model, but either way, it was the financial interest that actually built a ton of this software. Linux isn't unpopular with businesses because of its license model. It is healthy because it found ways to plug into financial interest.
The FSF will always push licensing models while ignoring financial interest, basically abandoning users and businesses. There are how many billion smartphone users on Earth, and the FSF expects volunteer programmers and volunteer donations recruited on one of the worst websites I have ever seen to carry the load? Give me a break.
The FSF will argue "you can totally sell Free Software"[1], which ignores the fact that without any restrictions on distribution/copying, the fair market value of said Free Software rapidly drops to ~$0. It's not a viable business model. Companies have built alternate business models around soliciting donations, or selling support or non-free add-ons to Free software, but selling Free Software itself (at least as the FSF defines it) doesn't actually work in practice. (You can do it obviously, but it's effectively just a different way of soliciting donations at that point; the fair market value of the software is ~$0.)
> You can do it obviously, but it's effectively just a different way of soliciting donations at that point; the fair market value of the software is ~$0
It is a viable business model. At XWiki SAS¹, they do this for their "Pro apps" [1] which are paid extensions for XWiki targeted to businesses and that are free software (under the LGPLv2 license) with license checks.
Businesses won't bother removing the license checks, it's easy enough to pay, and far easier than donating.
It is not XWiki SAS's only business strategy nor the one that brings the most money, but still, that's not a possibility to discard too fast.
You can also find paid open source Android apps on the Play store, and people (individuals!) will totally pay for them even if you can have them for free from F-Droid, like OsmAnd+ [2] or Conversations [3].
¹ I work for them
I'm not saying it's impossible to survive with that model; lots of organization survive on donations. But you're not gonna be able to build the Free Software equivalent of Microsoft or Google on donations.
That said, I think doing that with business software is a particularly interesting case because it allows low level employees to justify running a donation through the regular software purchasing process without raising too many eyebrows if they care to. I've seen a few other projects with similar models.
In XWiki's case, we know it's not perceived like "I could be having it for free but I'll pay anyway because it's a nice thing to do".
We do explain that our stuff is open source to our customers though. It's a selling point.
In our case, admittedly, it helps that our target customers want our support anyway.
> before someone just undercuts you with a fork.
Absolutely, it is a risk to take into consideration. Now, maintaining a fork has costs too, and someone doing this would rely on continued maintenance and goodwill from the upstream vendor as well.
Downstream vendors actually have an incentive to keep good relationships with upstream, so they can share fixes and have some guarantee that whatever they base their business on keeps being maintained.
That's almost like saying that Netflix relies on the consumers' goodwill, since pirating is too easy. In reality, people pay for convenience in getting what they want.
I think there is an issue with your definition of "user freedom". What do you mean by it?
Stallman, when defining free software, does not bother with standards or terms: he relies on his own definition of what "user freedom" means and from there states that free software is software that is not restrictive of this freedom.
Free software simply does not restrict what the user can do with a program. It is not a matter of interest. People that choose a free license when they publish something (and respect the license's terms, obviously) are voluntarily letting go of their ability to restrict the user's usage of the program.
The issue I would have with "non-predatory" or "non-abusive" non-free software is that it does not allow me to fix problems I might have with the program. But this is only a problem I have. In other contexts, maybe a user needs to send (modified or otherwise) copies to other people of the software without being able to make sure the author agrees that this transaction is ok.
Fundamentally, non-free software restricts the user's freedom, even if it fully respects what the user would want to do. Similarly, a typewriter that can only output English text would restrict your freedom to type anything beyond English text (which is not something you would care about if you only wanted to write English).
That's the idea anyway. What do you think?
Stallman goes further than my preferred definition, insisting that Free Software must also be freely redistributable with no required payment. This cripples that very same market for patches by greatly limiting the resources available to fund it, and cripples the software itself if there's no big commercial interest backing it. The result is that Free Software is often not competitive with proprietary software, except when it does have a big commercial backer (Chromium, AOSP, etc) in which case that developer is often able to maintain a virtual monopoly on patches despite it theoretically being open to competition.
What do you mean? What would free software requiring redistribution payment look like? Say I send a copy of a free-as-in-freedom game that I may or may not have modified in some way to a friend or on a forum, should I pay its author(s) for this? How could I, for instance, commission someone to modify software if I want to change it when I don't have the skills to do so myself, in your definition of free software? I think a simpler definition, like Stallman's, is less restrictive of software modification.
Restricting how software is redistributed holds a great deal of power, especially when you remember the idea behind free software is that you get to have control over your software. Copyleft is such an example -- it is highly restrictive.
I get the financial issue one could have with free software as defined by Stallman; freeing the software you distribute is a difficult decision. Free software is advocated from the point of view of its users, who are ignorant to the difficulties one might face when developing and publishing software. If this is a decision you can make, it is kinder to your users to free the software you publish.
Side note: free software requires one to examine how they value commodities. Do you value the object itself, or the human time it took to make it? In a world where software is thought of as free by default, developers can be paid not per copy, but per patch. I believe such a world would be better for software quality because I agree with you that competitive markets are better at aligning with consumer interests than monopolies.
/e/OS already partners with Fairphone, if you like that hardware: https://murena.com/shop/smartphones/brand-new/murena-fairpho...
I agree that PostmarketOS needs a lot more love, but it's very far from being a daily driver system today.
/e/ rolls back privacy and security far more than LineageOS and /e/ includes their own invasive services. Murena services even send data to OpenAI without user consent.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a detailed post covering the lack of privacy and security of /e/ with a bunch of linked sources including other detailed posts by third party privacy and security researchers. It also touches on the lack of security of Fairphone hardware including end-of-life Linux kernel branches not getting LTS updates and delays for driver/firmware patches, but it's much worse with /e/.
I recognize that GrapheneOS has a different threat model in mind (journalists, activists, etc.), but /e/OS is a big improvement over OEM Android for most regular people. I tend to agree with your linked article that for users happy to live in Apple's locked-down glass box, iOS is a more secure, more usable system than either Graphene or /e/OS.
/e/ claiming a voice-to-text service is private while it actually sends the audio data to OpenAI is not the approach of a privacy project. Falsely claiming the data sent to OpenAI is anonymized when it's brought up makes it worse. That's one representative example.
I didn't mention GrapheneOS in my reply above, but it's not aimed at a niche audience or specifically for people who need advanced protections as your claiming. It provides much broader app compatibility, stability and usability than /e/ despite their inaccurate claims about it. GrapheneOS is a privacy project providing both privacy protections and also security protections to avoid exploits compromising privacy. iOS is certainly far more private and secure than /e/. It's definitely less secure than GrapheneOS against remote attacks on browsers, messaging apps, etc. iOS having a more secure kernel than the current status quo of hardened Linux doesn't mean it's more secure overall.
Your idea of a super-secure phone is a modern kernel with all the security patches running trusted, official signed Google Play spyware in a sandbox and all the apps collecting personal data in the same sandbox. There's an XKCD meme about this: https://xkcd.com/1200/ You are worrying about the printer drivers.
Taking advantage of privacy flaws in older versions of software is the norm and not treated as malware by most platforms, app stores, news sites or the public at large. Many widely used apps abuse privacy flaws in older Android versions. That happens both in the form of privacy bugs which were fixed in newer versions and weaknesses in the design addressed by newer OS versions. Only privacy patches for issues considered bugs which are assigned a High or Critical severity are backported. The severity is very subjective and they try to avoid adding a large number of backported patches since some OEMs struggle to keep up with it and adding more patches would make it harder. As an example, VPN leaks are only considered Low or Moderate severity issues by Android and don't get backported. Many other kinds of privacy issues are similarly only fixed for the latest OS releases. As another example, many important privacy improvements are not considered bug fixes at all and aren't candidates for being backported regardless of importance. Many privacy improvements require changing the APIs used by apps with new target API levels which can't be backported without breaking compatibility.
A large portion of the missing patches in /e/ we're referring to are privacy patches, not security patches. However, security patches are also needed to protect privacy. Many apps and services abuse the privacy vulnerabilities. The patches being referred to are a mix of both. A large subset are privacy patches, especially the Moderate and Low severity patches due to how they assign severity. Only certain particularly awful classes of privacy vulnerabilities can get considered High or Critical severity to be candidates for Android's backporting to older releases.
Apps exploiting security vulnerabilities to get code execution would be considered malware and is rare, but apps abusing many privacy flaws in older Android is the norm among mainstream apps. You're wrongly interpreting the regular stream of patches for vulnerabilities as only being for security issues when many are for privacy issues. With /e/, you aren't getting the bare minimum to protect privacy and security. Privacy also depends on security and is not an entirely separate thing as you're portraying it. We're not conflating them but rather they're very closely related. You're also disregarding privacy vulnerabilities and the steadily improving standard Android privacy protections.
https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
I really do not understand this comment at all. I don't understand the weird judgemental tone, and I don't understand that people have reacted to it like there is content there.
eBPF was introduced with Kernel 4.14 officially (but partly long before that). Most LineageOS supported devices still rely on older kernels, the most range being around the Kernel 4.4 or 4.9 branches, which lack that eBPF functionality. The LineageOS maintainers were backporting a lot of things already, but that's the "hardcut of now unsupported legacy devices" that people are experiencing with their old phones.
The issue here is that upstream vendors (e.g. Fairphone, actually meaning upstream Qualcomm IoT) only maintain their outdated kernel versions, and never maintain them in the sense of updating their driver code into newer kernel releases. The drivers are always stuck in an outdated state of a feature frozen kernel.
I'm just making this specific example with the Fairphone because "5 to 8 years support" isn't what most people would think it is. It means "only the really critical security patches of old stuff gets backported" and does not mean "hey we migrated our old code to a new kernel and Android version".
For example, Fairphone 1, 2, 3, 3+ are all stuck in old kernels right now (4.9 being the latest backport for the FP3+) and are essentially not updatable because of this.
I don't try to blame Fairphone here, because other manufacturers are much much worse in this regard. Fairphone and Pixel are already the "as good as it can get" for third-party ROMs case.
I mentioned postmarketOS specifically, because they're trying to fix that by upstreaming the kernel drivers, so that Linux support of those devices will stay updated with newer kernel releases (hopefully).
[1] https://source.android.com/docs/core/architecture/kernel/bpf
Just an aside, but this is one of the major downsides of monolithic kernels, and a case where microkernels would have had more consumer friendly upsides.
There's tons of evidence of this with stuff like linux distros, desktop environments (each one MUST have its own sanctioned file manager, video player, music player etc, god forbid some godless charlatan come along and make its own).
The price of admission into these 'tribes' is the adoption of the local creed (libraries/HIG/coding style/whatever/not speaking out against the Dear Leader/Core Principles/local purity committee). As with other such despotic organizations, incompetence and laziness is tolerated, disloyalty is not.
- Fundamentalists never hijacked the FSF, they founded it: Stallman is about as fundamentalist as possible about free software.
- In the case of the FSF, the fundamentalists are absolutely walking the walk, both in terms of contributing software, and in terms of going out of their way to not use proprietary software.
Performative and an example of very self-defeating tactics that belie motivations other than actually accomplishing anything.
> they founded it
This is true, but it actually contributes to arguments that the FSF is full of crazies content to preach from the monastery of ascetic suffering rather than live in a world with lots of independence and strong open source.
What are these "huge problems" caused by Pixel devices?
Isn't it only the device tree, and therefore only affecting initial support for the Pixel 10?
Doesn't feel like a huge problem, though it makes it harder to support the Pixel 10.
You can buy a new pixel, install GrapheneOS, and laugh thinking about how you're denying the enemy the OS level tracking they wanted with that device.
When you buy a used phone, it's already been bought by someone. The profit is already in Google's hands. Loads of old phones are in drawers somewhere. Once Graphene is on it, it's faster, not bloated, and you don't need Google anything.
If a major manufacturer released a good smartphone that GrapheneOS could support, they would get new users from the set of people who want GrapheneOS. I would gladly buy a non-Pixel as long as it can run GrapheneOS.
Which means that in a way, if you buy a Pixel and install GrapheneOS, you give more credibility to GrapheneOS, making it more interesting for a different manufacturer to consider supporting them.
I guess maybe a good analogy would be like trying to port coreboot to a laptop.
The project is about opening up the closed blobs that mobile chipsets use:
"This project's goal is not another Android distribution, but a long-term project to better understand and reverse-engineer the nonfree blobs used by virtually all SoCs made today."
There's little point in "partnering" with postmarketOS, because the project is literally about clean room reversing the proprietary blobs found in android devices: https://librephone.fsf.org/site/ - there are no commercial phones using postmarketOS with blobs to reverse engineer.
This is false: https://wiki.postmarketos.org/wiki/Purism_Librem5_(purism-li...
See also my other comment: https://news.ycombinator.com/item?id=45589096
You can install postmarketOS on it (just as you can install lineageOS, etc on a Samsung galaxy, etc), but it ships with PureOS. "The Librem 5 is a phone built on PureOS" - https://puri.sm/products/librem-5/
The project is to reverse engineer proprietary blobs - so it makes sense to go where those blobs are and reverse to match the functionality that is exposed commercially instead of guessing at a subset for base implementation on a non-official OS?
> See also my other comment
It seems you are just as confused about this project as the OP, which is ironic given your name.
Why does it matter? Yes, I would prefer that FSF collaborated with PureOS directly, but collaborating with postmarketOS also seems possible. There are enough blobs in Librem 5, which don't depend on the OS.
> which is ironic given your name
Indeed I'm quite surprised about the FSF actions lately.
Because to reverse it you need to have a functionally complete baseline to compare it to. For the Librem that baseline is what it ships with (PureOS). For nearly every other device on the planet, that is Android.
By them focusing on creating fully functional free drivers to swap out with the non-free driver blobs on Android, they will have created a reference source that can be adapted for any other OS.
But sure, librem5 probably has most of that already.
So it would be less work and would benefit more operating systems to work on it. Yet the FSF chose another hardware - I don't understand why.
How can you reverse engineer firmware without focusing on a specific piece of hardware? Firmware is tied to hardware, isn't it?
I realized that there will never be a vendor that actually open sources their firmware blobs. We need better legislation or a complete rewrite of our judicative system to fix this, which realistically is never going to happen.
It's an anti-model in their business world, given how contracts and licensing works from upstream ARM or NXP or MediaTek. It doesn't matter really where the vendor sources their chips from. They all have similar NDAs and contracts and royalty fees.
That's why I was so disappointed by my Librem phone, again, because they, again, promised that the NXP related firmware blobs were open sourced, which honestly was a very overpriced lie to begin with in comparison to the Pinephone devices that were sold at self-cost.
I have no idea how the FSF could recommend Librem devices, because they are literally just as free as every next door Qualcomm or Snapdragon chipset.
Because in FOSS world every single actor is a snowflake with unique vision. Any form of cooperation ends up in drama and moral accusations.
But as soon as FOSS orgs will obtain resources comparable to those of car companies I will stop complaining.
For example, there should only ever be one clipboard by default. If power users want multiple, they can go out of their way to configure their device config as such. Similarly, the function keys should function as function keys on a keyboard out of the box, without us having to fiddle with config files. Also the scroll wheel click to scroll should work out of the box without requiring editing config files. The default experience is still pretty poor.
What's missing is building something that resonates with the user/consumer's experience backwards, not just personal preferences or interpretations, which is fine, but at that point it's a personal project, not a product, or much larger unless it really captivates both people who can contribute to creating it and also it is adopted quite easily.
Creating beginners can seem like something too many OSS projects can be allergic to. It's the greatest sin of too many projects, and they ultimately can't be freed of it.
Of course no one can be forced to do so, but that's the problem - FOSS crowd would have to actually forced to cooperate, because otherwise petty dramas sabotage any common effort.
So if you tell them it's evil to fork you're saying, in effect, stop working.
I have lots of new functions for GNU make but the chance of getting them into make is almost 0 because the maintainer doesn't like this or that aspect of anything. Fortunately, I can make a fork. If people eventually show a desire to use my fork (nobody, unfortunately!) then he might eventually change his mind or develop some competing feature to kill mine off.
That's what is happening. To get people to pull together, they have to have a reason, like money.
But that's how a lot of projects do: Apache for instance, nginx, or llvm.
The problem is not being OSS, it is the lack of focus, and a game where everybody brings their ball and are playing the way they want instead of an unified game
Why does nginx exist? They could simply have found that config bug in Apache that made Apache slower and we wouldn't have needed another web server...?
Every project should have some competition, in the same way there are several commercial DBs available
At the same time we have several linux distros that suck in different ways
Ubuntu went down the weird GUI route but Linux Mint is OK - it's just nearly as complicated as Fedora.
Now I'm using Artix. The install was a bit old school but that's a one off effort. It's a rolling distribution so I almost never need to build dependencies to get something from git to work. There's never a "big upgrade". No selinux. The packaging system is extremely easy to use so I can often install the very latest e.g. chromium from git by building it myself and installing the package rather than a messy self-install in /usr/local.
In Artix all packages install with the dev component - no separation between dev and binary. For me this is vastly less hassle.
You can use Arch Linux (Artix is an arch derivative), with systemd if you want but I like Artix with dinit - it has all the ease of use of systemd but with an architecture that I prefer.
It's probable that none of this appeals to you, but I just wanted to point out that in an odd way I tumbled through lots of distros (including ones that I haven't mentioned) and found a little heavenly one that I love using every day because it suits my personality - perhaps you will too.
Apparently an usable daily driver already, FuriLabs' FLX1s. Nobody seems to have mentioned it yet.
Currently scope only seems to go as far as the operating system
These projects have stuff that works, but the lack of firmware for chips that can connect to modern cell infrastructure means that they can't really create an appealing product. The OS layer is where all previous Linux phone efforts have failed, and I hope the FSF makes it farther than everyone else has.
The OS layer is where the existing projects are thriving, with various distros and shells to choose from to match one's needs and tastes. It's the appropriate hardware that's in undersupply. I'm using a Librem 5, a 2019 design, and if I wanted to switch to something newer I can't because there's no viable upgrade path on the market. No other hardware vendor has invested significant resources into mobile GNU/Linux since then, everything else is either purely community-based or uses Halium.
One element of this could be a WiFi-only phone, effectively a VOIP endpoint which relies on whatever local WiFi is available for connectivity. Where a fixed-point WiFi isn't present, that phone could rely on a cellular WiFi hotspot. Given the various vulnerabilities and proprietary aspects of cellular comms, this at least offloads the security concerns to its own device.
Increasingly people are relying on Bluetooth devices to hear and speak through smartphones. The logical extension to me is to move the primary phone guts entirely into a Bluetooth earpiece or headset. This would handle the voice aspect of the call itself.
Palmtop computing appears all but entirely dead (with some DIY/hobbyist exceptions, e.g., the MNT Reform Next (<https://www.crowdsupply.com/mnt/mnt-reform-next>). There are also small-form-factor laptops, with 12" and smaller screens being comparable with tablets (and even some of the larger monster smartphones available today), but offering a full, user-controlled, operating system.
There's still the problem of software availability in an iOS/Android App-dominated world. It's technically possible to run many of these within a VM or emulated environment, but some app providers, particularly for financial interactions, attempt to detect and disable this. Ultimately regulation and/or lawsuits may be necessary.
As power-hungry as they are, mobile devices do make remarkable use of available battery capabilities, which is a place traditional laptops will struggle with. There's the question of having to carry multiple devices, though I suspect many of us are doing so already. There's also the possibility that market segmentation will make such users attractive to business and other institutions, reducing the barriers that presently exist.
All that said, I do applaud the FSF's effort, though I would like to see other paths (such as the one I suggest here) pursued as well.
> Triaging existing packages and device compatibility to find a phone with the fewest, most fixable freedom problems is the first step. From there, the FSF and Savoye aim to reverse-engineer and replace the remaining nonfree software. Librephone will serve existing developers and projects who aim to build a fully functioning and free (as in freedom) Android-compatible OS.
This needs to be done before age verification apps become universal..
But the modem binary blob is a whole other world, and I am not sure how they could tackle that, since my understanding is that this is partly done for carrier licensing reasons? ie. to avoid abuse on the cellular networks. So isn't an open source radio driver also going to have to be licensed in the same way, and then ultimately shared as another binary blob?
The PinePhone compromise seems to be 'isolating' the modem & blob at the end of a USB link. Although I'm not 100% sure how that works yet, since I only just got the graphics & fonts working.
But even that is a bit of a puzzler, since I'm currently framebuffer-to-lcd based, but I know there is a Mali GPU hiding somewhere. I suspect that will also involve another blob. Anyway, the framebuffer approach seems fine for now, it is booting in ~2s, and the less binary blobs involved the better.
It will be interesting to see what FSF can achieve. But, personally I think they would be better focusing on a fully open-hardware dumb phone, and build upon that.
Any reason that can't happen now in something like the Steam Deck?
[0] https://www.thinkpenguin.com/gnu-linux/usb-4g-lte-advanced-m...
Also i dont think routing audio is problem, the dongle could represent itself as external audio device, like those external usb dac.
Librephone isn't going to be releasing their own OS. It's an effort to systematically replace binary blobs so that existing projects like GrapheneOS and LineageOS are more free.
> Librephone will serve existing developers and projects who aim to build a fully functioning and free (as in freedom) Android-compatible OS.
It may well be that Google will not rest until "Android-compatible" means that they can put their foot down on this. We should be prepared for that eventuality.
Their efforts would be better spent on building up maintainers of existing custom ROMs and partnering with open source phone hardware initiatives like Pinephone. Maybe even go the route of HarmonyOS and run a completely different kernel and support Android app emulation. They should be looking ahead and not trying to match functionality today and it changes around them.
They should probably prepare themselves to make ideological concessions... The situation is very ugly here in mobile land. Treacherous computing, remote attestation, DRM, all ubiquitous and normalized...
Phones aren't x86 hardware, which only got open due to a lucky event, regretted by IBM.
Maybe this is my PM brain but why go after the most compatible devices first vs the most popular devices today?
Surely you’d maximize software freedom by targeting the most used devices so those can switch first
Why not simply start from scratch and make a truly open source phone? That is, design and build the electronics and the OS that goes on top of it. A bit like an iPhone+iOS but fully open source. Is this dream really unreachable?
I am so happy they are focusing on Android, one of the most popular operating systems widely used by every day people. This is important work for providing user friendly, free software to users.
Let's just hope they don't fall into the trap of disqualifying binary blobs sent as part of drivers vs opting for hardware that harcodes the blob.
Open Source Firmware signed by OS > Firmware blob signed by device manufacturer > Firmware blob hardcoded by device Manufacturer
The FSF treats hardcoded firmware blobs as "free" and updatable firmware blobs as nonfree despite there not being a big difference between them in practice. And practical differences like being able to fix security issues benefits users.
More often than not these updates are not actually benefits to the users.
https://news.ycombinator.com/item?id=45568700
There are by now thousands of examples of this, I wonder why you would ask for an example, this is about as uncontroversial as the sun going up tomorrow.
Yes, agreed, the entire idea of OTA updates to cars has a lot of bad consequences. No matter the license.
So when we analyze the entire position of the FSF, all three cases listed above, I don't think you actually agree with them. FSF isn't against updating firmware on the fly, they just want certain things when it happens. And those things won't improve safety.
But: Stallman & the FSF are idealists, they are not in a position to argue for practical measures, by definition they have to take a relatively extremist position and dig in. If they didn't do that they would get nowhere. So I understand why they're doing it but I do not think their stance is overly practical or workable. But everybody will dilute that stance in their own particular way and so the net effect is potentially positive. If they would take a much milder stance then that positive effect would be diminished.
I don't even mind the ROMS, I mind the ROMS that I can not read out myself.
The OP's point is, having the firmware permanently burnt-in on a ROM chip vs loaded as a binary blob via a driver doesn't change the "non-free"-ness of the firmware itself.
So opting for hardware which has a "fully-open-source" driver, but runs a binary blob encoded into the hardware, doesn't make the system fully open.
It's a take for a more Free system, not for accepting binary blobs.
(Or I guess for acknowledging that if you're willing to allow binary blobs stored in hardware, then dynamically-loaded binary blobs doesn't change the "free"-ness.)
They're saying approval of any who-knows-what code shouldn't be decided based on how it's loaded.
Concerning the UI, I wish we had another attempt at a web-based mobile OS. FirefoxOS was too early, but APIs are much more mature now, and WASM offers great performance for low-level stuff. I might work on this full time when I retire.
An initiative that supports a (quasi) mainline linux kernel and driver support for smartphones seems like the more logical initiative before ironing in a smartphone linux distribution.
In contrast, Librephone has only been aannounced this week, and it attempts to reverse engineer stuff related to device firmware and binary blobs. It's not the same as creating another Android distro, and any usable results won't be tied to Android, so they for example can be used to give better support for mobile non-Android Linux efforts.
Anyone who has replaced Windows 8 or Windows 10 on their 5+ year old machine with a distro like Xubuntu/Lubuntu realizes that "outdated" is often a sales propaganda term, not necessarily a technical term.
The leap I seem to have trouble getting to is this. If you can't trust the people responsible for the proprietary software, how can you be sure that they won't turn around and start using new chips or software once the existing ones are reverse engineered? Perhaps it's about patents and the patent holders could be using this IP as a cash cow?
but actually these kind of websites are way more informative also
instead of "clean" look where everything is just fluffed up
It does the job but it's not easy on the eye.
Full-width line of text. Readability nightmare. Here is how it looks with just a link to a CSS (I closed my eyes on the cssbed.com and picked one at random).
Two many xkcd already about creating new standards.
*Edit* Because Idiots are Downvoting me, look at the texas law SB 2420 as an example. These phones will essentially be illegal in texas unless they comply with already passed laws.
I can't take these jokers seriously.
Years after mobile phones came onto the market they are now planning to create their own phone.
For years they have studiously ignored the fact that the mobile phone is the place where many people engage with IT and have been faffing about in the desktop and server space.
Instead of leading they have always trailed behind. What they should have been doing was focusing on the software vision which they will most definitely screw up.
Focus on the software vision and wait for the deblobblable hardware to emerge or commission their own hardware from scratch.
I'm sorry but these guys have and will always be useless, much like the Wayland project.
How many years has that crew taken to create something fully capable of replacing X11?