The smallest footprint for an actual scripting probably will be posix sh - since you already have it ready.

A slightly bigger footprint would be Python or Lua.

If you can drop your requirement for actual scripting and are willing to add a compile step, Go and it’s ecosystem is pretty dang powerful and it’s really easy to learn for small automation tasks.

Personally, with the requirement of not adding too much space for runtimes, I’d write it in go. You don’t need a runtime, you can compile it to a really small zero dependency lib and you have clean and readable code that you can extend, test and maintain easily.

How in the fuck are people actually defending signal for this, and with stupid arguments such as windows is compromised out of the box?

You. Don’t. Store. Secrets. In. Plaintext.

There is no circumstance where an app should store its secrets in plaintext, and there is no secret which should be stored in plaintext. Especially since this is not some random dudes random project, but a messenger claiming to be secure.

Edit: “If you got malware then this is a problem anyway and not only for signal” - no, because if secure means to store secrets are used, than they are encrypted or not easily accessible to the malware, and require way more resources to obtain. In this case, someone would only need to start a process on your machine. No further exploits, no malicious signatures, no privilege escalations.

“you need device access to exploit this” - There is no exploiting, just reading a file.

You’re right, containers are not VMs, and I’ve never claimed that. For the matter of basic unix access control for a beginner they are similar enough to treat them as such. It’s enough of a baseline for basic security for a beginners workload imo. For advanced use cases - absolutely do not treat containers as you would VMs.

Imagine your containers as very lightweight mini-VMs. Would you run everything as root in your virtual machines? Containers aren’t really that different to classical VMs from an operations point of view. You have a different attack surface, but it is still there, and running as a non-root user inside the container reduces this attack surface, and should IMHO be the default. Privileged containers and users may be required for specific purposes, but should not be the norm, if possible.

Well, guess how the comfy OK Google or hey siri works, hearing you while you say it all across the room. Or that noise cancelation for your calls. Admittably, the way he’s put it sounds really tinfoil hat weird, but he’s got a point there.

Any current mobile phone is so very crammed with sensors of any kind, which do make a lot of features possible/usable/comfortable and the same sensors may be used to track a good lot of your behavior, if used for malicious purposes. And we know that for a fact with targeted ads, where several people I’ve talked to noticed the same, where that even talking about a topic may be enough for ads to be show up. Check https://adssettings.google.com/ for example, it’s actually scary what Google “assumes” about you, and even scarier how on point those assumptions are. A lot of this information is sourced from your devices sensors, and the argument of “there’s just not that much computing power to process this data” is simply not valid anymore.