Live data from Hacker News

The browser is the sandbox

aifoc.us

141–150 of 202 posts

Re: The browser is the sandbox

#141
post #54
post #37

Earlier quoted context omitted.

> Sidenote: Flash's scripting language, ActionScript is also directly responsible for the generational design of Java-ahem-ECMAScript later on, also TypeScript too. I feel like I am the only one who absolutely loved ActionScript, especially AS3. I wrote a video aggregator (chime.tv[1]) back in the day using AS3 and it was such a fun experience. 1. https://techcrunch.com/2007/06/12/chimetv-a-prettier-way-to-...

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…

> ... and then it was all killed because Apple did not dare to open source it, or put serious efforts on their own into improving the technical base of the flash player (that had aquired lots of technical dept).

IIRC, they couldn't open source Flash due to its use of a number of 3rd party C/C++ libraries that were proprietary.

Adobe's license with these 3rd parties permitted binary-only distribution so it would have meant renegotiating a fresh license (and paying out $$$) for an EOL codebase that had enormous technical debt, as you also acknowledge in your last sentence.

Re: The browser is the sandbox

#142
post #116

Earlier quoted context omitted.

COM is pretty much alive, it is the main delivery mechanism for new Windows APIs since Windows vista, and in the context of your remark powers UI Automation framework. I have a DDE book somewhere, with endless pages of C boilerplate to exchange a couple of values between two applications on Windows 3.x.

I'm not sure new windows APIs use COM as people remember it. Nowadays they are written against WinRT, which is arguably an evolution of COM.

Not at all, the WinRT APIs that exist, which is indeed one additional interface (IInspectable), .NET metadata instead of type libraries, application identity, is a minority constrained to WinAppSDK and WinUI 3.0, that barely anyone uses other than Microsoft employees on the Windows team.

If not using WinUI 3.0, or Windows ML with CoPilot+, there is no reason to submit oneself to the pain of using CsWinRT or C++/WinRT bindings with lesser tooling than their UWP counterparts.

The large majority of new APIs, since Vista are based on traditional COM, with the biggest exception being UMDF that in version 2.0 rolled back its COM API from version 1.0, back to a C based one.

Re: The browser is the sandbox

#143
post #125

Earlier quoted context omitted.

Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue And today this is.. not suff…

>And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model Unix permissions remain a fundamental building block of Android's sandbox. Each app runs as its own unix user.

Subthread from a while ago where I wrote some details on how Android sandboxing architecture uses Linux’s primitives: https://news.ycombinator.com/item?id=40676309

Re: The browser is the sandbox

#144

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.

[deleted]

Re: The browser is the sandbox

#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.

Re: The browser is the sandbox

#146

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.

Re: The browser is the sandbox

#148

iframes are cool again :)

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

Re: The browser is the sandbox

#149
post #101

> Paul Kinlan is a web platform developer advocate at Google That's enough reason for me to say, f** no. Google will try as hard as possible to promote this even if it's not technically the best solution.

The title of the post is amazing, the content is not. Truly HN

The title and content of my post?
Post reply on HN