The summary should also mention that the main selling point of the Trump phone was that it was supposed to be Made in America. That was a major part of the sales pitch and a key promise that motivated whatever pre-orders they got. To whatever extent the alleged 600k pre-orders is plausible, it was that promise that made it so. But Trump Mobile quietly changed the terms on their web site, removing the "Made in America" promise and replacing it with a claim that the phones are "Designed with American values in mind".

My guess is that they announced before even checking whether they could actually make a phone, typical Trump business "strategy", then discovered that doing it ranges from extremely difficult/expensive to impossible depending on how you define "made". You could probably import all the parts and assemble them in the US, though it'd add a lot of cost (Moto tried it). You simply couldn't create an even marginally-decent device from chips fabbed here. You could get an SoC and a modem that are only a few years behind current flagships, thanks to TSMC Arizona (thanks, Biden!), but DRAM, flash, display, camera sensor, MLCCs... even high-density PCBs are available only from Asia.

Note that I think this is a national security problem that needs serious attention. We're way too dependent on foreign manufacturing chains for critical components, components that aren't just needed for modern consumer electronics, but for high-tech weaponry. Biden made a little bit of a start on addressing it with the CHIPS act, but Trump has undermined a lot of that (and wants to repeal it entirely). To really get to where you could build something comparable to a five year-old flagship entirely in the US would require another half-dozen CHIPS Acts focusing on flash, displays, image sensors, MLCCCs, PCBs, batteries (the US makes lots of Li-ion batteries but they're EV batteries and the differences in form factor, chemistry and defect rates between those and phone batteries are enormous), etc. We're just that far behind.

I don't think Google has any intention or desire to kill F-droid -- and here I really understand the situation quite deeply from my decade in Android Security. I worked on platform security, not the anti-malware team, but I knew a lot of the core anti-malware guys and talked to them regularly. I was the twelfth engineer to join the Android Security team back when one small team was responsible for all of it (platform, anti-malware and offensive/red-team), so I knew the anti-malware guys (all three of them!) well back then. The team later split and the anti-malware group grew to dozens, then hundreds of engineers, but my old colleagues were (and are) still involved.

What you're referring to is the developer registration requirements, and those absolutely are another example of Google trying to stop abuse that hurts users, and trying to do it in the least-invasive way possible. The problem is that there is a massive ecosystem of malware out there. Google spends incredible sums of money fighting it, but in the armor v warhead battle, the armor is perpetually behind.

In recent years it's gotten a lot worse, and the old techniques (static and dynamic analysis) are no longer working because the malware construction tools have gotten so good that the malware authors are incredibly agile. When the anti-malware team identifies a malicious app in the ecosystem they have the tools to shut it down, but the authors can replace it in hours, maybe minutes, with a new version that can't be identified. This isn't because the team's malware-identification tools are lousy, in fact they're incredibly sophisticated.

I'm not sure how much of the cat-and-mouse game I should describe here. Both legally and morally it's unclear to me how much I can safely say about the details of what Google does to detect malware and what malware authors do to counter it, so I won't say much. I'll just say that it's a very complicated and subtle technical battle... and Google is losing. Not on the Play store, because they have a non-technical advantage there: Developers have to identify themselves and pay a fee. Those requirements mean that when malware is identified, Google can not only shut down the malware, but can also block the malware author. The author can get another ID and pay another fee, so this defense is circumventable... but the circumvention is hard to scale.

What Google is trying to do is to apply this same highly-effective non-technical defense to the rest of the Android app ecosystem. Not because the fees mean anything, and not because Google objects to the existence of other Play stores, but because it's a simple and extremely effective way to break the business model of Big Malware.

Will it stop all malware? Obviously not. But it will make malware hard to scale and that fact alone will destroy the malware business model, and with the financial incentive removed, the sophisticated malware industry will die. This will actually benefit the Play store, too, because less sophisticated malware is easier to identify and kill.

If Google succeeds at this, it shouldn't kill F-Droid. It will just mean that someone, somewhere, in addition to spending their time on building open source apps and packaging them for distribution, will also have to give $25 to Google, and send their ID. Unless Google can work out a different way to handle F-Droid... and that seems very feasible! F-Droid's requirement that source code be available is a really good defense against malware, not so much because of "many eyes" as because people would be very skeptical of any open source code that does the obviously weird shit that malware does to evade Google's detection schemes.

Bottom line, I don't think F-Droid is at risk, and I don't know anyone in Android who even wants to eliminate it. Well, no one in a decisionmaking position, anyway. I do know a few Android engineers (in the security team) who sincerely believe that Apple's walled garden model is superior because it makes security a lot easier. But that's very much a minority view. 99% of Android engineers want their platform to be open.

Your freedom to swing your fist ends at my nose. Other people exist and sometimes that means you can't do whatever you want, get over it.

Yeah, that's unfortunate. At least where I live we have mountains full of standing dead timber for the taking (occasional forest fires, beetle kills, etc. -- this isn't to say the forests are unhealthy, healthy forests have standing dead timber) that is relatively accessible and the permits are cheap. It means people are burning varieties of pine rather than hardwoods, which burn hotter and longer, but it's clean wood. Except maybe for a bit of lead, apparently?

