10000truths
10000truths on Hacker News
Another option is to gate success behind a bunch of black-box tests that the agent has permission to execute but not read or write. You'd likely have to write those black-box tests yourself, though.
There is no one ecosystem. The world of web clients is highly diverse. Expecting every client implementation out there to converge onto one particular trust store is, first of all, magical thinking, but second of all, it reintroduces the single point of failure that web PKI is meant to avoid. The OS trust store is just one of many possible trust stores, there's nothing ordained about it. The problem is not with some standard, it's with a mistaken pre-conceived notion that there must only be one.
Many web clients have chosen to default to trust stores within their own ecosystem for usability and reproducibility reasons. When I as a user run "pip install requests", I expect to be able to issue HTTPS requests. I do not expect an implicit system dependency on ca-certificates - that might not even exist on my system!
If you want all of the web clients on your system to use a centrally managed trust store, then it's your responsibility to (a) know and enforce what clients exist on your system and (b) configure them all to use that trust store.
Web PKI doesn't mandate that every client ship with its own root certs. The clients you listed can be configured to use a centrally managed trust store, if that's what you want. The fact that they don't by default is a deliberate tradeoff that the clients made, not some standard's fault.
I'm guessing it's a cognate with the Spanish word for rabbit (conejo)?
> Are we including deleting RDS data? S3? Glacier storage?
If you're billing per GB of storage, then you can put hard caps on storage capacity, and then hard-reject any operation that would take the total stored size over that capacity.
Compassion and self-esteem are not artifacts of culture or ethics. They're intrinsic to humanity. The manner of expression of these virtues can vary among different cultures. The audience of these virtues can vary among different beliefs and ethical frameworks. But the virtues exist in every society.
> Arts and creativity is a luxury. Freedom to pursue passion is a luxury.
Sure.
> Compassion is a luxury. Self-esteem is a luxury.
No. These are virtues, not luxuries. You don't need a high income to be compassionate or have self-esteem.
The "technical" part is anything but. There's no dive into what failed or why. No insight into process, observability, mitigation or prevention gaps that served as contributing factors. There's no explanation of measures taken to prevent future occurrences of the same issue. That whole section is just an attempt to deflect rather than inform.
But members of your social circle (family members, friends, coworkers/bosses etc.) do pay attention, and when they do, they can make it your problem. You can ignore an Internet mob, but you can't ignore getting fired by your employer because they want to preserve optics.
Right, a lot of that trust is implicit and we don't think about it every day. But for threat modeling, it helps to spell out the chain of trust explicitly:
* You trust the browser/OS
* Browser trusts the root cert store (either embedded in the browser installation or managed by the OS)
* Root cert authenticates the twitter.com connection
* Twitter validates the legitimacy of the account (anti-spam/anti-impersonation/verified user etc.)
* You trust that the person who made the post on the Twitter account is the person you want to communicate with
If any of these can be violated, it's an opportunity for attack, be it via a technical exploit, social engineering, political favors, whatever. Ultimately it's up to the user to determine what to trust and what level of risk to accept.
Do you have a link to an example? I'm curious to see the effect you're describing.
Liquidity is a value of its own. 10% equity in a $1M non-fungible residentially-zoned lot is much less valuable than $100K in cash, ready to wire at a moment's notice.
Establishing secrecy is easy if you've already established authenticity - do a key exchange and use the shared secret for your AEAD. Establishing the authenticity is the tricky part, and most encrypted communications protocols offload that to the user in some way:
SSH - the client pubkey has to somehow reach the server's authorized_keys file, and the server fingerprint has to somehow reach the client's known_hosts file.
HTTPS - The root certs have to be present in the client cert store in order for the client to authenticate the servers they connect to.
PGP - People exchange their public keys in key signing parties after verifying each other's identities in person.
Because the public key is the identity in the Wireguard protocol. If Alice and Bob want to communicate with each other over Wireguard, then Alice has to know Bob's public key, and Bob has to know Alice's public key. If they don't already know each other's public keys, then that information has to be exchanged in a secure manner at least once, in order to prevent nosy Mallory from impersonating one of them. How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.
In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".
> But, wireguard also needs to update to support post-quantum
It's quantum-resistant if you define a PSK. You still have to distribute the key out of band, but you already have to do that anyways for the public keys of the peers.
So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in. Sending a binary over SSH/SFTP might sound weird at first glance, but VSCode can't assume that your remote machine can access the wider internet, and it needs a reliable way to bootstrap the agent on the remote. Shipping it over the SSH tunnel is the natural solution.
Sure, you can't avoid poorly designed apps. But a poorly designed app is much easier to fix/replace than a poorly designed OS, particularly when it comes to open-source software.
The need to drop privileges at all is a natural consequence of a process spawning API with inherit-by-default capability semantics. You'd never build a new VM or OS this way if you didn't require compatibility with existing software. The secure solution has always been default-nothing semantics, with whitelisted capabilities granted via explicit arguments in the process spawning API.
The closest you can get to that model on Linux is the strict mode in seccomp, which disallows every syscall except read(), write(), exit() and sigreturn(). It's more or less a way to restrict a process to being "pure compute/memory". If the process then wants to poke and prod at the outside world, it can only do so by reading/writing the file descriptors it inherited prior to the seccomp call. You can build a RPC on top of that to emulate the "whitelist", with access control and restrictions/policies enforced by whatever is listening on the other end.
Why stop there? The bottleneck is not some immutable force of nature. The number of judges is determined by legislative action. It is within Congress's power to allocate new federal judicial seats, and likewise at the state level with the equivalent lawmaking body (for most states, at least). Why don't they do so?
Because everything in the real universe occupies a volume, and therefore no two distinct "things" can be 0 distance apart. The distance between two marbles' center of masses is the sum of their radii. So if you want to measure the potential gravitational energy between the two marbles, you'd take the integral of (GM^2/x^2) dx between x = [sum of radii of marbles] and x = infinity, as an approximation.
It would have to find an open Wi-Fi network that isn't gated behind a captive portal, which is very rare. Rare enough that most telemetry would be too stale to be useful.
> What would <! as Iterator>::Item be?
Another ! makes sense to me here. Are there any cases where it doesn't work to auto-assign ! to all associated types of a ! trait impl? Associated constants might require some mechanism similar to `compile_error!()`.
Because safety and welfare have literally nothing to do with LLMs. They generate text. If someone is stupid enough to hook the text generator up to nuclear missile launchers and try to "align" it against nuclear annihilation with a "pretty please don't do that" prompt, I'm not going to blame the AI for the impending nuclear apocalypse, I'm going to blame the idiot who handed the big red button to the digital equivalent of a toddler.
It's not just dating platforms that have changed, it's also the users. Online dating used to be a niche you had to actively seek out, which meant that the users were naturally self-selected, had more interesting (for better or worse) personalities, and were (on average) more genuine.
Online dating today is far too mainstream for those qualities to remain. Any new dating platform that gains enough popularity to be useful will be quickly flooded with less-differentiated "normies" that dilute any quality in the platform's demographic, and the "optimizers" who game the platform at the cost of other users' experience.
Intellectual property is nothing more than a means of government-backed protectionism, alongside tariffs and embargoes. Any two countries that respect one others' claims of intellectual property do so by mutual agreement. No sovereign is entitled to unilaterally dictate the terms of trade with another, and that includes the exchange of ideas.
This would be interesting data to collect - given some field F, for each immigrant that enters the workforce, what is the delta between:
* The expected marginal increase in supply, from immigrants looking for jobs in F
* The expected marginal increase in demand, from immigrants (or non-immigrants identifying an opportunity) starting companies that need experts in F
And how strongly does that delta correlate with average salary in F?
Being paid the same as the other guy doesn't necessarily mean the wages themselves stayed the same. Adding H1B candidates to the talent pool exerts downward pressure on salary due to the law of supply and demand. I can't say for sure whether the allure of a green card or threat of deportation play a material factor in lowering the average salary that H1B immigrants are willing to accept. But in an environment where talent is treated as fungible (even if it isn't always so), any such downward pressure affects everyone.
Well yes, if the thing you're working on is subject to changes in requirements, then you fundamentally can't one-shot it, AI or no AI. That's why the waterfall process fell out of fashion long ago.
But there are cases where there are no changes, or only backwards-compatible changes. Take the core WebAssembly specification, for example. Extremely detailed, formally verified, comes with a large test suite. Someone else has done the hard work of specifying the behavior of every possible edge case. A WASM runtime implementer can point their agent to that spec, plus some prior art. The remaining manual work is in constructing a test harness and collecting a corpus of test WASM binaries that exercises decent coverage.
Headless agentic coding only works when:
* The scope is constrained and clearly defined
* You articulate an exhaustive and objective set of success criteria
* You provide a deterministic tool for the AI to evaluate its output against those criteria and receive feedback (compiler errors, unit tests, regression tests, etc.)
You're essentially writing a comprehensive spec for the AI to follow. The time suck was always from making the spec and the QA bulletproof.