There's a platform without a C compiler? What?

Rust does not depend on a commercial C compiler, and couldn't use one for anything even if it was persent. The only rust toolchain uses LLVM, the open source toolchain for Clang. There is no Rust-to-C compiler; the only Rust compiler is native, and works on any platform that LLVM works on (which is all of them).

(The fact that only one Rust compiler exists is a common criticism of the language, though I've yet to understand why it's a bad thing. The compiler is open source, uses the LLVM backend which makes it possible to easily target any ISA / environment, and is very high quality. The error messages are incredibly good, I've never seen anything like it. There is an effort under way to make a GCC front end for Rust, so eventually we'll have two.)

Can you tell me what exactly you're talking about? You mentioned AIX... IBM has a fully-supported Rust toolchain (which is just the open source toolchain, packaged and distributed by IBM), available free of charge (I only know that because I googled it; I haven't touched AIX since I left IBM in 2011). Well, they only provide support if you pay.

Why, are you doing lots of hardware interaction, writing to device registers and whatnot, or calling C APIs, or exposing C APIs to callers? Outside of those cases, I think I've only needed unsafe once or twice in the ~100 kloc I've written in Rust.

If you have a strategy that would work better, by all means go talk to the Android security team about it. They'd be happy to pay you a lot of money, if your ideas are good, and feasible. Honestly, that's very unlikely; a large number of very smart people have been thinking hard about this since about 2013, but maybe you can see something no one else has.

The strategy has a few parts:

1. Scan the the Play store apps for malicious code using both static and dynamic analysis. This will never catch everything; it's a continual arms race and the malware authors have insuperable advantages, but what the scanning can do is make the malware authors have to work hard, raise their development costs.
2. Require app authors to identify themselves and pay a small fee. This is another "cost-increasing" strategy, one that is obviously imperfect, but surprisingly effective anyway, which is why they want to apply it to all apps, not just Play store apps.
3. Put some friction in place to make it somewhat difficult for clueless users to be tricked into installing software from outside the Play store. It would be far, far easier to simply block sideloading or third-party app stores, but Google is committed, philosophically, to keeping those options open (which is also why Pixel phones have unlocked bootloaders, Chromebooks have "dev move", etc.). This is a balancing act; it needs to be hard enough to prevent casual installation, but still accessible.
4. Google Play Protect scans all apps (regardless of installation source) on all GMS devices (devices with Google Play), with user permission. If known malware is identified, GPP can either warn the user or simply remove the app. AFAIK, the "remove the app" option has never been used, but the last time I asked about it was several years ago, so I could be wrong.
5. Safe by default APIs. APIs are designed to limit potential abuse. This can't always work, in some cases because necessary APIs are abusable and in some cases because APIs were deployed that no one realized could be abused, and taking APIs away is hard (breaks apps). 6. Tight app sandboxing and tight mandatory access control (SELinux). This is largely successful, most malware works by abusing legitimate APIs, not by breaking out of the app restrictions, but there are always exceptions.

Again, if you have better ideas, by all means share!

I didn't write that very clearly. Google doesn't have a problem with non-Play and sideloaded apps being installed in general. They do have a problem with malicious apps, regardless of source.

No... I'm pretty sure it's not that. Android does protect against malicious non-Play and sideloaded apps, and Google doesn't have a problem with those being installed. (Context: From 2014 until late last year I worked on the Android security team. I have pretty good knowledge of what they do and don't care about.)

I'd like to understand exactly what this part of the Google response is talking about. Maybe it's just throwaway FUD, not referring to anything in particular, but it could also be something the EU is demanding that is actually bad for users.

In my experience, that's Rust. Or maybe Haskell. The more guardrails the AI has, the better.

While it would be nice if everyone had personal discipline, these service are predatory because they know there are people who are susceptible to their tactics. It's exploitation and enticement into debt that reputable companies should have nothing to do with. But certain companies clearly don't give a fuck.

Best value: $450 for ten years, includes free airbag unlock codes.

Do they continue paying because they want to, or because their subscriptions were renewed without a reminder or consent?

More likely it will be hot garbage heavily promoted on your your infotainment system with no way to hide or disable it. Satellite radio, OnStar of course but anything streamable, maybe also features you take for granted. Oh, and there is so much potential for ads unless you pay. And don't forget that GM is getting rid of support for Android Auto and Apple Carplay just for good measure. Don't buy GM vehicles. Don't buy any vehicle that pulls this shit.

16kloc is a small project.

I should soften what I said before: You can get away with seat-of-the-pants work if one or more of: (a) your projects are small, (b) your projects are non-critical or (c) you invest in massive testing and validation.

In my old job, if I made one kind of mistake it could prevent three billion Android devices from being able to boot. If I made a different kind, it could result in the same number of devices being insecure against data extraction and other attacks (of course, OEMs often made those mistakes for me). In my new job, if I make mistakes vehicles can crash and people can die.

I want all the help the tooling can give me, and I spend a fair amount of my time building additional tools to prevent mistakes. None of it eliminates the need for testing, of course, especially when lives are on the line, but bugs that get caught by the compiler cost almost nothing. Bugs that get caught by QA, or, far worse, in the field, are very expensive.

Note that there are big systems built in Python. Instagram has millions of lines of Python code. They also mandate explicit type declarations everywhere and they built their own static typechecker, Pyre. Lots of other people have built typechecking libraries and tools for Python, trying to fix that problem. Maybe the next time I write Python I should try some of those tools.

Though I probably won't ever write any Python again. I really only use it for quick and dirty scripts, and these days I tell AI to write those for me, and I don't even bother to read the code. If it works, fine. If it doesn't, I tell the LLM to figure out why, and fix it.

Buy something you can't afford because of a psychological trick. Realise you've been caught in a trap. Struggle to make payments. Get whacked with late payment fees. Get your phone disabled by Apple. Get harassed by debt collectors. Klarna and their ilk are a pox.

LLMs have two effects here:

1. They help the white hats find and fix bugs
2. They help the black hats find and exploit bugs

These two effects cancel each other out to some extent (depending on which "team" is more proactive in its bug-discovery and consequent activities).

Eventually all of the low-hanging-fruit will be picked, and the current deluge of AI-induced CVEs will be reduced to only those bugs that were subtle enough not to be noticeable by anyone except the latest-and-greatest AI models.

Sure there are. Some bug reports, you look at them and dig in and say "Damn, that's obscure. It depends on subtly-wrong but arguably-correct-in-isolation mistakes in four different places. How the hell did they even find that?".

Granted that it's more common to glance at it and just be ashamed, or to look at it and say "Really? You think an attacker can do A, B, C, D, and E, all at the same time? Oh, and to do B or D they'd already have to have the system mostly compromised. Okay, I'll fix it, but no way in hell is that actually exploitable."

Sorry, but you're wrong.

Maybe... if the projections are in formal filings I don't think they can do that without risking SEC penalties. They can be optimistic about revenues or falling costs or things, because who can tell? But straight up ignoring things, probably not.