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

The browser is the sandbox

aifoc.us

Post reply on HN
Print view View original

171–180 of 202 posts

Re: The browser is the sandbox

#171

Post by jefftk »

cxr wrote: post #167
jefftk wrote: post #161

Earlier quoted context omitted.

Providing a web app with edit access to a local directory is really needed for this to be usable. Without that you're constantly managing downloaded files and manually replacing things. I do think this is a case where the File System Access API shines.

> Providing a web app with edit access to a local directory is really needed for this to be usable. "This" what? sha256sum doesn't need read-write access for even one file to be able to compute a hash, let alone a whole directory. You're ignoring most of my comment, focusing on like 20%, and in so doing, missing (and/or deliberately misframing) 100% of the point.

We're talking about Simon's boosting of https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser. That's what I'm saying needs read-write access.

Re: The browser is the sandbox

#172

Post by dyarosla »

noduerme wrote: post #113
lukan wrote: post #54

Earlier quoted context omitted.

How did you got that impression? There is the universal hate for flash because it was used for ads and had shitty security, but anyone I know who actually used AS3 loved it. At its peak, with flex builder, we also had a full blown UI Editor, where you could just add your own custom elements designed directly with flash ... and then it was all killed because Apple did not dare to open source it, or put serious efforts…

I'm in a terrible situation right now where I promised a client a fairly simple web-based game, to be delivered in pixijs. Pixi is great for what it does, and as an old time Flash game coder, I find it mostly does enough for procedural stuff, although it's got its share of quirks, gotchas, bugs and memory leaks. What I didn't think about was how to get prefab vector animations into this game - not sprite sheets, but…

I also worked on a number of Flash projects in its heyday. I agree that there aren’t really any close equivalents to its feature set today, but there are some tools like Rive and Lottie that I’d consider modern day reimaginings for many multimedia workflows.

Re: The browser is the sandbox

#173

Post by tptacek »

lukan wrote: post #169
tptacek wrote: post #160

Earlier quoted context omitted.

It was by design very difficult to secure.

You mean intentionally? I think they just had the focus on features and speed and fps. Not security nor efficency (battery life).

Not intentionally, but it's one of a couple 90s designs (PDF is another one) that turned out to be goliath security problems just architecturally.

Re: The browser is the sandbox

#174

Post by cxr »

jefftk wrote: post #171
cxr wrote: post #167

Earlier quoted context omitted.

> Providing a web app with edit access to a local directory is really needed for this to be usable. "This" what? sha256sum doesn't need read-write access for even one file to be able to compute a hash, let alone a whole directory. You're ignoring most of my comment, focusing on like 20%, and in so doing, missing (and/or deliberately misframing) 100% of the point.

We're talking about Simon's boosting of https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser. That's what I'm saying needs read-write access.

> https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser

Yup. That's the link, all right—the one we all read and that I'm citing examples from. Thanks for the reminder, I guess: it has been a whole 8 hours since I first looked at it.

What "we" are talking about here, in this subthread, is the fact that "Browsers have had widespread support for processing files" for a long, long time, and that although "Chrome team's new, experimental APIs [...] provide additional capabilities" which are undoubtedly useful for certain programs, they're overkill and don't offer anything new and/or strictly necessary for many, many programs that don't actually need that sort of access—including "A bunch of the applications in the original post [that] fall into this category. You don't need new or novel APIs to be able to hash a file, for example."

Which is to say, we're talking about POLP/POLA. And the point of my comment was to address the very worthwhile matter of POLA violations. But you seem insistent on shutting that discussion down with chatter that looks like it's an on-topic reply or refutation to something, but in reality doesn't actually meaningfully engage with what you're purporting to respond to, or at best comes come across as confused and not particularly attentive.

There are already and will continue to be plenty of opportunities to discuss the acknowledged upsides of the new APIs for the class of programs for which they are strictly necessary. There's a lot of them in this very comment section. It doesn't have to come at the expense of changing the subject in the middle of a different conversation—accompanied by undertones that you're putting some matter to rest.

Re: The browser is the sandbox

#175

Post by jefftk »

cxr wrote: post #174
jefftk wrote: post #171

Earlier quoted context omitted.

We're talking about Simon's boosting of https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser. That's what I'm saying needs read-write access.

> https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser Yup. That's the link, all right—the one we all read and that I'm citing examples from. Thanks for the reminder, I guess: it has been a whole 8 hours since I first looked at it. What "we" are talking about here , in this subthread, is the fact that "Browsers have had widespread support for processing files" for a long,…

