ShadowHaven Reloaded:Host Guide
Understanding Hosts
Hosts are a weird thing that doesn’t exist in real life, and while we can compare them to IRL networking, most people don’t understand that either. So, let’s talk about what they look like in fiction and how we can talk about them so that people can better grasp what’s going on. See the flowchart to the right to figure out what type of host is right for you.
Hosts in Daily Life
Think of the grid as being like a landscape, and hosts are buildings on this landscape. You can go inside them if you’re allowed to, but you can’t see what’s in them from the outside, and you can’t see what’s outside if you’re in them. Hosts are handy because they allow for files, devices, and users to be hidden and protected. A persona can exist in a host while its user is in AR, so it is often the case that people enter a bunch of hosts as they go about their daily lives. Going to the mall? Be sure to enter the mall’s destination host to browse inventory and catch those flash sales! Going to the club? Here’s a mark to our private data host so you can interact with our AROs on the inside while your presence here is kept secret!
What the average person doesn’t realize (or care about) that a Shadowrunner knows is these hosts are constantly monitoring their users. Patrol IC can tell you’re hacking, sure, but they could also notice things like how you have a wireless gun icon in your PAN, which the host might be programmed to alert the owner about. You might then say “why would a Shadowrunner enter a location’s host?” Well, host entry might be enforced in some places. A club might require patrons to be in the host for security reasons, and if a bouncer doesn’t see your persona in AR, they’ll stop you. Not exactly Dante’s, but it’ll do.
Nested Hosts
What They Look Like
In the spatial metaphor that describes the grid as the landscape and hosts as buildings, nested hosts are like buildings with separate, interior spaces. You might think of them as having rooms, floors, or wings that are as separate from one another as the host is from the grid. One terminology problem that comes up here is that while hosts inside a host are referred to as “nested hosts,” a host that has hosts inside of it is sometimes also referred to as a “nested host,” though it can also be referred to as the “accommodating host.” I’m pretty sure the former is the way it’s used in the book, but there’s been enough confusion about throwing the word “host” around that we ought to clarify our language.
The concept of hosts being “inside” other hosts can also be confusing given host sculpts don’t necessarily need to portray them as such. For example, a host that appears as a building may have a nested host be accessible via a clearly marked doorway, or even have them running silent inside so that only people in the know can enter the secret passages. While it’s technically accurate to view nested hosts as like a nesting doll, it may be easier to view them as a tree that can possibly branch, which each point in the tree structure being a location you can go to. I’ve been referring to these locations as “nodes.” The accommodating host’s interior space that’s outside of a nested host is also referred to as a “node” despite not being a nested host, as it’s a location in the flowchart you visit. I refer to this particular node as the “entry node,” as it’s where you end up when you first enter the host (unless you arrived through a backdoor such as a direct connection hack).
Each node is statted as a host in its own right, having a type, rating, attributes, and IC. Remember that the total rating of all nodes must be less than that of the host’s Data Processing. Following these rules, you can create a flowchart as a sort of map, like the one linked in Design Goals. Simply stat each node and say what’s in it, then add it to the flowchart.
Their Everyday Role
Understanding how nested hosts behave, they probably seem like they should come up a lot more often than they tend to. The example to the right contains a hypothetical plan for Knight-Errant’s police host in Seattle. To the average person, this is like going to the police station, but in cyberspace. It’s a public building that you can go inside and do things like read public notices, talk to receptionists, leave information about criminals, etc. Thus, it’s a destination host, allowing free access to the entry node while disabling silent running and assigning a Patrol IC to each user. Of course, the general public isn’t allowed to go just anywhere in a police station, which is what the two nodes accessible from the destination node are for: Dispatch and Administration.
An officer can enter the Administration node to access their virtual desk, where they have case files active. The Administrator here serves as a virtual evidence clerk in addition to acting as a spider, pulling digital info on evidence and old case files from the host’s archive as necessary. Administration is a data node, since its purpose is to store and access data. That one’s easy.
Dispatch controls the police department’s devices and serves as a communications hub for on-duty officers. All of the police cars and drones will be slaved to this node and managed by the Dispatcher, a spider who knows the schedules and routes of patrols. Home-field advantage is important here; because the spider knows how many device icons there are, how many marks should be on those icons, and who those icons should belong to, any deviation from this is suspicious, even if a hacker operating here hasn’t been detected. Working fast and covering tracks will be important, and social engineering can be a way to cover those tracks. Dispatch should be an industry node since it manages a bunch of important devices all at once. The flaw in Dispatch is that because it has slaved devices, and hacking one of those devices creates a backdoor into the host; of course, directly hacking a squad car, police commlink, or police drone requires doing some very sneaky or very bold things, which could give the team’s face, muscle, or B&E time to shine. Dispatch might be connected to Administration so that you can exit from the former into the latter, providing a secret backdoor to the filesystem for hackers bold/clever enough to get a direct connection.
All of this has been an example to illustrate a point: think of a host as a building and its nodes as spaces within that building, and extend that to any sort of intuitive security or privacy design you think ought to exist. Also, remember that nodes can be any host type so long as it would make sense. A data node can be inside a destination host, but you couldn’t have a rogue host inside. That’d be silly.
Using Hosts
Industry Hosts
Industry are pretty scary at a glance - direct connections on the inside are disabled, and all they get as a drawback is IC launch at the ends of turns instead of the beginnings. They’re a prime target for GMs to abuse by making it so the team’s hacker has a harder time for not much of any good reason, and they make enemy riggers really scary since they can form a WAN with their RCC network. GMs should understand what they’re for, and what the consequences of using one in level design are.
Thematically, industry hosts are used to manage large numbers of devices. You might see one cover a manufacturing plant, a fleet of vehicles owned by the same business, or a city-wide utilities network. Since all devices inside an industry host get to use the host’s attributes to defend themselves, note the following things are true:
- Hackers are much more likely to fail hacking a device.
- Successful hacks will generate overwatch score much faster.
- A hacker who gets spotted has an extra combat turn to flee before they have to fight.
- Direct connection hacks are still valuable because they allow for host entry by cracking a weaker defense pool.
So when putting an industry host in your level design, consider these things. Does it fit the thematics of protecting a lot of devices? What devices are being protected? How hard do you want it to be for your matrix support to operate inside it vs. how much does your run depend on them being able to? How much stuff do you expect them to do? How long are they supposed to be inside? In case it wasn’t obvious, an industry host is higher threat than a data host of the same rating, so be aware of that. Hackers who succeed still have limited time as their OS ticks toward 40 and the Patrol IC looks for them every few turns. Industry hosts increase the rate of OS acquisition.
Rigger Command Consoles are unique among devices in that they can be slaved to a host but still have their own slaved devices. Riggers love to be part of a WAN because it means hackers have to break into their host before they can even get a shot at them, and they’ll be under fire from IC the entire time they try. It also means there’s 0 noise due to distance for their entire PAN, so they can operate drones and vehicles remotely from however far away they want. Industry hosts grant them even more protection, as hackers on the inside have to beat the host’s firewall for each attack rather than just the RCC’s firewall. This may be desirable depending on the situation; be aware of the difficulty involved.
Non-Foundation Hosts
So, here’s where we get to the thing that sends people for a loop. All those hosts we’ve talked about so far do not run on hardware. They may be connected to hardware, and they benefit from the collective processing power of online devices, but fundamentally, they are rooted to the Foundation, which has literally infinite processing power thanks to the resonance realms, which defy the laws of physics apparently:
“Since 2075, however, online places known as hosts, with no hardware backing them up, simply exist in the Matrix. These hosts are built using the same virtual material the Foundation is made of, which is to say, no one knows what they are “made” of. They simply are,” (KC 41).
There is a sort of virtual firmament from which all foundation hosts grow. However, there are hosts that violate this paradigm, usually because they’re outdated. These come in the form of Outdated Hosts, Offline Hosts, and Rogue Hosts.
Offline Hosts
The oldest type of host is the offline host, which most closely resembles the hosts that existed in 3rd edition and before. They are completely offline, and so overwatch score doesn’t accumulate on the inside. They also lack foundations, meaning that everything inside the host exists as a file that can eventually be accessed with a deep enough search, they run on hardware, and they require a direct connection to access. They’re a bit easier to mess around in because they have weaker Data Processing and Firewall, though their IC gets nastier Attack and Sleaze as a result.
Outdated Hosts
Sometime after Crash 2.0 but before the Foundation was created, there were hosts that ran on a prototype wireless matrix. Think of them as a middle ground between an offline host and a modern-day data host. They lack foundations and so have no archive, and they run on hardware somewhere in the world. What’s different is that they can connect to the wireless matrix, and they are (begrudgingly) protected by GOD. However, GOD hates them for being outdated. Convergence doesn’t occur in one until OS reaches 50, and a demiGOD will not show up to protect them once that happens. GOD will converge as normal if a hacker leaves the host with at least 40 OS. Outdated hosts should be used sparingly, as they are old matrix protocols no longer allowed for new hosts. They should only be used where that makes sense. If you want the mechanics of one without the thematics, see below for info on rogue hosts.
Rogue Hosts
Not all hosts are cleared by GOD. Some are created by people and organizations working in secret. Their attributes can be custom-made so long as their sum is identical to the sum of host attributes for that rating, reflecting their owner’s whims. Some rogue hosts even have foundations. The ones that don’t follow the usual rules about no file archive and needing to run on hardware, but even the ones that do are not protected by GOD in any capacity, and so overwatch score doesn’t accumulate inside for any reason.
Nested Hosts
Clarification
The rule stating,
“The total rating of all nested hosts must be lower than the modified Data Processing of the accommodating host” (KC 45)
refers to all hosts contained within the exterior host and not just the hosts immediately nested, e.g., a rating 8 host with 8 Data Processing could have a rating 3 host in it and two rating 2 hosts in that, but no more.
Marks
A mark obtained on an interior host does not travel to the hosts in which it is nested. This means that a hacker could potentially exit into a host without having marks on it, which is immediate grounds for alert if they are detected by the Patrol IC. A hacker may attempt to mark a host they are already in, but they cannot attempt to mark hosts not accessible from their current node; they must first exit to a node from which the target node is visible, then attempt to place one.
Visibility and Control
Page 45 of Kill Code states,
“Spiders are blind to nested hosts (unless they are security nests, in which case they cannot control devices outside their nest).”
It doesn’t specify what a security nest is, however. Presumably it’s a nested host designated for security purposes, but there is no mechanical backing to this. ShadowHaven’s rule will be that spiders can see what is going on in all nested hosts for which they are authorized and control devices in the host they are currently in, as they are considered the hosts’ owner. Typically this will mean all nested hosts, but if a nested host has a branching structure, there may be different spiders in charge of their own branches. A separate matrix perception check is required to perceive inside each nested host.
While inside a node, players are able to see icons for the nodes nested inside of it as well as the accommodating node.