Handling "/$file/analytics." rule

General information, announcements and questions about the EasyList subscriptions.
Locked
trickos
New Member
New Member
Posts: 8
Joined: Sun Jun 22, 2014 8:39 pm

Handling "/$file/analytics." rule

Post by trickos »

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: 10497
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

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

Post by cretz »

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: 10497
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

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

Post by cretz »

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: 10497
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

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

Post by cretz »

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: 10497
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

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

Post by cretz »

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: 10497
Joined: Wed Mar 27, 2013 9:56 am

Post by intense »

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

Post by cretz »

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.
Locked