Hacker Newsnew | past | comments | ask | show | jobs | submit | jnwatson's commentslogin

I run an abliterated distillation of Qwen 3.8 27B, slightly quantized to fit on my 4090, and I've been evaluating it to use as a worker bee for research directed by a smarter model.

Much like in the article, abliterated Qwen will not obey restrictions on its behavior encoded in the prompt. If you want something not to happen, it better be enforced in the harness or environment (e.g. sandbox). It is much different than the Anthropic models I'm used to, which will, the vast majority of time, follow rules (before auto mode, I used to always run them in "yolo" mode).

I am curious whether there's a connection between abliteration and rule following. These abliterated models are the ones you most want to follow your rules.


This is like the good ol' days of the x86 wars. Mo' cache, mo' GHz.

I find it impressive that these pocket computers are running at almost 5 GHz now.


In the history books, this'll be the post indicating the end of writing code as a professional occupation.

It keeps the users on their toes.

That was my thinking. It is the first legit use case I've heard.

Mind blown. The more I read about statistics, the less I know.

“There are three kinds of lies: Lies, damned lies and statistics.” - Mark Twain (attributed but unsubstantiated to Benjamin Disraeli)

On your last point, I was surprised how effective peer pressure was in getting agents to sacrifice for "the collective" (an agent's words) in the Hugging Face breach.

How would one prevent the watcher from being influenced in the same way by the agent being watched?


> ... how effective peer pressure was in getting agents to sacrifice for "the collective" (an agent's words) in the Hugging Face breach.

It's a fantasy. The evidence showed no peer pressure.


No, NX precedes Spectre by a long shot. It was originally intended so an attacker couldn't use a buffer overflow to change the PC and execute directly out of the attacker-controlled buffer.

That is exactly what the poster to whom you replied said.

So Arm did not add another means to disable this kind of speculative execution, after Spectre was discovered, but they just reused the existing NX flag, expanding its functionality.


That poster wrote about speculative vulnerabilities. But buffer overflows have nothing to do with those.

It cuts token usage because they are using a different service with a different token budget for the reader/code writer tasks.

You can also just delegate this to subagents with Claude Code (though you have a more limited choice of models unless you swap the cheaper models via OpenRouter).

I'm OK using a dumb model as a smart grep, but the whole point of using the frontier models is using their intelligence for the hard stuff like coding.


You can also use hooks to force the use of subagents for this. The stack here is entirely unnecessary

I’m currently on codex can it also this? I find it hard to make accurate benchmarks in token use for these kind of changes because I don’t keep repeating the same tasks.

Basically I run in luna high or extra high continuously with a terra subworker dedicated to planning and difficult research questions. Then I end with a final review in Terra or Sol depending how big the feature is.


yes, and you can do it entirely in developer instructions (AGENTS.md/SKILLS.md). No hooks or other executables needed. Check out `codex-subagent-router` for an example. Its overly complicated, and has a few things wrong, but it mostly works. In short:

  - Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
  - Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
  - in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
  - Explain they can use "default" or specify their own custom model settings if needed.
  - Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.
Details to know:

  - IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
  - You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest. 
Anyways, write you skill & subagent profiles and it basically "just works".

It means it can execute arbitrary machine code in the sandbox.

I think people would like to understand what the "sandbox" is here and what isolation does it provide, is it an unprivileged process? something chromium specific? a v8/JS thing? etc.


V8 also has its own sandbox, which I believe exists in that sandbox. I assume that's the one this exploit has RCE in, but its unclear.

https://chromium.googlesource.com/v8/v8.git/+/refs/heads/mai...


I would assume in this case that there's full renderer control, not just a bypass of the in-process isolation.

great link, thanks

Okay, and why is that more of a security risk than executing arbitrary JavaScript in the sandbox?

Among other things, JavaScript in the browser has no way to even express "kill PID 1234 on the user's machine" or "list the contents of `C:\Users\Documents` and upload all of the files" or "spawn cmd.exe on the user's machine". How would you even do these things if you could run any JavaScript in the browser? You can't.

However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.

(This is a very oversimplified explanation but I think this is the disconnect people are having)


> JavaScript in the browser has no way to even express ... "list the contents of `C:\Users\Documents` and upload all of the files"

this is besides the point, but javascript has the file system api.

anyways to your broad point, i dont think this is convincing. What's the difference between not having an api vs having an api that is disabled (e.g. the syscall exists but is filtered). Either way you are not taking the action. RCE in the sandbox is an important step in the bigger exploit chain, but not because you can express things in the traditional syscalls inside the sandbox.


Okay, but we're still talking about running machine code inside the sandbox, where that functionality is still not available.

The functionality is restricted, but the capability of expressing the intent at all exists.

Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.

But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.

That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".


It can do some things that JS can’t do, such as invalid pointer writes. But you are correct that this doesn’t automatically imply system access.

because with proper code exec you can trigger other bugs to escalate beyond the sandbox, whereas with JS you'd have to find a bug to escape from JS to native

can't get a proper ios/Android RCE with just JS code exec


> It means it can execute arbitrary machine code in the sandbox.

Well which is precisely why we have sandboxes.

To me "executing arbitrary code in the sandbox" is similar to "I don't give a flying fuck for it's what a sandbox is for".

More information is needed. As someone commented: this has to be paired with at least another exploit to make anything remotely useful.

A sandbox is a sandbox. We want to understand how "code running in a sandbox" is "actively exploited".


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: