i agree, but unfortunately the librem5 is still no solution/replacement to this.
1 Like
Purism ship Raw Opensource-Evil_FirefoxESR-Google’s-default-settings, which does Not add privacy security Freedom for PureOS.
Also Purism shipping updated BLOBs to Librems without user Consents. This is an known Evil Practice from Opensource or FOSS.
2 Likes
When was this something they did?
1 Like
Purism it doing all time through Coreboot and Das-uboot Firmwares through Opensource Purism Programmers.
Even worse Purism also initiated by introducing BLOBs to PureOS directly through JAILs just to bypass FSF Rules but FSF Reject this Evil Practice.
2 Likes
So, does coreboot have blobs that self update or simply static blobs?
1 Like
It is Static Blobs but Purism is Accepting to updating the Blobs through Opensource Mainstream Coreboot or Uboot. I strongly do not Trust on any BLOBs and it is Shame that Purism Ridiculously Trusting on Blobs.
1 Like
Out of curiosity… which phones or computing devices do you use?
2 Likes
And for those unaquainted:
Raptor Computing Systems is closely associated with Raptor Engineering, which helped develop Libreboot on a few motherboards all those years ago.
2 Likes
I am very thankful for all the work Purism has done and continues to do enabling people to protect themselves from Google/Microsoft/Apple’s unconsented-to-stalking-for-profit. Please, keep pushing forward and innovating to protect people! You will have a lot of passionate and loyal customers if you do. Purism is a special company. Creating a mobile GNU/Linux interface, maintaining a fully-free operating system (PureOS), and adding usable kill switches to a phone (Librem 5) are all awesome accomplishments.
On the other hand, for example, the Librem 11 seems a big move in the wrong direction. No easily removable battery and no kill switches, with a lot of proprietary code in firmware jails. Of course, it is still better than the competition.
As others mentioned above, Gnome and Firefox are not privacy-respecting by default. Disabling some of their anti-features is one big area for potential improvement.
Thanks for all the hard work Purism.
3 Likes
I just want to say thanks for removing trackers from link. People didn’t say anything about it, but we recognized it. And as you can see, people still discuss things and focus more on topic.
3 Likes
This was pointed out once already, but I would like to address it:
Also Purism shipping updated BLOBs to Librems without user Consents. This is an known Evil Practice from Opensource or FOSS.
We did not update any blobs without user consent. We are transparent about what non-free components are in system firmware. System firmware updates can only be done manually today. I would like to improve that, because users often do not know to update firmware to get fixes they need, which I entirely understand.
I do not believe we have done anything “evil”, and responding to vague accusations is impossible. Please open a thread if you would like to discuss anything specific that you feel is “evil”.
5 Likes
Speaking of which, I used Crimson for quite some length of time while I was writing the Qubes OS image onto the other USB drive, and the overall experience is much better than using the Byzantium image. Also, Epiphany has been completely replaced by Firefox ESR, which now comes with uBlock Origin and Privacy Badger by default.
3 Likes
Automatically downloading and executing mystery binaries from the internet that cannot be audited would not be an improvement.
2 Likes
There are still solutions where it is easier to update than manually running shell scripts and answering questions, but not doing anything you haven’t chosen to do.
2 Likes
I see where you are coming from, but from my perspective, making proprietary firmware updates easier doesn’t improve anything.
For example, let’s say I have a computer with some un-auditable executable bits inside it (proprietary firmware). Then, let’s say that the publisher of the firmware, MalevolentCorp, discovers a security vulnerability in the un-auditable executable bits, informing everyone that the vulnerability needs to be fixed. So, my computer is insecure and unsafe because it contains that vulnerability.
Now, I believe you are saying that making it easier to inject new un-auditable executable bits from MalevolentCorp into my computer will improve security for my system, because MalevolentCorp will be able to fix the vulnerability in my system, making it “secure” and “safe”.
I disagree. Injecting the new un-auditable executable bits from MalevolentCorp is itself a security vulnerability that compromises my system, making it unsafe and insecure. Either way, I have an unsafe and insecure system, and I have no good way of judging which path yields a more unsafe, more insecure system. So, making it easier to inject new un-auditable executable bits into my computer (e.g. automatic proprietary firmware updates) offers no improvement in terms of security.
In fact, the opposite is true. By regularly allowing MalevolentCorp to inject new un-auditable executable bits into my computer, I know for a fact that my system is unsafe and insecure, even if MalevolentCorp never discovers any genuine oversight on their part leading to a vulnerability.
So, while I can see where you are coming from, making it easier to update proprietary firmware will actually lead to less security and safety for your customers.
3 Likes
Thank you for such a well-constructed explanation @weirdnerd. I agree that this is an inherent problem of any proprietary software, especially the proprietary components needed for firmware that we have not been able to eliminate. This has to be taken into consideration if any changes are ever made to the way we offer firmware updates.
Many firmware fixes don’t require changes to any proprietary components, maybe these should be considered separately from an update perspective. The OS could in principle update coreboot and the payload while preserving the existing microcode, FSP, ME, etc. Testing would be a bit more challenging here (the complete firmware has to be tested before release, since most users can’t recover non-booting firmware), but I think that is solvable.
Any solution to this problem has to respect the owner (not create vectors for proprietary code), and I believe we can do that while improving the experience for non-technical users as well.
4 Likes
Have you reported this?
One of the Purism principles is “the power of defaults” and I remain firmly convinced that using WiFi in geoclue should be off by default.
Of course, for my own phone, it’s in my list of things to check / change. So no drama for me personally.
1 Like
I mentioned it on this forum in a few places. Is there somewhere better I should report it?
This all being said, although I found myself at a location where the Librem 14 and Librem 5 both felt it necessary to ping the Mozilla Location Services frequently even when idle with no applications open, more recently I’m in a different place. And I just sat doomscrolling the tcpdump log on my Librem 5 for a while and I did not see it list amazonaws traffic when idle, even though today I’m on a different Librem 5 with a different install where geoclue had not been properly tweaked nor shut down to my knowledge.
So, I’m not sure exactly what is the trigger for the system feeling the need to ping location.services.mozilla.com and sometimes it seems we are not pinging it. But in a location where we are pinging it, the traffic was fairly constant and that’s how it becomes so concerning to me.
After reading this thread and looking back at my own posts, however, I would like to say that I greatly appreciate what Purism is doing and the Librem 5, because on other mobile devices asking the machine to inform me about its internet traffic is these days not even allowed, which seems nuts. So although I can be a bit negative about something like geoclue, being able to even find and identify it is leagues beyond Android or iOS.
It’s tough for me reading the back and forth you guys were having about firmware blobs. I surely don’t want any in my computer. But it seems like, I haven’t actually put in the time to inspect the non-proprietary code of any of the firmware anyway so when I think about not wanting proprietary code in the system, I’m being ideological rather than practical. The perhaps better more practical thing for me would be if I forced myself to learn all the code in the system by forcing myself to rewrite or regurgitate it all, and yet I have not done so and will quite possibly not do so anytime soon because of the time requirement involved.
I don’t know the answer, but I know that when I use the Purism devices I feel more of sound mind than when I do not use Purism devices. So please stay motivated, even in the face of adversity.
5 Likes
You would raise an Issue. But you would need an account to do that. So you would first apply for an account if you don’t already have one. Any existing Issue will give you the link to do so e.g. Secondary call disconnecting kills audio on established/primary call (#311) · Issues · Librem5 / OS-issues · GitLab (top right corner)
2 Likes