Ask HN: How do you develop locally with privacy/security in mind? | Hacker News Reader

Ask HN: How do you develop locally with privacy/security in mind?

28 pointsboolean17 comments

I do most of my software development locally on my Mac. This requires installing and giving full system access to hundreds of Python and Node libraries which I've been blindly trusting so far. I've explored the idea of remote development on a VPS (via VS Code remote plugin or vi) but constant connectivity requirement is a deal breaker to me.

How do you develop locally while making sure the privacy/security of your system is not compromised? This is my only computer where I do all my personal banking and other sensitive tasks.

View on HN

> How do you develop locally while making sure the privacy/security of your system is not compromised?

For me and all developers I've interacted with around me, I think the answer is "we don't [make sure that the privacy/security of our systems are not compromised]".

I would bet it's fairly common to have multiple machines however. My work machine has never seen my banking credentials or HN password. But of course a bunch of work-related sensitive stuff. And I of course have a bunch of programming stuff on my home machine, which I mostly just hope are not doing nefarious stuff.

If I wanted to up my security (in just this aspect) I would probably go for a simple VM as a first step. Resonable enough separation, while not causing too much havoc in my workflow. No folder sharing, just SSH in to it and treat it like a remote VPS, but local.

The next step up, which also increases isolation between other stuff (should I really trust any application to not do bad stuff?) would probably be QubeOS[1]. While I haven't used it, I would guess it would be a pretty major change to my current setup.

[1]: https://www.qubes-os.org/intro/

Agree with all of this, except I'd add Docker containers as a less severe step before going all the way to something like Qubes. Since the OP mentions Python and Node libraries, it's likely they're compatible with being run inside Docker containers, which should do a passable-but-not-perfect job at isolation.

In order of decreasing isolation:

For hardware and system's security QubesOS(i) is superb for isolation at the (virtual)machine layer. This talk(ii) from Micah Lee when 4.0 launched is a great overview/preview. It's my daily driver, and I find it indispensable.

For software security any standard linux distro you can utilize encrypted chroots(iii). This is how things like crouton(iv) work on ChromiumOS.

For library isolation you could utilise virtual environments like virtualenv for python. ( or nodenv(v) for 'Node libraries')

(i) https://www.qubes-os.org/

(ii) https://www.youtube.com/watch?v=f4U8YbXKwog

(iii) https://linux.die.net/man/1/chroot

(iv) https://github.com/dnschneid/crouton

(v) https://pypi.org/project/nodeenv/

I found Qubes too difficult to install.

It’s a real pity, since nothing comes close security wise.

It depends on the hardware of course. Consider these machines: https://forum.qubes-os.org/t/community-recommended-computers....

With some cli familiarity the install process is super simple:

    Download the most recent iso
    Plug in a USB
    $ sudo dd if=Qubes-R<YOUR_ISO_VERSION>-x86_64.iso of=/dev/sd<YOUR_USB_DRIVE> status=progress bs=1048576 && sync

Now start up the destination machine with the USB and follow the installer instructions.

But for whatever reason the actual procedure is fraught with difficulties; and this is from someone who uses qubes daily and has installed and reinstalled qubes on multiple machines.

I've seen:

- multiple random installer freezes (hard shutoff, start again, 3rd try magically works, ?shrug?)

- USB drive overheating (apparently, according to forum posts, sdcards are incompatible with the installer, and some USBA drives are actually sd cards welded to boards... had to crack one open to see that was the failing point)

- incompatible hardware blocks (motherboard is compatible but digging deeper apparently the mobo's chipset is incompatible)

- successful installs freeze on login due to incompatible hardware (Broadcom wifi cards)

Also 8G is the real min req

Dom0, the admin qube, will gobble all of the 'minimum required 4G RAM', 8G will be sluggish with only one qube running, 16G+ should be the min req to use as intended

The best way to avoid headaches is follow the hardware compatibility list and go big on RAM: https://www.qubes-os.org/hcl/

Or buy certified hardware: https://www.qubes-os.org/doc/certified-hardware/

Once running, it sings.

Running projects in rootless containers from the beginning goes a long way for baseline workstation security, clarity about project dependencies, and ease of managing multiple environments.

Strongly recommend additionally keeping work isolated to employer-owned hardware, though.

Isn't the production deploy of the code dependent on all these modules even more important than the security of your random laptop?

General practice is minimize dependencies, scan build directories by "malware scanners," pin dependencies, block unfiltered outbound access. Personally I find the last to be the most important - even if they slip a discord creds stealer or a coin miner into your system, if its endpoints aren't on your allow list, it won't hurt you.

It does take some inconvenience to install an allow-list based proxy on your non-work machine, but is doable. Hopefully your work is doing that for your at some layer of the network.

Another useful principal is that the laptop shouldn't really have any private or irreplaceable data on it. Push your code to GitHub, clean up the web browsing data, script installing all your apps and stuff that you use, and then the laptop is just a disposable network access point. Maybe have a passphrase protected SSH key for reaching VPS with important stuff. Open source dev should be possible to constantly twitch-broadcast it to everyone.

Caveats I don't use node much at all, and am somewhat strict on being minimalist for python dependencies. My email is on my VPS and all my money is behind 2-factor. And I'll do more random web browsing on my tablet than on my laptop.

I do believe that npm and pip packages should be regarded as potentially compromised if you don't check the dependency tree regularly (don't believe anyone does that tbh). The solution isn't moving into the cloud though, that would probably expose you more than a local machine.

Put your work into a VM if you want a layer of security and separation. Personally I don't do that. I have a VPS (they are very cheap) but I never thought to use it as a platform for development. I use it to host my projects there for myself mostly. Perhaps monitor the traffic, but this is tedious as well.

Otherwise you need to check you dependencies. If you do not do that you don't want to offer your software to others anyway.

If you can't have a second laptop (e.g. Lenovo X230 can run coreboot and Qubes) or mini-PC/NUC for DevOps, then look into ways to harden the local OS and regularly scan your local laptop for compromised software.

Apple's MDM subscription solution may be worth a look, https://www.apple.com/business/essentials/

You could always develop inside a virtual machine.. depending on how resource intensive and complex your work codebase is.

Not sure why so many people are recommending QubesOS AKA a virtual machine for each dev environment. Podman containers are far more lightweight, and secure enough that you won't need a full VM if you're just doing application development.

> Podman containers are far more lightweight

Qubes virtualization should have very little overhead.

> and secure enough

Depends on your threat model.

But the main advantage of Qubes is its well-designed interface which allows to manage the VMs easily even without a command line if you want.

Using a dedicated VM on Qubes OS.

Virtual machine. Vagrant + vmware works quite good.

   as + gcc + ld + make + vim + bash

monitor network egress. use littlesnitch and prompt on everything.

Reply on news.ycombinator.com