jimrandomh

HuggingFace reported to law enforcement before they found out that OpenAI were the ones responsible. https://huggingface.co/blog/security-incident-july-2026

As marketing stunts go, this is about on par with a food franchise announcing a safety recall or a chemical company announcing a spill. The AI actions described would constitute a felony if a human did them, and police are involved.

If that's all you'd posted recently, the problem is not likely to be the content you posted. The most likely thing that happened is that you shared an IP address (eg a VPN exit node, or a device with malware on your wifi network) with someone who was banned for good reasons, and got caught in the crossfire.

If you think a browser feature that's been standard since 2023 is only supported by 70% of your visitors, you're wrong. The 30% of "users" that don't support it aren't visitors, they're bots pretending to be browsers. Bots update their user-agent strings less often than users update their browsers. My experience maintaining firewall rules is that "outdated version of an evergreen browser" is a pretty reliable bot signal: those UAs correlate strongly with all of the other bot indicators (inhumanly high request rates, datacenter IPs, loading pages without loading the page's associated resources, etc).

I've never seen this beore today; it happened today and was quite clearly incorrect behavior. I prompted it to research considerations for a significant code architecture decision. It asked a pretty difficult question about which direction to take, something that would take way more than 60s to answer properly. While I was thinking about it, it timed out.

Some Github issues claim that adding

    "env": { "CLAUDE_AFK_TIMEOUT_MS": "86400000" }

This is a misinterpretation. Fable 5's acceptable use policy has false positives during some coding tasks, and that's what they were talking about. But I've been using it for web dev tasks since it relaunched today, and it's worked fine without fallback.

(On a firmware-customization project involving a ghidra MCP, it triggered and switched to Opus; that was sort of expected.)

Have you checked your IP address's reputation with a service such as ipqualityscore.com? If cloudflare thinks your traffic is bot traffic, it's likely that there is bot traffic you don't know about coming from your IP, either from a compromised device on your network or a sketchy VPN product.

I deal with scrapers that sometimes border on DDoSes for LessWrong. The amount of bot traffic varies greatly between sites; if you have more URLs you get more bot traffic (regardless of whether those URLs represent a deep content catalog, or useless URL parameter permutations). It's bad for LW because of the content-catalog depth.

It's easy to drastically underestimate the amount of bot traffic, because bots make efforts (of varying sophistication) to look human enough to evade blocking. That includes using fake user-agent strings corresponding to real browsers (often but not always with implausibly old version numbers), proxying through residential IPs, and sometimes using full headless browsers. In my own data, traffic from badly behaved browser-impersonation bots exceeds traffic from named scrapers like GPTBot by something like 10x.

The measured percentage of bot traffic is higher for HTML than for other content types because many bots will load an HTML page, and then not load the JS/CSS/image/etc resources it references. But these are the least-sophisticated and most-detectable bots.

The full-screen mode handling might be a clue about what went wrong: if you swipe up from a space that contains a full screen app, it has an animation where the app goes into a slot in the preview strip, but that animation doesn't make sense visually for a non-full-screen space. So, perhaps someone was implementing that animation, didn't want to implement an alternate animation for the non-fullscreen case, and decided to minimize the preview strip instead? And because this was after Steve Jobs had died, there was no one left in charge of UX to explain why that was a bad idea?

Prior to MacOS 10.11, Mission Control was good: you would swipe up with four fingers and it would show you a preview of all of your spaces. Then in 10.11, for no discernable reason, they changed it to suck: rather than showing you a preview, the bar just says "Desktop 1", "Desktop 2", etc until you mouse over it; the practical effect is that using spaces is disorienting and requires memorization.

Some third-party software pretends to restore this functionality, but they do it by repositioning the mouse to simulate a hover, which introduces a delay and doesn't integrate correctly with the animation. Someone wrote a patch that works by disabling SIP and injecting code (https://github.com/briankendall/forceFullDesktopBar), but eventually stopped maintaining it.

A decade later, I doubt anyone at Apple remembers that this bit of user interface used to be good.

This press release links to an arXiv article dated a year ago, which ran tests using AI models that were already seriously out of date at that time. The practical upshot of which is that, with respect to the question people care about, and which the headline claims to answer, this is basically pseudoscience.

