[GoLUG] JS allows Linux to be a first class citizen on the internet.

[Barry Fishman]

On 2025-08-27 02:22:57 -07, Ron wrote:
> Barry Fishman wrote on 2025-08-22 12:13:
>>>> Couldn't independently reviewed repositories exist, to people
>>>> building websites could have some validation that the software
>>>> they use has had at least some vetting?
>>> Sure, but who's going to pay for that?
>> Who is paying for all the damage that is being done to sites that
>> have been burned by JS's lack of validation.
>
> What damage? It's not like sites are going offline frequently. I can't
> remember the last time a site I frequently visit was offline, never mind
> due to JS.

I misspoke.  At the time I was talking about JS code that was linked in
by the use of un-validated JS code taken from sites like Node.js.

I'm not an expert in this area, and am not really interested in becoming
one.  I do follow Steve Gibson's Security Now podcast which does spend a
lot of time going though the means which have been used to get others to
use their CPU time to generate Crypto currency, or get into sites in
order to do ransom attacks based on encrypting data or just blackmail.

These attacks often require following a  chain of exploits, usually
starting with social engineering and then use memory overflow bugs,
weak security, and hooks added to Node.js (or other public) library
repositories by people contributing code to these libraries to use in
exploits.

Although its clear that a great deal of damage has been done to people
by internet exploits, I have not made a study of which exploits have
explicitly depended on Node.js malware.

But some parts of these chains of exploits are more easily dealt with
then others.  Things like memory overflow can be greatly improved by
using language that are designed to catch these problems early (in the
compiler) or give some guarantees they will be handled at runtime.

Other parts of the chain are hard to solve, like the current issue with
password managers, where you have to balance security against usability.

My point (which I express badly) was that validating code that was
pulled into websites was something whose cost could be balanced against
the damage done by exploits.

This is something that is currently being done by the Linux kernel.
There is a trade association (The Linux Foundation) that corporations
fund to validate the code that goes into the OS (Linux) that they use.
They realize that investing into a implementation/validation project
representing their interest is cheaper than them relying on individual
vendors, with their own independent profit trade-offs.

I'm expressing my impressions, since as I have said I am not an expert
in this domain.

But I do have long term bias against web browsers.  Netscape, in an
attempt to help improve the quality of there web browser were one of the
first developers of a public bug tracking system, which they were very
proud.  They touted the number of bugs that were found and fixed in
their code.

But I was concerned that although many bugs were fixed, I didn't seem
that the rate of bug discovery was decreasing.

My experience in developing new software systems was that the bug rate
should decrease with time as problems in the code was found.  This
seemed to indicate they were patching around individual bugs but with
added code rather than treating them as possible design issue and
updating the design so the type of bug did not occur.

Of course this takes more initial time, but usually leads to shrinking
the code base rather than increasing it.  It is also unpopular with
managers who worry about how much progress they can demonstrate at the
next meeting with their managers.

Fortunately some of my managers trusted us and discovered that although
for a long time these projects looked like they were behind schedule, we
finished early, and when the program structure stabilized the bug rate
began dropping rapidly and we had releasable (easier to maintain)
products.

But we were creating bespoke tightly designed closed systems. Web
browsers do have the issue that by there nature are open world systems
and need to evolve by maintaining upward compatibility and adding
features.  But this also adds to a growing technical debt.

But alternatively:

This eventually leads to the point like X11 that the system becomes far
more complex than can realistically be maintained, and still meet a
shifting set of priorities.

After several attempts at an X12, its development team decided to start
from scratch with a new approach, Wayland, that had a quite restricted
and different set of design goals.

This caused problems with a large community and base of programs that
were dependent on the APIs and features that was being dropped.  I know
that this loss of functionality would impact my computer usage
adversely.  Although XWayland has mitigated some of the problem, XWayland
will probably go away as the Wayland developers ween themselves from
their own dependencies on X11, and forget the original use cases behind
its development.

                     ----------------------------

I tend to ramble on in my posts, but I am trying to use these
discussions as a way for me to work out my conflicting ideas about what
kind of internet we should build (and maybe learn to express myself
better).

My feeling is that it would help if more people focused on non-browser
approaches to using the net.  This gives them less dependence on the
browser based ecosystem, a chance to build simpler systems that tackle
specific problems, and a way do start figuring out how common security
approaches (like SSL) could be used in a alternative internet that has
time to develop before it could become co-opted large commercial
entities and a large user base.

And it might avoid some of the problem of Wayland by trying to build a
replacement ecosystem that doesn't need to tackle everyone's desires all
at once (and in any indirect sense force out the competition).

-- 
Barry Fishman