[Done] Site-specific filters

Various discussions related to Adblock Plus development

[Done] Site-specific filters

Postby Wladimir Palant » Mon Dec 15, 2008 9:22 am

This feature is requested from time to time: making sure a filter applies only on some sites. So here a proposal on how this could be implemented:

foo.com/ad$domain=foo.com|bar.com|~baz.bar.com

This will block anything matching "foo.com/ad" on www.foo.com or www.bar.com but not on baz.bar.com and not on www.baz.com.

Frames would be handled the same as with $third-party (or element hiding rules): if the site contains frames, the relevant domain is the domain of the frame the element is in, not the domain of the top page. That's less obvious to the user, to compensate the composer should have a "Restrict to domain" checkbox under "First/third-party only", if checked you can edit the domain in a text field (pre-filled with the current domain minus "www.").

I would like to follow the syntax of element hiding rules but comma is already reserved as an option separator which is too bad.

Opinions? Suggestions?
Last edited by Wladimir Palant on Sun Dec 21, 2008 7:31 am, edited 1 time in total.
Wladimir Palant
ABP Developer
 
Posts: 8398
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby fanboy » Mon Dec 15, 2008 12:21 pm

I'd prefer an new addon (maybe seperate the element hider), that filters javascript, ability to stop javascript functions from loading without whitelisting.

This would be more benefit, better than a site-specific filter feature, stops these hacks attempting to detect adp+.
User avatar
fanboy
 
Posts: 3446
Joined: Sun Jun 17, 2007 4:45 am

Postby Wladimir Palant » Mon Dec 15, 2008 1:09 pm

