"Librephone is the FSF's project to free up those blobs. 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. " Looks they're going to build something literally from the ground

I feel that free software sometimes obsesses over the 1% when the 99% of their objective is achieved.

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.

> I feel that free software sometimes obsesses over the 1% when the 99% of their objective is achieved.

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.

> I feel that free software sometimes obsesses over the 1% when the 99% of their objective is achieved.

Yes, that's what it means to have ideals.

  > we all would agree that there's some functions of government related to war and security that should not be transparent

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".

  > 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.

Yeah but the problem here is that the FSF has this annoying track record of being proven correct, over and over again. Two of your examples are github and android: github got bought out by microsoft, and android is about to be hobbled to the point that f-droid won't work on it anymore. If you want to go and look at the history you'll see a bunch of other instances of Stallman and the FSF saying things that sound paranoid at first, but which turn out to be correct in the long run. It's genuinely annoying, life would be easier if they were wrong occasionally.

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".

If your enemy knows your entire plan of attack in a battle you will lose. This isn't theoretical it's just a fact. It's why military organizations invest so much in intelligence. Knowing what the other guy is planning gives you a massive advantage.

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.

I'm not at war with anybody though.

Good for you, but that has nothing to do with whether secrecy is necessary in a security context.

it does, however, point out that there's not been a valid security context listed where secrecy would be necessary.

Pull your head out of the sand my friend. There's murders, kidnappings, wars occurring around us every day.

which of these requires my government to not be transparent?

"Yeah but the problem here is that the FSF has this annoying track record of being proven correct, over and over again"

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.

That doesn't actually mean that they're not correct.

too many false positives means you should reconsider what you call a false positive

> free software sometimes obsesses over the 1% when the 99% of their objective is achieved.

That is the nature of software. 1% is too much. It is Free or it is not

From my understanding of the article, Postmarket or Lineage or any other mobile operating system will be able to make use of this project. The goal is to provide FOSS drivers, so that you can run Lineage without proprietary blobs copied from the distribution of Android provided by the device manufacturer.

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"

There aren't even any arm or x86 desktops that are completely blob free. There is some ridiculously expensive amd power hungry power9 thing that nothing will run on, and some of sifive's newer boards might qualify. Every arm at least has some soc blobs. And every x86 has something like ime. Going straight for a blob free phone seems like getting ahead of ourselves. How about we shoot for a completely free rpi usable on the desktop first?

Rockchip AFAIK doesn't have any. It boots with mainline u-boot, but it doesn't include any wifi or other radios.

It os definitely more open than most, thanks! I'm pretty sure it still has the masked boot rom before getting to the open bits. While the tpl and ddr are still blobs and might harbor naughtiness, people have at least figured out how to edit the blobs https://github.com/hbiyik/rkddr

U-boot for Rockchip builds it's own TPL. I'm using it right now. It can also use Rockchip's TPL, but that's optional, not the default. DDR training code is here:

https://github.com/u-boot/u-boot/tree/master/drivers/ram/roc...

Also, libreboot supports quite a bit of hardware. What binary blobs are left of you have one of those systems?

No, software licensing often gets in the way.

They are also software that is licensed?

AFAIK you can use and reverse engineer the firmware blobs on any OS, free or not.

Reverse engineer? Probably. As long as there aren't patents involved. And that is what the librephone project aims to do, from what I understand.

But the binary blobs are protected by copyright, so you need a license to use them.

Legally, you mean? In the US? Interested in more info on this.

Sure.

https://en.wikipedia.org/wiki/Clean-room_design

That doesn't make sense to me, extracting/copying a firmware blob is not clean-room design. It would only be clean-room design, as the article you link to explains, if you constructed it yourself from scratch based on the functionality you understand it should have. But ok!

You might have gotten lost on the steps involved in clean-room reverse engineering here?

>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.

I wonder if it's one of those situations where the potential for legal system abuse is a chilling effect.

Can you elaborate?

