[edbrowse-dev] It can be done, but is it worth it?

[edbrowse-dev] It can be done, but is it worth it?

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

This with regard to sharing classes and methods in the master window.

As mentioned, we put a class or method or constant there, we have to know it can't be tampered with.
Do this.

Object.defineProperty(mw$, "blah",{enumerable:false,writable:false,configurable:false});

Not just what we put in the master window, but the methods we put in the prototypes in the classes in the master window,
and the prototype objects themselves. All of it.
There.

But what stops them from adding something nefarious?
Nothing.
But we can detect it.
After every browse, and after every js function, in jSideEffects(),
I could call a master window tamper check method
that would get all the keys in the master window, and all the keys in the prototypes of our classes,
and count them, and make sure no new ones were added.
See the latest commit which uses GetOwnPropertyNames() to do this.
So we could detect tampering, and if discovered, turn off javascript for the duration of the edbrowse program.
It's ugly to implement, the solution is a bit drastic, but it would be secure,
and would guard against something that almost certainly would never happen.

That's the thought for the day.

Karl Dahlke

Re: [edbrowse-dev] It can be done, but is it worth it?

[Adam Thompson]

On Sun, Mar 28, 2021 at 08:43:22PM -0400, Karl Dahlke wrote:
> This with regard to sharing classes and methods in the master window.
> 
> As mentioned, we put a class or method or constant there, we have to know it can't be tampered with.
> Do this.
> 
> Object.defineProperty(mw$, "blah",{enumerable:false,writable:false,configurable:false});
> 
> Not just what we put in the master window, but the methods we put in the prototypes in the classes in the master window,
> and the prototype objects themselves. All of it.
> There.
> 
> But what stops them from adding something nefarious?
> Nothing.
> But we can detect it.
> After every browse, and after every js function, in jSideEffects(),
> I could call a master window tamper check method
> that would get all the keys in the master window, and all the keys in the prototypes of our classes,
> and count them, and make sure no new ones were added.
> See the latest commit which uses GetOwnPropertyNames() to do this.
> So we could detect tampering, and if discovered, turn off javascript for the duration of the edbrowse program.
> It's ugly to implement, the solution is a bit drastic, but it would be secure,
> and would guard against something that almost certainly would never happen.
> 

Tbh, I'm wondering whether the memory savings etc are worth the sharing at
this point.  There's part of me thinking to simply not have a master window
and pay the penalty that way rather than having to do something ugly like
this.  Particularly as I've performance concerns with this (also with the
idea of not sharing classes but I *think* that'd be less problematic).  Just
another thought.

Cheers,
Adam.

[edbrowse-dev] It can be done, but is it worth it?

[Karl Dahlke]

> There's part of me thinking to simply not have a master window

Well there's no harm in having it, and no harm in using it for our deminimizing debugging stuff,
which doesn't even go out to distribution.
And that's kinda big, half a meg of source.
And it sort of proves the concept if we choose to go further.

Probably some actual functions can be shared safely, probably not classes.

We have plenty of time to step back and think about it.
For now it seems to be working pretty well.
The most important thing is probably our find&fix, and a more complete DOM, etc.

Karl Dahlke

Re: [edbrowse-dev] It can be done, but is it worth it?

[Adam Thompson]

On Tue, Mar 30, 2021 at 10:41:58PM -0400, Karl Dahlke wrote:
> > There's part of me thinking to simply not have a master window
> 
> Well there's no harm in having it, and no harm in using it for our deminimizing debugging stuff,
> which doesn't even go out to distribution.
> And that's kinda big, half a meg of source.
> And it sort of proves the concept if we choose to go further.
> 
> Probably some actual functions can be shared safely, probably not classes.
> 
> We have plenty of time to step back and think about it.
> For now it seems to be working pretty well.
> The most important thing is probably our find&fix, and a more complete DOM, etc.

Agreed, we need to try and fix what we know is broken for now and try and get more things working.  However it's
definitely worth thinking about, particularly as sandboxing individual pages
appears to be an increasingly important part of browser design.