I’m always reminded of https://youtu.be/ZI0w_pwZY3E for Skype

I mean, I guess, but that’s only a selling point to the small number of people without smartphones, which isn’t a large enough group to make it a sound business strategy.

Also, the “(after federal incentives)” is doing a lot of heavy lifting here. The basic option for the 2023 Bolt comes out to about $20K after federal incentives, but you get way more range and a bunch of those “luxury” features this is missing. Considering how cheap low-end smart phones are, I have a hard time imagining that infotainment systems actually add more than 1-2% of the cost of the vehicle. Feels more like a type of virtue signal than a real cost-saving measure.

For me, the huge value-add of Discord is for gaming (and is what Discord was created for). In college, my friends and I were originally using Skype calls when we’d play League together, but it was super annoying; essentially in order to not have to create a new call and add everyone who happened to be playing every time we just had one giant call with everyone we’d “redial” when playing. The downside is that if you were on Skype but not part of the game (in class or something) you’d get the Skype call invitation and have to decline it.

Switching to Discord was fantastic. We’d just have a persistent voice channel for different games, and you could chill in there to indicate it’s what you were playing or wanted to play, and if someone wanted to join they just jump on the call. It was also nice for organizing our text chats into different subjects (using different text channels), so if you were trying to ask if anyone had any advice for a certain class, you wouldn’t have your messages drowned out by people talking about news about a upcoming game. We just have a “games” text channels and a “classes” text channels and a “weekend plans” text channel, etc. This became particularly important as the server grew from friends to friends of friends and would’ve been overwhelming to have everyone stuck in one chat.

That’s pretty much been the extent of my Discord use, and I’m continually amazed to hear how others have been using it. I’ve seen the “join us on Discord, X, Facebook, etc.” for different games coming out, but never thought much of it or ever considered doing that.

Relevant xkcd’s

Corporations cannot create nontoxic social media, the incentives will always be there to make it toxic.

I don’t know that’s true. The incentives to make it toxic come from engagement being the goal, which is a function of advertising being the income. I’m not advocating for it, but if there were a flat subscription and no ads, I don’t think they’d have any economic pressures for toxicity.

I would throw out that Windows executables work surprisingly well on Linux these days via “wine.” I use EndeavorOS and it’s pretty much no work on my part, I double-click a .exe and it starts it up via wine. I think the only thing that’s been spotty for me is Meshmixer crashes sometimes, but it’s also abandonware so I’m not sure it actually runs better on Windows.

To me, the potential point of confusion is referring to “sent by Ctrl+D” and things “received by the end process” as synonymous, ignoring the tty driver in between. When you Ctrl+d, you send a magic byte value to the tty master (which I would refer to as a EOF character, but I understand the argument against the terminology). On the other side of it the process doesn’t receive this value, but instead has its read call returned even if the buffer is 0.

A simple example hopefully highlighting the difference

Window1:
nc -nvlp 5555 #"far nc"

Window2:
nc -nv 127.0.0.1 5555 #"local NC"
Hi there[Enter]
Hi [Ctrl+D]There[Ctrl+D][Enter]

Window3:
strace -p [pid of local nc]

Window2:
[Right arrow][Right arrow][Ctrl+D]
[Ctrl+D]Uh oh[Enter]

What we see is pretty much as described. From the first line, we see “Hi there\n” on the other side. For the second line, we first see "Hi " appear, then “There” then “\n”.

From the third line, in the strace we can see the sequences representing the right-arrow key, and we can see the tty driver on the far side takes those sequences and interprets them to render the cursor two characters to the right.

The fourth line is where it gets more interesting. We send the tty driver the EOF byte, and the tty driver interprets this and gives the current active tty client a 0-byte return to read() and assumes we have no more data to send. But unlike bash, nc doesn’t care about a 0-byte read and is still looking for more data (as we can see in the strace). But if we continue to type and send more data (the “Uh oh”), we can see in the strace that the tty never sends this to the nc. So, to some definition, we’re still sending data to the local nc, but the tty driver isn’t actually relaying it

I haven’t heard of that being what threading is, but that threading is about shared resourcing and memory space and not any special relationship with the scheduler.

Per the wiki:

On a multiprocessor or multi-core system, multiple threads can execute in parallel, with every processor or core executing a separate thread simultaneously; on a processor or core with hardware threads, separate software threads can also be executed concurrently by separate hardware threads.

https://en.m.wikipedia.org/wiki/Thread_(computing)

I also think you might be misunderstanding the relationship between concurrency and parallelism; they are not mutually exclusive. Something can be concurrent through parallelism, as the wiki page has (emphasis mine):

Concurrency refers to the ability of a system to execute multiple tasks through simultaneous execution or time-sharing (context switching), sharing resources and managing interactions.

https://en.m.wikipedia.org/wiki/Concurrency_(computer_science)

Correct, which is why before I had said

I think OP is making a joke about python’s GIL, which makes it so even if you are explicitly multi threading, only one thread is ever running at a time, which can defeat the point in some circumstances.

If what you said were true, wouldn’t it make a lot more sense for OP to be making a joke about how even if the source includes multi threading, all his extra cores are wasted? And make your original comment suggesting a coding issue instead of a language issue pretty misleading?

But what you said is not correct. I just did a dumb little test

import threading 
import time

def task(name):
  time.sleep(600)

t1 = threading.Thread(target=task, args=("1",))
t2 = threading.Thread(target=task, args=("2",))
t3 = threading.Thread(target=task, args=("3",))