I agree we're talking past each other somewhat, but it really feels to me like you're missing the point. Here's the convo:

mg: This is a great example of how useful the File System Access API is ...

auggierose: the API is not supported (yet?) either by Safari or Firefox

you: describes the current situation with cross-browser file input support, says it's a "developer education problem"

me: this specific use case really does need the full API

It read to me, and still does read to me, like you were saying that Kinlan's use of FSA was hubris.

Re: The browser is the sandbox

#176

Post by brid »

kinlan wrote: post #152
brid wrote: post #145

What are the limits of this? Could you replicate Gemini CLI in the browser but with better ux to support non Agentic coding use cases? Could this be used with arbitrary local tools as well? I could be missing something but I don't see how you could use a non remote MCP server with this setup.

I don't want to say Yes... but... given all of these tools are mostly built with JS and wrapped in a TUI we could probably go some way to having it run in the browser. There are fewer and fewer Node based APIs that haven't got a way to run in the browser.

It looks like co-do platform sandboxes the WASM tools, meaning you can't introduce a custom tool that allows pulling in remote data. How would you go about, say, adding custom mcp servers into a tool like you've created? Super interesting!

Re: The browser is the sandbox

#177

Post by cxr »

jefftk wrote: post #175
cxr wrote: post #174

Earlier quoted context omitted.

> https://aifoc.us/the-browser-is-the-sandbox/ which is a prototype of Claude Cowork in the browser Yup. That's the link, all right—the one we all read and that I'm citing examples from. Thanks for the reminder, I guess: it has been a whole 8 hours since I first looked at it. What "we" are talking about here , in this subthread, is the fact that "Browsers have had widespread support for processing files" for a long,…

I agree we're talking past each other somewhat, but it really feels to me like you're missing the point. Here's the convo: mg: This is a great example of how useful the File System Access API is ... auggierose: the API is not supported (yet?) either by Safari or Firefox you: describes the current situation with cross-browser file input support, says it's a "developer education problem" me: this specific use case real…

Boy, this has been a really fun and rewarding experience.

> I agree we're talking past each other

You're exactly half right.

Let's make this dead simple: does anyone need any of these new APIs to compute the SHA-2 hash for a file? A simple answer will do. Simple, non-evasive, no "look thither" misdirection.

Re: The browser is the sandbox

#178

Post by storystarling »

mg wrote: post #82

This is a great example of how useful the File System Access API is. On http://co-do.xyz/ you can select a directory and let AI get to work inside of it without having to worry about side effects. The Fily System Access API is the best thing that happened to the web in years. It makes web apps first class productivity applications.

It definitely makes deployment cheaper, but I'm skeptical about relying on the browser for state management in longer chains. I tried this for a publishing tool and ended up migrating back to LangGraph and Celery just to ensure reliability. The infrastructure savings weren't worth the headache of handling edge cases on the client.

Re: The browser is the sandbox

#179

Post by written-beyond »

I applaud you sir!

You've successfully hacked the collective HN hive mind. I can't go a week without either seeing your post on the frontpage, someone mentioning you, your comment branching into a huge thread or obligatory pelican riding bike SVG.

I don't personally have a taste for LLM comparison posts but your consistency has paid dividends. SimonW is tattooed in my eyelids, a name I shall never forget. Wishing you all the best.

Re: The browser is the sandbox

#180

Post by mike_hearn »

tptacek wrote: post #160
as1mov wrote: post #88

Earlier quoted context omitted.

> There is the universal hate for flash because it was used for ads and had shitty security That's only one side of it. Flash was the precursor to the indie/mobile gamedev industry we have today (Newgrounds, Miniclip, Armor Games), before smartphones become ubiquitous. Not to mention some rather creative websites, albeit at the cost of accessibility . Flash's only fault was it's creators were gobbled up by Adobe, who…

It was by design very difficult to secure.

Arguably, so is the web. A long series of extremely complicated and constantly changing data formats that are nightmarishly difficult to parse, which has to be done in C++ for speed reasons, combined with a full scripting language, which has to be JIT compiled for speed reasons, combined with 30 years of legacy and a security model that was completely ad hoc and more discovered than designed (e.g. the different variants of the same origin policy). Take that and add on top a browser community that doesn't philosophically recognize any limits on what the web is meant to do, so it just keeps getting more and more APIs until one day both Mozilla and the Chrome team decided to just stop pretending and build full blown operating systems on top of them.

I don't think Flash was harder to secure than HTML itself. People just gave up trying because browser vendors used security to purge the web of anything they didn't control.

Post reply on HN