Having an open source version allows regular people to do scraping and not just those rich in capital.
Much of the best data services on the internet all start with scraping, the README lists many of them.
540 karma · joined October 30, 2013
http://www.test.com https://www.test.com JavAscRipt://www.test.com%0aalert(1)
<a href="https://www.test.com">test</a> [test](https://www.test.com)
tst
Having an open source version allows regular people to do scraping and not just those rich in capital.
Much of the best data services on the internet all start with scraping, the README lists many of them.
I'd also like to figure out how to turn an image into a description of whats in it. My ML/tensorflow knowledge is very weak though, so I still have a lot to learn here.
Short TL;DR: It runs off my home server running a large vector database (opendistro): https://opendistro.github.io/for-elasticsearch-docs/docs/knn...
Their support basically ignored any evidence to the contrary and let my domains expire and be sniped by other buyers.
Spear-phishing by its very definition is a highly targeted attack. I wouldn't count on any level of training to prevent someone from getting phished. Given some of the spear phishing campaigns I've seen, I wouldn't trust even myself not to fall for them.
It's a problem that needs to be solved with technical solutions like hardware U2F, locked-down customer support devices (e.g. Chrome enterprise policy managed ChromeOS devices), and special account VIP/anomaly locking and auto-escalation.
If you click "Reload policies" under the chrome://policy page does it kick in after ~15 seconds?
Saying "this is not the major security issue the author describes. He couldn't have hijacked any DNS traffic this way." seems a bit dishonest. You're saying that you have personally vetting all the DNS implementations of various DNS resolvers and have verified all of them take the resolution steps you've described exactly? If this is the case why did I receive so many queries (such as A, AAAA for the NS hostnames - which I assumed/assume was to cached these IP addresses for future resolution of the TLD's IPs). The way dig resolves things is different from how many production resolvers would do so, etc.
I can certainly see that some resolvers may take different steps for resolution which would make them unaffected by this issue (I'd have to think on it some more). A big issue here is of course that I didn't actually attempt to poison a bunch of the DNS resolvers which were hitting my server because I didn't want to affect any actual users. "Proving the point" in this case would've been dangerous and probably illegal as well.
That being said, mapping out how various DNS resolvers would perform their full resolution is an interesting side project and I've added it to my TODO list :)