Technology

That’s also how the most damaging attacks on proprietary software work.

Yeah, supply chain attacks can happen. There was that infamous SolarWinds supply chain attack recently. But I think that there are some important mitigating factors there.

• Proprietary software companies -- unless they're using something open-source like xz upstream in their supply chain, as it's not just a "proprietary software world" and "open-source software world" -- tend to have someone's personal information if they're employed by them. They're not gonna hire and pay some random name who they know only as a GitHub account through a VPN, certainly not make them maintainer of their software.

• Many -- not all -- proprietary software companies mandate that employees work locally. I's likely that if I'm working for a US company, a person is also subject to US law enforcement. In contrast, if you have a state-backed group, they're probably targeting people elsewhere. Whoever the people from the Jia Tan group are, my guess is that it's good odds that they will probably aim to avoid being in a country that they are targeting. Even if we expose their identities, they probably aren't going to be directly-impacted by law enforcement. Open source projects hypothetically could do that, I suppose, but normally they're pretty border-agnostic.

That is, I think that this is going to be specially a challenge for the open-source world, as the attacks are targeting some things that the open-source community is notable for -- border-agnosticism, a relatively-low bar to join a project, and often not a lot of personal identity validation.

At some point all organizations need to trust their members and co-workers need to trust each other - I can’t think of a way to be more miserable at work than having to second guess everyone around you.

Yeah, that's kinda what I was thinking, but you put it more-frankly.

It seems like there's a lot of potential for this to be corrosive to the community.

desktop

Some of it is that a lot of desktop software paradigms weren't built to operate in that kind of environment, and you can't just break backwards compatibility without enormous costs.

Wayland's been banging on that, but there's a lot to change.

Like, in a traditional desktop environment, the clipboard is designed so that software packages can query its contents, rather than having the contents pushed to it. That lets software snoop on the clipboard.

What's on the screen and a lot of system state like keys that are down and where the mouse pointer is and so forth wasn't treated as information that needed to be kept private from an application.

Access to input hardware like controllers aren't linked to any concept of "focus" or "visibility" in a windowing system. That may-or-may-not matter much for a traditional game controller (well, unless you're using some system where one inputs a password using a controller), but modern ones have things like microphones. Hell, access to microphones and cameras in general on laptops isn't normally restricted on a per-app basis for desktop software. From microphone access alone, you can extract keystrokes.

I don't think that there's a great way to run isolated game-level 3d graphics in a VM unless you're gonna have separate hardware.

Something that I've wondered about is potential vulnerability via Steam. None of the software there is isolated in a "this might be malicious" sense -- not from the rest of the system, not from other software sold via Steam. And Steam is used to distribute free software...I haven't looked into it, but I don't think that the bar to get something into Steam is likely super high. And then consider that there are free-to-play games that have to make money however they can, and some of that is going to be selling data, and some of how they do that may be to just offer to run whatever libraries with their game the highest bidder offers. How secure are those supply chains? And on Steam, most of the software is closed source, which makes inspecting what's going on harder. And that's before we even get to mods and stuff like that, which are from all over the place.

I mean, let's say that random library from ad company used by a free-to-play game is sending up the identity of the user on the computer. It has some functionality that slurps in a payload from the network telling it to grab credentials off the existing system, and does so for ten critical users. Would anyone notice? I have a really hard time believing that there'd be any way to pick up on that. Even if you wanted to, you can't isolate many of these games from the network without breaking their functionality, and there's no mechanism in in place today isolating them from the user's storage or other identity information.

I own IL-2 Sturmovik: 1946. It's published and developed out of Russia, and the publisher, 1C, has apparently even been sanctioned as part of general sanctions against Russia. Russia is at war with Ukraine, and we in the US are supplying Ukraine. 1C runs a lot of software on user computers and can push updates to it. If the Russian authorities come knocking on 1C's door and want a change made to some library, keeping in mind 1C's position, are they going to say "no"? Keep in mind that what they say may determine whether the company survives an already-difficult environment, and that they may have no idea the full extent of what the state has going on. Now, okay, sure, probably -- hopefully -- there aren't US military people or defense contractors running IL-2 Sturmovik directly on critical systems. But...let's say that they run it at home. How carefully do they isolate their credentials and home information on that system? Does their home machine ever VPN in to work? Is there personal information -- such as access to personal email accounts -- that could be used for kompromat on such systems?

I've managed to get some Ren'Py software (no 3d requirements, normally limited access to input hardware required, one common codebase for most functionality, can generally use one's local Ren'Py engine running games instead of using the binaries provided, all favorable characteristics for sandbox) running in firejail (and in the process, discovered that one of the games I had was talking to a chat channel...this was described in the source as reporting numbers of users, and the game is a noncommercial effort, but chat channels have been used for commanding botnets before, and even if it's not malicious, if it can do that without attracting attention, I'd very much expect that malicious software could do so). That is about the extent of my attempts to really sandbox games, and even with that very limited and superficial effort, I already ran into something that I'd have some security concerns about. My guess is that there are a lot of holes out there, even if unintentional.

As things stand, Valve and similar app store operators have no incentive to isolate what they distribute, so if they do so, it's out of some kind of general sense of responsibility to users. Users generally don't have the technical expertise to understand what the security implications of Valve's decisions are, so they can't take that into account in purchasing decisions. We could mandate something like strict liability to Valve and other app store vendors or maybe OS vendors in the event of compromise -- that'd probably make them introduce isolation for software that they distribute. But there'd be some real costs to that. It'd make games more expensive. It might make it harder for smaller "app stores" like gog.com, itch.io, or Lutris to operate. I use Debian. Debian doesn't cost anything, and if you put the Debian project in the position where it may be legally liable, they're gonna have to charge for their OS to cover those costs. With charging probably comes DRM. With DRM probably comes restrictions on what one can do with software, which smashes into problems with open-source software. It's definitely a problem.

FreeBSD jails were way ahead of their time