An admin password prompt is hardly a deterrence to people doing stupid things. A young physics PhD friend of mine fell victim to a tech support scam, happily installing whatever spyware “Apple Support” told her to install over phone. That was a few years ago. The average person is too easily social engineered into allowing anything.
Sure, I don't think either this[1] commenter or Ken Thompson were trying to say that the product category shouldn't exist. A computer is vastly overpowered for what the average user is capable of or interested in doing[2], which is why toy devices like iPads are so popular.
I interpreted both of their comments as claiming that the direction MacOS is taking is a poor fit for those who still get value from powerful, general-purpose computers (myself very much included! I occasionally have the misfortune of using Macs, but am much much happier on systems where I can dig as deep into its layers as I need to solve my problems or scratch my itches)
[2] Though I do think it's a minor tragedy that the increasing amount of guardrails has narrowed the opportunity for an inquisitive youngster to explore his computer's internals
> The average person is too easily social engineered into allowing anything.
How many "average" users you know who use sudo? At some point, the software needs to acknowledge users who are saying "I know what I'm doing and the risks, just let me do it" i.e. sudo.
An admin check tells the OS that you are an admin, not that you know what the software does and that you are ok with CoolWallpapers logging all inputs.
So what should happen when the threat model changes? Just abandon all software, ossify it in a poor state, or something else?
You always to be advocating for ossification to avoid breaking apps which are no longer ok under an evolved threat model.
Finally, you didn’t actually answer the question I asked. It’s all very well and good to say how things should be, but people have to face the world as it actually is instead.
If applications can edit arbitrary files on the system it's already game over. I have no idea why people focus so much on “keylogging” as the supposed super important and dangerous thing.
If one run any malware with the full file edit permissions of one's user account at that point in theory the only solution is erase not only the hard drive, but also every other drive on any other system one's user account has access to or at least in sofar those do not have some logging for connexions in some way to see who connected that cannot be edited by the permissions one has on that system. Of course if one has root on one's own system nothing on that system can be trusted any more from that point. The malware could in theory have edited the firmware at that point to hide any checks one could do with a recovery system on a portable drive, but that's all quite theoretical of course, but it's possible in theory.
Keylogging is such a strange thing to focus on in the face of being able to edit arbitrary files owned by the user.
It doesn't matter and it's still a theatre. Those malicious applications can do what they want regardless by editing arbitrary files and obtain the same end.
The supposed threads of malicious applications keylogging and stealing your website passwords to worry about is rather strange when such an application can edit the files on your system such that you're starting a modified version of a web browser they injected with whatever code they want to do the same. In fact, this is probably easier to do than try to write some kind of a.i. that filters what it thinks are “password keypresses” opposed to altering the code of the web browser such that it simply sends whatever is being put into a field marked as “password” on a website.
It's a moral panic boogeyman that has no actual implications for actual real life security. Like quite a bit of “security” talk these days. Much of it comes down to the “door in your room” analogy where “security experts” talk about putting a big door in the middle of one's living room with an impenetrable lock on the idea of kindly asking criminals to only go through that door to steal things. In reality they'll just walk around it, and now one has an inconvenient door in the middle of one's living room.
Both ffmpeg(1) and openssl(1) share that they're meant, or used to be meant, as examples/demos of the underlying APIs. No one was actually supposed to run an actual CA with openssl(1), for example. Both also share that some things are vastly easier using the API than bending over backwards thrice at full moon using the CLI, but because using the API has more friction to it, people generally stick to the CLI (almost) no matter how hard that'll make things.
Oh, and just like you have to know a ton about how media containers, streams and codecs actually work to use the ffmpeg API, you likewise need to be a crypto expert to use the OpenSSL API. Almost the same is true for their CLIs as well, though.
I'm less familiar with ffmpeg, but the openssl(1) command wasn't originally designed to expose the API. It was intended to provide very rudimentary examples for using the API, and perhaps operated as a useful development tool for contributors, but that's it. There were plenty of APIs it never exposed, and plenty API changes it was never updated to accommodate. And IIRC there were some breakages along the way.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.
The same is true of ffmepg. The api documentation even links to the source of the bins so you can read the example code. To pick on ffplay, I think it most clearly illustrates this - with the bare minimum rendering context to get video on the screen but clean code continously updated to reflect the api's best practices, and an invaluable resource when I was writing an embedded player for a game.
True, but you use the wrong FFMpeg codec, or transcode an audio track instead of copying it to the output, no one is left dangerously insecure. You just have a bloated MKV :-D
There are plenty of ffmpeg interfaces, though. The most prominent is Handbrake. Of course, I don't think any of them try to expose every single option. The goal for them is almost always to create an interface that works for the 99% and let the 1% deal with the CLI
An FFMPEG GUI in the style of this OpenSSL one would be great if you are familar with the options but don't use the tool enough to remember the exact commands. It'll also let me explore interesting parameters that I can look up in the manual later to see if they apply to my application. Maybe the GUI could even have buttons that will open the manual page to that specific option. With the CLI I'll likely only grab the specific options I need from the manual and not explore as much.
