I think the deeper question is how SO would get paid for that.

Historically, SO has been funded by advertising. Users would google their question, land on SO, get an answer, and SO would get paid by advertisers. (The job portal was a variation on the advertising product.)

Even in your ideal world, newbies and experts would first ask their questions to an LLM. The LLM might search SO and find the answer there, but the user would get the answer without viewing an ad, so SO wouldn't get paid for that.

The same issue is facing Wikipedia. Wikipedia isn't funded by commercial advertisers, but they are funded by donations, which are driven by ads. If LLMs just answer the questions based on Wikipedia data, the user won't see the Wikipedia ad asking them to donate; they may not even know that Wikipedia was the source of the information, so they may not even develop a fondness for Wikipedia that's necessary to get users excited to donate.

This is why you see people shouting about how LLMs are "killing the web." I think it's more correct to say that LLMs are killing free web resources. Without advertising, not even donation-funded resources can remain available for free.

But, this is a non-story, because those comments were correctly killed precisely so they wouldn't clog up this thread.

Comments URL: https://news.ycombinator.com/item?id=47506357

Points: 2

# Comments: 0

As a lot of people on this thread have pointed out, Apple's Business Manager needs a lot of improvements. ("Bring your own device" support is terrible, for example. Changing business names requires a perilous migration step. Support reps don't have the tools to fix serious issues.)

If Apple Business were a real revenue source, if they charged luxury prices for a luxurious business support experience, they could pay for developers to fix their stuff.

Instead, Apple Business is a free side hustle for Apple, a hobby. But they're proposing to control your entire domain, to Domain Lock all Apple accounts for your domain, to put your businesses's life in their hands, for "free."

Don't fall for it.

You're using stavrobot instead of OpenClaw precisely because the purpose of OpenClaw is to do everything; a tool to do everything needs access to everything.

OpenClaw could be kinda useful and secure if it were stavrobot instead, if it could only do a few limited things, if everything important it tried to do required human review and intervention.

But stavrobot isn't a revolutionary tool to do everything for you, and that's what OpenClaw is, and that's why people are excited about it, and why its problems can never be fixed.

We have no general-purpose solutions to the principal-agent problem, but we have partial solutions, and they only work on humans: make the human liable for misconduct, pay the human a percentage of the profits for doing a good job, build a culture where dishonesty is shameful.

The "lethal trifecta" is just like that other infamously unsolvable problem, but harder. (If you could solve the lethal trifecta, you could solve the principal-agent problem, too.)

Since we've been dealing with the principal-agent problem in various forms for all of human history, I don't feel lucky that we'll solve a more difficult version of it in our lifetime. I think we'll probably never solve it.

> As I have mentioned, treat OpenClaw as a separate entity. So, give it its own Gmail account, Calendar, and every integration possible. And teach it to access its own email and other accounts. In addition, create a separate 1Password account to store credentials. It’s akin to having a personal assistant with a separate identity, rather than an automation tool.

The whole point of OpenClaw is to run AI actions with your own private data, your own Gmail, your own WhatsApp, etc. There's no point in using OpenClaw with that much restriction on it.

Which is to say, there is no way to run OpenClaw safely at all, and there literally never will be, because the "lethal trifecta" problem is inherently unsolvable.

https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Android Studio has a nifty little tool that tells you what percentage of users are on what versions of Android. 99.2% of users are on Android 7 or later. I predict that next year, a similar percentage of users will be on Android 8 or later.

This should not be required for apps that do HTTPS requests and store app-local data, like 99%+ of all apps, including 99% of F-Droid apps.

But, in my opinion, the benefit of anonymity to you is much smaller than the harm of anonymous malware authors coaching/coercing users to install phone-takeover apps.

