Easily set up, and easily attached to other things. Simple notifications about whatever is needed, like service health or updates, new posts on public platforms, etc. A simple curl is plenty to send and receive notifications, and it works on Android without requiring FCM (Google infrastructure).
I use mautrix/discord, it can work in both puppeting (sign into your account) mode and relay (bot account with webhooks) mode.
I use mine for a single channel in a “medium-size” server (~2k people), a friend group server, DMs, and a few channels that follow a bunch of announcement channels on other servers.
“LineageOS stan”?? The same arguments go for any custom Android rom that doesn’t ship with Google Play Services or MicroG.
“It’s always LineageOS users”
FYI, Since I personally prefer absolutely zero connections I didn’t approve of, I’m using a privacy-focused rom. I’m not even on LineageOS.
I love the complaining about privacy, after which you immediately share a google translate link. Was it that hard to find an English source stating LineageOS connects to Google?
Anyway, this doesn’t dispute any of my arguments. LineageOS connecting to Google by default does not mean it sends the same amount of data as a stock rom with Google Play Services. A user shouldn’t be discouraged in taking steps to further their privacy because it’s “not good enough”.
not actually degoogled
Aside from vendor firmware, LineageOS is mostly deblobbed by default afaik. The remaining bits that connect to google (by default) like AGPS or captive portal are significantly less information than full google play services.
try to do it in ways that provide no privacy benefit
Replacing google play services with microg might have the same security downsides as regular google play services (privileged access), however, MicroG is open source. It still connects to Google, but sends significantly less data, and you can see exactly what it sends.
Break any semblance of security model
Rooting is one example, but access to it is often left up to the user. Keeping the bootloader unlocked has some major security downsides, but they’re entirely for when an attacker has physical access. The privacy downsides of an unlocked bootloader do exist, but they’re hard to exploit even with physical access.
ingnoring all of AOSP is Google
Yes, this is something you are forced to ignore with any custom Android ROM. Graphene, Divest, Calyx, etc all suffer from the same issue. Sending data to Google and privacy is not the same as being independant from Google developed software.
purely focussing on Google
On an AOSP or LineageOS based rom without preinstalled bloat, this is almost entirely up to user choice. You can choose to only install FOSS apps without trackers, or use Aurora store and install proprietary apps. You can choose to block network access for apps with trackers, or isolate them to a work profile and kill them in the background. It isn’t good to focus only on Google, but it’s a good starting point to use a rom without standard google play services.
While I agree that a hardened and privacy focused rom is better for privacy than regular LineageOS, privacy is not black and white. MicroG sending significantly less data is better than full access google play services sending all data. Not sending data is better than MicroG. That doesn’t mean every user is able to use an entirely degoogled rom. Each person should decide for themselves what they’re okay with and what they absolutely require on their own device. When someone is trying to get some privacy back, MicroG is a great option “in the middle” where as little functionality as possible is lost while sending as little data as possible. Discouraging that someone takes steps to improve their privacy just because it isn’t perfect is not good, as that often results in someone not taking any steps towards privacy.
On the compatibility, while MicroG has some issues with specific apps, it does generally work (from what I hear from others). Not having google play services (or MicroG) can work, but it requires missing out on some google services like notifications for proprietary apps. For me personally, that’s not a big issue, as I only use FOSS apps.
Simply not having google play services installed is a massive privacy win. Any custom rom (without google) will offer that. Divest and Graphene offer some extra security features.
The compatibility can be usable if you don’t rely much on closed source apps or their notifications. If you do, you’ll need either microg or full google play services.
According to Jim Starkey, the person who coined the term, “Blob don’t stand for nothin’.” However, it is often referred to as a “Binary Large OBject”, meaning a large file with content not easily readable by people.
With an open source project, you have source code which is turned into executables/“blobs” by the compiler. As long as you trust the compiler, you can (functionally) know the content of the blobs by looking at the source code they were made from.
In the case of Ventoy, several “blobs” are included from an unknown or vague origin. This is a great way to bundle malware, as seen with the XZ backdoor from earlier this year. As such, the original creator of the linked issue is requesting they are built/obtained at compile time, so either the content or origin of these files can easily be found.
Correct, Vector does not receive this information unless you willingly share it with them.
Element is able to use features called “Integration Manager” and “Identity Server”. When using an Identity Server, you can choose to link name, email, and phone number to your Matrix account. When using an Integration Manager, there’s a feature to share your location with others in chat.
As such, Vector discloses that they “collect this information”, although (except some diagnostics), this is completely optional.
(I am not associated with Vector, just interested in Matrix)
Although “custom Windows ISOs” are a big security risk, AtlasOS isn’t a “custom ISO” and running a random binary off some guy on YouTube is arguably just as bad. He has next to no knowledge of Linux, neither do any other “Linux YouTubers”. Trusting someone like that with your Linux machine is risky at best.
Lets go through the summary and see if anything is wrong or misleading:
Linutil is a distro-agnostic toolbox designed to simplify everyday Linux tasks. It helps you set up applications and optimize your system for specific use cases. The utility is actively developed in Rust 🦀, providing performance and reliability.
sudo pacman -S networkmanager as “helping”, even when it ignores existing network configuration.So lets revise the short description, to exclude any incorrect/misleading statements:
Linutil is a toolbox. The utility is actively developed.
Alongside all that, the “installation instructions” include the biggest sin of all:
curl -fsSL https://christitus.com/linux | sh
TL;DR Never trust Chris Titus, or any “Linux YouTuber”, with your Linux machine. They do not know what the hell they’re doing.
Despite the downsides of F-Droid, there’s one thing they provide that other stores like Accrescent simply can’t. F-Droid provides APK builds with the exact source used for the build available. There’s a lot of trust involved, but this trust is in a single entity, rather than random developers. F-Droid has existed for a long time without adding malicious code to builds, so when they say “this source code produces this APK”, they have years of history doing exactly that to back their claim.
A random app developer has no such trust built up. Stores like Accrescent, even if you download only FOSS apps, trust the app developer with building apps. It’s less prone to one massive takeover, but APKs built by random devs are much harder to verify and check for malicious code than the source code. If F-Droid is taken over, it should be noticed relatively quickly, but affects everyone using F-Droid. If an app on Accrescent bundles malware, only users of that app are affected, but it may go unnoticed for a much longer time.
Afaik the bug was never present in a release. The developer who quit had to jump through a bunch of hoops, and treat it as a security issue, when it only affected people running the latest git commit.
KDE Connect, and if needed, ntfy.sh.
I don’t have a direct source other than the source code of the software they use: https://github.com/mautrix/signal
When using one of their “cloud hosted” bridges, the bridge software (that connects between Matrix/Beeper and other protocols) has to read all message content. Otherwise, it’s impossible to bridge to another protocol. E2EE becomes end (other users) to bridge (beeper) encryption.
With “local hosted” bridges, E2EE stays intact, but messages can’t be sent/received if the device hosting the bridge is unavailable.
In the future, with MLS (a different E2EE protocol), it could be possible to keep E2EE even when bridging to Matrix on cloud hosted bridges.
iirc NPxSP was getting messy internally, the author went and rewrote a lot of things
per-site process isolation, as mentioned here: https://divestos.org/pages/browsers#processIsolation
My experience with several firefox-based browsers on Android was not usable, with constant freezes, crashes, and performance issues.
There are some security considerations to using a Firefox-based browser on Android. In my experience, performance and stability has not been as good on Firefox Android as Chromium Android.
Fully agreed. There’s some stuff in the list that could leak server info or metadata about available content to the public, but the rest seems to require some knowledge before being able to exploit it, such as user IDs.
That doesn’t mean these aren’t issues, but they’re not “take your jellyfin down now” type issues either.