adlog

[GµårÐïåñ]

@ GµårÐïåñ.
i'm not throwing a tantrum.(i'm not sure where you got that idea.)
Tom was just arguing with me about something else.plus,he can not see/confirm what i was seeing.therube has confirmed it though.see,i'm not alone on this.
here's proof:
http://img841.imageshack.us/img841/8104/cnetadlog01.jpg
http://img688.imageshack.us/img688/2589/cnetadlog02.jpg
as you can clearly see:noscript is on,the abe rule was in effect,the host file was blocking everything.(including adlog.)
however,adlog still gets through.(believe me,don't believe me.i don't know what to tell you.)
as a hacker for 20+ years you know better than anybody that,"nothing is unhackable."

Correct, nothing is unhackable and tantrum wasn't meant as an insult, just the fevered fury by which one clouds its thinking and not allowing objective analysis in, that's my take on it. Now, the images you provided as proof, simply shows the site TRYING to get a link that is in its code, doesn't mean it succeeded. What you are showing me is simple HTTP requests that are initiated based on code in the site, not a guarantee that they actually fetch ANYTHING. Additionally, keep in mind that someone could ENCODE the image inline to be constructed and produced by the browser, in which case NOTHING (for all intents and purposes) can block its creation. Lots of addons use that method to create their own icons within the CHROME: framework. In those cases, if they are malicious, NS will indeed catch and cripple them but if they are pure image, or without payload, yes they will show up and NS has no reason to interfere with it. There are many factors to consider. I have been too busy to actually hack the page code to see what gives but I would bet my reputation that its one of the things I have listed already. If I can wrangle a free moment today, I will take a more in dept look at the code and try to put your mind at ease.

@ Tom T.
@ Tantrum.you are a funny,funny guy.(who is being insulting now?)
when did i insult you!???
therube has confirmed it,it's there with an abe rule on.(i'm glad you see it now.)
how many times had i told you,"THIS HAS NOTHING TO DO WITH COOKIES.I WAS USING IT AS AN EXAMPLE???"
yet,you keep arguing with me about something else off topic for 2 pages.
@ therube.
again,thank you.

As far was therube has or has not verified, it stands to some dispute as he has mentioned as part of his posts that he has confirmed it and also that he has blocked it, given how he normally posts in narrative and not absolutes (no offense intended) it can stand to reason that although it was "confirmed", it might have been cached, specially that he admitted not having ABE enabled during testing, then enabling it after it has been cached, might be moot already. Best way to verify by him, if willing, would be to clear ALL cache, enable ABE and THEN try to confirm it still shows up and verify by checking page content information for the existence of the media (the image) in the resources, as the only absolute proof its actually there.

EDIT: Again my post came linear in my notification but much has been said since, and seems Giorgio and others have already found the culprit and suggested ways to deal with it. If it works for you, great, then nothing further needed, if not then I will still do my promise to look into it as soon as a free moment presents itself.

[Thrawn]

how many times must i say this:THE DELIVERY METHOD OF ADLOG BYPASSES EVERYTHING,& THEREFORE IT'S A HUGE SECURITY FLAW.

The 'delivery method' in this case is that the site you're actually visiting chooses to embed content. Not request it or link to it, but embed it. If you trust the site, you trust what it chooses to serve. See the relevant section of the FAQ.

mark my words:THIS DELIVERY METHOD WILL BE USED FOR EVIL!!!

Er...OK. The only avenues I can see for serving malicious scripts this way are a) Breaking into the website's servers and altering their page content; b) Persuading the webmaster to include your malware script in their page; or c) Persistent XSS.

NoScript might save you even if one of those happens, especially c), but a) and b) are really out of scope.

it makes no difference if cnet owns adlog.<snip>
it makes no difference if this is an in house promotion/ad.

It makes all the difference. This content was deliberately embedded by the webmaster before the page was ever served to you. It's just an image and a link. It happens to link to adlog, but it could just as easily link to Google. NoScript can neuter it (untrust the top-level site), contain it (with ABE rule), and in general protect you from any danger, but if you want to actually strip out the content of the pages served to you, then you want something like GreaseMonkey.