All of what you’re saying seems correct. I think this is more of a meta discussion, on how (in this case) retries, even with exponential back off, aren’t a solution by themselves when you look at the system overall. There are interesting hidden caveats to any common solutions, this is one I personally wasn’t aware of.

Practically, adding a timeout budget so that the clients themselves just error out (forcing a manual refresh) sorta accomplishes the same as what you’re positing.

Hmm… I’d say that was an obvious example to cause the situation, the real point was exposing the more subtle problems with feedback loops.

What happens if the server in question was at 80% capacity, and due to hardware faults, that leads to 100% utilization? Can you reconfigure your services if there’s a cascading overload through enough of the system without actually adding to the system load? What do you do about the fact that these loops gets ever more powerful and sudden the larger the system?

The author seemed to be suggesting that we carefully consider how to avoid open feedback loops, and build stability in. This article clued me in that stability problems can be borne from “industry standard” advice if you don’t carefully think about it.

Very interesting, thanks for this article. It’s funny how I notice ever more repetition of phenomena through different branches of engineering; metastable failure caused by feedback loops is possible both in mechanical and electrical engineering. Named differently though, resonance and ringing, respectively.

Good article, thanks

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

My hardware is too old to support MTE. I’m running a pixel 3 because I’m more worried about damaging our earthly environment with this constant hardware churn.

I’m sorry you’re unhappy that I’m happy. I’m still able to run Android 14 in a reasonably secure manner, I’m able to exchange information with other people easily, without Google getting much information from me, and that’s satisfactory. My actual security relevant machinations happen on my much better protected laptop.

Thanks for your input, have a nice day.

Dude I’m looking at the source code, there’s only a binary downloaded for enabling Safety net. Why are you making false statements?

Very nice. Can I use the much smaller codebase of microG instead of Google’s? Even you do not know how Play Services actually works, and that’s a problem.

Further, a memory exploit that leads to compromise would need a chain of privilege escalation. There’s a lot in the way of making that trivial even on stock Android. And you know what helps reduce risk of exploit? Smaller codebases.

Just about all of your identifying data is stripped out by the framework before interacting with Google at all: https://github.com/microg/GmsCore/wiki/Google-Network-Connections

That alone makes it an important tool. I’m not too worried about memory exploits as I don’t really install apps, but it’s an important feature in graphene’s toolkit.

For most people who want an Android alternative that’s open source but don’t have time to fiddle with it, calyxOS seems like a good solution. It just works out of the box.

I like calyx, might try graphene some day. But I absolutely won’t run Google’s play services ala graphene. It’s sandboxed, supposedly, but why run it at all?

Calyx uses microG, a much smaller, fully open source emulator of Google’s services.