Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes on the new Claude analysis JavaScript code execution tool

simonwillison.net

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Notes on the new Claude analysis JavaScript code execution tool

#11

Post by spankalee »

simonw wrote: post #3

I've been trying to figure out the right pattern for running untrusted JavaScript code in a browser sandbox that's controlled by a page for a while now, looks like Anthropic have figured that out. Hoping someone can reverse engineer exactly how they are doing this - their JavaScript code is too obfuscated for me to dig out the tricks, sadly.

The key is running the untrusted code in a cross-origin iframe so you can rely on the same-origin policies and `sandbox`[1].

You can control the code in a number of ways - loading a trusted shim that sets up a postMessage handler is pretty common. You can be careful and do that in a way that untructed code can't forge messages to look like their from the trusted code.

Another way is to use two iframes to the untrusted origin. One only loads untrusted code, the other loads a control API that talks to the trusted code. You can then to the loading into the iframe with a service worker. This is how the Playground Elements work (they're a set of web components that let you safely embed a mini IDE for code samples) https://github.com/google/playground-elements

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

Re: Notes on the new Claude analysis JavaScript code execution tool

#12

Post by TimTheTinker »

aabhay wrote: post #5
simonw wrote: post #3

I've been trying to figure out the right pattern for running untrusted JavaScript code in a browser sandbox that's controlled by a page for a while now, looks like Anthropic have figured that out. Hoping someone can reverse engineer exactly how they are doing this - their JavaScript code is too obfuscated for me to dig out the tricks, sadly.

What are the attack vectors for a web browser js environment to do malicious things? All browser code is sandboxed via origin controls, and process isolation. It can’t even open an iframe and read the contents of that iframe.

It's a fine place to run code trusted by the server (or code trusted by the client within the scope of the app).

But for code not trusted by either, it's bad -- user data in the app can be compromised/exfiltrated.

Hence for third-party plugins for a web app, the built-in JS runtime doesn't have sufficient trust management capability.

Re: Notes on the new Claude analysis JavaScript code execution tool

#14

Post by TheRealPomax »

dartos wrote: post #4
simonw wrote: post #3

I've been trying to figure out the right pattern for running untrusted JavaScript code in a browser sandbox that's controlled by a page for a while now, looks like Anthropic have figured that out. Hoping someone can reverse engineer exactly how they are doing this - their JavaScript code is too obfuscated for me to dig out the tricks, sadly.

Isn’t that how all JavaScript code runs in a browser?

Isn't what how all JS runs in the browser? There are different restrictions based on where JS comes from, and what context it gets loaded into.

Re: Notes on the new Claude analysis JavaScript code execution tool

#15

Post by refulgentis »

mritchie712 wrote: post #13

duckdb-wasm[0] would be a good addition here. We use it in Definite[1] and I can't say enough good things about duckdb in general. 0 - https://github.com/duckdb/duckdb-wasm 1 - https://www.definite.app/

Interesting: I'm curious, what about it helps here specifically.

Approaching it naively and undercaffeinated, it sounds abstract, as in it would benefit the way any code could benefit from a persistence layer / DB

Also I'm curious if it would require a special one-off integration to make it work, or could it write JS that just imported the library?

Re: Notes on the new Claude analysis JavaScript code execution tool

#16

Post by [deleted] »

TimTheTinker wrote: post #12
aabhay wrote: post #5

Earlier quoted context omitted.

What are the attack vectors for a web browser js environment to do malicious things? All browser code is sandboxed via origin controls, and process isolation. It can’t even open an iframe and read the contents of that iframe.

It's a fine place to run code trusted by the server (or code trusted by the client within the scope of the app). But for code not trusted by either, it's bad -- user data in the app can be compromised/exfiltrated. Hence for third-party plugins for a web app, the built-in JS runtime doesn't have sufficient trust management capability.

[deleted]

Re: Notes on the new Claude analysis JavaScript code execution tool

#17

Post by njtransit »

aabhay wrote: post #5
simonw wrote: post #3

I've been trying to figure out the right pattern for running untrusted JavaScript code in a browser sandbox that's controlled by a page for a while now, looks like Anthropic have figured that out. Hoping someone can reverse engineer exactly how they are doing this - their JavaScript code is too obfuscated for me to dig out the tricks, sadly.

What are the attack vectors for a web browser js environment to do malicious things? All browser code is sandboxed via origin controls, and process isolation. It can’t even open an iframe and read the contents of that iframe.

The attack vectors are either some type of credential or account compromise. Generally, these attacks fall under the cross-site scripting (XSS) umbrella. The browser exposes certain things to the JS context based on the origin. E.g. if you log in to facebook.com, facebook.com might set an authentication cookie that can be accessed in the JS context. Additionally, all outbound requests to facebook.com will include this authentication cookie. So, if you can execute JS in the context of facebook.com, you could steal this cookie or have the browser perform malicious actions that get implicitly authenticated.

Re: Notes on the new Claude analysis JavaScript code execution tool

#19

Post by stanleydrew »

animal_spirits wrote: post #2

That's an interesting idea to generate javascript and execute it client side rather than server side. I'm sure that saves a ton of money for Anthropic not by not having to spin up a server for each execution.

Also means you're not having to do a bunch of isolation work to make the server-side execution environment safe.

Re: Notes on the new Claude analysis JavaScript code execution tool

#20

Post by qeternity »

animal_spirits wrote: post #2

That's an interesting idea to generate javascript and execute it client side rather than server side. I'm sure that saves a ton of money for Anthropic not by not having to spin up a server for each execution.

The cost savings for this are going to be a rounding error. I imagine this is a broader push to be able to have Claude pilot your browser (and other applications) in the future. This is the right way to go about it versus having a headless agent: users can be in the loop and you can bootstrap and existing environment.

Otoh it’s going to be a security nightmare.

Post reply on HN