> The problem is that we cannot trust code we cannot instrument. If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace except by squinting at it and developing theories. So we write our own. More work upfront, but the clients we write are observable by construction, because we built them that way from the start.
> If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace
Given that tracing etc. is IO, are they just threading IO through the entirety of all their Haskell code?
Despite the article title, IPv6 is not the complication. The problem is that IPv4 is incumbent and IPv6 has to live along side of it. It doesn’t matter how it’s done, the dual stack nature of expanding the addressing system will always exist.
this is why people keep inventing nonsense like ipv8 which is worse than ipv6 in every possible way but they think because ipv6 has problems and ipv8 isn't ipv6, ipv8 doesn't have exactly the same problems.
Dual stack isn't a terrible experience it's just usually bad. I wonder if more effort should have been put into making dual stack good instead of making IPv6 good?
Would that have been possible? No clue but my instinct is that most design decisions are trade offs and if you can imagine a trade there's someone out there clever enough to make it happen.
IMHO, the worst thing about dual-stack is that you have to do it at all. There are translation mechanisms but that doesn’t help when you have local devices (maybe IoT?) that don’t support IPv6.
I think that's why this new IPv6-Mostly stuff is so exciting. You can dual stack a network segment if some of those v4-only devices exist there, but IPv6-Mostly will make sure that the other devices stay on v6 (translated or native).
NAT requires remembering every connection pair (IPv4:port for both internal and external sides of the NAT)
You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.
Do you have credentials anywhere within reach of that session? Can you open your bank account in a browser ... within reach of that session? Are your contacts available within reach of that session? What about personal notes/emails/goals or other sensitive information? That people think these can't be added together in one very socially/monetarily destructive fell swoop is ... telling.
Ignoring obvious bad-actor concerns from just giving root to your whole life to an LLM running on someone else's server, LLMs themselves can act in ways that are extremely counterproductive to their organization/host/etc.
A quote/warning I learned in the late 90s is just as relevant today, "Computers make very fast, very accurate mistakes."
Anything an LLM does on your computer should happen it its own account. No sudo config of course, or at most one that is strictly limited to what you want to allow it to do (risk here, as many programs have non-obvious paths to general command execution).
It should have zero access to your private home directory or your system configs. You can have access to its files of course. That's the beauty of separate accounts and permissions.
How many devs really do run damned near everything from a single account that also has sudo/runas/various_osx_methods access? This threat model has a decidedly non-zero target market.
Even those folks who are cautious enough to require passwords (sudo or plain su) to elevate are still at risk of having their account thoroughly brought under control of an attacker. Just imagine what a baddie could inject into your .bashrc if your editor can change it.
If you run your clanker-controlled emacs in console mode under a restricted user account, best case scenario, system compromise is only one unpatched privesc vuln away from Shai-Hulud completely pwning you.
Doing it in a locked down VM is much better but even then you're only better off by matter of degrees than if you had done a yolo curl - | bash because VM host attacks and even escapes are very much a thing.
These HNers expressing concern about giving a LLM control of an editor are 100% thinking rightly.
This is a textbook motte-and-bailey. You're telescoping threat escalation - chaining together "what if" steps until everything sounds equally catastrophic:
"Your editor can write to .bashrc. Therefore an attacker controls your shell. You probably have sudo. Therefore full system compromise. Even a VM does not help because VM escapes exist. Therefore this is basically curl|bash."
By this reasoning, every program you run under your user account is equally dangerous. Your shell, your file manager, git, make, pip install, npm install, docker, any program that writes files. The argument proves too much, therefore proves nothing.
This is all unhinged poetry - philosophical argy-bargy without any concrete, well-grounded argumentation. I'm just baffled for why none of you guys crying wolf even tried to ask me reasonably productive questions of what do I actually do in my setup.
- My LLM use is mainly not about code generation. Especially it is not about autonomous code generation and execution.
- Why nobody's asking about scope of the LLM file access, audit logs, tool use confirmation, allowlists/denylists, rate limiting/circuit breakers - pre-tool hooks, scoped tool sets per context, etc.?
Whatever. If you think it's unsafe - just don't do what I'm doing. Just please spare me from security-as-ritual, I don't believe in prayers, I preach security-as-engineering. None of you proposed a threat model. None of you started with: "here is the specific attack, here is the attack vector, here is the probability, here is the blast radius", it's all just: "imagine what a baddie could do" followed by an escalation chain that terminates in total system compromise. By that reasoning you should not run any software.
In the interconnected, online world, you can do more damage without root access
"they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission"
https://xkcd.com/1200/
So? My terminal has the same full system access. If I didn't use Emacs, I'd be using Claude code in it. It's contained locally on my computer, I don't see any problem here. I use Emacs like my OS-layer. Why would I complain that my OS has access to something? It would be weird and annoying if it's the opposite.
Yeah, that's incredibly unsafe. You made a footgun machine and you're firing it with no shoes on. Don't run that on any machine with credentials you care about.
At the very least, run it in Docker. It's not a security tool, but it's at least some kind of guardrail against data loss and exfiltration.
Having a browser on your machines is unsafe. The browser is a massively more dangerous attack surface than an Emacs-based LLM tool. What I have is a curated set of Lisp functions exposed to an LLM through a protocol I control, running in a single-user process, on my machine, behind my firewall. The attack surface is comically small by comparison.
Any browser that I trust to not instantly[1] eat my face has sandboxing features to at least pretend it wants to be secure. I'm not aware of any text editor that has built in anything of the sort.
It's a nice habit to get into if you can bring yourself to firejail your editor to $HOME/jail and keep all your r/w files in $HOME/jail/Documents and such. But only the most socially unacceptable of paranoid sysadmins do that. Ahem.
[1] FF/Chrome/javascriptless ones. The others are put in prison with no chance of parole and strict visitation policies.
A browser's sandbox exists because it routinely executes arbitrary code from untrusted remote origins. Emacs (or any other editor) with an LLM integration does not fetch and auto-execute code from random origins. Your firejail point proves too much, even though the idea sure is riveting. By that logic, my shell is also catastrophically insecure - it can rm -rf /, read my ssh keys, send some files anywhere. Yet nobody seriously argues shells need browser-style sandboxing. The implicit trust model is different: these are tools where you control what runs.
Yes, there are prompt injection risks, they are legit but that's the property of the LLM, not Emacs. A browser sandbox protects you from code you never chose to run. An editor integration runs code you asked for. These are different problems requiring different mitigations.
You guys keep patronizing me on this, you think I'm some truck driver/florist/butcher by day, and I put on my amateur coder suit at night? Just so you know, I spent years working on security.cisco.com team and went through SANS training and certification. Ever occurred to you that just maybe, perhaps, potentially, theoretically, hypothetically - I'm not completely, utterly ignorant about all this shit?
I don't think it's very reasonable to use claude code on a computer that have credentials without some kind of sandboxing or validing every command it does, at which point I'd rather do things manually
Ah come on, guys, let's talk pragmatically. "Malleable editor as an OS layer" has benefits beyond subjective reasoning. Emacs has had M-x shell-command and arbitrary elisp eval forever. A metacircular MCP isn't some new capability class. Even if I didn't use Emacs - my shell, my editor, my browser extensions, my npm install, my VSCode plugins, my curl | bash from yesterday - they all have the same access. Singling out the LLM in this context is like selection bias.
Of course, reasonable mitigations are a must - just like for any other tool. Narrowing MCP scope - tool routing rules, read-only git defaults, etc. "Docker or nothing" is a lazy answer - Docker-for-everything has real costs: friction, broken integrations, worse ergonomics.
Practical security is all about staying in the goldilocks zone. You shouldn't get relaxed about the basics - sandboxing, 2FA, password managers - they are worth doing, and you can get so paranoid about so many things, and yet against a targeted, well-resourced attacker, your sandboxing posture is mostly irrelevant. The interesting attacks bypass the threat model entirely. Read about Ben Nassi's team research¹ - pretty cool example. There are multitudes of other ways and your Docker container won't stop them. Defend against the boring 99%, and accept that the 1% is someone else's problem (or a much bigger problem than your dev environment)
TLDR LLM Summary: Researchers showed that a device's power LED subtly flickers in brightness and color while the CPU performs cryptographic work, and these flickers leak information about the secret key. By pointing an ordinary video camera (an iPhone or an internet-connected security camera) at the LED and exploiting the camera's rolling shutter, they boosted the effective sampling rate from 60 to 60,000 measurements per second, enough to do cryptanalysis. Using only this video footage, they recovered full ECDSA and SIKE keys from a smartcard reader and a Samsung Galaxy S8, with no malware on the target devices.
It's your computer and you can do whatever yolo nonsense you want, my dude, but put those goalposts back where they were.
"Don't run that shit on a credentialed box with data you care about" is addressing real threats, not some goofy nation state thing or abstract security research.
If you let the footgun machine constantly generate new code and run it on your computer, you're just asking for data loss and bad shit to happen.
Docker isn't a great solution but it at least doesn't let yolo code delete files or access env vars or read the contents of .ssh/
> my browser extensions, my npm install, my VSCode plugins, my curl | bash
Yeah, and you shouldn't yolo those, either lol. If they didn't come from a trusted source, you need to read through them. If you don't want to, don't use them. That's not paranoia, that's, like, normal.
> If you let the footgun machine constantly generate new code
Are you talking about autonomous LLM projects that automatically write code? Yeah, no shit, I wouldn't run anything like that directly on any machine without sandboxing. My typical LLM use inside my editor is never in self-driving mode, there's not even cruise-control - I tell it exactly when to write, where to write and how to do it. Automated scripts never get run by LLM and don't get to run at all without prior precise and meticulous inspection. I'm not moving goalposts - at worst we're in disagreement on the level of pragmatics vs. paranoia, that's all.
I don't even get why people are so crazy about LLMs generating code - on both sides. LLMs for me personally are such a great tool for investigating things, for finding things, for bridging the gaps - the stuff that happens 10K feet above code writing. By the time I'm done gathering the details, code generation becomes an almost insignificant touch of the whole endeavor.
That exactly what it is. People's reaction is a default pattern-matching on "AI executes code on your machine." - Ay the horrors!. They have no idea of my cybersec posture, my network perimeter - vpn, firewall, malware protection, etc.
It's not like I'm giving the LLM root shell. It's as if I said: "I learned how to juggle three chainsaws - so fun...", and people reacted as if I suggested doing that in a school bus full of children going 140kmh down the highway.
It's culturally fitting for HN - signaling caution is always socially safe. Nobody ever got criticized for saying "that sounds risky". But "I evaluated the risks and accepted the tradeoffs for my situation" is the actual, pragmatic engineering. Security is risk management, not risk elimination.
Choosing red is choosing to survive knowing that there will always be people who choose blue, potentially an amount that would mean you don't survive if you didn't take explicit action against it.
They didn't cause the peril, but knowing that their choice is possibility, if I don't make a decision to protect myself now their decisions may then be the cause of my continued not-survival.
To me, the whole point of the riddle is that it reveals the most internal bias towards either yourself or others, meaning that you do things for society or for yourself. Blues don't understand reds, reds don't understand blues. The bias is invisible to the self but it is clearly there given the huge contrast in the opinions of people.
You fail to see how anyone could choose blue, even though there are plenty of people on the internet and even in the comments here who are stating they would choose blue?
Depends on the scenario… or the number of people in the experiment. A sufficiently large number of people will guarantee votes in both bins. The specific scenario (reading this outside of a vacuum) will also have knock-on effects.
Eg: reading this into the current political landscape in the US vs reading this into another toy problem about jumping off a cliff or not will have very different outcomes and ethics.
The article makes a good point with their reframing.
"Give everyone a magic gun. They may choose to shoot themselves in the head. If more than 50% of people choose to shoot themselves, all the guns jam. The person also has the option to put the gun down and not shoot it."
The "dilemma" is asking to what lengths we should go to save people choosing to commit suicide, and does that change when they are unintentionally choosing suicide due to being "tricked" into it.
I guess that just underlines how reframing can really muddy or clarify a problem. The original problem can be mapped onto many varied scenarios with wildly different ethics.
Practically at least one person will choose blue for lulz or curiosity or as a moral compass. Shall we punish them? How does it affect survival of whole population in a long term?
The problem posted is being taken at face value by some and being interpreted outside of a vacuum for others.
The reality is that we don’t live in a vacuum and the framing of red vs blue is almost certainly not an accidental alignment with political colors. If you are in the US, voting blue is also highly correlated with broader empathy characteristics.
It’s telling that some folks think 100% voting one way is just as attainable as more than 50% voting a certain way. The strong irony here is that they themselves would likely not change their vote to help get to 100% no matter which direction that happened to be. This is also why we are roughly split in half with only a small percentage actually voting differently than their identity politics allow.
> is almost certainly not an accidental alignment with political colors. If you are in the US,
Please keep in mind that the association of colour to political wing is radically different, even the exact opposite, in other countries.
> It’s telling that some folks think 100% voting one way is just as attainable as more than 50% voting a certain way.
I don't see anybody arguing this. The entire point of the red strategy is that it is not dependent on how many press red. There are people who predict that everyone will independently come to the same conclusion (it's wrong to assume the entire population will be rational). That is not the same thing.
The argument, as far as I can tell, is that in the world where blue pressers failed to get a majority, red pressers are not responsible for those deaths. They were free to choose red, and had no real incentive not to choose red beyond sympathy for other blue pressers.
But also, in the world where blue pressers do get a majority, red pressers don't suffer any consequences for the "betrayal", as described. It would have to literally be a fate worse than death for choosing blue to make any sense. (In the limit, if we imagine that blue pressers will, if successful, enact their revenge and kill all the reds, then the game merely becomes symmetric and the goal is just to be in the majority.)
> The entire point of the red strategy is that it is not dependent on how many press red.
Yes, but depending on the specifics of the actual implementation of this problem there are extended consequences. What is missed by the red POV is, in some implementations of this, you are losing collaboration/collaborative populations. Society works because of both competition and collaboration. Some people can’t see anything but one side of that.
> Please keep in mind that the association of colour to political wing is radically different, even the exact opposite, in other countries.
Yup, that’s why I worded it the specific way I did. It doesn’t stop people from having a strong opinion on which color they would choose in this scenario. My point is that red vs blue is pre-charged.
> you are losing collaboration/collaborative populations. Society works because of both competition and collaboration. Some people can’t see anything but one side of that.
I don't follow. This would only make sense if we infer that pushing red demonstrates that a person is somehow incapable of cooperating on ordinary societal endeavours. I think that's laughably untrue. I disagree that a society without blue-pushers falls apart, because the button test is not an accurate or even reasonable proxy for whether someone is "collaborative". I parse it as more like a proxy of whether someone is "suicidal".
Then, let's use a different instance of the red/blue problem onto a real world scenario. Since we are talking life/death, let's even go to the extreme of fascism, just so it's clear.
Voting red: In a world where fascism is taking hold and votes are monitored, voting for "red" allows you to stay alive (today.)
Voting blue: In that same world, if enough people vote blue (say at least 50%), then everyone lives.
This has all the same hallmarks of the original problem. Voting red=live another day, voting blue=maybe die.
Here is the rub, fascism usually vilifies a group of people whom will live immediately after voting red but ultimately won't matter if they vote red or blue. If the targeted group is less than 50% of the population then they need people who are not in the targeted group to vote blue to stay alive long-term. There will always be people who "just vote for themselves" since the immediate payout is obvious. Hopefully there will also be enough people who collaborate and vote blue despite that obvious/immediate payout to avoid genocide.
This changes the equation from "suicidal" to something else entirely. I think one key part of that something else is collaboration. It also takes courage and faith in fellow humans with whom you ultimately rely on. One could even say that voting red is cowardly in this scenario.
> This has all the same hallmarks of the original problem.
No, it doesn't. It introduces a bunch of political baggage that doesn't fit, for no reason other than so that you can talk about political groups you don't like.
> If the targeted group is less than 50% of the population then they need people who are not in the targeted group to vote blue to stay alive long-term.
There are no "groups" in the thought experiment (except the ones defined by the choice), and nobody is being "targeted". No "vilification" occurs, and crucially anyone in the "blue group" can trivially just not be so (unlike the identity markers that you're clearly trying to allude to).
> There will always be people who "just vote for themselves" since the immediate payout is obvious. Hopefully there will also be enough people who collaborate and vote blue despite that obvious/immediate payout to avoid genocide.
Survival is not a "payout", and no "genocide" occurs in the case that blue voters fail to attain a majority. You say "hopefully", and you load the situation by describing evil politics. But in the actually described experiment, as an objective matter of fact, there is no meaningful difference between a world where 51% voted blue and a world where 100% voted red.
> One could even say that voting red is cowardly in this scenario.
One could say this, but ordinary tests of courage do not expect people to risk their own lives for no benefit beyond the possibility of contributing to saving people who don't need saving (as they can trivially save themselves.
> As usual, the devil is always in the details.
Things that you add to the situation, or read into it, are not "details".
> Even the “reframed” version in TFA had additional details.
None that are relevant. Adding a real-world political context is obviously not the same thing as adding a manner of death.
> I hope you can find the knowledge you seek elsewhere.
I genuinely have no idea what "knowledge" you think I'm "seeking" in the first place. My purpose here was to explain why I disagree with you.
I also have no idea what you meant in the first place by "This is also why we are roughly split in half with only a small percentage actually voting differently than their identity politics allow.". To be clear, "identity politics" does not mean "which political wing one tends to associate with" or "what political party one tends to vote for" (making politics part of your identity). It refers, instead, to treating immutable characteristics such as sex, race, gender, sexual orientation etc. as a justification for political views; or to promulgating political questions surrounding the merit of those groups or regarding matters somehow particular to those groups (making your identity part of politics).
Reading through the exchange further, it comes across that you imagine that there are such things as "collaborative populations". There are not. There is not some gene people inherit that prevents them from cooperating with others and drives them to an individualistic mindset. (If there were any forces driving people's actions so certainly, then there would obviously be no point in having the discussion in the first place, since obviously nobody could be convinced of anything.) In practice, people show willingness to collaborate with certain groups, and to greater or lesser extent according to the circumstances.
And I am not going to collaborate in a circumstance that implies extreme personal risk for no legible benefit whatsoever. It has nothing to do with how I feel about anyone else's mindset, or how I feel about them as people. It has everything to do with the fact that I know they face the same choice I do: one of extreme personal risk for what should be no legible benefit whatsoever.
You will not live forever. Would applying the same logic again suit you?
Timing matters. Where current resources go matters. Having a plan matters. The current system is not perfect but it’s far better than no system at all.
> The current system is not perfect but it’s far better than no system at all.
you should question this assertion. your assertion is dependent on the assumption that science is a strictly positive sum game (with respect to funding). i am saying it is not, and i have provided the mechanistic explanation of why it's not.
all i ask people to think about is: bad science is worth negative.
imagine trying to insinuate with a straight face that firing everyone on a funding oversight body because they queried the executive branch bypassing the oversight is somehow going to reduce fraudulent research and grift in state sponsored science...
the existence of a body named X does not imply they were doing X, or doing X well.
a better argument would be that trump doing this is possibly toxic because the process of resetting becomes overly political and associated with trump shenanigans. i guess that argument was too sophisticated to make
The possibility a body may have not being doing X perfectly does not mean that anybody should even consider the possibility that centralising X in the hands of the "vaccines cause autism" and "we have different ways of calculating percentages" division of the executive branch instead - the thing that actually happened - is anything other than a bad idea.
Linking Trump's characteristic firing of anybody who questions his actions to a replication crisis he and his acolytes wouldn't be interested in solving even if they had the slightest understanding of it is far too disingenuous an argument to elicit a "sophisticated" response, or indeed anything other than contemptuous dismissal.
> The problem is that we cannot trust code we cannot instrument. If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace except by squinting at it and developing theories. So we write our own. More work upfront, but the clients we write are observable by construction, because we built them that way from the start.
reply