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

Unix in the Browser Tab

browsix.org

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Unix in the Browser Tab

#61

Post by Ralo »

nteon wrote: post #44

I'm one of the authors - its so exciting to see continued interest here! The biggest problem with Browsix today stems from Spectre mitigations: Shared Array Buffers aren't enabled by default in browsers, and static hosting sites like GitHub Pages don't let you set the right COOP/COEP ( https://web.dev/coop-coep/ ) headers to get them enabled AFAICT. Additionally, Browsix hasn't been updated in a while, although I sti…

Weirdly enough, I was complaining about this exact issue this week. You can setup COOP/COEP in Github pages but you are still restricted to same domain for all resources. Which may or may not work in your case.

I've been working on a modified Emscripten runtime that treats threads as separate "programs" with their own memory, etc. Not an optimal solution at all but sometimes you need to hack your way around a problem.

Re: Unix in the Browser Tab

#62

Post by rezonant »

nteon wrote: post #35
pcthrowaway wrote: post #8

Earlier quoted context omitted.

Interesting, I'm assuming Browsix must have been rewritten in Typescript significantly later; TS must have been much more niche in 2016 (though wikipedia tells me it may be as old as 2012)

(one of the authors here) it was written in Typescript from the start! Typescript eliminated a bunch of type confusion errors when developing the kernel, although the need to marshal data across a MessagePort means we have to do some casting and lose some safety.

That's awesome!

I wouldn't say it's less compile-time type safety assuming you assert the type of the data as soon as you obtain it. Typescript doesn't give you runtime safety anyway, so I can't really imagine any better way short of adding types to the actual runtime and making the browser assert them across MessageEvent.

Re: Unix in the Browser Tab

#63

Post by rank0 »

rezonant wrote: post #60
rank0 wrote: post #56

Earlier quoted context omitted.

Ah thanks for pointing that out. But nonetheless, this is useful technology for a malicious actor. For example, a functioning http server would enable an http proxy that could intercept/modify requests made from the client no? Now I can add headers to requests made by an html form submit. This might allow for more potent csrf attacks, or circumvention of controls like the HttpOnly cookie flag. Can I use a victims bro…

No, you can't start a web server within Browsix that can accept connections from outside Browsix. Just like you can't do that in regular JavaScript in the browser.

I see. So an form submit POST request could not actually be sent to Browsix?

Re: Unix in the Browser Tab

#64

Post by rezonant »

rank0 wrote: post #63
rezonant wrote: post #60

Earlier quoted context omitted.

No, you can't start a web server within Browsix that can accept connections from outside Browsix. Just like you can't do that in regular JavaScript in the browser.

I see. So an form submit POST request could not actually be sent to Browsix?

That's right, unless the form was running in Browsix, or I suppose at least the same browsing context (ie same origin on the same browser instance on the same computing device) since you could emulate submission across multiple tabs of the same website using something like the BroadcastChannel API[1]

[1] https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_C...

EDIT: To be clear, this would require effort (TM)- the form would need to have a Javascript onsubmit handler and use preventDefault to stop the browser itself from handling it in order to facilitate that

Re: Unix in the Browser Tab

#65

Post by rank0 »

rezonant wrote: post #64
rank0 wrote: post #63

Earlier quoted context omitted.

I see. So an form submit POST request could not actually be sent to Browsix?

That's right, unless the form was running in Browsix, or I suppose at least the same browsing context (ie same origin on the same browser instance on the same computing device) since you could emulate submission across multiple tabs of the same website using something like the BroadcastChannel API[1] [1] https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_C... EDIT: To be clear, this would require effort (TM)-…

Neat! Thanks for working on this project and answering my questions.

Perhaps I need to look into it more but what you’re describing isn’t exactly far fetched.

With a csrf attack the victim has navigated to a malicious web app where the cross origin request does originate from the same browser instance where my hypothetical browsix http proxy is running.

Since I control the malicious app, I don’t see why I wouldn’t be able to have an onsubmit handler that proxies requests into browsix.

I’m not saying there’s guaranteed offensive use cases here…it’s just my intuition telling me it’s worth looking into for myself.

My comments aren’t intended as a criticism of your library. If I got a client to navigate to a web app I control there’s plenty of js-enabled damage to be caused without browsix.

Re: Unix in the Browser Tab

