ameliaquining

A sufficiently smart model could get somewhere that way. But again, I think it's less likely that our current ones are already there than that they can defeat the protections outlined in the post. So sandboxing would help.

Well, it seems better than not doing that?

You can keep airgapped software up to date, but you have to sneakernet all the updates to each machine. This isn't impossible if you operate your own data centers, but it's inconvenient, and also it sounds like they're largely using third-party clouds where you can't really do that.

I do think airgapping would be good, since it seems more likely to me that current or near-future frontier models can break out of VMs and hide from traffic monitoring, than that they can establish a conspiracy when they can communicate only in one direction and only via the channel of the experiment output.

I don't understand this comment, are you saying they should allow it to appear in training data?

Prior art here is the much older Oracle of Bacon project (which I'm hoping the author didn't know about). It uses the full IMDb data set (not just the top 10,000 films) and gets different results, with Eric Roberts in first place and Samuel L. Jackson in fifth: https://oracleofbacon.org/center_list.php

Well, it does look really bad at first glance, even if there's apparently an explanation.

I think it is reasonable, if apparently incorrect, for people to assume that your account is a throwaway account, given its name. I'm surprised that you're surprised by this.

Log4Shell wasn't a supply chain attack, though; it was a genuine bug in a widely used library that had become a de facto standard, even in an ecosystem that tends towards relatively smaller and shallower dependency trees. So that comparison doesn't seem apt.

He is in fact going to pay the taxes himself, in the sense that they will come out of his net worth, not Meta's market cap. The significance of this deal is that it allows him to retain voting control of Meta after doing so, which might not otherwise have been possible. The current HN submission title is wildly misleading and I'm asking the moderators to change it (it's not from the original source).

That actually increased my credence that the post is correct, because it indicates that the author isn't just a blind AI skeptic.

I don't think that's very true. Certainly, modern LLMs make it much easier to discover a vulnerability given only limited clues—but if it's easy to find that way, then probably someone will do that and post it for clout. So if no one has, then it probably isn't.

There's no need for an embargo before the patch is available, because the core team can just not tell anyone. It's only once there is a patch that the decision has to be made whether to embargo it.

The specific reason for the current degree of consternation, to the point where many websites went down preemptively which didn't happen even with Log4Shell, is that for about half a day there were multiple alleged proofs-of-concept circulating on Twitter while the PHP Foundation refused to release the patch. If that hadn't been the case, we'd still be having a conversation, but a different one.

Every business is in the business of marketing, that's a meaningless distinction.

The controversy over the embargo is why the post was written and why we're talking about this at all.

You can never rule out the possibility that someone interested in attacking you has a non-public exploit, but it's dramatically less likely if there aren't already working exploits circulating all over the internet.

Yes, but that's not really relevant to the controversy over the embargo.

The specific controversy here is about the disclosure timeline. Some people allege that the disclosure and patch release of this vulnerability were mishandled; others dispute this. The dispute turns crucially on how available exploits were during the embargo period. Nobody is arguing that the vulnerability doesn't need to be patched at all. (The PHP core team didn't initially treat it with much urgency, but they've acknowledged that this was a mistake.)

Log4Shell wouldn't have happened in Rust because no widely used Rust serialization library is designed to call arbitrary code at deserialization time.

Log4Shell was worse than Heartbleed and it doesn't seem totally outrageous to say that this might be worse than Log4Shell.

The problem is that, since proofs-of-concept have leaked but the patch isn't available, bad guys can attack any site whose operators aren't part of the club, and the only thing the operators can really do to prevent that is to take the site offline. (PHP core team has denied that the configuration change fixes the problem.) I would call this a significantly worse outcome than everyone finding out about the vulnerability at the same time, since in that case operators can take timely action if they get the news quickly enough.

C#'s embeddability/interop story is even worse than Go's; IIUC this was the primary reason they chose not to use it.

I expect I'll switch once Vite starts shipping it by default.

The conspiratorial interpretation is that the inclusion of these instructions in the public HTML was a deliberate attempt at prompt injection, targeted at users trying to use their own LLMs to navigate Meta's data-privacy procedures.

You can also do that with Cloudflare Workers if you want.

Source on Bun still being less stable than before the rewrite?

Doesn't this post consist entirely of the kind of narrative reasoning that it says doesn't work?

No, the question asked was whether binaries output by scriptc, such as the tsc-ts compiler binary, include a garbage collector that runs while they're running. (The question was not about the output of tsc-ts.) If not, then that would raise a bunch of questions about how the TypeScript code that was fed into scriptc is being executed without a GC. It is true that a TypeScript compiler could be written in a non-GC language like Rust, but tsc-ts in particular is written in TypeScript, which needs a GC.

The answer, according to https://scriptc.dev/docs/limitations#weak-collections-and-me..., is that scriptc relies primarily on reference counting, augmented with a cycle collector that runs at specific times, kind of like Python.

Yes, they're trusting it that much (https://developers.cloudflare.com/workers/reference/security...). This is nonzero controversial. Of course, spinning up a new isolate takes more than zero time, but it's quick enough that handling it in parallel with the TLS handshake eliminates most of the cold-start time (https://blog.cloudflare.com/eliminating-cold-starts-with-clo...), and also it's less likely to be needed if there's already an instance running somewhere (https://blog.cloudflare.com/eliminating-cold-starts-2-shard-...).

If you use the hosted OpenCode Console and bring your own API keys, then they'd have your keys on their backend servers.