Fanboy, that would also require a far larger effort (not to mention that I don't have any good ideas on how this would work). What I propose here can be even implemented in Adblock Plus 1.0.1 - it is fairly straightforward now that we have $third-party. Really, "but I would rather have a pony" isn't helpful.
Wladimir Palant
ABP Developer
 
Posts: 8398
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Dr. Evil » Mon Dec 15, 2008 3:57 pm

I think this would be great, especially for whitelists.

But maybe some spaces could improve readability?
Code: Select all
example.org/someads/* on *.example.com or *.example.net
@@example.org/someads/*$object_subrequest on foo.example.net

(Spaces have been forbidden since the old adblock, but with the filters stored in patterns.ini I don't see a problem in breaking this convention...)
Dr. Evil
 
Posts: 194
Joined: Fri Sep 08, 2006 3:51 pm

Postby Wladimir Palant » Mon Dec 15, 2008 4:08 pm

Spaces are not a problem (comments have spaces, as do element hiding rules in the raw CSS part). Only reason they are still being removed - it helps recognizing identical filters as actually identical.

But I wouldn't want to introduce an entirely new syntax (and especially a language-dependent one). We already have options to extend the syntax, I would rather use them.
Wladimir Palant
ABP Developer
 
Posts: 8398
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby rick752 » Mon Dec 15, 2008 4:39 pm

The whole idea sounds great, Wladimir. :D

Looking for to its implementation. That syntax works for me.
User avatar
rick752
 
Posts: 2709
Joined: Fri Jun 09, 2006 7:59 pm
Location: New York USA

Re: Opinions requested: Site-specific filters

Postby Adblock Plus Fan » Mon Dec 15, 2008 5:00 pm

Wladimir Palant wrote:|~baz.bar.com

This is an excellent idea Wladimir. This kind of pseudo whitelisting is even better normal whitelisting.
With this kind of capability, small sites will no longer be able to take otherwise good filters as hostage. And we won't have to give them privileges of having real whitelists.
User avatar
Adblock Plus Fan
 
Posts: 1255
Joined: Sat Feb 24, 2007 12:08 pm

Postby rick752 » Mon Dec 15, 2008 5:51 pm

Actually, a whitelisting would not even be necessary as you could just add "not" domains to the offending false-positive rule.

Code: Select all
google-analytics$domain=~a.com|~b.com|~c.com

Wouldn't this work as a general blocking rule but with its own built-in domain exceptions, Wladimir?
Last edited by rick752 on Mon Dec 15, 2008 6:00 pm, edited 1 time in total.
User avatar
rick752
 
Posts: 2709
Joined: Fri Jun 09, 2006 7:59 pm
Location: New York USA

Postby Wladimir Palant » Mon Dec 15, 2008 5:56 pm

@Rick: Yes, that was the idea that you could use it like this.
Wladimir Palant
ABP Developer
 
Posts: 8398
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby rick752 » Mon Dec 15, 2008 6:01 pm

That is AWESOME, Wladimir!
:D
User avatar
rick752
 
Posts: 2709
Joined: Fri Jun 09, 2006 7:59 pm
Location: New York USA

Postby Adblock Plus Fan » Mon Dec 15, 2008 7:07 pm

Dr. Evil wrote:I think this would be great, especially for whitelists.
Indeed, especially for users who have the filter
*$third-party,script
When adding whitelists for broken sites, this restriction capability makes ABP clearly the best tool to block 3rd party scripts now.


rick752 wrote:Actually, a whitelisting would not even be necessary
Yep that's what I meant Rick, you can pretty much clear all of your real whitelists from Easylist now and leave them entirely to users. No more complaints from them :P
User avatar
Adblock Plus Fan
 
Posts: 1255
Joined: Sat Feb 24, 2007 12:08 pm

Postby Dipole Moment » Tue Dec 16, 2008 2:34 am

Wladimir Palant wrote:Spaces are not a problem (comments have spaces, as do element hiding rules in the raw CSS part). Only reason they are still being removed - it helps recognizing identical filters as actually identical.

But I wouldn't want to introduce an entirely new syntax (and especially a language-dependent one). We already have options to extend the syntax, I would rather use them.


I think it's probably necessary at this point to devise a proper generalization of the filter syntax, rather than make a series of ad-hoc changes that could become cumbersome later on. I agree DE's suggestion is too language-specific, but it still seems rather awkward to cram all this into a $tag.

Even if it can't all get implemented at one go, what is needed is a syntax that can accommodate
  • match-url vs match-domain perhaps something like {foo.bar} vs foo.bar
  • page-restricted application as above eg
    Code: Select all
    {foo.org} || /bar.asp$/ >> /quux.js$/
  • future content-filtering (and modifying?) capability. This is a bit trickier given the potential for truly mammoth filters. Long-string arguments should be well-distinguished and probably kept to the end for readability's sake.
Dipole Moment
 

Postby Dipole Moment » Tue Dec 16, 2008 2:38 am

Obviously I meant foo.bar vs {foo.bar} :oops:
Dipole Moment
 

Postby Wladimir Palant » Tue Dec 16, 2008 10:57 am

That's what $tag is meant for - so that things can be crammed into it without revising the filter syntax every time.
Wladimir Palant
ABP Developer
 
Posts: 8398
Joined: Fri Jun 09, 2006 6:59 pm
Location: Cologne, Germany

Postby Adblock Plus Fan » Tue Dec 16, 2008 5:14 pm

Dipole Moment wrote:match-url
Code: Select all
{foo.org} || /bar.asp$/ >> /quux.js$/

You're thinking very far ahead there with regexp usage for url restriction, it's uncertain if we will even have this url restriction feature ever. But in the event that we get this feature, I don't see what's so bad about simply extending the current syntax.
Code: Select all
/quux.js$/$domain=foo.org,url=/bar.asp$/

Something like this should pretty much match your filter. And it looks less confusing in my opinion.

For now, domain restriction looks like it's enough to fit our needs.

Wladimir Palant wrote:I would like to follow the syntax of element hiding rules but comma is already reserved as an option separator which is too bad.
Is it realistic that we get a foo.com/ad$url= capability in the future?

If it is, then it may be better to reserve the pipe symbol for marking the end/beginning of the url restriction.

I don't know, maybe.
User avatar
Adblock Plus Fan
 
Posts: 1255
Joined: Sat Feb 24, 2007 12:08 pm

Next

Return to Adblock Plus development

Who is online

Users browsing this forum: No registered users and 1 guest