I've held, essentially since the beginning, that Virus was not believable
as described. Rupert Boleyn recently stated that he doesn't find it any
less problematical than gravitics, reactionless M-Drive, FTL, or Meson
weapons/screens. He cites the mess that current attacks on the internet
result in.

The latter four items all rely (essentially explicitly) on a handwave of
science or technology that we simply don't have at the present time (and,
in at least the case of FTL, may never be able to have).

Virus, however, doesn't rely on any of that. Virus is, essentially, an
extension of the idea of the current conception of a computer virus. BUT...

The vast majority of attacks that "mess up" 'the internet' are what are
called "denial of service" (DoS) attacks. These attacks, fundamentally,
attack not the computers themselves, but the communications links between
them, overloading the channels with bad data to such an extent that
legitimate traffic can't get through. A somewhat strained analogy might be
when a mass protest bike ride moves onto major thoroughfares and causes
traffic tie-ups that reverberate through the system - the bikes are the
illegitimate traffic, the cars that are jammed up are the legitimate
traffic, and the protest is the "denial of service" attack - the legitimate
users of the roads are denied the services thereof. These don't rely on any
specific characteristic of the target's hardware or software other than its
capacity to receive and respond to requests.

Most of the attacks that _aren't_ communications-based DoS attacks are of
two types: data destruction/"hostage taking", or data misappropriation.

Data misappropriation are usually aimed at acquiring (and misusing)
personal data such as national ID numbers, bank account and/or credit card
numbers, IDs and passwords to various monetary and public communications
accounts, and so on, ultimately with the aim of fraudulently obtaining
money from the "marks". These are the 'data breaches' that one most often
hears about in the news; they're also the widespread 'phishing' attacks.
These attacks rely on known flaws in software, or on a lack of
knowledge/awareness of the victim (including poor data security
procedures).

Data destruction/"hostage taking" attacks are almost exclusively aimed at
forcing the victim to pay - often a significant amount - to recover access
to their own data. As with data misappropriation attacks, they rely on a
combination of poor data security procedures, lack of knowledge/awareness
on the part of the victim, and known flaws in software.

The reason that the data misappropriation and hostage-taking attacks are so
widespread is because of a certain level of uniformity of software on the
various target computers - largely Linux and Windows, but targetting of iOS
(for iPads and iPhones) and Android (for Android-based tablets and phones)
is increasing, as is targetting MacOS/FreeBSD (for Macintosh computers).
Proponents of iOS and MacOS say that they're 'better' at defending against
attacks; this isn't really true: it's just harder to get the attack past
the initial wall of Apple's "walled garden" - but the cost of that is less
user choice. Safari, for example - the only permitted browser/browser
engine on iOS - is no less vulnerable to scripting attacks (due to inherent
weaknesses in ECMAScript/JavaScript) than Google's Chrome or the various
Chromium-engine-based browsers, or to the Gecko-based browsers on Windows
or MacOS.

That mostly does nothing to 'devalue' Virus as written; JavaScript/
ECMAScript is pretty consistent even across platforms. But there *is* a
problem not addressed in that: As written, Virus could hit _any_ computer,
and in computers/devices that didn't have enough power, it could "lay an
egg" that would later be able to infect a sufficiently powerful computer -
and the lower limit seemed to be fairly low. Worse, it could infect the
_hardware_, so that a purge and reload of the software wouldn't clean it
out of the computer.

To some extent, this was an advantage of the early MS-DOS/Windows systems -
the underlying architecture (so-called 'segment-offset' addressing) made it
difficult - but admittedly not impossible - for data manipulation to modify
the code of a program. But programmers wanted the simplicity of data
addressing that existed on systems and software based on non-Intel designs,
so with the iapx386 and later processors, Intel 'caved' and gave the
programmers what they wanted.

Let's remember something: The Traveller era is roughly 3500 years in the
future of Right Now. Yes, computing is showing some cyclic tendencies -
from centralized computing and data storage (mainframes) to distributed
computing and data storage (PCs) back toward centralized (cloud-hosted data
and virtual computers and emulators), but history doesn't repeat - it
echoes and rhymes. Attacks today can't succeed if they're trying to use
nothing more than the kinds of attacks that succeeded on the Apple II and
Apple DOS 3.3. Yet we have Virus that allegedly can infect the _hardware_
of _any_ computer? Or are we asserting that there's really only one
computer architecture in the Traveller universe, instead of diversity as
wide as the differences between computers based on the MOS 6502 family, the
Intel iapx86 family, and the Motorola 68000 family?

The problem with this is that it assumes that All Hardware Is The Same.
Building a single executable file that will run on such diverse
architectures as an Atari 800, an Apple II, an IBM PC, a Classic Macintosh,
a modern Mac, or an IBM S/360 seems ... unlikely at best; even the "fat"
binaries (which could run either on the PowerPC CPU or the iapx86 32- or
64-bit CPU) from the PowerPC/PowerMac days required that the operating
system specifically recognize them (as does the current 'universal binary'
to enable smoother transition from iapx86_64 CPUs to Apple M-class CPUs).
And while programmers like the idea of such concepts as the Java Virtual
Machine (write once, run anywhere), Information Security specialists are
increasingly recognizing the vulnerabilities of such designs and
increasingly insisting on system-level heterogeneity - the data storage
units should not run on the same OS - and preferably not even the same
class of hardware - as the user endpoints, and even "batch processing" -
the sort of computing where you set up the rules for data manipulation and
then submit the request to a large-scale data-flow system - should be on a
different architecture and OS than either the data store or the user
endpoint.

More, there is an increasing realization that critical systems need to be
'air gapped' - that is, no connection to the wider internet, even
indirectly - you should not be able to 'browse the web' on the same user
endpoint that you're accessing critical financial or patient data on. The
military has accepted this for years; why would they drop it (as they
clearly did in the spread of Virus; post-Collapse in the Regency,
hand-carrying data - which had been specifically sanitized - between
air-gapped critical systems was imposed as a safety measure)?

We're learning a lot of lessons about this sort of thing now. Are we really
going to forget them - or regard them as "solved" - in the Far Future? Even
today, we see that it's an ongoing arms race, in which the defender is at a
disadvantage, because the defender is always responding to someone taking
advantage of a previously-unknown vulnerability. There are actually ways of
proving a system architecturally secure - but to implement those
provably-secure systems is enormously expensive, and once set up, so too is
proving the specific system to be secure.

I don't believe that 3500 years is going to change that. I do believe that
the attacks that we know today will be considered trivial to defend against
- but because of the "arms race", a whole new set of attacks and defenses
will be evolving, and will continue to evolve, even in the Far Future's Far
Future.

®Traveller is a registered trademark of
Far Future Enterprises, 1977-2022. Use of
the trademark in this notice and in the
referenced materials is not intended to
infringe or devalue the trademark.

--
Jeff Zeitlin, Editor
Freelance Traveller
    The Electronic Fan-Supported Traveller® Resource
xxxxxx@freelancetraveller.com
http://www.freelancetraveller.com

Freelance Traveller extends its thanks to the following
enterprises for hosting services:

onCloud/CyberWeb Enterprises (http://www.oncloud.io)
The Traveller Downport (http://www.downport.com)