

Which means the entire article is bullshit.
Not necessarily. It could just be that Microsoft’s “root” detection is misnamed or poorly implemented. They would not be alone in either case.


Which means the entire article is bullshit.
Not necessarily. It could just be that Microsoft’s “root” detection is misnamed or poorly implemented. They would not be alone in either case.


For most: yes, there is a risk that the vendor has included a backdoor. There is also the risk that they are straight-up lying about how their service operates.
For Signal in particular: You can verify that their claims are true because you can audit the source code.
The Signal client is open-source, so any interested parties can verify that it is A) not sending the user’s private keys to any server, and B) not transmitting any messages that are not encrypted with those keys.
Even if you choose to obtain Signal from the Google Play Store (which comes with its own set of problems), you can verify its integrity because Signal uses reproducible builds. That means it is possible for you to download the public source code, compile it yourself, and verify that the published binary is identical. See: https://github.com/signalapp/Signal-Android/tree/main/reproducible-builds
You might not have the skills or patience to do that yourself, but Signal has undergone professional audits if anyone ever discovers a backdoor, it will be major news.
You are more likely to be compromised at the OS level (e.g. screen recorders, key loggers, Microsoft Recall, etc.) than from Signal itself.


Last I checked, there is still no way for developers to use RCS on Android, so it’s a non-starter for me. I do not and will not limit myself to first-party apps.
Please correct me if I’m wrong. If there’s an open-source RCS-compatible messaging app out there, I’d love to try it.


That’s a good rule of thumb, but as a direct point of comparison, it’s not that bad with iPhones. Apple’s MDM protocol is very particular about what admins are allowed to control even on company-owned devices. For example, admins can’t see the Apple ID used on the phone and can’t grant apps screen sharing permission without user approval.
And we certainly can’t access iMessage.


Kagi actually does have an anonymous authentication option. https://blog.kagi.com/kagi-privacy-pass


I get that they don’t want to deal with Google Play
Was that the reason? Shame they didn’t just leave it on F-Droid and GitHub then. Nobody needs to use Google Play (at least not yet…)


I used to use Filen for this, but it never worked very well. The file provider path it returned to Keepass2android was only temporary, so it would break periodically. Did Filen change how that works?
I eventually started using Syncthing instead. I connect to my home wi-fi often enough that it’s never too far out of sync with my home PC. And since it’s a local file, there’s no issue with using absolute paths.


Thanks for the info. I have not really tested Seedvault myself so this is all good to know.
Ironically, one of the main reasons I switched to GrapheneOS was because Google’s backups were so frustrating and I was hoping Seedvault would be more comprehensive.


What’s wrong with Seedvault?
I jumped on a lifetime deal they had a few years back. I mostly use it via the web UI and Android app, so I cannot comment on desktop or CLI client functionality.
The Android app is “okay”, but not great. Background photo sync doesn’t work consistently; I need to manually launch the app periodically to jog it. I know Android is kind of aggressive about background services, but other apps do this better so I think this is on Filen. Perhaps they should run a permanent notification to stay alive 24/7, like Syncthing does?
As with pretty much every other cloud storage app, it does not let me sync arbitrary folders/files, only photos and videos. *sigh*
It uses Android’s file provider API, so you can open and save files in most apps directly from/to Filen. However, this only seems to work for one-time use, not for apps that need to regularly open/save the same file. For example, when using Keepass2Android, you can have it store your password database on a cloud storage service. This works pretty well with Google Drive, but with Filen it loses the connection frequently because the pseudopaths the API returns are not stable over time (which makes sense, I guess, and is one more reason I want arbitrary local file sync instead). Personally, I went back to storing my Keepass database locally and then periodically backing it up rather than keeping it on live cloud storage.
It’s one of the cheapest E2EE cloud storage services I’ve seen (definitely the cheapest for me with the lifetime promo I got), and the core functionality of uploading and downloading files (and folders) works. That’s good enough for me to give it the thumbs-up.


But here’s the really funky bit. If you ask Claude how it got the correct answer of 95, it will apparently tell you, “I added the ones (6+9=15), carried the 1, then added the 10s (3+5+1=9), resulting in 95.” But that actually only reflects common answers in its training data as to how the sum might be completed, as opposed to what it actually did.
This is not surprising. LLMs are not designed to have any introspection capabilities.
Introspection could probably be tacked onto existing architectures in a few different ways, but as far as I know nobody’s done it yet. It will be interesting to see how that might change LLM behavior.


