I know in practice it no longer is the case, if it ever was.

But semantic HTML is exactly that explicit machine-readable entrypoint. I am firmly entrenched in the opinion that HTML, and the DOM is only for machines to read, it just happens to be also somewhat understandable to some humans. Take an average webpage, have a look at all characters(bytes) in there: often two third won't ever be shown to humans.

Point being: we don't need to invent something new. We just need to realize we already have it and use it correctly. Other than this requiring better understanding of web tech, it has no downsides. The low hanging fruit being the frameworks out there that should really do a better job of leveraging semantics in their output.

Since a few people ask "What can I do to help my govt/region/country to become more sovereign", here's my tips on this:

- All governments under EU (on almost all levels) are "required" to use and/or produce software as Open Source. The source of "that government app" should be available somewhere (though quite likely is not)¹ So go hunt for the source and start there.

- Look at underlying standards. EU regulation, trickling down into local laws and guidelines, rely on Open Standards almost always. That app you use to log into your tax environment quite probably uses (a weird, hard to recognize) variation of OAUTH2 or OpenID connect, SAML or such. The app that shows the time+dates for garbage-collection, quite probably uses a simple ical-feed under the hood. With that knowledge, you may be able to develop/fork/use open source alternatives without too much effort².

- Show (local) representatives the alternatives. Listen to them. Learn from them. Most representatives are suprisingly open to you as expert. But, I cannot stress enough, learn and listen foremost. IT experts and open source community in particular have an (IMHO well deserved) reputation for being arrogant, know-it-all unfriendly and rediculously single-minded. So don't lecture that councillor for using Twitter instead of Mastodon, riduculing them for not using GPG or scoffing at their insistence on using Microsoft Word over Vim with Markdown (My younger self was such an arrogant neckbeard; I am now convinced I have done actual harm to the Open Source community that way). But ask why twitter, have they tried mastodon, or bluesky? Why not? Why did they leave? What features in MSword do they require? Did they know that Jitsi is an option? Maybe you can show how they could use Nextcloud for at least their own files? Sometimes you can answer some of their questions and help them. More often, you learn a few things that you could use to improve sovereign and open source alternatives and align them slightly more with whats needed.

¹ The details, interpretations and implementations are a mess, but the idea is "open source, unless..." for any software that any government buys, rents, builds, etc. In practice almost all projects fall under "unless...". I spoke to a MSFT account-manager for several local govts and he told me they have f*in training material to "help" govt officials write tenders/requirements in such a way that Open Source is practically excluded and Microsoft the only option. I am appalled, but also not that surprised.

² The ical-finding is how I got my local garbage-collection schedule into my calendar app. And when I told this to someone who happened to work at the municipality, they realized that publishing the urls and docs online helped a lot of citizens. Ironically, the push-back, according to this person, was from a civil-servant whose career was influenced on the success (install counts) of the "municipality app" and who was afraid that if people could add the calendar to their outlook/google cal/ical/other-cal, might no longer install the app. Again, I was appalled at such perverse incentives.

How does a mounted secret (vault) protect against dumping secrets on crash or debugging?

The app still has it. It can dump it. It will dump it. Django for example (not a security best practice in itself, btw) will indeed dump ENV vars but will also dump its settings.

The solution to this problem lies not in how you get the secrets into the app, but in prohibiting them getting out of it. E.g. builds removing/stubbing tracing, dumping entirely. Or with proper logging and tracing layers that filter stuff.

There really is no difference, security wise, between logger.debug(system.env) and logger.debug(app.conf)

I'm not familiar with all current ongoing projects. Because of the situation mentioned above.

Currently I'm involved in projects surrounding https://developer.overheid.nl/kennisbank/security/standaarde... . Have a look there. It's not FLOSS in the way that you can just provide PRs of things you'd like different, but FLOSS in the way that you can get in touch and with enough expertise, have people listen to you.

I strongly disagree.

Environment variables are -by far- the securest AND most practical way to provide configuration and secrets to apps.

Any other way is less secure: files on disk, (cli)arguments, a database, etc. Or about as secure but far more complex and convoluted. I've seen enterprise hosting with a (virtual) mount (nfs, etc) that provides config files - read only - tight permissions, served from a secure vault. A lot of indirection for getting secrets into an app that will still just read them plain text. More secure than env vars? how?

Or some encrypted database/vault that the app can read from using - a shared secret provided as env var or on-disk config file.