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

161–170 of 202 posts

Re: The browser is the sandbox

#161

Post by jefftk »

cxr wrote: post #124
auggierose wrote: post #98

Earlier quoted context omitted.

Unfortunately, this feature of the API is not supported (yet?) either by Safari or Firefox.

Browsers have had widespread support for processing files via drag-and-drop and the element since HTML5 ( The Chrome team's new, experimental APIs are a separate matter. They provide additional capabilities, but many programs can get along just fine without since they don't don't strictly need them in order to work—if they would ever even have end up using them at all. A bunch of the applications in the original post…

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.

Re: The browser is the sandbox

#163

Post by jefftk »

RodgerTheGreat wrote: post #23
utopiah wrote: post #20

Wrong title, if it's "File System Access API (still Chrome-only as far as I can tell)" then it should read "A browser is the sandbox". At the risk of sounding obvious : - Chrome (and Chromium) is a product made and driven by one of the largest advertising company (Alphabet, formally Google) as a strategical tool for its business model - Chrome is one browser among many, it is not a de facto "standard" just because it…

I stand by a policy that if a feature in one of my projects can only be implemented in Chrome, it's better not to add the feature at all; the same is true for features which would be exclusive to Firefox. Giving users of a specific browser a superior experience encourages a dangerous browser monoculture.

Not writing the feature makes sense, but pushing Firefox and Safari to add support would be pro-social if you're up for it. The most common reason for browsers not to add support is something like "this can be done in other ways, and it has maintainability/security/bloat downsides". Running into a feature you can't build is evidence on the "this can be done in other ways" question (but of course the other downsides could still be big enough that it's not worth doing).

Re: The browser is the sandbox

#166

Post by storystarling »

rcarmo wrote: post #40

I don't buy it. It might be very useful for a few use cases, but despite all the desktop automation craze and "Claude for cooking" stuff that is inevitably to follow, our computing model for live business applications has, for maintainability, auditability, security, data access, etc. become cloud-centric to a point where running things locally is... kind of pointless for most "real" apps. Not that I'm not excited ab…

For bootstrapped GenAI apps, moving inference to the browser is basically an economic necessity. I'm refactoring a service right now to offload image generation to the client because the backend GPU costs make the margins impossible otherwise. It makes the architecture much messier, but unless you have VC money to burn on compute, the user's hardware is the only free resource you have.

Re: The browser is the sandbox

#167

Post by cxr »

jefftk wrote: post #161
cxr wrote: post #124

Earlier quoted context omitted.

Browsers have had widespread support for processing files via drag-and-drop and the element since HTML5 ( The Chrome team's new, experimental APIs are a separate matter. They provide additional capabilities, but many programs can get along just fine without since they don't don't strictly need them in order to work—if they would ever even have end up using them at all. A bunch of the applications in the original post…

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.

Re: The browser is the sandbox

#168

Post by [deleted] »

kinlan wrote: post #146
vbs_redlof wrote: post #28

What I'd really like to see is some kind of iframe that pins JS/wasm code within it to a particular bundle hash and prevents modification at runtime (even from chrome extensions). Something more like a TEE inside the browser of sorts. Not sure if there is anything like this.

Author of the linked post here. This is actually a pretty interesting idea, I'll pass it to the team.

[deleted]

Re: The browser is the sandbox

#169

Post by lukan »

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.

You mean intentionally?

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

Re: The browser is the sandbox

#170

Post by spankalee »

kinlan wrote: post #146
vbs_redlof wrote: post #28

What I'd really like to see is some kind of iframe that pins JS/wasm code within it to a particular bundle hash and prevents modification at runtime (even from chrome extensions). Something more like a TEE inside the browser of sorts. Not sure if there is anything like this.

Author of the linked post here. This is actually a pretty interesting idea, I'll pass it to the team.

Enabling the `integrity ` attribute on iframes would help: https://github.com/w3c/webappsec-subresource-integrity/issue...

But then you'd also want the frame content to use `integrity` on nested resoures.

CSP frame-src can help for now.

Post reply on HN