In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what we are defining.
In Java, a 6000LoC+ ecosystem of classes, abstractions, dependency-injectables and probably a new DSL would be invented so we can all say "over 4 Malaysian workdays"
But you know that Java solution will continue working even after we no longer use the Gregorian Calendar, the collapse and annexation of Malaysia to some foreign power, and then us finally switching to a 4-day work week; so it'd be worth it.
... and since it was architectured to allow runtime injection-patching of events before they hit the enterprise-service-bus, everyone using this library must first set fourteen ENV vars in their profile, and provide a /etc/java/springtime/enterprise-workday-handling/parse-event-mismatch.jar.patch. Which should fix the bug for you.
You can find the patch files for your OSs by registering at Oracle with a J3EE8.4-PatchLibID (note, the older J3EE16-PatchLib-ids aren't compatible), attainable from your regional Oracle account-manager.
And least one of those environment can contain template strings that are expanded with arguments from request headers when run under popular enterprise java frameworks, and by way of the injection patching could hot load arbitrary code in runtime.
A joke should be funny though, not just a dry description of real life, so let's leave it at that. We've already taken it too far.
In before someone thinks it's a joke, the most commonly used logging library in Java had LDAP support in format scripts enabled by default" (which resulted, of course in CVE)
JavaScript Temporal. Not sure knowing what a "workday" is in each timezone is in it's scope but it's the much needed and improved JS, date API (granted with limited support to date)
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.
It is probably unintentional. I work and worked in such projects (in The Netherlands), and the process is -rightfully- chaotic.
Governments typically don't have a central single team that builds all their android apps. They usually write a tender with loads of requirements and app-agencies will then build it. Or freelancers. Or volunteer teams. Or all of that. So there's no central team governed by one minister who can dictate what should happen today. There's hundreds of companies, teams, freelancers, interims, running around trying to make deadlines
Between writing a spec and the delivered app, there's chasms: could be a year between the specs are written and the first app pushed onto a phone. In a (trump)year a lot can change. But also between how specs are requirements or wishes in real life. "No user data may ever reach a google server" (actual specs are far vaguer and broader) may sound good, but will conflict directly with "user must receive push notifications of Foo and Bar". Or "passport NFC data must be attested for login", requiring a non-rooted, android, signed-by-google hardware attestation thingymajick.
So no, this is not malice. Nor incompetence. This is a sad reality, where we've allowed the monopoly to dictate what we, and users, expect, and to have that monopoly be the only option to provide those expectations.
As someone in the Netherlands, and also with a company in this space, could you point me to some relevant resources (like ongoing projects)? I'd love to help our country get more sovereign (in small steps).
Btw, NRC has a nice podcast series on the topic. One thing hampering the sovereignty effort is the enormous amounts of Azure/AWS/GCP certified people. Their career is build on these platforms.
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.
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.
It suprises me how often I see some Dockerfile, Helm, Kubernetes, Ansible etc write .env files to disk in some production-alike environment.
The OS, especially linux - most common for hosting production software - is perfectly capable of setting and providing ENV vars. Almost all common devops and older sysadmin tooling can set ENV vars. Really no need to ever write these to disk.
I think this comes from unaware developers that think a .env file, and runtime logic that reads this file (dotenv libs) in the app are required for this to work.
I certainly see this misconception a lot with (junior) developers working on windows.
- you don't need dotenv libraries searching files, parsing them, etc in your apps runtime. Please just leave it to the OS to provide the ENV vars and read those, in your app.
- Yes, also on your development machine. Plenty of tools from direnv to the bazillion "dotenv" runners will do this for you. But even those aren't required, you could just set env vars in .bashrc, /etc/environment (Don't put them there, though) etc.
- Yes, even for windows, plenty of options, even when developers refuse to or cannot use wsl. Various tools, but in the end, just `set foo=bar`.
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.
Disagree, the best way to pass secrets is by using mount namespaces (systemd and docker do this under /run/secrets/) so that the can program can access the secrets as needed but they don't exist in the environment. The process is not complicated, many system already implement it. By keeping them out of ENV variables you no longer have to worry about the entire ENV getting written out during a crash or debugging and exposing the secrets.
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)
Sops can natively handle .env files. All you need to apply them to your process is a small wrapper script that sources the decrypted file before invoking your command.
There's a lot of gotcha bundled into this statement. It is true what you say, but it also hides away the nightmare of shell escaping bullshit that comes with the .env format the second you have to have some sort of transformation on the data that is orthogonal to the normal decryption path. I think that now they have a better story around some of the edge cases but if you go into SOPS you will see several issues around how the .env file format is just a complete nightmare with crazy escaped values such as a Google Service Account JSON.
The way I got around this on my own stuff is just to have a policy that all sops secrets have to be base64 encoded before the encryption hits them. That seems to solve basically every piping issue you could hit. Works super well with kubernetes, who supports native base64 encoded secrets, so you just take the value and inject it in, using data: instead of stringData: in the manifest of the created secret.
You can achieve something like this with a pricing strategy.
As DHH and Jason Fried discuss in both the books REWORK, It Doesn’t Have to Be Crazy at Work, and their blog:
> The worst customer is the one you can’t afford to lose. The big whale that can crush your spirit and fray your nerves with just a hint of their dissatisfaction.
(It Doesn’t Have to Be Crazy at Work)
> First, since no one customer could pay us an outsized amount, no one customer’s demands for features or fixes or exceptions would automatically rise to the top. This left us free to make software for ourselves and on behalf of a broad base of customers, not at the behest of any single one. It’s a lot easier to do the right thing for the many when you don’t fear displeasing a few super customers could spell trouble.
But, this mechanism proposed by DHH and Fried only remove differences amongst the paying-customers. I Not between "paying" and "non-paying".
I'd think, however, there's some good ideas in there to manage that difference as well. For example to let all the customers, paying- or not-paying go through the exact same flow for support, features, bugs, etc. So not making these the distinctive "drivers" why people would pay. E.g. "you must be paying customer to get support". Obviously depends on the service, but maybe if you have other distinctive features that people would pay for (e.g. hosted version) that could work out.
However, I understood GP's mention of "embarrassment" to speak more to their own feelings of responsibility. Which would be more or less decoupled from the pressure that a particular client exerts.
"Informed decisions" mean you need to have the information.
Like with software development, we often lack the information on which we have to decide architectural, technical or business decisions.
The common solution for that is to embrace this. Defer decisions. Make changing easy once you do receive the information. And build "getting information" into the fabric. We call this "Agile", "Lean", "data driven" and so on.
I think this applies here too.
Very big chance that MinIO team honestly thought that they'd keep it open source but only now gathered enough "information" to make this "informed decision".
Your question is an important one, but also one that has been extensively researched, documented and improved upon. Whole fields of science, like "Metaethics" deal with answering your question. Other fields of science with defining "normative ethics" aka ethics that "everyone agrees upon" and so on.
I may have misread your question as a somewhat dismissive sarcastic take or as a "Ethics are nonsense, because of who defines them". So I tried to answer it as an honest question. ;)
Not quite. You are describing "kinds of ethics" after ethics is an already established concept. I.e. actual examples of human ethics. Now the question is who defines ethics as concept in general. Humans can have ethics, but is it applicable to the computer programs at all? Sure, programs can have programmed limitations, but is that called ethics at all? Does my Outlook client has ethics, only because it has configured rules? What is the difference between my email client automatically responding to an email with "salesforce" mentioned and an LLM program automatically responding to a query with the word "plutonium"?
> "Self-interest is the main motivation of human beings in their transactions" [...] The economic man solution is considered to be inadequate and flawed.[17]
An important distinction is that a human can *not* make pure rational decisions, or use complex deductions to make decisions on, such as "if I do X I will go to jail".
My point being: if AI were to risk jail time, it would still act different from humans, because (the current common LLMs) can make such deductions and rational decisions.
Humans will always add much broader contexts - from upbringing, via culture/religion, their current situation, to past experiences, or peer-consulting. In other words: a human may make an "(un)ethical" decision based on their social background, religion, a chat with a pal over a beer about the conundrum, their ability to find a new job, financial situation etc.
> a human may make an "(un)ethical" decision based on their social background, religion, a chat with a pal over a beer about the conundrum, their ability to find a new job, financial situation etc.
The stories they invent to rationalise their behaviour and make them feel good about themselves. Or inhumane political views ie fascism which declares other people worth less, so it's okay to abuse them.
Yes, humans tell themselves stories to justify their choices. Are you telling yourself the story that only bad humans do that, and choosing to feel that you are superior and they are worth less? It might be okay to abuse them, if you think about it…
This is javascript, not Java.
In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what we are defining.
In Java, a 6000LoC+ ecosystem of classes, abstractions, dependency-injectables and probably a new DSL would be invented so we can all say "over 4 Malaysian workdays"
reply