Top
Best
New

Posted by enos_feedler 1 day ago

The browser is the sandbox(simonwillison.net)
334 points | 175 commentspage 4
pdyc 21 hours ago|
that interesting insight, i just added file system support to my internal tool, i thought this was not possible in firefox but the workaround you mentioned works. thanks

by any chance anyone knows if users clicks can be captured for a website/tab/iframe for screen recording. i know i can record screen but i am wondering if this metadata can be collected.

sdoering 21 hours ago|
If you mean capturing click metadata (coordinates, timestamps, target elements) rather than actual pixel recording - yes, that's what tools like Hotjar/FullStory do. They record DOM mutations + interaction events and replay them.

For your own implementation, document-level event listeners work, though cross-origin iframes are off-limits due to same-origin policy.

pdyc 20 hours ago||
yes but i want to capture it without injecting my own js. hotjar etc. need to inject their own js and than they can add mutation observer. I want it for cross-origin frames but after taking users permission similar to screen recording, i guess thats not possible locally.
sdoering 18 hours ago||
> I want it for cross-origin frames but after taking users permission

Sadly not to my knowledge.

pplonski86 22 hours ago||
Are you aware of any lightweight sandboxes for Python? not browser based
simonw 22 hours ago|
You mean for running unsafe Python code?

I'm on a multi-year quest to answer that question!

The best I've found is running Python code inside Pyodide in WASM in Node.js or Deno accessed from Python via a subprocess, which is a wildly convoluted way to go but does appear to work! https://til.simonwillison.net/deno/pyodide-sandbox

Here's a related recent experimental library which does something similar but with JavaScript rather than Python as the unsafe language, again via Deno in a subprocess: https://github.com/simonw/denobox

I've also experimented with using wasmtime instead of Deno: https://til.simonwillison.net/webassembly/python-in-a-wasm-s...

syrusakbary 21 hours ago||
Stay tuned, we are about to release a new version of Wasmer with WASIX, that allows for things that can't currently be done with Pyodide:

  * Multithreaded support
  * Calling subprocesses
  * Signals
  * Full networking support
  * Support for greenlets (say hi to SQLAlchemy!) :)
It requires a small effort in wasmer-js, but it already works fully on the server! :)
albert_e 21 hours ago||
iframes are cool again :)
kinlan 16 hours ago|
Author of the linked post here, years ago there was a thing called "Magic iframes" that would allow you to move an iframe between windows - like a Service Worker before ServiceWorkers. I was always amazed by some of the things you could do, but now it seems we forget about iframes :D
saagarjha 23 hours ago||
I’m not entirely sure this is better than native sandboxes?
dawie 19 hours ago||
Is the source code on GitHub?
tomashubelbauer 19 hours ago|
https://github.com/PaulKinlan/Co-do/
kinlan 16 hours ago||
You beat me to it. Thanks for sharing it
andrewstuart 21 hours ago||
This is obvious isn’t it - headless browsers are the best sandbox if you want the features and can afford the weight.
benatkin 1 day ago||
Good time to surface the limitations of a Content Security Policy: https://github.com/w3c/webappsec-csp/issues/92

Also the double iframe technique is important for preventing exfiltration through navigation, but you have to make sure you don't allow top navigation. The outer iframe will prevent the inner iframe from loading something outside of the frame-src origins. This could mean restricting it to only a server which would allow sending it to the server, but if it's your server or a server you trust that might be OK. Or it could mean srcdoc and/or data urls for local-only navigation.

I find the WebAssembly route a lot more likely to be able to produce true sandboxen.

naikrovek 17 hours ago||
This is the kind of thing that the browser should not need to do. This is the kind of thing that the operating system should be doing. The operating system (the thing you use to run programs securely) should be securing you from bad anything, not just bad native applications.

A large part of the web is awful because of all the things browsers must do that the operating system should already be doing.

We have all tolerated stagnant operating systems for too long.

Plan 9's inherent per-process namespacing has made me angry at the people behind Windows, MacOS, and Linux. If something is a security feature and it's not an inherent part of how applications run, then you have to opt in, and that's not really good enough anymore. Security should be the default. It should be inherent, difficult to turn off for a layman, and it should be provided by the operating system. That's what the operating system is for: to run your programs securely.

AlienRobot 23 hours ago||
The browser being the sandbox isn't a good thing. It's frankly one of the greatest failures of personal computer operating systems.

Can you believe that if you download a calculator app it can delete your $HOME? What kind of idiot designed these systems?

zephen 1 day ago|
An interesting technique.

The problems discussed by both Simon and Paul where the browser can absolutely trash any directory you give it is perhaps the paradigmatic example where git worktree is useful.

Because you can check out the branch for the browser/AI agent into a worktree, and the only file there that halfway matters is the single file in .git which explains where the worktree comes from.

It's really easy to fix that file up if it gets trashed, and it's really easy to use git to see exactly what the AI did.

More comments...