I don't think this would fly between enterprise usage of custom DNS, captive portals, privacy protection etc

Yes, and this might take some years to catch on.

OTOH it's not out of the question that some open source non-extension Chrome mod emerges that will then block those kinds of ads. Brave is already shipping this anyway.

They should make it more clear that it's a concept.

I could see a real version that sends the inputs to the backend where some analysis is done, but right now an adversary can just run the onVerify callback as "bypass".

Inflated egress costs might make this prohibitively expensive, $80 per TB at GCP and AWS

That works on a single persistent box, but unfortunately, that means giving up on autoscaling, which is not so nice for cloud applications.

You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too.

Once it's networked you lose the "whitelist of systemd services" and it's then no different from any networked secret store.

No, this is a solved problem: https://spiffe.io/

You can do service attestation securely, even for networked services.

Nice. Really grateful for your participation in this comment tree

But the encrypted API key doesn't work, it needs to be decrypted first. Let's give the server access to the private key so it can decrypt the API key. We can do this by putting the private key in an env var. But now the private key is unencrypted. Ah, it doesn't work.

You’re thinking too much. When you run the app, the system decrypts the secrets and makes them available as env vars (or some other mechanism).

In an admin ui, you list the names of secrets only, and provide a “reveal” or a “replace” on each one. They are never decrypted unless explicitly asked for.

Is this perfect? Absolutely not. The key is controlled by the company, but it can be derived in a manner that doesn’t allow for the dump of everything if it’s leaked.

My gripe is that, if some additional authentication is then not required for deployments or SSH access, that whoever has access to the admin UI will still be able to access the box and extract all secrets, just with extra steps. There's usually no real security boundary between "admin UI controls the box" and "box requires secrets in plain text".

I still like the approach, but I'm afraid that it feels more secure than it is, and people should be aware of that.

It’s absolute baseline, but yes, it relies entirely on the platform’s permissions model, the administrator who assigns permissions, and the application authors to not create vectors for env var dumps. :)

But honestly, if you’re in the container, and the application running in the container can get secrets, so can a shell user.

_Maybe_ there’s a model where the platform exposes a Unix domain socket and checks the PID, user, group of the connection, and delivers secrets that way? This has its problems, too, like it being non-standard, only possible in some scenarios and otherwise fallible… but better than nothing? If you reap the container when that process dies, you can’t race for the same PID, at least. I dunno

My understanding is this is exactly how Vercel works. The users hadn’t checked the “don’t ever reveal, even to me” box next to the sensitive values. If they had, the attacker would only have been able to see the names of the variables and not their values.

Ah. The article has since been updated to point out that it’s not plaintext, but encrypted at rest (which would be expected). OK.

Theoretically maybe, but there's no indication that a quantum-resistant algorithm can't encrypt something that's secure for the coming million+ years.

Sure there is, just use a one time pad and never repeat the message.

Oops - you said the opposite of what I read, my mistake.

It looks like tricolon is about specifically three parallel elements, while staccato is about short consecutive sentences, so staccato would be the appropriate name here.

Yeah, "don't overuse these patterns" is the right attitude for tools like this, not "fix all mistakes". And that's OK?

It would be OK, but the point I'm raising is that the Grammarly-like design encourages the user to resolve everything it highlights, to make the text look uniform and spotless.

Yes, you have to imagine a much bigger star beneath the viewport.