…without it you cant properly secure the phone.

My understanding is that a locked bootloader helps protect against evil maid attacks and bootloader-level malware persistence. I find this a security risk that I would absolutely take for Google independence. “Properly secure” is subjective.

GrapheneOS do decide what phones they support. It is exactly their choice to support only Google Pixels, rather than taking a security hit for hardware independence (whether you agree with the decision or not).

My comment was to answer the question of: “Why is this relevant?” (Its been asked a lot). It’s relevant because Bitwarden is claiming that they “cannot see your passwords”.

Removed by mod

Removed by mod

Bitwarden is a zero-knowledge encryption password manager. This means that Bitwarden as a company cannot see your passwords. They remain encrypted end-to-end with your individual email and Master Password. Bitwarden never stores and cannot access your Master Password.

At which point it simply gets forked from the last release/commit. Unless the project nukes all of the history and no one comes forward with a backup.

And, they would typically need the consent of every contributor to legally change the license, unless they had been forcing contributors to sign over rights to their code before contribution.

they didn’t create a fork under their control

I’m sorry but this is simply incorrect (See 1,2,3), as I have previously stated. You could point to sources that agree with you though if you disagree.

1: https://itsfoss.com/librewolf/

2: https://wiki.gentoo.org/wiki/LibreWolf

3: https://lwn.net/Articles/1012453/

These are some examples that use “fork” in describing Librewolf.

What they are doing is customising the current code of Firefox at the time of compiling the LibreWolf project.

You have described the creation of a fork.

… I’m not going to continue a fruitless argument.

I’m here if you wish to discuss further.

there is no mention of that anywhere on their website.

A custom version of Firefox, focused on privacy, security and freedom.

This project is a custom and independent version of Firefox, …

LibreWolf is a free and open-source fork of Firefox, …

This repository contains all the patches and theming that make up LibreWolf, as well as scripts and a Makefile to build LibreWolf. There also is the Settings repository, which contains the LibreWolf preferences.

They take Firefox, make changes to it, then release it. As such, it is a fork. More specifically a “soft fork” since they continue to pull changes from upstream (Firefox).

EDIT: Oh I see you’re focused on the “duplication of the code” part. A bad phrasing on my part. It doesn’t matter the specifics of how they pull in the source code, it is pulled in and used as the basis for librewolf’s modifications.

They could even pull it in on first launch and compile the latest version of Firefox with their modifications for subsequent launches and it would by all means be a fork, since they are shipping a modified version.

LibreWolf is not a fork, though.

It certainly is.

They duplicate the code, creating a “fork” under their control, and make independent changes to the code. That is all that is needed to satisfy the “fork” definition.

Some of those countrymen are conscripts. 2/3rds? Which makes continuation of battle far less justifiable IMO.

Some people will choose to fight in Ukraine, to possibly die in Ukraine. Conscripts face punishment for refusal.

How many of those fighting would refuse the peace deal?

High memory usage isn’t a problem by itself.

The issue is when it’s used inefficiently or for useless purposes. An unoptimized application takes 500MB of extra memory and that is 500MB that cannot be used for read/write caching nor another application, and 500MB closer to an OOM situation.

In theory, an application can suffer from issues of underutilization of memory, just as one that over-utilizes memory. In practice, I find that lower-than-expected memory use is a much more positive indicator of an optimization-focused project than one that uses more memory than expected.

In the meantime, it’s not sitting there, unused and useless.

If your system uses caching, then “usused” memory may not be so. Memory used for caching is also cleanly “Available” for use if needed. This is not the case with the 500MB of extra memory a process might decide to capture. Of course this is complicated further with swap (I wouldn’t use it).

I’m reminded of the horrid example showcased on the amber-lang website previously.

…needed.

Wanted. It was a choice.

Overreaction is the only tool that works to stop enshittification before it starts.

Overreacting can undermine your cause. I don’t see how reacting accordingly cannot “stop enshittification before it starts”.

It can be if you buy from stores, such as GOG and Itch, that provide DRM-free downloads of games. Even Steam, depending on the game.

Do you lock your door at night? Why? Anyone could just use a fireman’s axe and open it. Or they could just drive through your living room and steal everything.

For kernel-level anti-cheats its quite simple. Those in opposition to kernel-level anti-cheats likely view locking a door as a small task with minimal downsides, which could reasonably deter an opportunistic criminal, or buy you time to escape with your life or call the police.

They also likely view kernel-level anti-cheats as, for the benefits they provide, having too large of downsides. (providing a third-party company kernel-level access via a closed-source program)

If you’re concerned about privacy just dual boot windows in a separate SSD to play games and use Linux and Graphene OS.

In another thread in this comment section I mention UEFI rootkits and firmware implants (kernel-level access is strong starting point for this). Your solutions do not address these issues, which could be important to someone. (Depending on their threat-model)

If you tell me that all I need to do to negate the security concern of the kernel level anticheat is to run the dualboot windows partition…

…it makes intuitive sense that installing a kernel level anticheat would only affect the windows kernel it was installed on not the linux kernel on the other drive partition.

The intuition is incorrect as the kernel-level anticheats are not necessarily trusted. Operating systems interact with low-level hardware and firmware on the system. As such, it is not self-contained.

https://www.kaspersky.com/about/press-releases/more-elusive-and-more-persistent-the-third-known-firmware-bootkit-shows-major-advancement

There exists both UEFI bootkits and firmware implants. Its intuitive if you understand it like this: if there exists a communication pathway from (A) lower-privilege code -> (B) higher-privilege code, there exists the potential for vulnerabilities.

This is due to (A) now having an effect on the code execution for (B).

I might have been experiencing this issue for the longest time. System fully locks up and is completely unresponsive. Happened on every distro I used.

Last distro I had it on was Artix Linux. Then I tried Alpine and I don’t think I’ve had it happen since.

…Apple does not.

Talk is cheap. Show me the code.

5. Remote didn’t work as well for the company.
6. Remote didn’t work as well for any number of people at that company.