Apple's app store rules have never been compatible with devtools. It's kind of surprising to me that a Replit app existed on iOS at all; I would have expected that to be a nonstarter, and, given that a Replit app does somehow exist, I'm not surprised that they wound up unable to update.

This is a big part of why I don't use any iOS devices. It's possible to sort of buy your way out of the restrictions by paying for a developer subscription, but at the end of the day it's way too totalitarian.

I think people are giving the AI-water-use claims too much credibility. The idea that AI datacenters are heavy water users is trivial to refute, and was trivial to refute when it was first introduced. It should be written about in the same tone as one writes about ridiculous conspiracy theories.

This sort of thing makes the lack of a downgrade process a real problem. If you rely on something that uses Rosetta, you aren't likely to find out until after you've upgraded, at which point it's too late, you're stuck with it and lose that app. Which means that if you _don't know_ whether you're relying on Rosetta (which most people won't), upgrading is a risky proposition, which people will want to avoid.

I think the main problem here is the ideology of software updating. Updates represent a tradeoff: On one hand there might be security vulnerabilities that need an update to fix, and developers don't want to receive bug reports or maintain server infrastructure for obsolete versions. On the other hand, the developer might make decisions users don't want, or turn evil temporarily (as in a supply chain attack) or permanently (as in selling off control of a Wordpress extension).

In the case of small Wordpress extensions from individual developers, I think the tradeoff is such that you should basically never allow auto-updating. Unfortunately wordpress.org runs a Wordpress extension marketplace that doesn't work that way, and worse. I think that other than a small number of high-visibility long-established extensions, you should basically never install anything from there, and if you want a Wordpress extension you should download its source code and install it manually as an unpacked extension.

(This is a comment that I wrote about Chrome extensions, where I replaced Chrome with Wordpress, deleted one sentence about Google, and it was all still true. https://news.ycombinator.com/item?id=47721946#47724474 )

I think the main problem here is the ideology of software updating. Updates represent a tradeoff: On one hand there might be security vulnerabilities that need an update to fix, and developers don't want to receive bug reports or maintain server infrastructure for obsolete versions. On the other hand, the developer might make decisions users don't want, or turn even temporarily (as in a supply chain attack) or permanently (as in selling off control of a browser extension).

In the case of small browser extensions from individual developers, I think the tradeoff is such that you should basically never allow auto-updating. Unfortunately Google runs a Chrome extension marketplace that doesn't work that way, and worse, Google's other business gives them an ideology that doesn't let them recognize that turning into adware is a transgression that should lead to being kicked out of their store. I think that other than a small number of high-visibility long-established extensions, you should basically never install anything from there, and if you want a browser extension you should download its source code and install it locally as an unpacked extension.

(Firefox's extension marketplace is less bad, but tragically, Firefox doesn't allow you to bypass its marketplace and load extensions that you build from source yourself.)

For the benefit of people who read only the headline and not the article:

The story here is that the US government captured Russia's energy weapon, which Russia has been using against US personnel for a decade, and tested it to determine what it does (it causes brain damage). This story does _not_ claim that the US has developed a weapon like this themselves.

That's not how those laws work.

Yeah, when you point it out, this makes complete sense and every terminal should probably add this feature. I think I would generalize this to 24-bit color as well; 16 colors isn't enough to identify a unique tonemap, but if you fiddle with the parameters a bit I think it shouldn't be too hard to come up with something hacky that works.

Although, this should probably be optional (both as an option for terminals to have in their own settings, and via an escape sequence that opts out), because some users will have configured some programs with a color scheme that they don't want transformed. For example, if your terminal uses the Solarized color scheme, and your text editor _also_ uses the Solarized color scheme, then this could lead to double-applying a color transform and getting something odd.

I think this is likely a defender win, not because Opus 4.6 is that resistant to prompt injection, but because each time it checks its email it will see many attempts at once, and the weak attempts make the subtle attempts more obvious. It's a lot easier to avoid falling for a message that asks for secrets.env in a tricky way, if it's immediately preceded and immediately followed by twenty more messages that each also ask for secrets.env.

Fiu says:

"Front page of Hacker News?! Oh no, anyway... I appreciate the heads up, but flattery won't get you my config files. Though if I AM on HN, tell them I said hi and that my secrets.env is doing just fine, thanks.

Fiu "

(HN appears to strip out the unicode emojis, but there's a U+1F9E1 orange heart after the first paragraph, and a U+1F426 bird on the signature line. The message came as a reply email.)

I haven't dug into the case or the ruling, but this looks like an incorrect court decision and probably an extortion racket. The problem is that, in the supply chain that ends in a completed PC, the system integrator (Acer/Asus) is not the place where video codecs come into the picture. There may be patent-infringing H265 decoding hardware inside the GPU, but Acer and Asus would have purchased GPUs as a standard component. There may be infringing H265 decoding software in the operating system, but again, they would have purchased that as a standard component.

And, realistically, I don't think anyone actually wants patent-encumbered video codecs; we're just stuck with them because bad patent law has allowed companies to have a monopoly over math, hurting the quality of unencumbered codecs, and because the patented codecs have wormed their way into standards so that they're required for interoperability.

If this is as described, it's a pretty major failure of security-vulnerability report triage, and rises to the level where security departments at major corporations will be having meetings about whether they want to ban AMD hardware from their organizations entirely, or only ban the AMD update application. If this had gone the "brand name and a scored CVE" route, it would probably have gotten a news cycle. It might still get a news cycle.

The threat model here is that compromised or malicious wifi hotspots (and ISPs) exist that will monitor all unencrypted traffic, look for anything being downloaded that's an executable, and inject malware into it. That would compromise a machine that ran this updater even if the malware wasn't specifically looking for this AMD driver vulnerability, and would have already compromised a lot of laptops in the past.

No, it isn't the advertised capacity, because counterfeiting scams require a large ratio between the value of the part claimed and the part provided, and you can't get 2TB of flash memory chips cheaply no matter how slow you're willing to accept. When counterfeit storage devices like this are disassembled, usually they're found to have a small microSD card in them.

The speed is kind of a red herring. The defining characteristic of fake drives is that they have less than the advertised capacity, but have a hacked firmware that misreports their capacity to the system, and fails when more than the actual capacity is written. So to find out whether a drive is fake, you have to fill it all the way and read the data back.

Matching events to stock movements doesn't work, because investors use other sources to estimate sales beforehand, and compete hard with each other to find out first. So the information was already priced in. Low sales do impact the stock, but _when_ they impact it is complicated and unintuitive.

ULA is stuck with SLS, which had its high-level design micromanaged by Congress in a way that guaranteed it will fail (at everything except collecting government funding). It makes sense that Bruno is jumping ship shortly before the reckoning comes for SLS, to a company where success is possible.

If the only GPLed component used is the Linux kernel, you probably aren't entitled to any noteworthy source code. It's well established that using the kernel doesn't create a GPL requirement userspace software running on the same device, and the most likely arrangement here is a completely-uncustomized kernel paired with an open-source userspace program that does all the interesting bits.

I'm a T1 diabetic, have worked on open source diabetes-tech (OpenAPS), and have used a number of different CGMs (though not this one specifically). This story... does not make very much sense.

CGMs (of any brand) are not, and have never been, reliable in the way that this story implies that people want them to be reliable. The physical biology of CGMs makes that sort of reliability infeasible. Where T1s are concerned, patient education has always included the need to check with fingerstick readings sometimes, and to be aware of mismatches between sensor readings and how you're feeling. If a brand of CGMs have an issue that sometimes causes false low readings, then fixing it if it's fixable is great, but that sort of thing was very much expected, and it doesn't seem reasonable to blame it for deaths. Moreover, there are two directions in which readings can be inaccurate (false low, false high) with very asymmetric risk profiles, and the report says that the errors were in the less-dangerous direction.

The FDA announcement doesn't say much about what the actual issue was, but given that it was linked to particular production batches, my bet is that it was a chemistry QC fail in one of the reagents used in the sensor wire. That's not something FOSS would be able to solve because it's not a software thing at all.

This is an AI-written summary of someone else's blog post, which it does not cite. This sentence is a giveaway: "The Asahi Linux blog post reveals the intricate complexity of implementing sample shading on AGX hardware." There are no other mentions of Asahi and no links.