[Dreamwalker]

First of all, thanks for all the nice clarifications above.

... what the sleaze attribute of a host is good for.

I'd imagine that if you try to map out the Host network architecture while there are some silent running Hosts in there, then you would probably resolve that as an opposed Matrix Perception test vs Willpower of their attending Spider (if it has one) + its Sleaze rating (of the host itself).

Can hosts actually run silently? That was feasible in SR5 and maybe Hack & Slash introduced it for SR6 (I don't have that book yet), but in the CRB there is no mention of silent running hosts (only PANs as far as I can see).

Intuitively, I would have expected a hosts sleaze attribute to govern how well a host or subhost can be hidden as a whole or how well it can conceal part of its contents (devices, files, etc.) from prying eyes. However, it is unclear, if hiding an entire host is actually an option (at least per CRB) and aside from that a hosts sleaze attribute doesn't seem to have any impact on matrix perception.

[Hobbes]

Any Icon can Run Silent.  Running Silent doesn't have any restrictions on it. 

Nested Hosts frequently Run Silent.  Security System Icons (Cameras, Locks, ect) usually Run Silent.  Sneaky Spiders can Run Silent.

[Dreamwalker]

If that is the case, it certainly makes the sleaze attribute more meaningful for at least some hosts.

[Hobbes]

Your are correct that a Hosts Sleaze attribute rarely comes up, except for AR/DR comparisons.  But it does for a few cases or actions.

[Dreamwalker]

Auswurfschock (p. 48; German version of Hack & Slash) provides some additional information on the event horizon: You can spot devices and icons on the inside (the non-public-facing side) of a host from the outside. Its an opposed matrix perception test involving the hosts sleaze attribute and it is what I (somehow) seemed to recall.

This should enable technomancers to interact with files and devices inside a host from the outside using editor and puppeteer complex forms (depending on rule precedence and how you read that section in Hack & Slash). In that case the explicit requirement of editor and puppeteer to detect an icon makes sense (again).

[Xenon]

(depending on rule precedence and how you read that section in Hack & Slash). In that case the explicit requirement of editor and puppeteer to detect an icon makes sense (again).

RAI here seem to be that Matrix Perception can be used to get aware of them, but that you still need to either breach the host or establish a Direct Connection if you want to use your complex forms on them;

Puppeteer lets you bypass getting hacked access levels but you still need to connect to it first. So you could use Skinlink, Auralink, or Resonance Wires to get the connection then Puppeteer to control it and never worry about hacking access. Puppeteer would work as you described on a device that is broadcasting a public wireless signal, but I am assuming the security camera is not in this case, otherwise it would be pointless to have it nested in a security host.

...

As I stated above, Puppeteer (and Editor), still needs a connection first it only allows you to bypass access levels

[Dreamwalker]

Puppeteer lets you bypass getting hacked access levels but you still need to connect to it first.

It would appear, being on the outside of a host does not per-se disrupt connectivity to icons on the inside. Otherwise, it would be impossible to detect them.

Puppeteer would work as you described on a device that is broadcasting a public wireless signal

This appears to be exactly the case. Clearly, we do have the ability to pick up the device on the outside of a host as granted by Hack & Slash. Its signal is merely obscured by the hosts firewall and sleaze.

I am assuming the security camera is not in this case, otherwise it would be pointless to have it nested in a security host.

Except it would still be protected through resistance to matrix perception, through the hosts firewall and against anyone not capable of using the puppeteer complex form.

The question that remains is, whether connectivity between icons on the inside of a host and the outside is or can be made bidirectional and exploitable. And yes, while that would be the spirit of editor and puppeteer in my view, it appears RAI discourages it.

[Xenon]

I read it as if you can see the host network architecture from the outside as well as devices inside hosts.
But that you need to enter the host to connect to hosts inside the host network or devices inside the hosts.

Or use a direct connection.

edit.

But as most times in this edition, the language is not very exact.
It can probably be played both ways :-)
But then again, why would you not just remotely hack the inner host directly in that case?
Or just remotely spoof commands to devices inside hosts without hacking and entering the host...?

[Dreamwalker]

But then again, why would not just hack the inner host directly in that case?
Or just spoof commands to devices inside hosts without hacking the host?

This is actually explicitly prohibited in that section of Hack & Slash. You are not allowed to execute any matrix action other than matrix perception against "devices or icons" on the inside of a host (aside from using send message across the event horizon). That being said, puppeteer and editor are not matrix actions but complex forms.

The section also states that you have to acquire access via brute force, backdoor entry or a direct connection before you can "attack" an icon on the inside of a host. If this also applies to puppeteer and editor or if these take a special place and create an explicit exception depends on how one interprets rule precedence. It appears, the access requirement is intended to apply to these complex forms as well (which is fine for me).