I doubt that the product is actually getting worse, and I have good reason for my doubt.

Nearly all of the things like this that Google does have one real purpose: Combating abuse. During my ~15 years at Google I never worked on counter-abuse, but I spend about a decade doing stuff that led me to work pretty closely with the counter-abuse teams, and the inventiveness of the people abusing Google's products and systems never ceased to amaze me. And it isn't trivial abuse that is ignorable, because not preventing the abuse would actually make the product offerings worse.

I don't know what the storage abuse might be, but I can think of a lot of things that could be done, and my experience touching on counter-abuse at Google taught me that for every thing I can think of, there are people out there who can think of a hundred more, and will then invest serious amounts of time and money in implementing them.

One of my favorite examples was related to Android GPS location. It's a favorite mostly because of how trivial it was, but the vast resources abusers poured into it, and I'm sure they only did it because they got even more out of it -- this large-scale abuse is all for-profit. For a long time it was easy to spoof your location without giving any evidence of the fact. This caused problems for location-based games like Pokemon Go or Ingres, who lost players because it screwed up the game[*]. So, the games started checking if the device was in developer mode, which allowed "legitimate" location spoofing. So cheaters started using bootloader-unlocked devices which they could configure to lie about being in developer mode. So games started using Android Keystore attestation (I wrote Keystore, hence why I got pulled in) to make it difficult to impossible to do that. Except that some number of official attestation keys leaked out of factories and people found they could get those and fake out the games. Also, there were some crappy devices that didn't do the Keystore security right. If you bought one of those cheap devices and modified the software, you could cheat

To this point, it's fine. Just normal security cat-and-mouse, and it keeps the number of cheaters small enough not to matter, so it's fine. But someone decided to scale it, for a fee. Someone (or some ones) set up massive device farms. One organization made some mistakes that leaked a bit of device information and allowed us to count the devices in the farm and there were tens of thousands. What did they do? They arranged to help Pokemon Go players spoof their location. If you played Pokemon Go and wanted to cheat, you could pay $5 per month and they'd give you a customized version of the game that would let you spoof your location but whenever the game asked for an attestation it would get one from one of the farm devices, all of which were hacked to be able to lie about their configuration.