Such as when it's technically legal to do something as long as you do it a certain way, but the interested parties may not believe that you did it correctly and will bury you in legal discovery requests that financially ruin you or force you to stop.

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)

Mobile software is unfortunately not really a lego that can always be combined at will.

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).

That's not entirely true.

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.

LineageOS kernels are AOSP downstream kernels, and PostmarketOS has expressly deprecated their use. LineageOS is now working on running their system on close-to-mainline kernels, as provided by PostmarketOS and most Linux distributions.

> Mobile software is unfortunately not really a lego that can always be combined at will.

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 postmarketOS, LineageOS, GrapheneOS, or CalyxOS? This would be an open source initiative that contributors from any of those projects to add to. The results could be used by any of the aforementioned distributions, and more. It might even make running vanilla Linux on our exiting smartphones viable.

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.

> tearing down the proprietary software barriers that prevent the vast majority of smartphone users

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.

This project is about reverse engineering the firmware blobs. It states that they do not want to create a distribution like postmarketOS or other projects do.

The listed distributions have already been created. The OP didn't suggest to create a distribution but to collaborate with existing ones not relying on the Google's OS.

Graphene and Lineage both rely on Google's OS, so this is not what the OP was saying.

Did you miss postmarketOS in the OP's post?

Why are all commenters on HN ignoring the only smartphone running an FSF-endorsed [0] operating system, Librem 5, and only list everything else? I just can't get it.

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?

[0] https://news.ycombinator.com/item?id=25504641

[1] https://www.fsf.org/givingguide/v11/

as someone who has followed this phone for a long time, it has had an image problem - fairly old hardware, early software/buggy, and bad customer service experiences.

i'm still pretty tempted to play with one.

> fairly old hardware

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.

We are talking about the FSF here, not Apple. The former concentrate on the user freedom, not modern hardware or polished experience (which is a good thing).

We know that you will post something about Librem 5 so there is no need for anyone else to do it.

It’s amusing to me that whenever I see a submission about Linux phones, I start looking for the obligatory @fsflover comment.

No bad feelings, fsflover, keep up the good work. I also can’t wait to post on here from a libre phone.

> LineageOS has huge problems since the mandatory eBPF requirements of late Android versions

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.

You have a good point about things coming together, but open source often is a lot of design and development by committee, or interest.

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.

Librem?

> Open source loses this war because proprietary devices are streamlined.

"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.

> It was exactly "Open source" that enabled Google to dominate the smartphone landscape.

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.

This is the one big flaw I've seen in Stallman's philosophy on software. He's been thoroughly proven right I think about the dangers of closed-source (unmodifiable) software to user freedom. But I think his insistence that Free Software also needs to be freely redistributable with no payment to the author in order to be Free has greatly limited the resources available to build such software.

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.)

[1]: https://www.gnu.org/philosophy/selling.html

> It's not a viable business model.

> 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].

[1] https://store.xwiki.com/

[2] https://osmand.net/

[3] https://conversations.im/

¹ I work for them

As I said that's just another way of soliciting donations; it relies entirely on consumer goodwill (or ignorance/poor accessibility of the free option). There are limits to how big you can get with that (or how much you can charge) before someone just undercuts you with a fork.

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.

It's nothing like donations: people pay these extensions / apps like any other paid software. That's my point, actually.

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 just another way of soliciting donations; it relies entirely on consumer goodwill (or ignorance/poor accessibility of the free option).

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.

The main reason Netflix is more convenient than piracy is that piracy is illegal. If The Pirate Bay was allowed to offer a $2/month unlimited movie streaming service with no legal repercussions, Netflix would be out of business.

Actually, piracy became rare exactly when Netflix became easy to use and not when the former became illegal (which it always was).

Hey don't discount the work that various actors did to make piracy less convenient as well. VPNs and upload caps, not to mention putting all the infrastructure and ops in place to force people to use them made piracy harder than it technically needs to be.