(I'm sure you and I won't agree about this; I bet you have a principled stand that you should be able to anonymously distribute malware phone-takeover apps because "I own my device," and so everyone must be vulnerable to being coerced to install malware under that ethical principle. It's a reasonable stance, but I don't share it, and I don't think most people share it.)

Getting someone to verify their identity before they have the permission to completely takeover my phone feels pretty reasonable to me. It should be a cheap, one-time process to verify your identity and develop an app with that much power.

I can already hear the reply, "What a slippery slope! First Google will make you verify identity for complete phone takeovers, but soon enough they'll try to verify developer identity for all apps."

But if I'm forced to choose between "any malware author can anonymously intercept texts and calls" or "only identified developers can do that, and maybe someday Google will go too far with it," I'm definitely picking the latter.

The use case they're trying to protect against is malware authors "coaching" users to install their app.

In November, they specifically called out anonymous malware apps with the permission to intercept text messages and phone calls (circumventing two-factor authentication). https://android-developers.googleblog.com/2025/11/android-de...

After today's announced policy goes into effect, it will be easier to coach users to install a Progressive Web App ("Installable Web Apps") than it will be to coach users to sideload a native Android app, even if the Android app has no permissions to do anything more than what an Installable Web App can do: make basic HTTPS requests and store some app-local data. (99% of apps need no more permissions than that!)

I think Google believes it should be easy to install a web app. It should be just as easy to sideload a native app with limited permissions. But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.

WebAssembly Components aren't nearly enough to accomplish what this article offers to accomplish. Even once components are a thing, you'd then have to restandardize the entire Web API in their new IDL, WIT.

The WebIDL specifications have taken decades to standardize. It requires Apple, Mozilla, Google, and Microsoft to agree on everything. Getting all of them to agree to restandardize on a new IDL is not going to happen this decade.

It absolutely is. Frankenstein is a seminal work of science-fiction horror, and the mysterious power of electricity to change everything is what made it so chilling to its readers in the 19th century.

> it really doesn’t compare to how much people hyped social media

The media is considerably different now from in 1818, thanks, in significant part, to the power of electricity. I assure you, when the electrical telegraph came on the scene, people were hyped.

Of course, much of that hype was on paper printed on printing presses, so it was, in some sense, "incomparable" to the hype possible on cable television, or the hype that's now possible with online social media.

But if your argument is "Yeah, electricity was kinda hyped, but, you know, not all that hyped, so it proves my point that the more the hype, the less the impact," you have some more research to do. Please just Google "War of the Currents" for a minute.

Yes, electricity was useful. And it had hyperbolic articles talking about how transformative it would be. Like all prognostication, some of those articles were overblown, but, in some ways, they understated the transformative effect electricity would have on human history.

And cars? Did you somehow miss the influx of hyperbolic articles about how cars will change everything? Like, the whole 20th century?

What was your approach to researching the history of media hype? You somehow overlooked the hype around air travel, refrigeration, and antibiotics…?

"Existing measures are working," perhaps?

In Google's announcement in Nov 2025, they articulated a pretty clear attack vector. https://android-developers.googleblog.com/2025/11/android-de...

> For example, a common attack we track in Southeast Asia illustrates this threat clearly. A scammer calls a victim claiming their bank account is compromised and uses fear and urgency to direct them to sideload a "verification app" to secure their funds, often coaching them to ignore standard security warnings. Once installed, this app — actually malware — intercepts the victim's notifications. When the user logs into their real banking app, the malware captures their two-factor authentication codes, giving the scammer everything they need to drain the account.

> While we have advanced safeguards and protections to detect and take down bad apps, without verification, bad actors can spin up new harmful apps instantly. It becomes an endless game of whack-a-mole. Verification changes the math by forcing them to use a real identity to distribute malware, making attacks significantly harder and more costly to scale.

I agree that mandatory developer registration feels too heavy handed, but I think the community needs a better response to this problem than "nuh uh, everything's fine as it is."

A related approach might be mandatory developer registration for certain extremely sensitive permissions, like intercepting notifications/SMSes...? Or requiring an expensive "extended validation" certificate for developers who choose not to register...?

Each of these tools provides real value.

* Bundlers drastically improve runtime performance, but it's tricky to figure out what to bundle where and how.

* Linting tools and type-safety checkers detect bugs before they happen, but they can be arbitrarily complex, and benefit from type annotations. (TypeScript won the type-annotation war in the marketplace against other competing type annotations, including Meta's Flow and Google's Closure Compiler.)

* Code formatters automatically ensure consistent formatting.

* Package installers are really important and a hugely complex problem in a performance-sensitive and security-sensitive area. (Managing dependency conflicts/diamonds, caching, platform-specific builds…)

As long as developers benefit from using bundlers, linters, type checkers, code formatters, and package installers, and as long as it's possible to make these tools faster and/or better, someone's going to try.

And here you are, incredulous that anyone thinks this is OK…? Because we should just … not use these tools? Not make them faster? Not improve their DX? Standardize on one and then staunchly refuse to improve it…?