There is one difference still, by downloading it locally, you only have to check it once and not everytime you want to use the script.
You definitely have to trust more parties by piping from the web, and these parties could be compromised at some point.
This might be fine, it depends on your own security policy.
The project ZAP is a really great tool to help you in the process.
(https://www.zaproxy.org)
Outside the web sphere, exploit database is a great site with a bunch of exploit code, explanation and papers.
(https://www.exploit-db.com)
The tool suite in Kali Linux is also very good if you don't mind read the documentation and try understanding the goal of the tools.
(https://www.kali.org)
Security is such a wide domain that you can quickly get flood.
I don't think the ultimate step-by-step learning guide exists.
Once you've learned and practiced a bit, if you don't give up too soon, you will get the point and understand how deep you need to go into a protocol or a system to actually do something yourself (then this not about security documentation anymore, but about understanding how the target works, and how you can make it work the way you want).
I would say that you need to focus on some targets first, and expand the scope over time depending on your needs/interests.
I had the same problem with an almost automatic !g.
A while back i decided to put more effort and try to survive with !so, !gh, !hn, !r, !w, and a couple more depending on the context.
DDG may not give exact results in less than a second, but i believe that blindly giving priority to the fastest result is a critical issue, in many areas.
For the very niche topics, i basically maintain myself lists of sites.
I still use !g as fallback or when i'm too lazy.
And also for pentest reconnaissance, i have a hard time seeing how to do it without Google honestly (which is scary).
Page load of DDG is not quite good indeed, but i don't mind let it a few seconds.
"For the very niche topics, i basically maintain myself lists of sites."
I have a Google CSE for the sites I have subscribed in RSS reader. It provides results that I could never get with straight Google search. Curious to know what your sources are like if you don't mind?
Well that's more of a manual work than anything else, not optimal in term of speed.
Trying to keep following mailing lists diagonally, keep contact with other people in the niche.
It eventually leads me to some other new site, mailing lists, blogs, videos. Then i use a bunch of scripts to maintain a todo list, and i'm processing (keep & index/drop) them when the time comes, and it loops.
TBH, i mostly do all of that just because i don't want to be stuck deeper in the Google web, but that's more of a philisophical issue. I could easily live without all the DDG stuff, but not (yet) without all the Google stuff.
Everybody is guilty in some way of not making a change, or not taking a stand, whatever the 'good' or 'bad' subject that is.
Still, no single indvidual is to blame in most cases.
The education and the media in practice are means to shape the values, believes and perception of people.
At the mass scale, people flows into an unstoppable current, growing, fed by itself.
Taking a stand against these currents from the outside would be suicide. (Fortunately there is not only one current to go into, yet).
FB will likely reach a dead end someday, but that sort of current will continue to flow.
IMHO, the best effort for an individual is trying to get other individuals realize and have some understanding in what kind of current they are flowing.
If i understand correctly, the problem of Java deserialization is 1) gadgets for code execution and maybe 2) DoS. And this is bad because even if it looks secure now, a gadget could be discovered later.
The default Java serialization is one of the easiest way to serialize instance of objects but there are many other ways, and many other risky ways among them.
It seems to be always the same problem: ClassLoader access. Couldn't there be a way to let the deserializers use a specific ClassLoader?
I mean some sort of (Sandboxed)ObjectInputStream that uses a specific ClassLoader defined in the JRE config. The sandboxed contexts could be defined in something like java.security, .policy, to define what it is supposed to know and when/where it is supposed to be used.
