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

121–130 of 202 posts

Re: The browser is the sandbox

#121

Post by vbezhenar »

graemep wrote: post #95
vbezhenar wrote: post #65

Earlier quoted context omitted.

Any sandbox technology works fine until it isn't. It's not like you could escape Java sandbox, but Java applets were removed from the browsers due to issues being found regularly. In the end, browser sandbox is one of the few that billions of people use and run arbitrary code there every day, without even understanding that. The only comparable technology is qemu. I don't think there are many hosters who will hand of…

> Java applets were removed from the browsers due to issues being found regularly Java applets were killed off my MS's attempt at "embrace, extent, extinguish" by bundling an incompatible version of Java with IE, and Sun's legal response to this.

No, Microsoft has nothing to do with it. Browsers are controlled by Google and Mozilla and they decided to block Java plugin.

Re: The browser is the sandbox

#122

Post by lukan »

noduerme wrote: post #120
lukan wrote: post #115

Earlier quoted context omitted.

Yes, I know what you mean. I gave up on Adobe Animate. Pixi is great for anything that is a texture, then it is really fast. Otherwise it is not a flash replacement. I do not use it for vector animations, but spritesheets or a webm video overlay is what I would use in your case.

yeah, I really didn't want to use video. The vectors are around 64kb per cut scene. I don't want to create several Mb worth of mp4s for each one.

Did you give it a try? If the scenes are quite short, I found webm to have a reasonable small size.

But .. it bothers me of course as well, having a full video of rastergraphic what could be just some vector and animation data.

Re: The browser is the sandbox

#123

Post by noduerme »

lukan wrote: post #122
noduerme wrote: post #120

Earlier quoted context omitted.

yeah, I really didn't want to use video. The vectors are around 64kb per cut scene. I don't want to create several Mb worth of mp4s for each one.

Did you give it a try? If the scenes are quite short, I found webm to have a reasonable small size. But .. it bothers me of course as well, having a full video of rastergraphic what could be just some vector and animation data.

I haven't tried with webm. But they need to play full screen on desktop and also stream well on mobile.

I might try Spine, I've heard some positive things. They'll still end up as textures in pixi but maybe at least they can pack well.

Re: The browser is the sandbox

#124

Post by cxr »

auggierose wrote: post #98
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.

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 fall into this category. You don't need new or novel APIs to be able to hash a file, for example. It's a developer education problem (see also: hubris).

Re: The browser is the sandbox

#125

Post by curt15 »

nextaccountic wrote: post #49
ijustlovemath wrote: post #18

I've found it interesting that systemd and Linux user permissions/groups never come into the sandboxing discussions. They're both quite robust, offer a good deal of customization in concert,and by their nature, are fairly low cost.

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.

Re: The browser is the sandbox

#126

Post by Sammi »

whywhywhywhy wrote: post #108
layer8 wrote: post #94

Earlier quoted context omitted.

> It makes web apps first class productivity applications. They won’t be first-class as long as native UI still has the upper hand.

This battle is long won in favor of webtech in every realm but 3d/video editing/audio work/things that do gpu heavy lifting like game engines. Outside those sort of spaces it’s hard to name a popular piece of software still on native that isn’t a wrapped webapp.

> video editing

cough CapCut cough

Re: The browser is the sandbox

#127

Post by [deleted] »

modeless wrote: post #9

Last I looked (a couple of years ago), you could ask the user for read-write access to a directory in Chrome using the File System Access API, however you couldn't persist this access, so the user would have to manually re-grant permission every time you reloaded the tab. Has this been fixed yet? It's a showstopper for the most interesting uses of the File System Access API IMO.

[deleted]

Re: The browser is the sandbox

#128

Post by cxr »

augusteo wrote: post #3

The folder input thing caught me off guard too when I first saw it. I've been building web apps for years and somehow missed that `webkitdirectory` attribute. What I find most compelling about this framing is the maturity argument. Browser sandboxing has been battle-tested by billions of users clicking on sketchy links for decades. Compare that to spinning up a fresh container approach every time you want to run untr…

> What I find most compelling about this framing is the maturity argument. Browser sandboxing has been battle-tested by billions of users clicking on sketchy links for decades[…] No system calls, no arbitrary binaries, no direct hardware access.

For the same reasons given, NPM programmers should be writing their source code processors (and other batch processing tools) to be able to run in the browser sandbox instead of writing command-line utilities directly against NodeJS's non-standard (and occasionally-breaking) APIs.

Re: The browser is the sandbox

#129

Post by arthens »

chime wrote: post #37
stevefan1999 wrote: post #4

We never say that it isn't. There is a reason Google developed NaCl in the first place that inspired WebAssembly to become the ultimate sandbox standard. Not only that, DOM, JS and CSS also serves as a sandbox of rendering standard, and the capability based design is also seen throughout many browsers even starting with the Netscape Navigator. Locking down features to have a unified experience is what a browser shoul…

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

My experience with AS3 is limited to a single project ~18 years ago, but I still remember it with fondness. No other language ever got close to how much I liked AS3.

Re: The browser is the sandbox

#130

Post by nitwit-se »

chime wrote: post #37
stevefan1999 wrote: post #4

We never say that it isn't. There is a reason Google developed NaCl in the first place that inspired WebAssembly to become the ultimate sandbox standard. Not only that, DOM, JS and CSS also serves as a sandbox of rendering standard, and the capability based design is also seen throughout many browsers even starting with the Netscape Navigator. Locking down features to have a unified experience is what a browser shoul…

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

Not the only one. I have great memories from many years spent building real products in AS3 - some of them even had users!

For a while RIM/Blackberry was using Adobe Air - on the Playbook and also the built-in app suite in the lead up to the launch of BB10. The latter never saw the light of day though, a late decision was made to replace all of the built-in apps with Qt/Cascades equivalents (if I remember right this was due largely to memory requirements of the Air apps).

Post reply on HN