🚀 go-pugleaf

On 2 Feb 2018 14:19:17 GMT, jmfbahciv <See....@aol.com> wrote:

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

I think you will find that the opposite has occurred.  Early PCs
didn't even have the means to enforce such a wall.  Now modern
operating systems run just about everything in userspace at some level
of virtualization.

> 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