thegamer/zardoz
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

README Updated

Browse source
This commit is contained in:
Loweel 2019-11-22 14:40:53 +01:00
parent 72eda5c2ed
commit edde332e62
1 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -69,9 +69,11 @@ export DEBUG="true""
The value of trigger can be from 0 to 1, like "0.5" or "0.6". The difference between BLOCK without learning and block with learning is execution time. On the point of view of user experience, it will change nothing (user will be blocked) but in case of "block+learn" the machine will try to learn the lesson, since there is some ambiguity (the good probability are high too).
The value of trigger can be from 0 to 1, like "0.5" or "0.6". The difference between BLOCK without learning and block with learning is execution time. On the point of view of user experience, it will change nothing (user will be blocked) but in case of "block+learn" the machine will try to learn the lesson.
The same happens for the situation "PASS+LEARN": in such a case, both probabilities are low, so we are in a situation of ambiguity. Zardoz cannot say this is a bad request, neither can say it is bad. In such a case, it will allow the request , but it will learn to improve future decisions.
Basically, if the GOOD and BAD are very far, "likelyhood" is very high, so that block and pass are taken strictly.
If the likelyhood is lesser than TRIGGER, then we aren't sure the prediction is good, so zardoz executes the PASS or BLOCK, but it waits for the response , and learns from it. To summerize, the concept is about "likelyhood", which makes the difference between an action and the same action + LEARN.
Personally I've got good results putting the trigger at 0.6, meaning this is not disturbing so much users, and in the same time it has filtered tons of malicious scan.