We should have terms and rigorous standards for software that is proprietary but not otherwise restrictive of user freedom. Most (weighing by how commonly it's used) software is either traditional, abusive, proprietary software like Windows or Google'd Android or is fully free like Linux. But, there is a large library of software that isn't under a free license, but doesn't attempt to abuse the user into being more profitable beyond any initial sale. Examples include the Nvidia drivers on Linux (but not Windows), Jetbrains IDEs, many game engines (I'm thinking of Unreal here), and most commercial software in the 90s and 2000s. The defining feature of this is that 1) it is not under a free license; and 2) aside from basic license checks in some cases and bugs, it never does anything against the interests of the users. Having well-defined standards and terms in this area could encourage more of such software, for product designers that appreciate the promise of free software but are not convinced by its revenue options.

The initial sale never has and never will be the issue with non free software; in fact, they can sometimes be acquired free of charge. I get your sentiment and I agree with you that some software can indeed be proprietary without being predatory or abusive.

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?

I think what GP means by "user freedom" is that the software acts in the interests of its users rather than the interests of its developers. Some proprietary software does do that, but there's an inherent conflict of interest there since the developer has a monopoly on the ability to control said software. Software that is open to user modification (which is how I would personally define Free Software) protects against this conflict somewhat by creating a free market for patches to the software, and free markets are much better at aligning with consumer interests than monopolies.

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.

> Stallman goes further than my preferred definition, insisting that Free Software must also be freely redistributable with no required payment.

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.

> 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?

Your friend would have to buy a copy of the original game from the author (or a reseller) before using your modified version of the game. You could even sell your mod to others, but they would also have to own a copy of the original software in order to use it since what you'd be selling is the modification, not the original software it depends on.

This is technically already legal, except most apps don't have the source code available for you to modify in the first place, and some companies try to abuse license terms to prevent it.

> 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?

You'd just... do that? Same way you commission a mechanic to rotate the tires on your car. You'd have the source code and build tools. What's the problem exactly?

> Restricting how software is redistributed holds a great deal of power

I agree. I don't think authors of my version of Free Software should have control over how software is distributed except that new licenses have to be purchased from them. Once a license is sold, I don't think the author should have control over how that license is used or who it gets transferred to (except perhaps a modest limit on how frequently it can be transferred, to prevent shenanigans like third party floating license pools).

> developers can be paid not per copy, but per patch

I don't think this is very practical with Stallman's version of Free Software, because once you sell one copy of a patch that person can just turn around and sell it to others, undercutting you. So you'd have to price your patches at an absurdly high rate to recoup your costs. Effectively you'd be selling a personalized support contract, not actually selling software. This model sort of works in commercial contexts (hi Red Hat), but it's clearly not competitive with the proprietary software model. (Compare the market cap to giants like Microsoft, IBM, Oracle, etc.)

Most people have no interest in redistributing software, they only want to use it.

PREACH. Sorry. I felt heard and seen!

I prefer /e/OS to LineageOS because it includes sensible defaults (e.g. Maps app + MicroG with location providers and signature spoofing enabled) that are a pain to set up for yourself after flashing vanilla LineageOS.

/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/ has extraordinarily poor privacy and security. Extremely delayed privacy and security patches including years of delays for kernel, driver and firmware updates or complete AOSP patches is not compatible with privacy.

/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/.

You post something similar almost every time /e/OS is mentioned.

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/ isn't a safe option for regular people. It doesn't provide the most basic privacy and security patches or protections. Multiple years of important privacy and security patches being missing is terrible for a personal computer with tons of sensitive data. Replacing the stock OS on a Pixel 7 with an OS multiple years behind on important privacy/security patches and protections with different service privacy issues is not an overall privacy upgrade. /e/ has their own privacy invasive services including sending sensitive user data to third parties without consent and user tracking via unique identifiers.

/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.

I think your threat model is wildly backwards if you believe that average users are concerned about threats from bugs in old kernel versions. In all of your posts, you carelessly (or deliberately?) conflate privacy and security. This is the same shell game that Google themselves play in their marketing https://www.tomsguide.com/phones/google-pixel-phones/the-pix...

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.

/e/ lacks privacy without taking exploits of unpatched security vulnerabilities into account due to having severe unpatched privacy vulnerabilities, lack of modern Android privacy protections and lack of important privacy features filling major gaps in Android privacy covered by iOS such as Contact Scopes and Storage Scopes. Some major gaps in privacy aren't covered by either Android or iOS such as a Sensors toggle, especially with how the sensors can be used to do rough recording of audio.

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.

Supposedly Graphene is partnering with a major OEM (they say "one of the top 10") to get better hardware support. Even then they're still at the whim of Google, though - the most recent QPR1 update still has not been pushed to AOSP even after many weeks. Supposedly partnering with an OEM means they get these updates quicker but who knows.

You may have missed this, it's only been ~11 days since the post but they've got a solution now, with the first release having happened:

https://discuss.grapheneos.org/d/27068-grapheneos-security-p...

This is a security patch which is different from the QPR1 release. _Supposedly_ once they partner with an OEM they will get more reliable access which would be nice, but I'm hesitant. I switched my Pixel 8 Pro to Graphene a few months ago and really like it.

Why is eBPF a problem?

A lot of functionality of newer Android releases (Android/AOSP 13 and later) rely on eBPF [1] for both interception of process insights and sandboxing of processes. eBPF in a nutshell is a way to build kernel hooks, so that you can also disallow or intercept syscalls or kernel API calls that the Apps are executing behind the scenes.

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

> only maintain their outdated kernel versions, and never maintain them in the sense of updating their driver code into newer kernel releases

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.

I don't think Android is really using eBPF for much. Last I remember they were loath to adding more things and they've definitely locked away the ability to load arbitrary new programs because they couldn't secure the attack surface it opened up.

I'm pretty sure they said they're partnering with everybody that they possibly can. I also don't know what you mean by "just partner with postmarketOS." It's basically a project to create a fully-free Android-compatible distribution (or rather the fully-free low-level elements that would support this), and postmarketOS is not Android. I also don't have any idea why you think that they wouldn't be talking to everybody who is reverse engineering phones to get OSes on them.

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.

I agree about postmarketOS but eOS isn't the same as Lineageos, I used both and they are pretty different. eOS wants to have its own non-Google ecosystem which is a non-goal for Lineageos

You're forgetting 1 tiny thing: the wjole AOSP ecosystem is running on volunteer dev time. It's much more difficult to organize and streamline vision / roadmap.

As in every idealistic movement, the fundamentalists(which contribute all the talk and non of the walk) hijack it and drive it into a wall.

Your statement is wrong in two distinct ways:

- 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.

> 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.

> GrapheneOS has huge problems because of Pixel devices, which LineageOS could help with.

What are these "huge problems" caused by Pixel devices?

Probably that Google is dragging their feet releasing Pixel kernel and other source code. LineageOS has many years of experience getting a working system on top of bad or incomplete sources, including getting kernel source out of vendors in the first place.

> dragging their feet releasing Pixel kernel

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.

I will never use GOS as long as it requires me to buy a Pixel, on principle, because it's made by Google. It's like having to buy a Microsoft Surface in order to use Linux.

You can use an older pixel, thus not really giving money to Google, and also preventing that phone from landing in a landfill. Without all that Google and carrier excess junk on board, an older phone is fast.

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.

But you still support Google and the closed source Android ecosystem with that.

No, actually, you don't. And Android is not closed source. Google's add ons are.

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.

You could offset that by convincing others to use graphene, and by degoogling your device you’re also cutting off one of their other income streams

The reason why GrapheneOS only supports the Pixels is that the other manufacturers are not trying to get their shit together and release a phone that is reasonably secure. It's not that GrapheneOS supports Google, it's just that the other manufacturers are worse than Google.

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.

PostmarketOS has never achieved proper support on any device so far.

Doesn't this count? https://wiki.postmarketos.org/wiki/Purism_Librem5_(purism-li...

Looks like it is not. Unfortunately.

What's not proper about it?

At least camera and other sensors. It looks much better than other devices, though. What I meant is that compared to Android, the average user might not want a half-baked device.

I got an FP5, would not buy again.

Could you elaborate on why? This type of comment doesn't add any value.

We bought two FP5 with e/OS/ from Murena (for spouse and myself), and would buy again. Why wouldn't you?

I don't like how /e/OS claims everywhere that they support all those phones, when in all my experience they just can't keep up and I end up with phones that don't receive vendor firmware updates for 1+ year.

I considered purchasing it, but ultimately turned it down due to its size. What's the reason you're not liking it?

I like the size. I do not like the weight. I love the phone overall though. Love love. Good choice despite downsides.

I got a FP4, will definitely buy again.

Can you elaborate?

Did you read the article? They're not creating nor choosing an operating system for the librephone project. They're looking into reverse engineering the binary firmware blobs needed to achieve a fully free software distribution on a modern device. Afaik, this work will benefit all alternative OS projects for whatever devices they succeed with.

I guess maybe a good analogy would be like trying to port coreboot to a laptop.

TLDR or something? They aren't making an OS.

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."

Thats clearly not what the OP is suggesting as per "Why do we have to have /e/OS instead of a better supported LineageOS, because /e/ is a 1:1 copy anyways?". Both cases are android. /e/OS is not librephone.

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.

> 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

> This is false

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.

> but it ships with PureOS

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.

> Why does it matter?

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.

You're right about the drivers, but you don't need to reverse engineer them for Librem 5: They are already free. You only need to do it for the firmware, which AFAIK doesn't depend on the OS.

"Non-free driver blobs" in the librephone context means anything needed to drive the hardware. i.e. kernel drivers, HAL modules, firmware images, user-space vendor libs, etc.

But sure, librem5 probably has most of that already.

> 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.

Because they aren’t focusing on a specific piece of hardware… I’m really not sure what you are expecting? The librephone project to be focused on librem5 instead of the hardware used in thousands of other devices?

> Because they aren’t focusing on a specific piece of hardware…

How can you reverse engineer firmware without focusing on a specific piece of hardware? Firmware is tied to hardware, isn't it?

Clearly you are just trolling now.

I wanted to mention that back then when Mozilla announced its FirefoxOS based devices with the "ZTE Open" as a developer device, I realized how broken the ecosystem actually is. The ZTE Open wasn't actually open source and you weren't even able to compile FirefoxOS completely, and only the Gaia (UI) parts could be flashed or changed. So much for open source as a branding, it was a pretty useless device in terms of development.

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.

Are you talking about the Librem's blobs in modem/WiFi or something else?

The FOSS world is primarily about freedom. You don’t have to align with someone else’s vision, you don’t need to be profitable, you don’t need to care about other projects

A.k.a. not getting paid, so you might as well do what you want.

Why do we need so many car models and manufacturers?

I don't mind the many multiple distributions but the default experience really sucks.

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.

So what exactly is the problem? To many options?

The options thinking they're an island retreat only for those who agree with their way while standing on the same continent.

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.

Either software is free or it isn't. You can't have single-vision-central control and freedom. Android is an example of an effort that took something free and made a usable mobile operating system ontop of it - but lead straight back to the problem that it isn't fully free.

Hm, there is also an option to avoid creating yet another fork the moment someone said something unpopular, or to try helping improve existing solutions instead of creating yet another cool project that achieves nothing.

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.

Forks happen, I think, because someone doesn't agree with the direction or can't get accepted into the clique of people working on something.

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.

Graceful forking is different than .. what too often happens with keyboard warrioring.

> You can't have single-vision-central control and freedom

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

To take LLVM as a convenient example ... why does it exist? Why didn't Apple pour its money into GCC?

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...?

Licensing reasons apart it's exactly because governance, even of these big projects like GCC suck

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

I found a distro I love. I was a Fedora user but it just ended up being far too complicated with selinux. It is a miserable job to try to create RPM packages that work and also miserable to try to build anything out of git where the dependencies offered by fedora were too old - and then it wouldn't work without some kind of selinux config anyhow.

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.