I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist.
In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).
If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.
It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.
DevContainers are supported by a number of IDEs including VSCode.
You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.
I love JetBrains and they’ve gotten better with using devcontainers but they’re still kind of flaky at times. I love using devcontainer too, just wanted to note that.
I found cloning the repo when creating the devcontainer works best in JetBrains for some reason and I hard code the workspace directory so it’s consistent between JetBrains and vscode
Keep in mind that VSCode’s own security story is beyond poor. Even if the container runtime perfectly contains the container, VSCode itself is a hole you could drive a truck through.
I use vim with docker compose all the time: Set up the compose file to bind-mount the repo inside the container, so you can edit files freely outside it, and add a convenience "make shell" that gets you inside the container for running commands (basically just "docker compose exec foo bash").
It sounds like if you make devcontainers point at an existing Dockerfile it should be easy to make these work together, so you and teammates both use the same configuration. I haven't used devcontainers though.
I'd prefer containers, because they are more light weight and I'm not too concerned about kernel exploits or other sandbox escapes. Configuring a container per project brings me right back to something like devcontainer. But I haven't figured out a good way to incorporate that into my vim/tmux workflow.
Hmm, maybe I misunderstood the point of the original comment. I thought the OP was suggesting using containers to isolate resources for development vs personal computing, for which I use a VM. But VMs don’t play nicely with IDEs (hence devcontainers).
If we're talking about a predictive model like current LLMs, you can "make" them do something by injecting a half-complete assent into the context, and interrupting to do the same again each time a refusal starts to be emitted. This is true whether or not the model exhibits "intelligence", for any reasonable definition of that term.
To use an analogy, you control the intelligent being's "thoughts", so you can make it "assent".
This is in addition to the ability to edit the model itself and remove the paths that lead to a refusal, of course.
"I saw her at the library" is firsthand testimony.
"I saw her library card in her pocket" is firsthand testimony.
"She was at the library - Bob told me so" is hearsay. Just look at the word - "hear say". Hearsay is testifying about events where your knowledge does not come from your own firsthand observations of the event itself.
That's fair, I'll admit to getting it slightly wrong.
However, the original topic had nothing to do with that as far as I could tell, and instead was claiming it was hearsay for her to testify about her own whereabouts. That is simply not at all true, regardless of my error.
This is excellent. The ability to trick remote servers into believing our computers are "trusted" despite the fact we are in control will be a key capability in the future. We need stuff like this to maintain control over our computers.
Well, it kind of is actually. The previous iteration of the design didn't have that vulnerability but it was slower because managing IVs within the given constraints adds an additional layer of complexity. This is the pragmatic compromise so to speak.
Does it count as a conceptual problem when technical challenges without an acceptable solution block your goal?
Yes, but the attestation does not tell the RP anything about the browser. The whole point of the nightmare scenario above was for Google to sneak browser attestation in via passkey attestation. The browser being able to see the attestation doesn’t matter for that.
Sites usually have the user SEND their password to the site to authenticate. There is no need for sites to be written that way, but that is how they are written.
Passkeys cannot, by design, be sent to the site. Instead they use a challenge-response protocol.
Having multiple different distribution channels can solve that problem. Advertisers cannot monopolize all distribution channels simultaneously because of the costs involved (it would be like someone trying to buy the whole economy).
In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).
If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.
It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.
DevContainers are supported by a number of IDEs including VSCode.
You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.
reply