Don't worry, they are probably getting paid 300b by Oracle, 250b by microsoft, and 38b from Amazon so it all will work out nicely.

A lot of the deals lately seem to be company A and B pay each other X amount of money and pretend that is big revenue despite relatively little net money exchanging hands.

You could, in theory, have a context that is entirely within the sandbox and useful. Hence my comment about getting things in and out of the environment potentially negating many of the scenarios I can think of. But broadly speaking, if you had some local processing to do, you feed the environment a blob and the environment can now pretend it's a normal file as far as it is concerned, and then you can pull the blob out when done. WASM can't touch real stuff but you can feed it stuff within the reach of javascript which itself is still sandboxed, but specific network touch points and user indicated file touch points can be put in the reach of javascript.

So if you wanted to apply, in browser, some linux utility to a file, then the user has to indicate a file for operating on via browser, and that action allows javascript code to access that file, and with that granted it can load it into some memory that you've allocated for this purpose, and when done move the data back or wherever.

But the much needed sandbox does greatly complicate things and for some sorts of files the resource usage would be prohibitive in this scenario.

So I have had a few scenarios where I really didn't have any business moving data between the browser and a backend service and I would have just as soon done an operation client-side, but the ecosystem that was equipped to do the task wasn't exactly trivial to get to work in-browser. I could imagine some such use cases easier to port if a Linux instance could live transiently in browser runtime.

I've spent a fair amount if time trying to wrangle specific use cases into this scenario, but could imagine a 'lazier' way if a linux layer already abstracted away the browser runtime weirdness that many libraries aren't equipped to deal with naturally.

I think broadly speaking people that induce these requirements on my team are thinking the wrong things, and there's generally a smarter way to do it, but it does mean I get exposed to some weird use cases where a more traditional software interface is abstracting the browser-specific environment. Though I wager moving data in and out of the wasm may disrupt all the potential benefit...

I once had an interesting conversation with an Android OEM. I sat down with them to discuss what security issues they'd like to see the Android security team work on. They asked me "When are you going to fix the USB hole?". I didn't know what they meant and asked for clarification. They explained that in some parts of the world, notably India and China, there were "free" charging stations set up in bus stops, train stations and other public areas. These charging stations allow the public to charge their phones, for free! There's just one catch. On a sign above the charging station there's a set of instructions that tells users how to go about activating the charging. The sign tells them to go into the Settings app, then "About Phone", then scroll down to the build number, tap it seven times, then... it walks them through enabling ADB and accepting the key of the "charging station" computer, which would then proceed to install malware -- and to start charging.

Huge numbers of people used these charging stations every day, to the point that the biggest problem users had (besides the malware) was that they were always occupied. No one had a problem with "activating" charging for their device.

90% of people are capable of following a list of instructions. 100% of people are capable of either following a list of instructions or getting someone nearby to do it for them.

Anyway, this OEM wanted us to disable ADB entirely, or allow them to, because their users were doing it, getting loaded up with malware, and then blaming the OEM for making a crappy phone. I, of course, told them that we were not going to disable ADB and we were not going to remove the compliance requirement that forces them to support ADB.

Unfortunately, the current change still doesn't fix the "USB hole", but it does offer a way to rate-limit malware installation via downloadables.

Anyway, if you really think your users can't follow instructions, or can't get someone else to do it for them, you can always just register for a developer account. As long as you don't distribute malware, people will be able to sideload your APKs without using ADB. If the $25 is too much for you, maybe share the cost with some buddies, or get one of the limited accounts, though your APKs will only be installable on a small number of devices. Except, of course, by people who can follow instructions, or get someone else to.

Yep. It allows them to stop malware. How terrible!

How did you learn this?

I suspect you actually do derive a lot of utility from AWS and Azure, you just don't realize how many of the services you use every day are running on them.

Oh, actually, I missed the most obvious flaw in this argument: The verification doesn't give Google any significant control! It does give them the real-world identities of registered developers, yes, but then what? It doesn't do anything to require registered developer to use the Play store or comply with any Play policies other than one: Don't distribute malware.

The real purpose here is malware rate-limiting. Right now, malware authors can pump out huge numbers of apps with small variations to defeat identification. Google may identify one malicious app and warn all of the user that have it installed, but the malware author has thrown out a hundred variations of that app and Google only twigged to one. What ID verification does is require the developer to tie each app to a unique government-issued ID. In countries where you can't just go get a hundred government IDs, this means teams of malware authors can make approximately one malicious APK per team member. In countries where they can go get a hundred unique government IDs per person (because the government is actively cooperating or because they have a cousin in the ID office) it doesn't help so much, but Google can then start working with the governments to crack down.

I don't know if you noticed in the announcement, but this program is starting in a small number of countries, with the cooperation of and at the request of the governments who are trying to defend their populace against waves of malware. This isn't an accident.

