edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: edbrowse-dev@edbrowse.org
Subject: Re: [edbrowse-dev] It can be done, but is it worth it?
Date: Mon, 29 Mar 2021 17:53:17 +0100	[thread overview]
Message-ID: <YGIF/WyYNBsSrrsU@toaster> (raw)
In-Reply-To: <20210228204322.eklhad@comcast.net>

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.


  reply	other threads:[~2021-03-29 17:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29  0:43 Karl Dahlke
2021-03-29 16:53 ` Adam Thompson [this message]
2021-03-31  2:41   ` Karl Dahlke
2021-03-31 17:31     ` Adam Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YGIF/WyYNBsSrrsU@toaster \
    --to=arthompson1990@gmail.com \
    --cc=edbrowse-dev@edbrowse.org \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).