Live data from Hacker News

Shadow: New browser engine made almost entirely in JavaScript

goose.icu

121–130 of 303 posts

Re: Shadow: New browser engine made almost entirely in JavaScript

#121
post #95

There's a product here that's been waiting to happen for awhile. I've been anticipating somebody cross-compiling another browser engine to WASM but this works, too. Deliver your site only to the "inner browser" (that the user has no control over because it's heavily obfuscated and tricked-out with anti-debugging code) and you eliminate all ad blockers. Throw some DNS-over-HTTPS w/ certificate pinning in for good meas…

Pre-render the whole site to a server side canvas and then redraw it.

Flutter is one step from becoming that... I guess that's why google pushes it so much

Re: Shadow: New browser engine made almost entirely in JavaScript

#124

There's a product here that's been waiting to happen for awhile. I've been anticipating somebody cross-compiling another browser engine to WASM but this works, too. Deliver your site only to the "inner browser" (that the user has no control over because it's heavily obfuscated and tricked-out with anti-debugging code) and you eliminate all ad blockers. Throw some DNS-over-HTTPS w/ certificate pinning in for good meas…

> Deliver your site only to the "inner browser" (that the user has no control over because it's heavily obfuscated and tricked-out with anti-debugging code) and you eliminate all ad blockers. Throw some DNS-over-HTTPS w/ certificate pinning in for good measure and you kill DNS-based ad blockers too. I'm confused how the "inner browser" meaningfully helps you accomplish this. How is this any easier or more effective t…

> I'm confused how the "inner browser" meaningfully helps you accomplish this.

Right not it is not hard to write an adblocker, just block network requests and DOM elements (regardless of whom hosts of proxies them).

A browser in a browser would make blocking dom as hard as attaching a debugger and manipulating a price that has been hardened.

Network requests may still be able to be blocked, but it is going to make ad blocking harder.

Re: Shadow: New browser engine made almost entirely in JavaScript

#125

There's a product here that's been waiting to happen for awhile. I've been anticipating somebody cross-compiling another browser engine to WASM but this works, too. Deliver your site only to the "inner browser" (that the user has no control over because it's heavily obfuscated and tricked-out with anti-debugging code) and you eliminate all ad blockers. Throw some DNS-over-HTTPS w/ certificate pinning in for good meas…

Some people are already building this using BrowserBox as the embedded browser layer.

Like a reverse proxy inside the browser, but with a server component.

When i first heard about their idea I couldn’t really comprehend it, and actually I still find it hard to understand. But they think it will be big!

https://dosyago.com/

https://github.com/BrowserBox/BrowserBox

Re: Shadow: New browser engine made almost entirely in JavaScript

#127

There's a product here that's been waiting to happen for awhile. I've been anticipating somebody cross-compiling another browser engine to WASM but this works, too. Deliver your site only to the "inner browser" (that the user has no control over because it's heavily obfuscated and tricked-out with anti-debugging code) and you eliminate all ad blockers. Throw some DNS-over-HTTPS w/ certificate pinning in for good meas…

This sounds like Flutter

Re: Shadow: New browser engine made almost entirely in JavaScript

#128

I think it's pretty cool. Maybe browsers are the kind of thing that should be written in s high level language like js. Except for the JavaScript engine of course.

Alot of the UI in browsers is actually written in HTML/CSS/JS.

Re: Shadow: New browser engine made almost entirely in JavaScript

#129

There's a product here that's been waiting to happen for awhile. I've been anticipating somebody cross-compiling another browser engine to WASM but this works, too. Deliver your site only to the "inner browser" (that the user has no control over because it's heavily obfuscated and tricked-out with anti-debugging code) and you eliminate all ad blockers. Throw some DNS-over-HTTPS w/ certificate pinning in for good meas…

I think this evokes the static vs dynamic linking argument again though. If you consider your browser client code as your "source code" and the browser as a "dynamically linked library", then there are substantial pros and cons.

Your proposal, while feasible, turns this into a static linking affair. This comes with many risks, like becoming complacent and not updating the "inner browser" due to browser incompatibilities and bugs. It creates a giant mess of dependency update hell if you aren't regularly updating the webview.

At that point, you might as well ship a desktop app that does something similar and proxies ads through the first party server since it's probably less work.

You are right that it would work. I just don't know if going to such lengths is required to achieve the same thing.

A good counter is that a desktop app could be exploited to alter the behavior via reverse engineering. But a browser would show you the WASM as well, so I'm sure you could reverse engineer it and alter it with an extension like a traditional binary.

Maybe I'm missing something though - I'll admit that I'm an advocate of WASM but don't keep super up to date on all advancements.

Post reply on HN