That's just one example, and there are an unbelievable number of others. I recently chatted with a friend on the counter-abuse team and they are really tearing their hair out over some of the incredibly clever attacks people are mounting with AI. She couldn't give me details (and if she had, I couldn't share them).

Anyway, what's really going on here, I'm sure, is that there's some large-scale, systematic abuse of GMail storage that is to a degree that it's costing Google hundreds of millions of dollars. What exactly, I have no idea. And they think that they can address it by reducing storage for people who won't take a simple step to prove that they're real people (phone number verification). Obviously, phone number verification doesn't prove that you're a real person... but it increases the cost of large-scale abuse, and that's the point. I'm sure there will be other I'm-a-person verification schemes so those without phones have an option, but all of them will aim to inconvenience abusers and increase their costs, without too-greatly inconveniencing legitimate users.

[*] My personal experience: I played Ingres quite a lot for a couple of years, but quit it completely after one cheating event, and never went back. I spent a whole day climbing a 10,000-foot mountain peak, covered in deep snow, in the dead of winter, to capture a key portal, only to have it taken away from me 30 minutes later by someone who definitely didn't climb the mountain. I know because if they'd been there, I'd have seen them. Pissed me off so bad I deleted the app and never installed it again.

Unless you're cooking brisket every day, and so are a lot of your neighbors, it's not likely to be a problem.

Where it becomes an issue is when a non-trivial number of people are using it for heating their homes... which is not that uncommon in the Mountain West.

It used to be very common where I live (northern Utah), and likely would be still, but the density of woodsmoke was enough that when combined with common winter weather conditions ("temperature inversions" that trap a layer of air 2-3 thousand feet deep in the bowl created by surrounding mountains), it became a health hazard. To combat that, the government instituted "no burn days" when using a wood-burning stove in your home was prohibited. Those became common enough that most people eventually found burning wood (and coal) for home heating was annoying.

When I was a kid, my home was primarily heated with wood, plus a bit of coal at night. The house had a gas furnace, but we could cut several cords of wood from the mountains for a permit that cost about $10, plus another $30 in gas -- and our time and sweat, of course, but given the family finances, labor was cheap. That ended in the mid-90s because there were so many no-burn days that my dad gave up.

However, it's still quite common in less densely-populated areas of the Mountain West. This information may change the calculation of how dense is too dense to allow heating with wood.

A large mass of cryogenic fuel/oxidizer right up against the other side of a thermally-conductive dome also makes a great heat sink. Warming the fuel will cause it to expand, but after burning a lot to get up there, tankage is not a problem.

*glances at Enron

Actually, that sounds truly brilliant. Let's raise the legal requirements so that happens...

Ah, gotcha. You were referring to the comment from the summary, not mine. Yeah, it's fun to watch the young'uns realize that they are absolutely going to spend their whole lives realizing they forgot something they used to know. It's even more fun to watch them the first time they look at code they wrote two months ago and say "Who wrote this stupid shit? Oh....".

Really? Doesn't feel that way at all to me. What it feels like is that LLMs are a massive force multiplier for the skills I already have.

Why the scare quotes? Are you uncertain if she's a woman? Or do you not understand how to use quotation marks?

Did they steal stuff worth millions?

Though, of course, this raises the question of why someone would leave valuable masters in a suitcase in an unoccupied core.

VeraCrypt is a particularly strong full-disk encryption, although you don't hear much of companies using it. However, BitLocker security issues keep getting mentioned and it looks like VeraCrypt fixed a number of theirs. However, code quality seems to be listed as unclear on some sites. Not sure how true that actually is though.

BestCrypt is another, but I'm not happy they permit fragile encryption schemes, as those could potentially be used by the software as standard for something important. Being commercial software, that wouldn't be easy to check.

BitLocker seems to be a typical Microsoft failure in terms of what it does, used only because it's Microsoft and that gives CTOs and CFOs someone to blame.

Not just not accurate but wrong.

That's like saying the price of the battery in an electric car is that car's price minus the price of a comparable ICE car. No, it isn't. There are more differences than just the battery.

And yes, of course they recoup their development costs. But that doesn't mean that the OP is right in this context.

Dude, I've been writing code for 40 years. I've used so many different tools, stacks, libraries and APIs that at this point I don't remember any of them, and I haven't remembered them for years, and it doesn't matter at all. Sure, I have to look everything up, but that's fine, that doesn't matter. What matters is that I know when something looks wrong, or hard to maintain, or inefficient, or insecure, or... pick the axis. And I can dig in and find the problem. Anyone can tell if code works, that's easy. Understanding when and why it might break or otherwise impose additional costs, that's the real skill.

Which, as it happens, is exactly the skill you need to use an LLM effectively. Also the skill you need to understand legacy code, review colleagues' commits, etc., etc., etc. I used to say that the ability to read and understand code is an underrated skill, but an old friend corrected me at lunch a couple of weeks ago, saying that the ability to read and understand code is the most important software engineering skill, and always has been. Upon reflection, I agreed. And LLMs make this clearer than ever before.