HN user
The root cause of the containment failure, in the deepest sense, was that their next-generation model was better at offensive security than their humans and current-generation models were at defensive security. That problem's only going to get worse if they keep training more and more capable models.
I might be missing something, so perhaps someone can explain: Why are the steps in the middle of the exploit chain necessary? The writeup describes getting a SQL injection, then going from there to cache poisoning to exploiting various logic bugs, to eventually creating an admin account (and WordPress grants RCE to admin accounts by design). But if you have a SQL injection, why can't you use that to just create an admin account directly, by inserting it into the users table?
I half-agree with this. People occasionally argue that, e.g., Rust won't be suitable for production use until it has two fully independent mature implementations, and I consider this a silly requirement that doesn't serve any real purpose. On the other hand, once multiple separate implementations are already in widespread use, there's immense value in working out a least common denominator of language features and standard library APIs that work everywhere, so that library authors can write portable code that users of any implementation can depend on.
Of course, it's always possible that the standardization body doesn't in practice do a very good job, as seems to maybe be the case with the C++ committee. Also, I'm only talking here about technical considerations, not governance ones.
Works fine for me. There's also the Wayback Machine: https://web.archive.org/web/20260718014646/https://wp2shell....
Pangram's "Supporting Evidence" feature is misleading and you should ignore it. It's entirely separate from the classifier that determines whether text is AI; it just takes text that's already been classified as AI and looks for some hardcoded AI tells in it. I kind of wish they'd get rid of it, but nontechnical users really like it.
The classifier itself has a very low rate of false positives: https://bfi.uchicago.edu/wp-content/uploads/2025/09/BFI_WP_2...
The proposal's at https://hackmd.io/@rust-cargo-team/SJT-p_rL2; progress is tracked at https://github.com/rust-lang/cargo/issues/12633.
What weird new generic features? Generic type aliases? Those aren't very complicated.
One hopes that the usual defenses against insider risk provide some help here.
Unsurprisingly, Wikipedia does not take this position, and is in fact pretty skeptical of self-published and especially AI-generated work. Its guidelines do say that "books published by respected publishing houses" are more likely to be reliable sources, but that's obviously different from having an ISBN, and of course such books are not AI-generated.
The primary sources thing is a different matter; primary and secondary sources serve different purposes.
In fairness, we haven't heard in these economists' own words what their position is and it's possible that it's more nuanced than the author gives them credit for. (There's the quote about Fifty Shades but that's making a more defensible point and doesn't get into the "customer satisfaction" thing.)
If a biography is authorized, then you can interview the subject, and in some cases those interviews provide a lot of the material. Walter Isaacson's biography of Steve Jobs was like this, for example.
If you're talking about the lack of support for binary responses, I don't think this'd stop people from using Base64 to tunnel arbitrary payloads? Otherwise I'm not sure what the alternative would be to "passing the URL in cleartext" to an HTTP client.
Pretty sure you can't do this, you'd need to instead move them into a lib/secrets.js file (which you'd then add to .gitignore).
It does seem kind of odd that they have so little support for developer amenities like secrets management, dependency management, cron tasks, TypeScript, etc, and didn't shape their API in a way that suggests that stuff's coming later. I don't think it'd be that hard to clone the parts of the Cloudflare Workers API that offer that stuff (workerd is even open source, and offers out of the box the V8-based tenant isolation that they need). Perhaps they don't want to support npm packages because this'd make people more likely to run into undocumented code-size limits?
Lets you write a Telegram bot in JavaScript and have Telegram run the code for you on their own servers (with authentication and such handled automatically) instead of having to separately wrangle a cloud deployment.
This is barely a cloud, since it only serves one particular purpose and everything runs in V8 isolates. Although they would need to ensure they're appropriately capping each tenant's compute and bandwidth; the article mostly doesn't get into that.
Fully AOT compilers for JavaScript are basically research projects rather than production-ready platforms, because the extensive dynamicity of JavaScript's semantics makes this a hard problem. (The most mature one I'm aware of is https://porffor.dev.) But even if that weren't the case, the thing Telegram is doing requires V8's low-overhead tenant isolation, so they're bound to V8's architectural choices. V8 does have APIs for code caching and startup snapshots; Telegram could be generating those at deploy time.
I think it was reposted today because https://core.telegram.org/bots/serverless was just announced, which prompted some curiosity on HN about Telegram's architecture (https://news.ycombinator.com/item?id=48918534). But yes, the title should be updated to indicate this.
It's not the terminology I'd have picked if I'd been asked, but at this point it's clearly established and we might as well use it.
Why? Bots using the bot API can't send unsolicited messages to people. (Bots that control regular user accounts without using the API can of course do this, but Signal's not immune to that either.)
I suppose tunneling over Telegram isn't really more ridiculous than tunneling over DNS. Indeed, someone seems to have tried it: https://github.com/PiMaker/Teletun
The post doesn't say anything about runtime resource limits, which I agree is a strange omission given the architecture they've chosen. I suppose someone could try building a bot that uses more and more resources, and see when it stops working.
There's a section about making HTTP requests (https://core.telegram.org/bots/serverless#http), which mentions "two constraints: * Response content is textual (binary payloads aren't supported). * The total response is capped at 32 MB. That cap covers the whole response — streaming with res.body lets you process a large body incrementally, but it does not raise the limit." Unclear whether the 32 MB limit is per outgoing request, or shared among all outgoing requests made by a single handler invocation. Also unclear what other limits apply. Non-HTTP protocols presumably are not available.
In my experience, "silently overwrite" appeared regularly in technical writing long before LLMs were a thing, because it's a useful concept to be able to point at. "Silently go unnoticed" is kind of redundant, though.
<marquee> hasn't been removed; although it is deprecated, the HTML standard requires browsers to support it, and they all do, and I don't think anyone is planning to change this.
<blink> hadn't worked for most users since 1998; Internet Explorer never supported it, and neither did Chrome or Safari. The only browser that dropped support for it was Firefox, which merely brought it in line with how other browsers had always behaved. Furthermore, when it was removed, content in existing pages' <blink> tags still appeared on the page; it just no longer blinked. So there was probably very little breakage, at least if we define "breakage" as "behavior change that causes problems for end users" rather than "any behavior change at all".
By contrast, if they remove scrollHeight, every existing page that uses it will crash.
There's actually a footnote to the <blink> saga that illustrates this perfectly. JavaScript strings have a .blink() method that surrounds them with <blink> tags (e.g., "a".blink() returns "<blink>a</blink>"). With hindsight we can say that making this a fundamental string operation was profoundly silly to begin with, and now that <blink> doesn't even work anymore it's basically 100% useless. Yet it remains in the standard, and every browser still supports it, and they almost certainly always will. Because while removing <blink> didn't cause breakage, removing .blink() absolutely would.
This API dates back to 1999 if not earlier.* Lots of APIs back then weren't designed very carefully, and now we're stuck with them.
* According to https://github.com/mdn/browser-compat-data/blob/v8.0.6/api/E..., Internet Explorer 5 had it. Unfortunately, I don't know of any way to look up which Netscape versions did.
PostHog has always been open core and source-available. What's new is that they now publish a GitHub repo containing just the open source parts.
So does that mean the rewrite made you less skeptical?
I think it's pretty widely recognized these days that type inference for local variables is a good idea. Most major languages that didn't previously have it have since added it.
Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.
TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.
They actually have partial unstable TypeScript 7 support already. Internal documentation of how it works: https://github.com/denoland/deno/blob/main/cli/tsc/README.md...