Handling "/$file/analytics." rule

General information, announcements and questions about the EasyList subscriptions.

Moderator: EasyList Authors

Post Reply
trickos
New Member
New Member
Posts: 8
Joined: Sun Jun 22, 2014 8:39 pm
Reputation: 0

Handling "/$file/analytics." rule

Post by trickos » Tue Jan 02, 2018 12:23 pm

Hello,

The following rule appears in easyprivacy rule set:

Code: Select all

/$file/analytics.
It raises again the question of how to handle dollar signs which (apparently?) do not signal option definitions. I have found ten years old conversations mentioning escaping syntax but nothing concrete seemed to been done about it:

https://adblockplus.org/forum/viewtopic.php?f=4&t=1069

Could anyone knowledgeable about mainstream adblock rules parsers tell me how this is usually handled? Do you attempt to parse the $ suffix as if it were an option list and take it as raw input upon failure? This approach seems fairly brittle to me.

Thank you.

intense
Contributor
Contributor
Posts: 8228
Joined: Wed Mar 27, 2013 9:56 am
Reputation: 124

Post by intense » Tue Jan 02, 2018 4:42 pm

ABP is blocking the element

example page:
http://axistrivia.altervista.org/

Image

cretz
New Member
New Member
Posts: 5
Joined: Wed Jan 03, 2018 6:45 pm
Reputation: 0

Post by cretz » Wed Jan 03, 2018 6:48 pm

I posted an issue at https://github.com/easylist/easylist/issues/809 but is this the proper place instead? According to ad block rules, "$file" is an option there? What kind of option? Is this just an invalid rule?

intense
Contributor
Contributor
Posts: 8228
Joined: Wed Mar 27, 2013 9:56 am
Reputation: 124

Post by intense » Wed Jan 03, 2018 7:11 pm

As I already said: ABP is blocking the element in the folder "/$file/"

cretz
New Member
New Member
Posts: 5
Joined: Wed Jan 03, 2018 6:45 pm
Reputation: 0

Post by cretz » Thu Jan 04, 2018 5:44 pm

Sorry, that post was from a brand new topic I created and it was moved by mods here. My post does not ask what the ABP program is doing, it is asking about the format. ABP is not the only blocker using those rules. Maybe this is not the place to discuss ambiguity in the syntax.

intense
Contributor
Contributor
Posts: 8228
Joined: Wed Mar 27, 2013 9:56 am
Reputation: 124

Post by intense » Thu Jan 04, 2018 6:12 pm

As you see above ABP is blocking that element, uBo (ublock origin) currently doesn't but will do in the future.

/$fileanalytics. => is still a normal filter (not interpreted as an option) blocking an element such http://axistrivia.altervista.org/$file/$fileanalytics.jpg

/$fileanalytics => will be seen as an option and rejected in ABP (and uBo)

cretz
New Member
New Member
Posts: 5
Joined: Wed Jan 03, 2018 6:45 pm
Reputation: 0

Post by cretz » Thu Jan 04, 2018 8:19 pm

Why is it not interpreted as an option? What about

Code: Select all

/$domain=foo.com
? Does that block

Code: Select all

http://example.com/$domain=foo.com
? I will go parse the code to see what is happening, but at least to me it seems ambiguous.

intense
Contributor
Contributor
Posts: 8228
Joined: Wed Mar 27, 2013 9:56 am
Reputation: 124

Post by intense » Thu Jan 04, 2018 8:47 pm

add
/$domain=google.com

and then go to google.com


cretz
New Member
New Member
Posts: 5
Joined: Wed Jan 03, 2018 6:45 pm
Reputation: 0

Post by cretz » Wed Jan 10, 2018 10:21 pm

Yup, I pointed out the commit in my issue: https://github.com/easylist/easylist/issues/809. With the adblock rules that I read, it is tough to determine options from dollar signs in URLs in some ambiguous situations. Unfortunately, here I was just told to check what happens instead of details on exactly how dollar signs should be handled in rules. So I just left it alone. I just updated my adblock parser to ignore rules it doesn't know about so my parser just ignores the rule which is probably against the norm.

intense
Contributor
Contributor
Posts: 8228
Joined: Wed Mar 27, 2013 9:56 am
Reputation: 124

Post by intense » Wed Jan 10, 2018 10:25 pm

from an ABP dev
Adblock Plus accepts this filter and considers it
a blocking filter. This is since there's a "/" character after the "$"
and so the text after "$" is not considered to be filter options.
For example try filter "/$fileanalytics", I don't think it'll work since
"fileanalytics" isn't a valid filter option.

The relevant code is the Filter.optionsRegExp regular expression[1] in
adblockpluscore/lib/filterClasses.js:

Code: Select all

/**
* Regular expression that options on a RegExp filter should match
* @type {RegExp}
*/
Filter.optionsRegExp = /\$(~?[\w-]+(?:=[^,\s]+)?(?:,~?[\w-]+(?:=[^,\s]+)?)*)$/;
filter options have to follow these rules:

- optionally start with a single "~"
- contain only a-z, A-Z, 0-9, "_" and "-"
- can optionally end with a single "=" followed by one or more
characters which aren't "," or whitespace
- separated by a single ","

Also the options string must start with "$" and end with the end of the
filter.

I don't see a way to escape the "$" character, so I don't think it's
possible to write a filter which ignores the options string should it
happen to follow the above rules. Instead you'd have to add an extra
character such as "/" like your example filter does

cretz
New Member
New Member
Posts: 5
Joined: Wed Jan 03, 2018 6:45 pm
Reputation: 0

Post by cretz » Thu Jan 11, 2018 5:49 pm

intense wrote:
Wed Jan 10, 2018 10:25 pm
This is since there's a "/" character after the "$" and so the text after "$" is not considered to be filter options.
Thanks! That helps a lot. But that appears to be implementation-dependent and not the same as the docs from here and here.

In my opinion, EasyList should not be writing/approving filters that rely on undefined behavior that you have to go to an ABP dev to figure out. Lots of people use the EasyList lists. For example, how does the Brave browser handle it? Alternatively, maybe ABP, uBO, Brave, etc need to get together and put together a grammar for the rules.

Post Reply