[Done] More flexible anchors

Various discussions related to Adblock Plus development

[Done] More flexible anchors

Postby Wladimir Palant » Sat Jan 03, 2009 12:19 am

A suggestion that came from the Mozilla Russia forum - make anchors more flexible so that one can omit the protocol and subdomains. It boils down to filters like "||example.com/foo.gif" that would match "http://example.com/foo.gif", "https://bar.example.com/foo.gif" but not "http://oneexample.com/foo.gif" or "http://redirect.com/?http://example.com/foo.gif". Sounds like a good generalization of the anchors, would help with the Malware Domains list for example.

Internally, a filter like "||example.com/" would be translated into /^[\w\-]+:\/\/(?:[^\/]+\.)?example\.com\//

Thoughts, opinions?
Last edited by Wladimir Palant on Thu May 07, 2009 12:23 pm, edited 4 times in total.
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Fox » Mon Jan 05, 2009 8:14 pm

I would like that.

Is filter like:
@@||example.com/

Then site whitelisting rule or item whitelisting rule.
Fox
 
Posts: 300
Joined: Sat Jun 10, 2006 3:05 pm
Location: Finland

Postby Wladimir Palant » Mon Jan 05, 2009 8:33 pm

@Fox: Site whitelisting rules should specify $document flag explicitly. It is done automatically for filters starting with http:// but that's mostly for backwards compatibility - I would rather not make it more complicated.
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby MonztA » Mon Jan 05, 2009 8:39 pm

Fox wrote:I would like that.

I second that. :)
MonztA
ABP IT Officer
 
Posts: 3957
Joined: Mon Aug 14, 2006 12:18 am
Location: Germany

Postby Wladimir Palant » Fri Jan 09, 2009 10:07 pm

Just got a mail asking for improvement of the "Disable on foo.com" menu item - it shouldn't require disabling on each subdomain. So maybe add a third option there: "Disable on *.foo.com" that will add the filter "@@||foo.com/$document", what do you think? It should offer disabling on the effective first-level domain meaning *.foo.com if the user is on bar.foo.com and *.foo.co.uk if he is on bar.foo.co.uk.

I dislike adding more options there but this new option really cannot replace any of the existing options.
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Ervin » Wed Jan 21, 2009 12:50 pm

How about |protocol|domain|path? This would even allow subdomain detection. So

Code: Select all
@@|https||


Would unblock any https://* URLs,

Code: Select all
||example.com|


would block any domain and subdomain of example.com, and

Code: Select all
|||*banner*


would block any URL that contains "banner" but not in the domain or protocol.

One thing remains. What if nonstandard port is used like http://www.example.com:8080/index.html
Ervin
 

Postby Ervin » Wed Jan 21, 2009 1:02 pm

Ervin wrote:How about |protocol|domain|path?


Or "|protocol|domain|port|path". That would solve the port problem for an extra pipe.
Ervin
 

Postby Wladimir Palant » Wed Jan 21, 2009 2:17 pm

Ervin, I think you are overcomplicating things now. I don't see a real use case for your suggestion.
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Ervin » Wed Jan 21, 2009 3:06 pm

Wladimir Palant wrote:Ervin, I think you are overcomplicating things now. I don't see a real use case for your suggestion.


Agreed, but I do think this syntax would be much cleaner. If you think in anchors, each pipe character would mean a specific boundary in the URL. Also this is a superset of the original suggestion. But this was just my thought.
Ervin
 

Postby Stupid Head » Sat Jan 24, 2009 9:45 pm

Fox wrote:I would like that.
Me too.
What, me worry?
User avatar
Stupid Head
 
Posts: 214
Joined: Sat Aug 26, 2006 8:11 pm
Location: USA

Postby Ares2 » Fri May 01, 2009 2:39 am

Is this on the ABP 1.1 to-do list? :)
Ares2
 
Posts: 1275
Joined: Fri Feb 15, 2008 1:47 pm

Postby Wladimir Palant » Fri May 01, 2009 1:29 pm

Yes, it is.
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Fox » Fri May 01, 2009 1:38 pm

would it be good idea to have later || too.
later || would mean
: and /
then filter like:
.example.com||
would block these:
.example.com:8080
.example.com:81
.example.com/

But not:
.example.com.au
Fox
 
Posts: 300
Joined: Sat Jun 10, 2006 3:05 pm
Location: Finland

Postby Wladimir Palant » Tue May 05, 2009 8:14 am

Done: http://hg.mozdev.org/adblockplus/rev/cf31fbc930ab

@Fox: Not sure whether this should be done, will think about it.
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Wladimir Palant » Wed May 06, 2009 9:05 am

I was too eager to mark this as "done". There is still work left:

* "Disable on foo.com" should create a filter with flexible anchor
* Filter composer should be able to use flexible anchors (should that be the default for all suggestions?)
* Filter export from preferences should set ABP version to 1.1 if flexible anchors are found

Concerning flexible anchors at the end of the filter, I thought that the following definition would make sense:

foo|| means that "foo" should either be at the end of the address or it should be followed by a separator character. Separator characters are all characters but letters (need to recognize international letters somehow), digits, underscore, period, -, %. So || will be translated into something like:

([^\w\.\-%]|$)

So "||example.com||" will match "http://example.com/foo" and "http://example.com:1234/foo" but not "http://example.company.com/" and not "http://example.com.com/". Similarly "||example.com/foo||" will match "http://example.com/foo" and "http://example.com/foo/bar" but not "http://example.com/foobar".

Opinions?
Wladimir Palant
ABP Developer
 
Posts: 8395
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Next

Return to Adblock Plus development

Who is online

Users browsing this forum: No registered users and 7 guests