comStar Firewall alert - PhaseThrough

Matrix topoloGy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
pilots
Pilots are a special type of OS with more autonomous decision-making
ability, used in agents and drones. Unlike operating
systems or most other programs, Pilots are capable of operating
independently and maneuvering through the Matrix on their own;
see Autonomous Programs, p. 110. Like an OS, Pilots may also be
programmed with sets of commands; see Agent Scripts, p. 100.
Drone Pilots are also customized for the specific device they are
made for (see Pilot Capabilities, p. 103, Arsenal).
prograMS
Programs are the tools of the Matrix. Every time something
is done, a program is involved. Sometimes only a very small
program is needed, and those instances are not covered by the
rules—but it’s still a program doing the work. Programs are always
run by nodes. The maximum number of programs a node
can handle is called its processor limit, while the number it is actually
running is the processor load. If the processor load exceeds
the processor limit, the node is subject to Response degradation
(see Matrix Attributes, p. 212, SR4). Programs do not have to be
run by the persona’s node to be used by a persona. It is possible
to use programs run on the remote node a persona is accessing.
The remotely used program then counts towards the processor
load of the remote node instead of the node running the persona.
Public nexi like libraries, archives, and data havens often provide
remote browse programs.
protocoLS
Every time a node interacts with another node, predefined
Matrix protocols are invoked. The receiving node looks at account
data, access rights, and status of the connection and then decides
whether a request will be accepted or not. By using hacking tools,
hackers try to circumvent or exploit these protocols to again access
rights, crash other icons, or do things not allowed by their current
account privileges.
accoUntS
Access rights on nodes are governed by accounts. Every subscription
and data request (see Data Requests, p. 54) is assigned
certain privileges, depending on the account information that
was sent with the request, or with the initial login in the case of
subscriptions (see Subscriptions, p. 55). There are various flavors
of accounts, depending on the status of the connection and what
kind of information was sent.
Standard accounts
In the case of a standard account, the login data consists of
a username and a password of arbitrary size. This information is
always encrypted by the operating system, with a Rating of 6, upon
sending. The password can be an alphanumeric string, a biometric
pattern, or a signature produced by a passkey (see Passkeys, p. 64).
The password is then compared to either the node’s internal user
database or other sources (see Web of Trust, p. 64) and either confirmed
or rejected. Most users store their passwords or signatures
in encrypted files on their commlink, as they are normally too
long and complex to remember. Biometric signatures can be read
directly from the user with the help of various types of scanners.
node accounts
Node accounts grant access rights on nodes depending on
the privileges a user has on another node it is linked to at that moment.
User access on a security node, for example, might include
a user account, and thus user rights, on the various cameras and
sensors the security node is connected to. A spider working in the
security node is then able to access all the sensors without having
to provide the entire username and password data for the various
sensor devices. The security node sends this information for him,
and the spider can simply access the devices and control them. Or
he could just read out their sensor feed as long as he is logged into
the security node with the appropriate access rights.
access id accounts
Access rights can also be granted by access ID. This means
that every time a node or construct with a certain access ID is accessing
a node, it is automatically granted the access rights related
to the ID. Just like standard accounts, the node compares the access
ID with its internal user database and grants the appropriate
rights upon initial login. A hacker can abuse this by spoofing his
access ID (see The Datatrail, p. 216, SR4) and thus forcing the
node to automatically assign the related rights to the hacker.
accoUnt priviLegeS
Access rights tell the node what the user of an account can
or cannot do. In principle the administrator of a node sets the
privileges related to certain accounts. Most nodes, however, tend
to have the same categories of access rights. There are four levels
of access rights: User, Security, Admin (see Account Privileges, p.
216, SR4), and Public.
public access rights
If a connection is established without sending any information
except the access ID, the connection is automatically granted
public access rights. This is the type of access a user receives when
she is entering the public part of a node. The public account allows
access to public data like website information, blogs, databases,
personal profiles, and so on. Depending on the accessed data,
different access rights might come with the public account, for example
the ability to write without a username in public forums.
User access rights
The vast majority of accounts on a standard Matrix node are
user accounts. The most important privilege normally granted
via user access is one slot on the subscription list. This allows the
user, or any of his agents, to enter the node in VR or AR mode.
Most other rights vary from node to node and from account to
account. Depending on the purpose of the account, User accounts
grant access to file indexes, files, the ability to edit files, command
devices controlled by a node, upload data, common-use programs,
and so on.
Security access rights
Security access rights are mostly given to those who need more
control over parts of a system without managing the entire system.
This level is often granted to spiders, privileged users, and IC. They
are allowed to view log files and node statistics and can alter general
Unwired
Simon Wentworth (order #1132857) 9