Phones aren’t built to protect the end user, though it might they should be because they are part of everyday life. Most modern phones are actually built with the idea of exploiting the end user by analyzing and categorizing you and then selling who you are to others. This is called surveillance capitalism. It’s where you personally are analyzed, and then your analysis is used by the companies gathering the data or is sold on the open market. This leaves some of your most private data in the hands of vendors, advertisers, governments, and, well, anyone who gathers or buys your data.
Without any doubt.
Like how PureOS on Librem 5 includes geoclue
by default, which by default sends user location data to amazonaws
every few seconds?
i agree, but unfortunately the librem5 is still no solution/replacement to this.
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.
When was this something they did?
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.
So, does coreboot have blobs that self update or simply static blobs?
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.
Out of curiosity… which phones or computing devices do you use?
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.
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.
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.
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”.
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.
Automatically downloading and executing mystery binaries from the internet that cannot be audited would not be an improvement.
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.
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.
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.