Most high-level languages do a lot of things implicitly, like casting types, cloning values, deciding what the default is. Rust tends to avoid that, which though less convenient makes behavior more predictable, reducing footguns and surprises.
Mint is a glorious debloat of Ubuntu with several extras and are strategically wise in having LMDE ready and in production. They fill a very important role as an user-friendly not-DIY distro suitable for someone completely unfamiliar with Linux. I wouldn't describe Fedora that way. It changes too fast for that use case and compared to Mint comes with not much preinstalled.
I wrote a small script that takes a query as its single argument and if it finds a matching filename in a given directory it shows that in a pager. If it doesn't, it uses ripgrep to search inside that directory and returns the filenames in a picker. If I prepend the filename with e, it opens that file (either existing or new) in an editor. Then I track that directory with Git.
This way I have a quick way to store, find and retrieve notes from the terminal itself.
I think the goal is to be a browser for daily use for privacy-conscious people who are willing to do some work in telling the browser what information to keep/give and to whom. That means it's likely not meant for the general public, more like privacy nerds and those so inclined to see the browser as a more fine-grained tool to access information rather than a pragmatic, straightforward interface into various web services.
Privacy, like security, is usually at odds with convenience. I agree with you it could be made more convenient, and as I said I think the first time you start LibreWolf it should tell you about some of its convenient features such as the address bar toggles.
So yes, Mullvad is not meant for daily use doing all your browsing, much less Tor Browser. I think you can use LibreWolf as your main browser, particularly if you use several browser profiles. You can e.g. have a separate "work" profile, where you might need to keep/allow more things from corporate systems from personal browsing, where you can block more aggressively and access mostly things you trust. This way you don't need to have an all-or-nothing approach to your privacy.
I don't think storing passwords, cookies and other information should be the default. In fact that is one of my favorite features in LibreWolf. I think it's an excellent default, but it needs some adjusting to in how you think about the browser. That's why I think it should have a screen on the first run for the first profile explaining its controls, because it does make all this convenient in some ways, but one has to discover that convenience by themselves and at that point frustration might have already overcome them.
I think it's neither. Mullvad and Tor are a bit more extreme in their defaults, but LibreWolf is not as vanilla as your average browser. I think a welcome screen explaining the address bar controls for toggling data storage and disabling fingerprinting protection on broken trusted sites would make it much more practical.
I'm focusing on the lock screen as having one single job to do well: protect the session from any access not granted exclusively through the password.
You posit this as if the attacker and the killing of the lock screen were connected: the attacker can only kill if they already have malware, so "it doesn't matter". But the point is, if the lock screen won't relinquish access upon receiving the kill signal, even if the attacker had compromised this vector, or if there were some other cause behind the lock screen dying, crashing, whatever, access would not be granted in the first place. It stops at that layer.
Thinking in terms of "if they already can access the system, whatever" is different from thinking about security in depth/layers. So its not so much about the cause of the problem, but where you can contain it. This threat (a physical access attacker) is pretty extreme, but if we are going there, then yes, it's not unfeasible to think that they could leverage this weakness to go from a possibly limited shell access to a fully unlocked physical session where you could have unrestricted access to e.g. a browser or unlocked password manager or other in-memory information.
But the two things don't really need to be connected. The lock screen having a secondary way to allow access that does not require the password is a weakness in itself, that the attacker could exploit, but that should not have been there in the first place.
Not all processes that can send a kill signal to another process have the same degree of access as physical access. The fact they are already running inside the session doesn't automatically imply they have unrestricted access. In fact, you could argue no access at all a process has can compare to physical access. So that's quite an escalation.
If killing your lock screen unlocks the system, that signals there is actually little protection. Killing a lock screen should kill the session and log you out, or at least render the session unusable.
If you still want to go that route, you could wrap your hibernation process in a script or use a slightly more complex service setup to kill it once, by inspecting system/service state and enqueued systemctl operations, you determine hibernation is done (not pending)
Yes, Fossify came precisely as a continuation for the Simple apps. The https://github.com/FossifyOrg org and the website https://www.fossify.org/ are linked from the F-Droid metadata so they should be legit as well.
Most high-level languages do a lot of things implicitly, like casting types, cloning values, deciding what the default is. Rust tends to avoid that, which though less convenient makes behavior more predictable, reducing footguns and surprises.
Average Debian system update experience:
I guess, but:
Some websites are really cursed in how hard they make overriding their styles.
Some things I usually do to handle these are using Stylus with Instant inject mode and some
!importantrules for a global dark theme.If that also fails, I have an anti-Flash-of-Unstyled-Content userscript ready to toggle per-website as needed:
It works by preventing display of content before it's fully loaded. This won't make websites dark on its own, just prevent the flash.
(I have tested this with Violentmonkey on boardgamegeek.com plus a Stylus dark theme and it did solve it. With Dark Reader though it will still flash)
If even that fails I have a second one that will strip all inline and
!importantstyles, but it rarely ever comes to that.I hope this is helpful because being flashed with a fully white page makes me want to cry and punch my computer.
this is beautiful, and sobering
Mint is a glorious debloat of Ubuntu with several extras and are strategically wise in having LMDE ready and in production. They fill a very important role as an user-friendly not-DIY distro suitable for someone completely unfamiliar with Linux. I wouldn't describe Fedora that way. It changes too fast for that use case and compared to Mint comes with not much preinstalled.
I wrote a small script that takes a query as its single argument and if it finds a matching filename in a given directory it shows that in a pager. If it doesn't, it uses ripgrep to search inside that directory and returns the filenames in a picker. If I prepend the filename with
e, it opens that file (either existing or new) in an editor. Then I track that directory with Git.This way I have a quick way to store, find and retrieve notes from the terminal itself.
This really depends on your client. Some clients can fetch the full content as needed, and some can filter this content through some external program.
In Newsboat, for instance, you can change its pager or create bindings to open a given URL with any specified program. I use this to pass the original URL to a program that extracts only the article content.
There's an add-on for that.
I think the goal is to be a browser for daily use for privacy-conscious people who are willing to do some work in telling the browser what information to keep/give and to whom. That means it's likely not meant for the general public, more like privacy nerds and those so inclined to see the browser as a more fine-grained tool to access information rather than a pragmatic, straightforward interface into various web services.
Privacy, like security, is usually at odds with convenience. I agree with you it could be made more convenient, and as I said I think the first time you start LibreWolf it should tell you about some of its convenient features such as the address bar toggles.
So yes, Mullvad is not meant for daily use doing all your browsing, much less Tor Browser. I think you can use LibreWolf as your main browser, particularly if you use several browser profiles. You can e.g. have a separate "work" profile, where you might need to keep/allow more things from corporate systems from personal browsing, where you can block more aggressively and access mostly things you trust. This way you don't need to have an all-or-nothing approach to your privacy.
I don't think storing passwords, cookies and other information should be the default. In fact that is one of my favorite features in LibreWolf. I think it's an excellent default, but it needs some adjusting to in how you think about the browser. That's why I think it should have a screen on the first run for the first profile explaining its controls, because it does make all this convenient in some ways, but one has to discover that convenience by themselves and at that point frustration might have already overcome them.
I think it's neither. Mullvad and Tor are a bit more extreme in their defaults, but LibreWolf is not as vanilla as your average browser. I think a welcome screen explaining the address bar controls for toggling data storage and disabling fingerprinting protection on broken trusted sites would make it much more practical.
That's already configurable in Settings > General > Share Links.
I'm focusing on the lock screen as having one single job to do well: protect the session from any access not granted exclusively through the password.
You posit this as if the attacker and the killing of the lock screen were connected: the attacker can only kill if they already have malware, so "it doesn't matter". But the point is, if the lock screen won't relinquish access upon receiving the kill signal, even if the attacker had compromised this vector, or if there were some other cause behind the lock screen dying, crashing, whatever, access would not be granted in the first place. It stops at that layer.
Thinking in terms of "if they already can access the system, whatever" is different from thinking about security in depth/layers. So its not so much about the cause of the problem, but where you can contain it. This threat (a physical access attacker) is pretty extreme, but if we are going there, then yes, it's not unfeasible to think that they could leverage this weakness to go from a possibly limited shell access to a fully unlocked physical session where you could have unrestricted access to e.g. a browser or unlocked password manager or other in-memory information.
But the two things don't really need to be connected. The lock screen having a secondary way to allow access that does not require the password is a weakness in itself, that the attacker could exploit, but that should not have been there in the first place.
Not all processes that can send a kill signal to another process have the same degree of access as physical access. The fact they are already running inside the session doesn't automatically imply they have unrestricted access. In fact, you could argue no access at all a process has can compare to physical access. So that's quite an escalation.
If killing your lock screen unlocks the system, that signals there is actually little protection. Killing a lock screen should kill the session and log you out, or at least render the session unusable.
If you still want to go that route, you could wrap your hibernation process in a script or use a slightly more complex service setup to kill it once, by inspecting system/service state and enqueued systemctl operations, you determine hibernation is done (not pending)
a singularity
at this crossroads in time it'd be better to boost this lest we celebrate one of F-Droid's last birthdays
Just fiddled with it to see how it works. And sorry, I'm not aware of any reviews to recommend.
https://radicle.xyz/ fits your description
Yes, Fossify came precisely as a continuation for the Simple apps. The https://github.com/FossifyOrg org and the website https://www.fossify.org/ are linked from the F-Droid metadata so they should be legit as well.
See also: https://f-droid.org/2024/01/04/twif.html