An adventure 'nugget'?
Phil Pugliese
(17 Jan 2023 18:46 UTC)
|
Re: [TML] An adventure 'nugget'?
Evyn MacDude
(17 Jan 2023 22:07 UTC)
|
Re: [TML] An adventure 'nugget'?
Timothy Collinson
(17 Jan 2023 22:12 UTC)
|
Re: [TML] An adventure 'nugget'?
Alex Goodwin
(17 Jan 2023 22:25 UTC)
|
Re: [TML] An adventure 'nugget'?
Greg Nokes
(17 Jan 2023 23:59 UTC)
|
Re: [TML] An adventure 'nugget'?
Ethan McKinney
(18 Jan 2023 01:37 UTC)
|
Re: [TML] An adventure 'nugget'?
Greg nokes
(18 Jan 2023 01:40 UTC)
|
Re: [TML] An adventure 'nugget'?
Alex Goodwin
(18 Jan 2023 02:07 UTC)
|
Re: [TML] An adventure 'nugget'?
Greg Nokes
(18 Jan 2023 03:24 UTC)
|
Re: [TML] An adventure 'nugget'?
Rupert Boleyn
(18 Jan 2023 07:53 UTC)
|
Re: [TML] An adventure 'nugget'?
Greg Nokes
(18 Jan 2023 17:33 UTC)
|
Re: [TML] An adventure 'nugget'?
Evyn MacDude
(21 Jan 2023 01:49 UTC)
|
Re: [TML] An adventure 'nugget'?
Alex Goodwin
(18 Jan 2023 20:59 UTC)
|
Re: [TML] An adventure 'nugget'?
Timothy Collinson
(22 Jan 2023 13:00 UTC)
|
Re: [TML] An adventure 'nugget'?
Alex Goodwin
(22 Jan 2023 14:09 UTC)
|
Re: [TML] An adventure 'nugget'?
Timothy Collinson
(22 Jan 2023 17:39 UTC)
|
Re: [TML] An adventure 'nugget'?
Alex Goodwin
(22 Jan 2023 18:08 UTC)
|
Re: [TML] An adventure 'nugget'?
Timothy Collinson
(22 Jan 2023 18:14 UTC)
|
Re: [TML] An adventure 'nugget'? Greg Nokes (22 Jan 2023 20:14 UTC)
|
Re: [TML] An adventure 'nugget'?
Phil Pugliese
(23 Jan 2023 00:28 UTC)
|
Re: [TML] An adventure 'nugget'?
Rupert Boleyn
(23 Jan 2023 04:16 UTC)
|
Re: [TML] An adventure 'nugget'?
Richard Aiken
(13 Apr 2023 02:14 UTC)
|
Re: [TML] An adventure 'nugget'?
David Johnson
(22 Jan 2023 15:34 UTC)
|
Re: [TML] An adventure 'nugget'?
Timothy Collinson
(22 Jan 2023 17:39 UTC)
|
Re: [EXT]Re: [TML] An adventure 'nugget'?
Johnson, Bruce E - (bjohnson)
(20 Jan 2023 23:47 UTC)
|
Re: [EXT]Re: [TML] An adventure 'nugget'?
Tom Rux
(21 Jan 2023 01:13 UTC)
|
I love the conversation on this! I'm glad my wild ideas were somewhat helpful ;D Some comments and further thought in an omibus: > The way I see it, by using the Cybeline chips as a basis, Lucan's researchers got themselves a full AI (normally TL17) two full tech levels early, and then trained it in hacking using cutting edge TL15 military hacking tech. As even a lot of the 3I's military was TL14 before the 'Rebellion', the X-boat net was TL13, and most of the rest wasn't even that, Virus unsurprisingly was able to get in, especially as it had an easy entry via the IFF systems, and the more generations down the track a given Virus was, the better it got. My only issue with this, is that if it's a X TL's delta makes stuff hackable - then what about when the 3I deploys cutting edge TL16 tools against a TL 13 foe such as the Varger? Even TL15 is a 2 TL delta. I could never wrap my brain around why folks would shoot at each other if you could simply access their systems and turn stuff off, or force a jump, or turn up their floor grav plates to 11… So IMTU the Terrans solved this in the TL 8/9 era - learning how to harden their systems against most future threats via the crucible of the Internet. The Vilani and the 1I solve this in a diffrent fashion. They have non-programmable computers, according to GURPS: IW page 136 Computer Programming skill. Which of course IMHO the Terrans "borrowed" for some systems. > Virus from TNE > > [dons flameproof suit] (Puts fingers in ears) Lalalalalalala - I can’t hear you. > My mistake - I didn't intend to ask about the safety-of-flight kit, but the mass-market commercial kit such as used dirtside I would assume that a lot of that stuff uses similar tech, tho scaled down a bit. You might not have 3 systems operating in consensus to run your home automation after all. However you will still need to have it facing the common network if you want to be able to access it from outside your network. That even brings interesting ideas - the idea of "inside" vs "outside" is crumbling with the advent of powerful Zero Trust networking tools like Wireguard. You can be "inside" your trusted network even if you are not on the same physical network these days. I'd really hope that these technologies increase, and with strong encryption and identity verification on a machine level, I have a feeling in 20 years what we call the internet will be almost unrecognizable. Carry that 5,000 years in the future and the protocols and safeguards they will have in place are as unimaginable to us as an iPhone would be to someone in the Crusades. > This couples nicely with hardware systems mentioned above. If you need to reset a replicated system, you can do it one element at a time (subject to some preparation) - a "rolling reboot". After all "down due to reboot" is seen as simply another failure condition to deal with. Exactly. I ran a firewall system in the early 2000's that was mission critical. The firewall's OS, supporting apps, and management tools literall ran off a write-once CDRom. Update? cut a new CDRom, swap it, and reboot the system. Someone got root and compromises the running system? Reboot, and it's fresh. Now updating firewall rules was a PITA, as I had to cut a new CDRom with the new rules embedded, and reboot it, but the extra security it bought us was worth the extra legwork. And I got to go into the Data Center all of the time! ;D > "Neural network based firewalls" - I'm not sure what Greg was meaning here. At a guess, some sort of pseudo-AI automagically-adaptive set of defences that can react and adapt to electronic attacks at electronic speed. So, I see some of the new "AI" stuff as the first wave in neural networks and expert systems - it's not really AI yet. However, if we could train a neural network to inspect packet level traffic, and start to build mental maps around "trusted" and "sketchy" external and internal systems, it could start to make choices in milliseconds around if traffic should be allowed - not because it's seen that exact threat before but rather on what it thinks may be bad traffic. Today's virus scanners are mostly operating on the "we have seen this exact code before, so block it". That's going to evolve more into "we have seen things like this before block it" to "we have never seen this before, but it feels like it's doing bad stuff, block it". Imagine a firewall being able, in real time, to build out maps of the attached networks like that. > Given the Nokesian architecture in place, subverting a system via the electron two-step is thus orders of magnitude more difficult than conning some twit - so twits will continue to be conned. Hah, That feels like a TML award! :D > It's the same way an attacker bypasses an alarm system - convince the sophont(s) monitoring it that it's "another bloody false alarm". > Back in the 90's I was a consultant. I would walk into small businesses in my town, and work on their NetWare, Windows and Unix servers. The first time I'd walk in, I would sometimes try to either just walk in past the front desk like I knew what I was doing, or if I got stopped, I'd try to talk my way in with out telling them I was supposed to be there. Generally that would be a finding on my initial report of the health of the server. It was scary how often that I could just stroll in. Also I had a co-worker who had to help a company recover from being "hacked". The hack was someone broke a window, reached in, poured gas on their server (with the backup tapes sitting on top of it), and tossed a match in. Two lessons - humans are almost always the weakest point to attack a system, and if you get physical access it's all bets off. Honestly the early adventure “Smash And Grab” is a perfect example of hacking in the 3I. Smash the systems, hope there are no backups. :D > >> Only allowing sanitized messages" is (again, I think - blame me if I've >> got it wrong) implementing the principle of "default deny" - aka using >> whitelists. > > Ah, that helps, definitely. White lists are an idea I'm familiar with. > >> Following that analogy, only _well-formed_ messages are accepted. All >> the i's must be dotted, all the t's must be crossed, etc - whatever >> "well-formed" means in the particular case you're looking at. > > Hah! That might stop a lot of spam messages - Prince so-and-so has a zillion dollars he wants to give me for example. Just refuse any email with a typo! > Of course, it might also stop a bunch of my friends communicating with me... you win some, you lose some.. Spam filters attempt to use past messages to learn what is spam and what is ham (ham is good email). it does a pretty good job these days! Imagine a program that accepts API inputs. Say it has 2 endpoints. One for targeting that needs two numbers (direction and inclination) and one to fire that needs a command to fire. It could be constructed in a number of ways, the two that are important here are - accept input or accept input and reject anything that does not match an allowlist of values. Say we build the the first way. I send the following messages: 123.37d 42%I AND FIRE 123.38d 43%I AND FIR;(some magic hacking codes) 00.00d -25%I AND FIRE "Bad stuff" could happen. If we built it the second way, it would look at the second message, chuckle, and drop it. And probably the third message, as can a weapon traverse to a negative inclination? One of the problems today is a lot of systems operate in the first way. See https://xkcd.com/327/. Because we used to trust the network. We are slowly fixing that massive mistake.