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] sharing and security
Date: Tue, 23 Mar 2021 07:39:04 +0000	[thread overview]
Message-ID: <YFmbGOM9g1Gylm7n@toaster> (raw)
In-Reply-To: <20210221173421.eklhad@comcast.net>

On Sun, Mar 21, 2021 at 05:34:21PM -0400, Karl Dahlke wrote:
> This is just me thinking out loud.
> 
> Let's say we share the Table class in the master window mw$.
> I don't have to replicate it and its methods for every web page.
> Saves time and memory etc. All good.

Agreed, if we can do so safely.

[...]

> If the prototype object exists, and you can see it, you can add something to it.
> Maybe you can't change what's there, but you can add to it.
> So we would have to be 100% perfect, with a function or at least a stub for every method that exists,
> and we would have to stay current with this as the DOM evolves,
> cause if we don't, a shared class opens up a security risk.

Does it also open us up to any other unintended interaction (e.g.  someone
getting their hands on our prototype object somehow without using our shared
window object)? I simply don't know js well enough to know if there's any
way to get hold of an object's prototype from the object or, in a browser
context, its own window and for that to cascade to other windows if one does that.

> That's how it looks to me anyways.
> 
> Do you follow what I'm saying?
> 
> No wonder every browser writes all its classes in C, thus shared at a level that can't be hijacked;
> but of course we don't have the manpower to do that.
> And if we did, we are, at that point, heavily invested in an engine;
> I couldn't just switch engines in a couple weeks as I just did with quick.
> 
> That's my discouraging thought for the day.

Even if I'm concerned about nothing above, your security explanation makes
perfect sense (unfortunately).  I'm not sure of the best way around this
other than not to share classes.  This'd suck a bit from a performance
perspective (and possibly others) however it'd mean we had a somewhat better
isolation model from a security perspective.

In the spirit of coming up with an overly positive take on this; at least
we're thinking of security and getting to a point where this matters.
That's a good, if work-intensive, thing.

Cheers,
Adam.


      reply	other threads:[~2021-03-23  7:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21 21:34 Karl Dahlke
2021-03-23  7:39 ` Adam Thompson [this message]

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=YFmbGOM9g1Gylm7n@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).