Actually, though, your comment and my off-the-cuff response both miss the real difference which is why malware authors would choose to use F-Droid to distribute their apps. They'd have to publish source, which would be a disadvantage in the competitive world of malware authoring, and publishing source code would also make it easy for their malicious code to be identified. It makes a lot more sense for them to publish via downloadable sideloads or -- even better, if they can manage it -- in the Play store.

From a security perspective, it makes sense to treat F-Droid differently from random downloadable sideloads... but how is the Android OS supposed to tell the difference? The Android mechanism for establishing APK trust is signatures. So... F-Droid could arrange with Google to get the platform to trust APKs signed by F-Droid, which would make F-Droid work fine. And, actually, there's no need for Google to go through any complicated process to set that up: F-Droid can simply register as a developer and sign the APKs it distributes. Done. Of course, if F-Droid ever screws up and does distribute malware, it could result in all of their apps being evicted from Android device, but since F-Droid is a zero-malware platform, that's not a problem, right?

How many apps in F-Droid vs how many in the Play store?

I just got the v14 upgrade a few days ago, and it's a mixed bag. On the plus side, it now handles parking, as in I give it a destination, it drives me there, goes into the parking lot, picks out a spot and parks in it, all with zero human input or intervention. On the negative side, I think v14 needs a little more compute horsepower than my 2025 Model S has. I used to have a 2020, with previous-gen computer, and as FSD got more capable it actually degraded a bit, becoming indecisive and occasionally "stuttering". With the new car that went away entirely. I was very impressed. With v14, in the new car, it's began to get indecisive and stutter again. Not often, but it happens. I think this is a result of the model not being able to complete its processing quickly enough, because it doesn't have enough compute.

I'm hopeful that they can refine and optimize v14, though, to fix that problem. Other than that, and the fact that on the country roads where I live it always wants to drive too slow (the roads are small, but the speed limit is 45 and everyone drives 50-55, while the car is clearly not comfortable going over 35-40), it's extremely good.

Experience is just a feedback loop. Stuff happens externally, triggering computation and generation of explanations, then the events are stored in memory -- including the memory of the explanations. Then, later explanatory computation (reflection / introspection) uses those memories and creates additional memories. These layers of reflective/introspective computation constitute the experience of consciousness, but there's really nothing special about it. It's just cycles of self-referential computation.

I'm pretty confident that as our AI models begin to run more continuously as agents rather than episodically as task-focused systems, and as they gain better ability to reason about and generate explanations of their own previous "thoughts", they'll reach a point where we'll have to call them conscious or at least admit that we can't distinguish what they do from what we do.

If it's about control, why is Google leaving ADB installation open? That undermines their control. Unverified limited distribution accounts also undermine their control. Why isn't Google just doing what Apple does, and requiring a verified developer account before you can do anything at all?

I'm curious how you interpret these decisions within your "100% about control" theory.

So... your argument is that if Google isn't 100% successful at keeping malware out of the Play Store, they aren't doing the job at all? You think identifying malware at scale is easy? I used to work on Android security and know a lot of people on the anti-malware team. It's incredibly difficult, especially since it's a continual cat-and-mouse game with malware developers who do all sorts of things to obfuscate what their code does. Google has hundreds of talented engineers focused on this problem, but there are tens of thousands of people producing malware; it's big business and there's a lot of money in it.

As the announcement said, Google finds that 50X as many malware installations on Android devices are from sideloading. You really don't think it makes sense for Google to try to reduce that?

I agree this is more like 'religion' than science, as it is not falsifiable, even if this 'proof' purports to do that. It's kind of a pointless exercise of no practical use, however...

But it isn't non-sensical. Because we would have no perspective to know about 'complexity' in absolute terms. We think quantum stuff is small and the speed of light is fast, but that's just because of what we possibly observe. If hypothetically a 3d engine were self aware, they may conclude that triangles are the impossibly smallest things, and some game engine limitations dictated some absolute limits to reality that the outside world sees as a significant simplification.

That's the thing, by definition in the hypothetical the computation device is *not* within the given universe that contains it. Again, if you look at some of these things like minecraft where they build logic devices, they are, in the scale of the target universe, impossibly huge because that's what the in-engine physics allow. So again, such a self-aware hypothetical would conclude that even a simple calculator has to be the size of a large building and mock the concept of a handheld device being able to simulate everything they observe despite us knowing that such a game engine is in fact on the easier side of things a handheld computer can do.

Which comes to another point, we have no absolute concept of time. If it takes the hypothetical higher order universe an hour to simulate a second of our universe, we'd be none the wiser. We do these sorts of things in simulation all the time, though we don't run it for long.

Also there's fact that we don't have any way of really *knowing* everything we think we remember and observe is substantially done at all. In Half Life in-universe they would perceive the phenomenon as some maddeningly complex physics stuff, because that's what the game engine presents. However we know that it's just "special effects". We think we have memory of many years and history of centuries, but a lot of games present themselves the same way, despite never actually *running* that material, just preloading the memory/history into the scenario. Any individual can only speak to what they see in that instant of time and can't know that there's really anything substantial directly behind them let alone light years away.

Trying to disprove is pretty much a waste because the goalposts can move freely.