t1.start()
t2.start()
t3.start()

And then ps -efT | grep python and sure enough that python process has 4 threads. If you want to be even more certain of it you can strace -e clone,clone3 python ./threadtest.py and see that it is making clone3 syscalls.

I think OP is making a joke about python’s GIL, which makes it so even if you are explicitly multi threading, only one thread is ever running at a time, which can defeat the point in some circumstances.

Sorry, I was looking more specifically at that DNAT rule

8   480 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2222 to:192.168.101.4:22

That rule exists in the host 192.168.86.73, correct? And from the guest, 192.168.101.4 you are attempting to ssh into 192.168.86.73:2222?

It might not be your issue (or only issue), but that DNAT rule says that if a connection comes in on port 2222, instead send it to 192.168.101.4:22. So 192.168.101.4->192.168.86.73:2222->192.168.101.4:22. I would have thought you’d want it to be a DNAT to 192.168.86.73, functionally doing port bending, so it goes 192.168.101.4->192.168.86.73:2222->192.168.86.73:22.

That doesn’t explain the connection refused, though, based on what you’ve said; there’s some fringe possibilities, but I wouldn’t expect for your setup if you hadn’t said (like your ~/.ssh/ssh_config defining an alternate ssh port for your guest OS than 22). It’s somewhat annoying, but it might be worthwhile to do a packet capture on both ends and follow exactly where the packet is going. So a

tcpdump -v -Nnn tcp port 22 or tcp port 2222

For general awareness, not all flags can match all parts of an iptables command; the part you included there with “–to offset” is only valid with the string module, and not the DNAT action. That said after playing around with it a little, iptables actually does short flag matching, so ‘DNAT --to 1.2.3.4’ ‘DNAT --to-d 1.2.3.4’ and ‘DNAT --to-destination’ are all equivalent, so not the source of your issue.

I am having trouble following the IP scheme, though. Is your Alma guest 192.168.101.4, or is that the host IP? If it’s Alma’s and you are attempting to ssh from that IP to the host with that iptables rule, what should happen is that DNAT would then redirect that connection back to Alma. If the guest doesn’t have a :22 listener, you’d get a connection refused from itself.

Your hook has

/sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT

But I’d didn’t think that “–to” was a flag for DNAT, I thought it was “–to-destination”

If you ‘iptables -nvL’ and ‘iptables -t nat -nvL’ do you see both your DNAT and forwarding rules (although if the default is ACCEPT and you don’t have other rules, the FORWARD one isn’t needed), and do you see the packet count for the rules increase?

Because it’s your computer

Ah, gotcha, I was thinking more in terms of software attacks than hardware, and that some vulnerability would come up at some point for them to get root access, at which point I think they’d be able to get the key one way or another. I’d imagine it also depends on how locked down the system can be based on the nature of their duties; arbitrary internet access makes shipping it off somewhere a bit easier. Another consideration would be that the drive could also be imaged, and if the key were ever recovered at a later date through whatever method/mistake/etc. the entirety of the data could be recovered.

But, yeah, definitely agree that that’s all moving well outside the bounds of disgruntled/opportunistic employee and more into the persistent adversary realm.

Fundamentally, once someone has some of the data, they have that data, and you can make no guarantees to remove it. The main question you need to ask is whether or not you’re okay with limiting it to the data they’ve already seen, and what level of technical expertise they need to have to keep the data.

Making some assumptions for what’s acceptable as a possibility, and how much you want to invest, I’d recommend having the data on a network-mapped share, and put a daily enforced quota for their access to it. Any data they accessed (presumably as part of their normal duties) is their’s, and is “gone.” But if you remove their access, they can’t get any new data they didn’t touch before, and if they were to try and hoover up all the data at some point to copy it off, they’d hit their quota and lose access for a bit (and potentially send you an alert as well). This wouldn’t prevent them from slowly sucking out the data day after day.

If they only need to touch a small fraction of the customer data, and particularly if the sensitivity of the data goes down over time (data from a year ago is less sensitive than data from a day ago) this might be a decent solution. If they need to touch a large portion of the data, this isn’t as useful.

Edit: another nice bit is that you could log on the network share (at your location) which of the customer data they’re accessing and when. If you ever want to audit, and see them accessing things they don’t need, you can take action.

I think the next best solution is the VDI one, where you run a compute at your location, and they have to remote into it. If they screen capture, they’ll still save off whatever data they access, and if they have poor, or inconsistent, connection up your network it’ll affect their ability to do their job (and depending how far away they are it might just be super annoying dealing with the lag). On top of that, it’s dependent on how locked-down they need to be to do their job. If they need general Internet access, they could always attempt to upload the data somewhere else for them to pull it. If your corporate network has monitoring to catch that, you might be okay, but otherwise I think it’s a lot of downside with a fairly easy way to circumvent.

I’m not the most up to speed on TPM’s, but does it have the capability to directly do network access in order to pull the key? Otherwise, you’re going to need the regular OS to get it to the TPM somehow, in which case that’s the weak link to pull the key instead of ripping it from the TPM itself.

And once they have the key once, how do you enforce them having to re-request it? Is there a reason that that point they couldn’t just unplug from the Internet (if even necessary) and copy the entirety of that drive/partition somewhere else?

Oh shit, I’m sorry. I misunderstood what you were saying, I thought you were referring to them purchasing and running their own physical server hardware as opposed to running their servers off of a cloud platform.