🚀 go-pugleaf

Quadibloc wrote:
> On Wednesday, January 31, 2018 at 6:32:06 AM UTC-7, jmfbahciv wrote:
>
>> that doesn't prevent "bad bits" from occupying the machine.  I would
>> think that a goal should be to prevent this; so the slow machine or
>> slow core would be in the box which passes bits to the real machine.
>
> Ah, so you're saying that the router is the best place for a security
measure.

To keep the kids from tracking in filth, you have them take their boots
off before they get into the house.  Same principle is true with
computer bits and bytes.
>
> It certainly does make sense to stop threats at a level that is as high
> upstream as possible.

This isn't necessarily upstream; it could be a hub.
>
> However, what I'm talking about is bits that... we don't know whether or not
> they're bad.

That's defined by usage and the intent of the user.  My bad bits are your
good bits and visa versa.  Scott's usage of his bits is going to be
"scarier" than a mundane user like me because his usage is stuff
which has "never been before".  I used to do the same kind of work; everyone
in my group had POKE privs which allowed patching the running monitor if
we wished to do so.

>
> A lot of web pages have JavaScript. That lets the web page include a little
> program that runs on your computer. Normally, this is for legitimate
purposes,
> like letting web forms be a little fancier without overloading the server.

This is an abmonination.  If code has to be run in order to display
a web page which a user has requested, that web page should be built
on the "dirty" computer and then pushed to the user's system.

The problem we're having is that noone, especially the operating
systems, keeps the user actions separated from system actions.  There
should have been a strict wall between the two functionalities.
TOPS-10 and TOPS-20 got this right via the UUO interface.  Unix and
MSoft's developers, over the years, got lazy while writing new code
and didn't keep a strict wall between the two.  Hardware manufacturers
had more control over these kinds of edicts; that's no longer the case.
With the introduction of networking, things got really muddled about
who is "boss" and the network wars are still being fought.  There
isn't any agreement about who is boss because everyone is a boss,
especially the poor users who are forced to be system and network
managers with no training, documentation or access to reasonable
advice.

I'll ranting now.


>
> But these programs, because they're programs running on your computer,
_could_
> be doing sneaky stuff there.
>
> One way to deal with this is the virus scanner approach. Check against
patters
> of known tricky JavaScript. You can do _that_ in a router, with deep packet
> inspection at least. But new exploits, or even re-arranged code for old
ones,
> could evade detection.

Correct.  Detection of adverse bit arrangements isn't the key even
though it's a pitiful tool.  The decsions of which are "good"
bit arrangements really need to be done based on the type of usage of
the bit requester.  Now, how that is determined and implemented is
about 4-5 months of bullshit sessions.

>
> So what I'm proposing is some way to approach a more total fix to the
problem.

<grin>  So am I.  The above is thinking so far outside the box that
a whole new computing service provider rigor is going to be developed.
>
> Don't let web sites run programs on your computer at all.

Yup.  But that also has it's problems.  Consider the event where the
data on your computer is the input to the web site's service (which
the user requested by opening the web page).  An example is income
tax.  You don't want your data to be uploaded to anything but you
do want the number (tax owed) to be used to transfer money from
your bank to the government's.
>
> Have those programs run in a second computer, or in a really locked-down
> sandbox virtualization mode, at least. One which basically gets scrubbed and
> re-initialized for every web page you look at (not slow, because it's a tiny
> second computer).

Yes.  I would prefer that the second computer not be in the same physical
box; it allows the functionality and bits to be separated by network
protocol.

>
> If you can't find all the bad bits, ensure that they can do no harm.

That is a result, not a goal because you can't define bad bits until
after they do harm.  Those same bits could do good things.

/BAH