@daniel31x13@lemmy.world

No, but I think ArchiveBox would be a much better place to implement this

Is is open source though?

RSS should become popular again. There are great clients for all platforms, even iOS:

• NetNewsWire (iOS/macOS)
• Read You (Android)
• RSS Guard (Linux/Windows)

I also recommend using the Awesome RSS extension in Firefox/LibreWolf to quickly see if a website has an RSS feed. It also works in Firefox Mobile/Fennec/Mull.

Peppermint - not Ubuntu, but Debian, so it’s pretty similar

When do you think will Valve enable this by default in SteamOS? It would greatly help the little Steam Deck with playing more performance-intensive titles.

https://f-droid.org/en/packages/com.svenjacobs.app.leon/

Codeberg Pages

I believe Veyon can do this. Chris Titus Tech once made a pretty good video about it: https://www.youtube.com/watch?v=ysOr91dUy-8

Yes.

This argument assumes that they’d only do something if they could get perfect coverage

Doing this and not covering like half of the phones out there would be even dumber, and way too risky. It’s not just about Chinese phones, the most popular smartphone vendor, Samsung, is from South Korea. Yeah, South Korea is a US ally, and the NSA might have some kind of crazy deal in place with them to backdoor their phones, but that would exponentially increase the risk, as not only would the NSA and all the US phone manufacturers have to keep this a secret, the South Korean government as well as Samsung, which is a massive corporation with hundreds of thousands of employees, would also have to make sure that none of this gets leaked to the public. This is way too unrealistic, and can easily be dismissed as a conspiracy theory.

Err… That component appears to be built from source per Calyx’s Gradle rules? The source is pulled from here: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/telephony/java/android/telephony/euicc

That’s apparently not the entire thing though. I haven’t used CalyxOS in a long time, could go to the settings menu for adding a new eSIM and take a screenshot of it?

I’m sorry you’re unhappy that I’m happy.

Oh I’m absolutely not. I’m glad you found an OS you like, I just pointed out that GrapheneOS is far superior in terms of privacy and security, and therefore probably the better choice, but you are obviously free to use whatever suits your needs and makes you happy. And it’s better than the stock OS I guess.

My actual security relevant machinations happen on my much better protected laptop.

How do you protect a laptop to be more secure than a modern mobile device? Desktop operating systems are inherently less secure, since they lack proper application sandboxing, they often don’t even have mandatory access control mechanisms (such as SELinux or AppArmor) in place and don’t have a good way of verifying the boot image. Secure Boot is broken and essentially useless, and can’t be compared to Android Verified Boot whatsoever. TPMs aren’t secure either, and can’t even remotely be compared with proper secure elements such as the Google Titan M2 or Apple’s Secure Enclave. Do you use QubesOS, or how did you achieve better protection on your laptop compared to your smartphone?

Because I want a secure phone with relatively good specs, relatively good design, battery life and camera quality. And because it is one of the very few devices with a user-unlockable and re-lockable bootloader.

Oppo, Huawei, Xiaomi, all do not work on USA cell networks

Wait what? Is that actually true? What if you are a foreigner visiting the US and bring your e.g. Oppo phone with you? You can’t use it? Even with a foreign SIM?

Can you elaborate on MicroG needing root? To my understanding that is only required on ROMs that don’t require Sig. Spoofing, and Calyx does support it, specifically and only for MicroG.

I’m not entirely sure if all of microG needs to run as root, but I’m pretty sure that some parts do. Nonetheless, microG runs in the priv_app SELinux domain instead of untrusted_app, reducing the isolation and granting it more access to sensitive APIs. Sandboxed Google Play on GrapheneOS on the other hand is a normal application that can be installed and uninstalled by the user, running in the untrusted_app domain. It is tightly controlled by the Android permission mechanism, and doesn’t have any permissions by default.

If you only care about security, you should keep Play Services isolated in a separate profile. That way, even if there happens to be a memory corruption vulnerability in Play services, which isn’t caught by hardened_malloc or the hardware MTE in newer devices with ARMv9 chips, the rest of your system would still be safe, since Play services aren’t running as root, and in order to compromise the entire system, there would need to be a privilege escalation vulnerability in all of Android, not just Play services.

And you know what helps reduce risk of exploit? Smaller codebases.

Why does CalyxOS include the F-Droid privileged extension then? It’s yet another component running with elevated permissions and unnecessarily increasing attack surface. Why does it include Google’s eUICC component with elevated privileges and no proper sandboxing?

they can subsidize EV manufacturing to the same degree

Meaning that we would either have to increase tax rates or borrow more money? Wow, what a great solution.

And we really have no idea how close of a relationship Google, or any other corp for that matter, has with various intelligence agencies

Ok let’s assume this is true, and US intelligence agencies have actually backdoored all US phone manufacturers. What about foreign phones? If this was true, someone the NSA is interested in could just defend themselves by e.g. buying a Chinese phone. All this effort, just to be defeated by foreign phone manufacturers? It wouldn’t be worth it, which is why it’s so highly unlikely.

I think I found it https://discuss.grapheneos.org/d/12019-passkeys-as-mfa-on-grapheneos-a-guide

It might also be this one, I don’t remember https://discuss.grapheneos.org/d/8184-graphene-os-3rd-party-passkey-support-on-android-14

Just about all of your identifying data is stripped out by the framework before interacting with Google at all

For all of them, we strip device identifier (MAC addresses, IMEI, etc)

This is literally nothing special, as all user-installed apps are denied access to identifiers like the IMEI and MAC address since Android 10. Since GrapheneOS isolates Play services in the Android application sandbox, they don’t have access to any of these identifiers either.

I’m not too worried about memory exploits as I don’t really install apps

That’s not how memory corruption exploits work. These can occur anywhere in the system, and just need to be triggered by an attacker. This doesn’t require you to install an app, receiving a rogue message might for example be enough to exploit a memory vulnerability in the SMS app. Visiting a rogue website, which loads malicious JavaScript can be enough to trigger a memory corruption vulnerability in the Chromium WebView. That’s why GrapheneOS doesn’t just use hardened_malloc, but it also disables the JavaScript JIT compiler in Vanadium by default, and offers a toggle in the settings to disallow JavaScript JIT compilation in all apps making use of the system WebView component.