Whitelist common false-positives #20
Comments
|
I prefer to solve false positives at the root and contact the maintainer of the original list, I have done it in some occasions and it has worked. But I understand that it is a tedious operation and not always the maintainer will eliminate that entry from the list. Currently the Meanwhile, I checked the domains that are currently present in both hBlock and anudeepND whitelist and these are the results. comm -12 <(curl -fsS https://hblock.molinero.xyz/hosts_domains.txt | sort) <(curl -fsS https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt | sort)
|
|
I edited the script to include the list like this:
it seems to work fine without any problems. |
|
Even though it seems to work, you are actually whitelisting more domains than you think, because the If you want to modify the script, I suggest you do this instead: whitelist=$(curl -fsSL 'https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt' \
| while read -r d; do printf '^%s$\n' "$(quoteRe "$d")"; done \
) |
|
Huh, you're right. I don't have a tonne of experience with bash scripting, so thanks for that. Would there be any negative reason to add this by default? You could even mirror the whitelist or host your own to only include domains which shouldn't be blocked but are in the blocklists. |
|
The solution I have given in #20 (comment) works for this case, but it is not generic enough, since it assumes that each line is a domain name, and is also too slow. In order to implement this feature I should first sanitize the input and improve the performance. I still have improvements to make to the On the other hand, are any of the domains that I mentioned in #20 (comment) causing you problems? |
|
Can I thank you first for making this script - promoted it here - Can I add something to the wishing list? What if you provide a .config/hblock/whitelist.txt to the users so they can add an url rather then a regex (that is not everybody's cup of tea). Currently I want to whitelist analytics.google.com to see my traffic. Regex works fine but we have implemented your application in a timer and a service. At that point the whitelisting is not applied or gone again and I need to manually intervene to whitelist it. |
|
I'm thinking of making the Clearly this breaks compatibility, so I must increase the version to 2.0.0. |
|
so --whitelist-regex will only support regex and no url and will read a file that contains 1 specific rule on each line? and whitelist will only support a file with urls in it and will read a file that contains 1 specific url on each line? or is it something else? Since Hblock runs by default in our system... it is best we supply already url's that we whitelist for the users like google analytics. So it would be great that if you just type hblock the application looks for the two files and already includes or excludes what is in those files.If no files or content ... nothing happens. So it is up to the users to manage their own whitelist and blacklist. |
|
I have created an experimental branch with these changes and other improvements. I haven't updated the readme, but you can use the |
|
Thanks for your effort. ./hblock --whitelist HBLOCK_WHITELIST Just ran hblock from the download folder - did not build anything and hblock was already installed |
|
The |
|
it worked with this line of code so
would be become the same thing or is that what this variable is for? |
|
In the new branch the whitelist works as follows. If the environment variable With the option |
|
looking good - lets move forward |
|
I think these files should be created explicitly by the user and not by the script. When I make the priority change mentioned in the previous comment, I will make a merge in master and publish version 2.0.0. |
|
Ok If you want me to test it before release...
I will make the time.
Op za 24 nov. 2018 om 16:26 schreef Héctor Molinero Fernández <
[email protected]>:
… I think these files should be created explicitly by the user and not by
the script.
When I make the priority change mentioned in the previous comment, I will
make a merge in master and publish version 2.0.0.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKGp9o4iHnd1QLAVO7rkSOlgdRfMHrzEks5uyWU-gaJpZM4VQDxq>
.
|
|
I'd really appreciate it if you'd take the time to check it out. Thank you! |
|
Done (d2f935a). |
|
super
Op zo 25 nov. 2018 om 13:36 schreef Héctor Molinero Fernández <
[email protected]>:
… Done (d2f935a
<d2f935a>
).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKGp9kwxc1ukZZw2QZw2FO_po7h2P4BWks5uyo6vgaJpZM4VQDxq>
.
|
|
and how to test - stay in the experimental branch?
Op zo 25 nov. 2018 om 13:36 schreef Héctor Molinero Fernández <
[email protected]>:
… Done (d2f935a
<d2f935a>
).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKGp9kwxc1ukZZw2QZw2FO_po7h2P4BWks5uyo6vgaJpZM4VQDxq>
.
|
|
Crazy idea... this is what I did without reading the posts again. |
|
tried the experimental branch and typing hblock works Just for your information. You decide the best option. Should we not add already a file blacklist.list to the pkgbuild? |
|
I think the correct path should be On the other hand, since you are including the |
|
as I said it is up to you...
consistency is key- agreed
Op do 29 nov. 2018 om 19:20 schreef Héctor Molinero Fernández <
[email protected]>:
… I think the correct path should be /etc/hblock.d/whitelist.list as the
user needs permission to modify the /etc/hosts file anyway and it is a
change that affects all users.
On the other hand, since you are including the
/etc/hblock.d/whitelist.list file, I think it's a good idea to also
include /etc/hblock.d/blacklist.list for consistency. I have no plans to
use any blacklist by default.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKGp9n9E9uWfiRrw6Xz2PmQJBu_sm6mtks5u0CVXgaJpZM4VQDxq>
.
|
|
let me know when I can test again
cheers
Op do 29 nov. 2018 om 19:20 schreef Héctor Molinero Fernández <
[email protected]>:
… I think the correct path should be /etc/hblock.d/whitelist.list as the
user needs permission to modify the /etc/hosts file anyway and it is a
change that affects all users.
On the other hand, since you are including the
/etc/hblock.d/whitelist.list file, I think it's a good idea to also
include /etc/hblock.d/blacklist.list for consistency. I have no plans to
use any blacklist by default.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKGp9n9E9uWfiRrw6Xz2PmQJBu_sm6mtks5u0CVXgaJpZM4VQDxq>
.
|
|
All right, I just released version 2.0.0. |
|
It is past midnight ... quick test ;-)
Op vr 30 nov. 2018 om 23:49 schreef Héctor Molinero Fernández <
[email protected]>:
… All right, I just released version 2.0.0.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKGp9poaGwlgQvUuDEGSjj-WLAa1dxGyks5u0bX4gaJpZM4VQDxq>
.
|
|
works fine |
It might be a good idea to add a list of commonly whitelisted domains such as this to lower the probability of people having problems.
Found the list at https://firebog.net/ under "Whitelisting Suggestions".
The text was updated successfully, but these errors were encountered: