|
In my case, mainly to lower the risk of supply chain attacks. Windows gaming and other such activity still includes a lot of “must run as administrator and does unclear things with this”, especially in anything with anti-cheat mechanisms as mentioned elsewhere, and there are environments (especially when dealing with mods) where you can wind up running code from dozens of randoms across the Internet in nothing approaching a meaningful sandbox. Popular messengers, video apps, etc. don't exactly seem trustworthy nowadays either. I wouldn't want to try to directly deliver anything from such an environment that I would ask other people to run. Even my more-trusted development laptop feels scary at times, especially when I'm operating in environments where I have to do about the same thing as above with installing a dozen dependencies from who-knows-whom. I generally use separate build UIDs for some measure of separation in these cases, but we still have Linux and X being potential emmentaler attack surfaces, and I haven't yet arranged my workflow to the point that spinning up new virtual machines is trivial, especially because then you have a lot more friction with testing GUI software, sharing existing files, etc. etc.—most of the easier solutions to which seem to be very cloud-oriented and “when your Internet connection goes down, so does everything else”, which is something I insist on pushing back against in this context, including because “someone upstream did something unexpected and now everything is instantly broken in a way I have no real leverage over” is its own massive trust hazard. My dedicated low-sensitivity machine isn't very powerful, so the cost wasn't as much of an issue as it could have been; it was a midrange laptop several years ago which I'm still using. If your workplace environment comes with its own hardware, then that's a thing too. It would certainly be nice to have better, though, and the desire for less redundancy of costly hardware is legitimate. My desired setup from a while ago, which I never managed thus far, is to have more powerful hardware with multiple boot configurations, but not all of them persistently present like most multi-boot machines: instead, I would physically attach and detach system and user disks, assuming that firmware-level attack persistence is rare, and then rely on power-down flushing any lower-trust code before attaching a higher-trust disk. It'd be hard to ask most people to do this, though. |