Hope you don't mind me asking but I'm just curious why you have a list of filters like:
/ads/*.asp
/ads/*.gif|
/ads/*.htm
...
Is that because '/ads/*' causes some false positives?
Question about filters
Yes they do ... the problem is mostly for different video feeds, especially different news one that run the "/ads/" string within the initiation code. The specific problem mostly lies in */realmedia/ads/* strings which cannot always be blocked for this reason because it contains */ads/*. It was a little tricky working around it with simple filters. I was debating about creating a single regexp for them but came under fire from my 'team' for even suggestion such a thing. They like the 'simples'. But some new 'switches' in ABP should allow me to re-write the filters to be more specific.Anonymous wrote:Hope you don't mind me asking but I'm just curious why you have a list of filters like:
/ads/*.asp
/ads/*.gif|
/ads/*.htm
...
Is that because '/ads/*' causes some false positives?
I am just now testing a way to fix the way they are written in my filters so there aren't as many */ads/* strings in there
"Experience is something you don't get until just after you need it"
Guilty, but I wouldn't have hunted you down or anythingrick752 wrote:I was debating about creating a single regexp for them but came under fire from my 'team' for even suggestion such a thing. They like the 'simples'.
Nice to know you may fine a way around it. You and WP are workaholics.
Yes Dogg ... I think we both drink a lot and then workIceDogg wrote:Guilty, but I wouldn't have hunted you down or anythingrick752 wrote:I was debating about creating a single regexp for them but came under fire from my 'team' for even suggestion such a thing. They like the 'simples'.
Nice to know you may fine a way around it. You and WP are workaholics.
"Experience is something you don't get until just after you need it"
It is because of starting to use some of the new syntaxes that I am now going to stop supporting versions of Adblock/Adblock Plus earlier than 0.7.1.IceDogg wrote: Nice to know you may find a way around it.
(That ought to go over like a fart in church, hey?)
I'm adding it to the forum now. Might as well ... getting a free hour of time tonite.
"Experience is something you don't get until just after you need it"
-
- Guest
Oh you mean like:rick752 wrote:I am just now testing a way to fix the way they are written in my filters so there aren't as many */ads/* strings in there
/ads/*$~object
Never new about those switches.
Exactly:
I'm testing:
*/ads/*$images
to replace the gif, jpg, and png ones first. Haven't tried any of these new syntaxes yet, but one of my team suggested using one of those to fix a false-positive. Now I'm taking a look at the whole thing to see if there are more uses for those.
I'm testing:
*/ads/*$images
to replace the gif, jpg, and png ones first. Haven't tried any of these new syntaxes yet, but one of my team suggested using one of those to fix a false-positive. Now I'm taking a look at the whole thing to see if there are more uses for those.
"Experience is something you don't get until just after you need it"
To add even more info for you guys, it seems that */banners/* was blocking the background of the top logo area of weather.com.
Stupid Head suggested using:
Using a tilda (~) before the syntax 'identifier' removes that item from the block ... it means "except".
So basically what it says is, "Block everything with */banners/* , EXCEPT if it is a background.
If you don't use the tilda, then it says, "Block */banners/* only if it IS a background.
My problem and curiosity right now is what these syntaxes will actually block ... or actually allow. Will a $script kill media .. or flash? Does the $image syntax remove png besides gifs and jpegs? And after testing a little, the "~background" is NOT like a whitelist string... it will be overridden by another filter block that matches up to that same 'background' image.
And what in hell did I make each filter string of mine to block? ... images, scripting, objects? .... I don't know!
Work, work, work
Stupid Head suggested using:
Code: Select all
*/banners/*$~background
So basically what it says is, "Block everything with */banners/* , EXCEPT if it is a background.
If you don't use the tilda, then it says, "Block */banners/* only if it IS a background.
My problem and curiosity right now is what these syntaxes will actually block ... or actually allow. Will a $script kill media .. or flash? Does the $image syntax remove png besides gifs and jpegs? And after testing a little, the "~background" is NOT like a whitelist string... it will be overridden by another filter block that matches up to that same 'background' image.
And what in hell did I make each filter string of mine to block? ... images, scripting, objects? .... I don't know!
Work, work, work
"Experience is something you don't get until just after you need it"
-
- Guest
The easiest way to tell is open up the blockable items window, next to the link the type is specified. For example flash and media are usually listed as 'Objects' so $script would not block them.rick752 wrote:Will a $script kill media .. or flash? Does the $image syntax remove png besides gifs and jpegs?
-
- Guest
Wouldn't the object link be something different from the script that loaded it? But I see what you mean you do need to be careful.
You should talk to Wladimir about creating a database where known ad links can be added and common false positives too. Then to paste filters to be checked against them. It would be an easy way to test your filter set after making a change to prevent blocking something you already fixed previously.
You should talk to Wladimir about creating a database where known ad links can be added and common false positives too. Then to paste filters to be checked against them. It would be an easy way to test your filter set after making a change to prevent blocking something you already fixed previously.
@ Guest:
Why don't you just register here? It's easier to post and get notified that way. You obviously have an interest in this.
I enjoy listening to anyone who brings "anything to the table" here. All points are well taken in this forum and we do not have trolls here. This forum is very laid back with very good people.
Why don't you just register here? It's easier to post and get notified that way. You obviously have an interest in this.
I enjoy listening to anyone who brings "anything to the table" here. All points are well taken in this forum and we do not have trolls here. This forum is very laid back with very good people.
"Experience is something you don't get until just after you need it"
What I'm saying is that people would create (say) a block using the $script syntax. The next thing you know, they are complaining about not being to see a flash video because the script actually initiated that too.Anonymous wrote:Wouldn't the object link be something different from the script that loaded it? But I see what you mean you do need to be careful.
You should talk to Wladimir about creating a database where known ad links can be added and common false positives too. Then to paste filters to be checked against them. It would be an easy way to test your filter set after making a change to prevent blocking something you already fixed previously.
Wladimir has been talking about finally starting his "global database" that he has been talking to me about for months. ABP may just be ready to handle it now.
This would definitely change a lot of things as far as filter-making goes.
"Experience is something you don't get until just after you need it"
-
- Guest
Thanx for the kudos.Anonymous Coward wrote:Is this "global database" related to his plan for "Automatic filter generation" in Adblock Plus 0.8? Anyway keep up the good work.
Sometimes I think that Wladimir is waiting to see where the program takes HIM ... and not so much the other way around. He has a direction but then he'll have a breakthrough and then ..... ??????
"Experience is something you don't get until just after you need it"