edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [edbrowse-dev] It can be done, but is it worth it?
@ 2021-03-29  0:43 Karl Dahlke
  2021-03-29 16:53 ` Adam Thompson
  0 siblings, 1 reply; 4+ messages in thread
From: Karl Dahlke @ 2021-03-29  0:43 UTC (permalink / raw)
  To: edbrowse-dev

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [edbrowse-dev] It can be done, but is it worth it?
  2021-03-29  0:43 [edbrowse-dev] It can be done, but is it worth it? Karl Dahlke
@ 2021-03-29 16:53 ` Adam Thompson
  2021-03-31  2:41   ` Karl Dahlke
  0 siblings, 1 reply; 4+ messages in thread
From: Adam Thompson @ 2021-03-29 16:53 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: edbrowse-dev

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [edbrowse-dev] It can be done, but is it worth it?
  2021-03-29 16:53 ` Adam Thompson
@ 2021-03-31  2:41   ` Karl Dahlke
  2021-03-31 17:31     ` Adam Thompson
  0 siblings, 1 reply; 4+ messages in thread
From: Karl Dahlke @ 2021-03-31  2:41 UTC (permalink / raw)
  To: edbrowse-dev

> 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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [edbrowse-dev] It can be done, but is it worth it?
  2021-03-31  2:41   ` Karl Dahlke
@ 2021-03-31 17:31     ` Adam Thompson
  0 siblings, 0 replies; 4+ messages in thread
From: Adam Thompson @ 2021-03-31 17:31 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: edbrowse-dev

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-03-31 17:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29  0:43 [edbrowse-dev] It can be done, but is it worth it? Karl Dahlke
2021-03-29 16:53 ` Adam Thompson
2021-03-31  2:41   ` Karl Dahlke
2021-03-31 17:31     ` Adam Thompson

edbrowse-dev - development list for edbrowse

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/edbrowse-dev

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 edbrowse-dev edbrowse-dev/ http://inbox.vuxu.org/edbrowse-dev \
		edbrowse-dev@edbrowse.org
	public-inbox-index edbrowse-dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.edbrowse.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git