Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Custom rules" section to DNS filtering #2803

Closed
ameshkov opened this issue Jun 17, 2019 · 12 comments
Closed

Add "Custom rules" section to DNS filtering #2803

ameshkov opened this issue Jun 17, 2019 · 12 comments
Assignees
Milestone

Comments

@ameshkov
Copy link
Member

@ameshkov ameshkov commented Jun 17, 2019

Basically, this is a "User filter" for DNS filtering only.

  1. It should support basic blocking rules and hosts-level rules.
  2. It should be integrated with the filtering log (block/unblock should add/remove rules to the user filter)
  3. It should support import/export
  4. Help icon should lead to an article explaining DNS-level filtering rules
  5. We need to add this article to the knowledge base: https://uploads.adguard.com/up04_dvfc5_AdGuard_Home.png
  6. It should be possible to enable/disable custom rules filter

UI

  1. Place the "Custom rules" inside the "DNS Filters".
  2. Visually separate blocklists and custom rules.
@lancelot-moon

This comment has been minimized.

Copy link

@lancelot-moon lancelot-moon commented Jun 17, 2019

Is it possible that AG team make the default whitelist for only DNS filtering?
AdguardTeam/FiltersRegistry#153

@admitrevskiy

This comment has been minimized.

Copy link

@admitrevskiy admitrevskiy commented Jul 1, 2019

Done.

Testing instructions for QA:
-Reinstall AG
-Check issue items

@SergeiShir

This comment has been minimized.

Copy link

@SergeiShir SergeiShir commented Jul 2, 2019

Hi
The latest v3.1.53 brings the custom DNS rules feature.
From what I see, I need to manually reconfigure all my DNS rules ($app=com.adguard.dns) that are saved in the list of all custom rules.
Is there a simple way of doing this?

@SergeiShir

This comment has been minimized.

Copy link

@SergeiShir SergeiShir commented Jul 2, 2019

In addition, this is a problem:
export of DNS rules saves them under the same name as the export of regular rules - "adguard_user_filter_...".
Could you please change the name to "adguard_user_filter_DNS..."?

@TheHasagi TheHasagi closed this Jul 20, 2019
@superlex

This comment has been minimized.

Copy link

@superlex superlex commented Jul 23, 2019

Hi, thank you for this feature :)
I'm trying the new beta v. 3.2.98 (PS: in the README file, beta link is not updated for the new beta).
As regards

It should be integrated with the filtering log (block/unblock should add/remove rules to the user filter)

maybe it could be improved:

  • when you unblock a rule, currently it says that the rule will be deleted: why not disable it instead (empty square)?
  • when you add a rule (by blocking a log entry or simply adding a new rule to the user filter), this new rule could be added to the top instead of the bottom, just for user convenience (e.g. if there are a lot of rules).

My 2 cents :)

@ameshkov

This comment has been minimized.

Copy link
Member Author

@ameshkov ameshkov commented Jul 25, 2019

when you unblock a rule, currently it says that the rule will be deleted: why not disable it instead (empty square)?

Well, the reason is to not clutter the user filter. It's simple to add a new rule, it should be simple to remove it:)

when you add a rule (by blocking a log entry or simply adding a new rule to the user filter), this new rule could be added to the top instead of the bottom, just for user convenience (e.g. if there are a lot of rules).

Hm, do you think we should do the same with the regular content blocking user filter?
Could you please open a feature request about it?

@superlex

This comment has been minimized.

Copy link

@superlex superlex commented Jul 25, 2019

Well, the reason is to not clutter the user filter. It's simple to add a new rule, it should be simple to remove it:)

Make sense :)

Hm, do you think we should do the same with the regular content blocking user filter?

Thinking about it, it could be useful if a user has many custom rules..

Could you please open a feature request about it?

Of course :)
#2962

Then, I'd like to ask two questions:

  1. when you add example.org to dns user filter only example.org is blocked, while when you add ||example.org^ then its subdomains are blocked as well: is this behavior wanted? Should AdGuard convert example.org to ||example.org^ internally?
    For example, uBlock Origin does that.
    Currently, domains lists like for example Malvertising list by Disconnect are not recognized as valid dns lists, while they could.

  2. when you import a dns/hosts list, should a rule that begins with # be considered as a rule that begins with !, that is only a comment (without the square box)? Or as an alternative, should the rule have an empty square box (and the same for ! as regards content blocking user filter)?

Thanks :)

@ameshkov

This comment has been minimized.

Copy link
Member Author

@ameshkov ameshkov commented Jul 26, 2019

Should AdGuard convert example.org to ||example.org^ internally?
For example, uBlock Origin does that.

Well, it works exactly as we wanted it to.

The thing is that most of these domains lists are actually a different form of the existing hosts lists, so we're just keeping the semantics of the original list.

Currently, domains lists like for example Malvertising list by Disconnect are not recognized as valid dns lists, while they could.

Most likely because of Content-Type: application/octet-stream, the list is served as it was a binary file and not a text file.

when you import a dns/hosts list, should a rule that begins with # be considered as a rule that begins with !, that is only a comment (without the square box)? Or as an alternative, should the rule have an empty square box (and the same for ! as regards content blocking user filter)?

AdGuard respects the /etc/hosts specification, # is how comments should be marked in hosts files. You can even use it on the same line as the rule: 127.0.0.1 hosts # blah blah comment

@superlex

This comment has been minimized.

Copy link

@superlex superlex commented Jul 26, 2019

The thing is that most of these domains lists are actually a different form of the existing hosts lists, so we're just keeping the semantics of the original list.

I agree.

AdGuard respects the /etc/hosts specification, # is how comments should be marked in hosts files. You can even use it on the same line as the rule: 127.0.0.1 hosts # blah blah comment

Ok :)

Most likely because of Content-Type: application/octet-stream, the list is served as it was a binary file and not a text file.

Uhm, Spam404 has Content-Type: text/plain; but the warning is the same..

@ameshkov

This comment has been minimized.

Copy link
Member Author

@ameshkov ameshkov commented Aug 1, 2019

Uhm, Spam404 has Content-Type: text/plain; but the warning is the same..

Well, and this looks like a bug :)

Filed a bug report:
#2982

@superlex

This comment has been minimized.

Copy link

@superlex superlex commented Aug 2, 2019

Ok, thank you @ameshkov :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.