10000truths

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.