Snapchat does not use end-to-end encryption for messages, so it doesn’t even belong in the conversation.
WhatsApp and FB Messenger are somewhat defensible choices since they at least use E2EE by default (Messenger did not until recently). However, there are a few good reasons to favor Signal:
Additionally, you can set Android to use an ad-blocking DNS server without apps. In Settings > Network & Internet > DNS, select “Private DNS” and set the hostname to a custom server, like base.dns.mullvad.net (Mullvad’s DNS server is free to the public, does not require a VPN subscription).
The per-app controls sound neat! I might give that a try. Google killed the ability to restrict apps’ network access years ago, specifically so ads would always work. I’ve never tried a local VPN as a workaround.


It used to say “container-native”. They recently changed the wording, but there was no technical change.
It’s a Linux distro that runs locally, like any other. It has no particular tie-in with any cloud services. If Flatpak, Docker/Podman, Distrobox, Homebrew, etc. are “cloud” just because they involve downloading packages hosted on the internet, then I don’t know why you wouldn’t call “traditional” package managers like apt, dnf, zypper, etc. “cloud” as well. 🤷 So yeah, I feel your confusion.
The big difference compared to something like Debian or vanilla Fedora is that Bazzite is an “immutable” distro. What this means is that the OS image is monolithic and you don’t make changes directly to the system. Instead, you install apps and utilities via containers, or as a last resort you can apply a layer on top of the OS using rpm-ostree.
The only thing cloud-related about any of this is that atomic OS images and containers are more common in the server space than the desktop space.


There’s a separate command called visudo for this purpose.
You CAN use any ol’ text editor but visudo has built-in validation specific to the sudoers file. This is helpful because sudoers syntax is unique and arcane, and errors are potentially quite harmful.


There are a handful on non-default apps I’ve used across my last 3-4 distros at least:
mpv - the best video player, period. Minimalist UI, maximalist configuration options. I’ve been using it for many years across many OSes and at this point everything else feels wrong.
Geany - My favorite GUI text editor on Linux.
Foliate - the simplest eBook reader I’ve found.
Strawberry - It’s “fine”. Honestly, I’ve never found a music player on Linux that I really liked. I keep falling back to Strawberry because it’s familiar and generally works as expected.


Related feature on my wish list: I’d love a way to basically fork a feed based on regex pattern matching. This would be useful for some premium feeds that lump multiple podcasts together. For example, one of my Patreon feeds includes three shows: the ad-free main feed, the first-tier weekly premium feed, and the second-tier monthly premium feed.
I don’t want to filter them out because I DO want to listen to all of them, but for organizational purposes I don’t want them lumped together. I’d prefer to display these as two or three separate podcasts in my display.
Another example is the Maximum Fun premium BoCo feed. They include the bonus content for ALL their shows (which is…a lot) in a single feed. I only listen to about half a dozen, and even that is a bit of a mess in one feed!
They have a big IRL ad campaign in major US cities. See https://mullvad.net/en/blog/advertising-that-targets-everyone
These ads certainly aren’t the worst, but they’re still a bit misleading. Using a VPN is not going to prevent tracking in general. Your phone apps will still send GPS data to all the same places. Web sites will still use all the same cookies. Facebook is still gonna be Facebook. 🤷
That said, Mullvad does include domain-based ad and tracker blocking with their DNS server (which is free and available to the public, btw), and that’s also optional on the VPN, so it does help to a point.
(Pinging @countrypunk@slrpnk.net to avoid double-replying. )
Sure. I’m referring to the ones that run big ad campaigns, like Nord and Mullvad. They tend to overstate how a VPN can protect you, sometimes in ways that barely make sense. There is no epidemic of criminals stealing personal credit card information over insecure wi-fi, for example. The ads play into ignorance and fear.
That said, yeah, I’d rather be on a VPN when on a public wi-fi network. But I’m not really worried about someone sniffing my encrypted HTTPS traffic (which is pretty much everything nowadays; Firefox by default won’t even load unencrypted web sites).
If I understand you correctly: 63.4% odds of having at least one hallucination.
The simple way to calculate the odds of getting at least one error is to calculate the odds of having ZERO, and then inverting that.
If the odds of a single instance being an error is 1%, that means you have a 99% chance of having no errors. If you repeat that 100 times, then it’s 99% of 99% of 99%…etc. In other words, 0.99^100 = 0.366. That’s the odds of getting zero errors 100 times in a row. The inverse of that is 0.634, or 63.4%.
This is the same way to calculate the odds of N coin flips all coming up heads. It’s going to be 0.5^N. So the odds of getting 10 heads in a row is 0.5^10 = ~0.0977%, or 1:1024.
Edit: This is assuming independence of all 100 prompts, which is not generally true in a single chat window, where each prompt follows the last and retains both the previous prompts and answers in its context. As the paper explains, error rate tends to increase with context length. You should generally start a new chat rather than continue in an existing one if the previous context is not highly relevant.