The compounds in this medicine are public knowledge, but taking them could be dangerous. For a safer experience, review all medical literature pertaining to these compounds before consuming.
Not really the same. One of the main issues with curl pipes is that the server (or MITM) can detect that the request goes into a pipe.
This allows an attacker to display one (safe) source when you view it in your browser on your workstation, or wget it, and serve a different (nefarious) source when you curl/pipe it.
So, a more complete analogy would be: a bottle that gives you a safe chemical compound when you extract it for analysis, but throws in some VX when you go to administer it.
Summary: Fill your script with an invisible payload that fills any buffers, and put something time consuming (say `sleep 5`) early in your script in order to detect that the script is being executed directly rather than just stored to disk. If the client halts before having read all data, it is likely a `curl | bash` scenario. If it just keeps reading, it's a regular browser just downloading.
That way, it is the same as running cURL without piping the output to bash, so people can easily check the code without worrying if the server is sending them different code when they pipe to bash
If you're going to manually audit the source, you can curl into a file then run bash on it. If you're not going to read the code anyway, there's no harm in curl|bash.
You acknowledge the prioritization of ease-of-use/adoption vs. security so I think we're on the same page.
I doubt step-by-step instructions including a review of the script's content would improve the average user's security, in much the same way that click-through ToS dialogs always garner such much scrutiny.
Edit: another comment quoted the warning on the page, at this point it feels like complaining is tilting at windmills.
Yes, I know this is supposed to be a convenience thing, but I wish people wouldn't actively encourage this pattern.