• 1 Post
  • 14 Comments
Joined 1 year ago
cake
Cake day: June 5th, 2025

help-circle

  • Yeah, okay—of course you can’t compare the “thief-infested” U.S. to other countries. As a business, I’d definitely require proof photos there, too. You’d have to rebuild the entire U.S. from scratch. Here where I live, the drivers are happy when I meet them halfway so they don’t have to go all the way to my front door. And if I can pick up packages from my neighbors while I’m at it, they’re really happy.

    My sympathy, however, has its limits. If the U.S. would just stop causing hundreds of billions in damages in Europe every year through industrial espionage, I’d have more sympathy. But I basically never hear any criticism of this—not even from U.S. citizens (at most, after comments like these, but you can’t really consider that their own criticism—it’s just agreement).








  • In the long run, I’m pinning my hopes on the LibrePhone project, which is reverse-engineering firmware blobs to eventually offer open-source alternatives. I hope to be able to combine that with the Fairphone at some point (which, as I mentioned, already allows you to remove modules like the microphone, camera, etc.). But right now, there simply isn’t any alternative free, open-source firmware yet. So, yes, it’s the best option for now—though it’s still not trustworthy. Especially since old cross-device tracking methods, such as uXDT, continue to play a role there as well.

    With PCs and laptops, there isn’t anything completely open-source either, but it’s still easier to run them in a completely isolated environment, because a smartphone that’s completely isolated loses its purpose—that’s the difference.




  • The better alternative? Don’t trust any hardware where the software and hardware aren’t 100% open. You simply can’t trust anything else at all. Hard to understand, isn’t it?
    I don’t feel like arguing with the grapheneOS cult either, because it’s pointless. Stay in your bubble.

    Project Ara would have been an alternative at one time… That’s why Google bought it and put it on hold.

    Then there’s the ultimate argument that applies to everything that uses cellular networks… the SS7 protocol Class 1 (normal SMS) CLASS 0 (flash SMS) TYPE 0/Stealth Ping <
    ( • Technical identifier: The TP-PID byte is set exactly to 0x40 (Short Message Type 0). • Protocol behavior: When this SMS reaches the phone, the baseband (the Qualcomm/Samsung modem chip) reads the header. The standard mandates the following for Type 0: “The device must acknowledge receipt of the message but must neither display the content nor store it in memory.” • The effect: The cell phone receives the SMS. The display remains black, no sound is heard, and the GrapheneOS interface is completely unaware of it. However, the modem chip automatically sends an acknowledgment (ACK) back to the sender via the SS7 network. This cannot be blocked by the GrapheneOS team, etc.

    Oh, right—encryption in mobile communications itself ends as soon as the connection switches from a cell tower to satellite communication. In other words, the connection goes from cell phone < encrypted > to cell tower < unencrypted > to satellite. ( https://youtu.be/fM5w7bFNvWI ) However, this applies only to the encryption of the cellular network itself.

    GrapheneOS may be the best, but you should treat it as untrustworthy.

    BTW, I use Chinese stuff. They’re more interested in state secrets and such, and less in my religion, sexual orientation, etc.—the kinds of things the West is increasingly using against its own citizens… I wonder why that Chinese stuff was banned in the U.S… Yeah, I wonder why…
    But you could also, for example, use a Fairphone and remove certain modules yourself.


  • Just a small sample Qualcomm CVEs – August 2026

    CVE-2026-25289
    CVE-2026-21366
    CVE-2026-24079
    CVE-2026-24080
    CVE-2026-24084
    CVE-2026-25288
    CVE-2026-24076
    CVE-2026-24078
    CVE-2026-24077
    CVE-2026-25292
    

    Additional Qualcomm CVEs Affecting Snapdragon

    CVE-2022-40514
    CVE-2022-40512
    CVE-2022-33232
    CVE-2022-33279
    CVE-2022-25729
    CVE-2022-25728
    CVE-2022-33216
    CVE-2022-33233
    CVE-2022-33248
    CVE-2022-33225
    CVE-2022-33246
    

    (There are probably even more by now anyway) This doesn’t include any of the CVEs from GrapheneOS itself, and those exist as well. Then the GrapheneOS team is explicitly developing for Google hardware or smartphones with closed-source software from Qualcomm—where they have absolutely no access, can’t fix anything at all, etc. They’re explicitly choosing hardware we can’t trust.

    Since the brainwashed GrapheneOS cult followers just blindly dismiss any criticism anyway, I’m not even going to bother anymore here in the community. You guys won’t accept it either way. True to the motto “Hail GrapheneOS”

    You blindly trust the underlying hardware, which has its own real-time operating system (RTOS). There’s no point in arguing with you about this.