Interesting, so the spoofing is only active during attacks? That explains the short duration.
I am wondering what changed though, since this hasn't happened before in the previous 4 years. More spoofing installations maybe? Higher radio transmitter power?
I'm also very curious, do you have any technical mitigations for this to be able to use your GPS devices? Or is it now just a fact of life?
It doesn't have any credentials inside the VM though, not even for git, so it could commit but not push. And I manually review/commit/push outside of the VM since I don't want to just dump stuff without reading it first.
But good call-out if someone uses a different workflow.
I'm still happy with my containment setup[1][2] on linux. The only risk that I see from the article would be the "Exfiltration through an approved domain" one. But in the VM there's (by design) nothing to exfiltrate besides the source code itself, which is less valuable these days.
The major benefit for me with this setup is that the agent can do all of the dev things that I can (install packages, build/run docker images, ...) which is a way faster loop than me trying it manually and then reporting back to the agent.
> Romania reportedly has unlimited for 4€ but I don't know which operator.
Orange Yoxo is the only one which has actually-unlimited, all the others have a fine-print somewhere with "up to X GB/month, then bandwidth is severely throttled".
I'm using the 4.9€ plan for a mountain webcam[1] and they have been true to their word, no throttling so far.
I've been happily using oauth2-proxy[1] with nginx as an extra layer of authentication to prevent situations where e.g. home-assistant had an unauthenticated RCE.
It's pretty neat since you can have one oauth instances for all virtual hosts, e.g.:
Hmm, perhaps I'm missing something, so let's go through it step by step and see where the disconnect is:
- There's a cloned 'my-project' git repo on the base OS
- The 'Vagrantfile' is added to the project
- 'vagrant up', 'vagrant ssh' and claude login is run inside the VM
At this stage, besides the source code and the Claude Code token (after logging in), there are no other credentials on the VM: no SSH keys, no DB credentials, no API tokens, nothing.
There is also no need to add:
- SSH keys or GitHub tokens: because git push/pull is handled outside the VM
- DB credentials: because Claude can just install a DB inside the VM and run the project migrations against that isolated instance, not any shared/production database
API tokens can definitely be a problem if you need external service integration. But that's an explicit opt-in decision, you'd have to deliberately add those credentials to the Vagrantfile or sync them in. At that point, yes, you need proper token scoping and permissions.
> Mounting the Docker socket grants the agent full access to your Docker daemon, which has root-level privileges on your system. The agent can start or stop any container, access volumes, and potentially escape the sandbox. Only use this option when you fully trust the code the agent is working with.
I tried this approach for a while, but I really wanted it to be able to do anything (install system packages, build/run Docker containers, the works).
With these powers there's a lot less back-and-forth with me running commands, copying the output, pasting it to Claude, etc.
I'm sure you've had the case where you had to instruct someone to do something (e.g. playing tech support with family, helping another engineer, etc). While it helps the other person learn, it feels soooo slow vs just doing it yourself :) And since I don't have to teach the agent, I think this approach makes sense.
This was also the direction I was initially headed, but then I realized I wanted one-VM-per-project so it can really do anything it wants on the complete VM. So the blast-from-the-past-Vagrant won because of the Vagrantfile + `vagrant up` easiness.
I totally understand, Vagrant and VirtualBox are quite a blast from the past for me as well. But besides the what-are-the-odds bug, it's been smooth sailing.
> VMs with 3D acceleration
I think we don't even need 3D acceleration since Vagrant is running the VMs headless anyways and just ssh-ing in.
> Incus (on Linux hosts)
That looks interesting, though from a quick search it doesn't seem to have a "Vagrantfile" equivalent (is that correct?), but I guess a good old shell script could replace that, even if imperative can be more annoying than declarative.
And since it seems to have a full-VM mode, docker would also work without exposing the host docker socket.
Thanks for the tip, it looks promising, I need to try it out!
Good point. For me, that was intentional, since all my projects are in git I don't care if it messes something up. Then you get the benefit of being able to use your regular git tooling/flows/whatever, without having to add credentials to the VM.
But if you need something more strict, 'config.vm.synced_folder' also supports 'type rsync', which will copy the source folder at startup to the VM, but then it's on you to sync it back or whatever.
Since Android 15, Google Pixel phones have a "notification cooldown" that sort of fixes this. Hopefully it makes it's way to all Android phones at some point.
Back in the day when Direct Connect[1] was a thing, and we all had insane speeds in the metropolitan area (but not so great outside of that), I used to run a DC hub. Which due to said speeds had mostly people that were close by, geographically speaking, and the interactions felt so much more relevant, probably because of the "third thing" you mention, the common interest/background.
So I've also been thinking for a while now: how can that style of community be recreated? There's of course the chicken-and-egg problem until you have traction, but also things like: how big should the community be, geographically? The same size in the US vs EU likely encompasses quite different amounts of people. Should it be anonymous or real identities? Should history be viewable by new members or should it be ephemeral? And so on.
Anyway, interesting prototype, I hope you get some traction!
+1 here, with the latest Chrome v3 manifest shenanigans, the Pushbullet extension stopped working and the devs said they have no interest in pursuing that (understandable).
I always wanted a dedicated binary anyway, so 1 hour later I got: https://github.com/emilburzo/pushbulleter (10 minutes vibe coding with Claude, 50 minutes reviewing code/small changes, adding CI and so on). And that's just one where I put in the effort of making it open source, as others might benefit, nevermind the many small scripts/tools that I needed just for myself.
So I share the author's sentiments, before I would have considered the "startup cost" too high in an ever busy day to even attempt it. Now after 80% of what I wanted was done for me, the fine tuning didn't feel like much effort.
I am wondering what changed though, since this hasn't happened before in the previous 4 years. More spoofing installations maybe? Higher radio transmitter power?
I'm also very curious, do you have any technical mitigations for this to be able to use your GPS devices? Or is it now just a fact of life?
Sorry for what you are going through.