#66

Post by nteon »

Ralo wrote: post #61
nteon wrote: post #44

I'm one of the authors - its so exciting to see continued interest here! The biggest problem with Browsix today stems from Spectre mitigations: Shared Array Buffers aren't enabled by default in browsers, and static hosting sites like GitHub Pages don't let you set the right COOP/COEP ( https://web.dev/coop-coep/ ) headers to get them enabled AFAICT. Additionally, Browsix hasn't been updated in a while, although I sti…

Weirdly enough, I was complaining about this exact issue this week. You can setup COOP/COEP in Github pages but you are still restricted to same domain for all resources. Which may or may not work in your case. I've been working on a modified Emscripten runtime that treats threads as separate "programs" with their own memory, etc. Not an optimal solution at all but sometimes you need to hack your way around a problem…

How did you get COOP/COEP in Github pages? A quick search just now suggested it might be possible with a Service Worker[0], with the caveat that it may only work on _second_ load.

0 - https://dev.to/stefnotch/enabling-coop-coep-without-touching...

Re: Unix in the Browser Tab

#67

Post by Ralo »

nteon wrote: post #66
Ralo wrote: post #61

Earlier quoted context omitted.

Weirdly enough, I was complaining about this exact issue this week. You can setup COOP/COEP in Github pages but you are still restricted to same domain for all resources. Which may or may not work in your case. I've been working on a modified Emscripten runtime that treats threads as separate "programs" with their own memory, etc. Not an optimal solution at all but sometimes you need to hack your way around a problem…

How did you get COOP/COEP in Github pages? A quick search just now suggested it might be possible with a Service Worker[0], with the caveat that it may only work on _second_ load. 0 - https://dev.to/stefnotch/enabling-coop-coep-without-touching...

That was basically it, not a great solution.

Re: Unix in the Browser Tab

#68

Post by quasarj »

nteon wrote: post #44

I'm one of the authors - its so exciting to see continued interest here! The biggest problem with Browsix today stems from Spectre mitigations: Shared Array Buffers aren't enabled by default in browsers, and static hosting sites like GitHub Pages don't let you set the right COOP/COEP ( https://web.dev/coop-coep/ ) headers to get them enabled AFAICT. Additionally, Browsix hasn't been updated in a while, although I sti…

It said I needed Firefox Nightly, so I installed it, and it still doesn't work. How do I enable Shared Array Buffers? Google is no help..

Re: Unix in the Browser Tab

#69

Post by pcthrowaway »

nteon wrote: post #35
pcthrowaway wrote: post #8

Earlier quoted context omitted.

Interesting, I'm assuming Browsix must have been rewritten in Typescript significantly later; TS must have been much more niche in 2016 (though wikipedia tells me it may be as old as 2012)

(one of the authors here) it was written in Typescript from the start! Typescript eliminated a bunch of type confusion errors when developing the kernel, although the need to marshal data across a MessagePort means we have to do some casting and lose some safety.

Thanks for the response! I don't know what the MessagePort is, but have dealt with the pains of marshaling/unmarshaling in a browser caching library I wrote that stores app data in localStorage (which is string-only)

Re: Unix in the Browser Tab

#70

Post by 0xbadcafebee »

The browser is an operating system now. Chromebooks proved that a long time ago. Every single feature of a native app is implemented in the browser now. There's already multiple different versions of "apps in browsers" (PWAs, SPAs, etc). It's just taking the industry a very long time to come to grips with the fact that they are writing dynamically-downloaded-and-interpreted apps for an operating system in an operating system in a scripting language that uses assembly to implement another virtual machine. They can't come right out and say it because it's ridiculous. But that's what it is.

We failed at making network protocols, so every protocol improvement now goes over HTTPS. We failed at making universal virtual machine-based applications, so every new app is in the browser. We failed to bridge the gaps of client-based, server-based and p2p computing, so we build all 3 into one interface. None of academic computer science seems to reflect this, and we still write most of our code by hand like it's the 1970's. We use fixed-width text-based 80-character terminals embedded in 8K OLED displays. Our telephones have as much processing power, memory and storage as our desktop computers and use batteries that last for 2 days (and are 1/10th the size), but we haven't yet standardized on one way to create new lines in a text file.

We're farmers from the 17th century working at a biotech startup.

Post reply on HN