Re: [Edbrowse-dev] a JS centric design

[Chris Brannon <chris@the-brannons.com>]

Adam Thompson <arthompson1990@gmail.com> writes:

> And both insecure and incredibly fragile against a malicious web page.
> Someone could insert all sorts of crud in there,
> or use some sort of compromise to insert a magic property in place of the array
> to, for example (in a world where we have ajax)
> capture all cookies set by a different website or similar (and I've not even
> tried to think about this too hard).

Yes, the possibility of exposing internals to JavaScript seems too
fraught with danger, and it seems that the best (and only?) place for
them is in native code.

> That's, if anything, why we need a *more* native DOM,
> but decoupled from the js engine, i.e.
> create object stubs which go back to the DOM to set DOM attributes so we don't
> need to make a bunch of js variable checks to render the DOM.

Yes, the problem we had with native code was, first and foremost, that
it was fragile.  How many months did we spend porting from Spidermonkey
1.8.5 to Spidermonkey 24?  What happens when 24 gets end-of-lifed and
we're stuck scrambling to move to a new engine?  This is why moving as
much as possible out of native code is so darned attractive.
It's a very sweet siren's song.  But if we could come up with a native
DOM that wasn't tied to an engine, it would be even better.  So where do
we start?

> However, if I've learned anything about the internet it's that, in general,
> browsers are the primary way of exploiting users' computers

That's because the industry has been singing the "do it in the browser"
tune since the mid-90s, and now, a document delivery platform is being
used for everything under the sun, from word processing to online
banking.  It wasn't designed for most of these things, so we have this
horrible impedence mismatch.
Unfortunately, we can't change that.

-- Chris