InformAction Forums

Posted: **Sun Dec 04, 2011 7:20 am**

Hello, everyone.
I noticed this behavior from several days ago.(with using WebConsole)
NoScript version: 2.2.1
noscript.blockNSWB: true

For instance: http://www.w3schools.com/tags/tag_noscript.asp

Code: Select all

<noscript>
<img src="//me.effectivemeasure.net/em_image" alt="" style="position:absolute; left:-5px;" />
</noscript>

Image is unexpectedly loaded...
Is there anyone who can confirm same behavior?

Posted: **Sun Dec 04, 2011 11:28 am**

I'm not sure I understand both the required steps and the expected result.

1) I go to the site linked. (I'm a bit familiar with w3schools.)
2) I copy your code, and paste it in their "TryIt! Editor", correct?
3) Click "Edit and Click Me"
4) In "Your result" ... I see nothing. What image am I supposed to see?

This is on Fx 3.6.24. I'll check it on Fx 8.01 (you really should update from 8.0) if I have time.
Also, please try latest development build, which is now up to 2.2.3rc4. Let us know if it makes a difference.

You do understand that the "Forbid Web Bugs" option (which is accessible through the GUI, NS Options > Advanced > Untrusted, not just through about:config) is for *untrusted* sites?

If w3 is a trusted site for you, its own images would load. A web bug from an untrusted third party, say, "eviltracker.com", should still be blocked.

Posted: **Sun Dec 04, 2011 12:03 pm**

OK, on Fx 8.01, NS 2.2.3rc4

I did steps 1-4, with w3 default-denied (did not allow scripting). Results window:

Filename missing

Web Console is empty.

Temp-allow w3schools.com. Same as above.

Now, temp-alllow googleadservices.com.
Still no image. Web console lists several "not defined" errors, plus

Code: Select all

 Use of getAttributeNode() is deprecated. Use getAttribute() instead. @ http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_noscript

Now, temp-allow google-analytics.com.
The number of errors in Web Console continues to increase, but no images anywhere.

Viewing "Page Info" does not even *have* a Media tab, as it usually does.

What exactly is this image?
Screenshot?

Posted: **Mon Dec 05, 2011 12:57 am**

Thanks Tom T. for reply & testing, and sorry for my insufficient explanation...

2) I copy your code, and paste it in their "TryIt! Editor", correct?
3) Click "Edit and Click Me"
4) In "Your result" ... I see nothing. What image am I supposed to see?

CODE I pasted was a snippet of the page source.

You do understand that the "Forbid Web Bugs" option (which is accessible through the GUI, NS Options > Advanced > Untrusted, not just through about:config) is for *untrusted* sites?

Yes.

I tested again with that link(http://www.w3schools.com/tags/tag_noscript.asp), but unaccountably, the URL i expected(me.effectivemeasure.net) wasn't appeared in WebConsole.(Why...? There's a bug in Firefox or site ? Weird...)
So, I tested with another site http://mail.yahoo.com/(redirected to https://login.yahoo.com/config/login_verify2?&.src=ym).
In this instance, it reproduce almost certainly. (Reloading, reloading, reloading...)

I also created a new profile and tested with another PC(Firefox 8.0.1, NoScript 2.2.1 & devbuild 2.2.3rc4), but it was same result.
Changed settings from defalut:
NoScript:
1) Deleting all "black text" whitelist without about:blank & about:credits
2) Checking "Forbid Web Bugs" option
Firefox:
1) Unchecking "Accept cookies from sites"
2) Checking "Clear history when Firefox closes"
(Also, I supposed it might be relation with network.prefetch-next pref, but it was not.)

If someone who is kind(like Tom T.) would test again, it's much appricated.

Posted: **Mon Dec 05, 2011 10:04 am**

foobar wrote:Thanks Tom T. for reply & testing, and sorry for my insufficient explanation...

I tested again with that link(http://www.w3schools.com/tags/tag_noscript.asp), but unaccountably, the URL i expected(me.effectivemeasure.net) wasn't appeared in WebConsole.(Why...? There's a bug in Firefox or site ? Weird...)

I never saw any such web site there. Which means that NoScript is protecting you from web bugs, AFAICT.

So, I tested with another site http://mail.yahoo.com/(redirected to https://login.yahoo.com/config/login_verify2?&.src=ym).
In this instance, it reproduce almost certainly. (Reloading, reloading, reloading...)

I use Yahoo mail as my main e-mail, and it always works just fine. For safety's sake, I bookmarked the destination - the login itself, exactly as you had it:

Code: Select all

https://login.yahoo.com/config/login_verify2?&.src=ym

But just now I tried your first link, and it redirects to the secure login page without problem. How is this related to web bugs, anyway?

I also created a new profile and tested with another PC(Firefox 8.0.1, NoScript 2.2.1 & devbuild 2.2.3rc4), but it was same result.
Changed settings from defalut:
NoScript:
1) Deleting all "black text" whitelist without about:blank & about:credits
2) Checking "Forbid Web Bugs" option
Firefox:
1) Unchecking "Accept cookies from sites"
2) Checking "Clear history when Firefox closes"
(Also, I supposed it might be relation with network.prefetch-next pref, but it was not.)

If someone who is kind(like Tom T.) would test again, it's much appricated.

Thanks for the kind words, and I'm happy to donate whatever time can be spared to help NoScript users, but I still don't know what it is I'm looking for, or what I'm supposed to see.

Are we using "web bug" in the same sense? Typically, a *clear* (transparent) image, 1 pixel by 1 pixel, which means you can't see it. So how can I see something invisible? ... Ahh,

you're inferring the existence of the web bug.

If you're inferring it from the Page Source, forget it. Sure, it will try to call it, but with NoScript's protection, it won't be loaded.
If you're inferring it from Web Console, it will probably show as an error, if at all, because the page tried to do something and didn't succeed --*Which is exactly what we want".

There may be a small language barrier, but the "reloading, reloading... " at Yahoo has never happened to me. Exactly what steps must I take to make this happen, and how must I configure Firefox and NoScript to make it happen?

And what other add-ons do you have installed? I don't think there is actually a problem, but we can't diagnose it unless we can see if there is one, and how to make it happen. Please try your best, and I will do the same.

Posted: **Tue Dec 06, 2011 9:30 am**

Sorry for the delay.
Thanks Tom T., and I apologize for bothering you frequently. (It came from not being able to be fluent in English.)

Are we using "web bug" in the same sense? Typically, a *clear* (transparent) image, 1 pixel by 1 pixel, which means you can't see it.

Yes, in same sense.

If you're inferring it from Web Console, it will probably show as an error, if at all, because the page tried to do something and didn't succeed --*Which is exactly what we want".

This is exactly what we want, but "web-bugs" are loaded...

So how can I see something invisible?

With using Web Cosole(Ctrl+Shift+K). Keeping WebCosole opened.

There may be a small language barrier, but the "reloading, reloading..." at Yahoo has never happened to me.

Intended meaning of "Reloading, reloading..." description was manually reloading(Ctrl+R or Ctrl+Shift+R) the page(https://login.yahoo.com/config/login_verify2?&.src=ym)
Three "web bugs" are confirmable on https://login.yahoo.com/config/login_verify2?&.src=ym
Two URLs: begin with https://us.bc.yahoo.com/...
One URL: begin with https://csc.beap.ad.yieldmanager.net/...

And what other add-ons do you have installed?

Add-on I intalled with clean profile was NoScript only. No other add-ons existed except NoScript.

Umm... If my understanding and remembrance is correct, previous version of NoScript could block images within <noscript> element.
(Is this misconception?)
If none of other NoScript users can confirm this behavior, this problem may become unsolved mystery...

Posted: **Tue Dec 06, 2011 11:54 am**

No need to apologize! We have users from all over the world, and we appreciate their best effort to keep this board in the language that is spoken as a first or second language by the largest number of Internet users worldwide, according to statistics. The fact that it is my native language is only an accident of birth.

foobar wrote:Intended meaning of "Reloading, reloading..." description was manually reloading(Ctrl+R or Ctrl+Shift+R) the page

Sorry, I thought that you meant that the page kept reloading by itself. One more misunderstanding cleared.

Three "web bugs" are confirmable on https://login.yahoo.com/config/login_verify2?&.src=ym
Two URLs: begin with https://us.bc.yahoo.com/...
One URL: begin with https://csc.beap.ad.yieldmanager.net/...

Ahhh, OK.
First, what scripting are you allowing at Yahoo? Please remember that web bugs are forbidden (if checked) on Untrusted sites. Is Yahoo trusted or temp-allowed? Is yieldmanager trusted or temp-allowed?

I myself would never receive anything from yieldmanager, as it is blocked in my HOSTS file.

Many users don't like using HOSTS in this way, but another way is with RequestPolicy, which I also use.
The secure login page at Yahoo shows an *attempted* request to yieldmanager, but RP blocks it.
So it doesn't even show in the Web Console or in Page Info > Media.
Probably if I were to disable the Hosts blocking, and allow all in RP, then NS would block it. I'm sorry, that experiment will have to wait for another day.

I do see in Page Source

Code: Select all

<noscript><img width=1 height=1 alt="" src="https://us.bc.yahoo.com/b?P=li30I[snip]3d1"></noscript>

But all this is doing is telling a sub-domain of yahoo.com that I am logging in, or logged in, to another sub-domain. They would probably know this already.

It only becomes a "web bug" if I visit another domain -- say, Facebook (I never do!), and *it plants the Yahoo bug as well". Now Yahoo knows that I am on Facebook, and probably a lot more -- which pages I visit, etc. This would require more experimentation -- perhaps you can try it.

The real evil one here is yieldmanager.net. That is a third party that many sites will try to run script from, and perhaps allow to plant web bugs. Then yieldmanager itself can track you across every site that allows it.

The only scripts required for Yahoo mail are
mail.yahoo.com
mail.yimg.com

So please add those to your whitelist, and try marking Yahoo.com as Untrusted. Yes, you can still log in!
Do you still get the yieldmanager bug?

Umm... If my understanding and remembrance is correct, previous version of NoScript could block images within <noscript> element.
(Is this misconception?)

IIUC, they sort of do. They did, and still do, forbid META redirection, and hide elements inside <noscript> if you so choose. Most of those things inside the <noscript> elements are those annoying messages, "Your browser does not support JavaScript. Please enable it... blah, blah" This could be text or an image, but from the same domain. Third-party web-bug images really should be blocked by NoScript, as you said, on untrusted sites.

If none of other NoScript users can confirm this behavior, this problem may become unsolved mystery...

Unfortunately, I prefer to stay on the Firefox 3.6.x branch, and use 8.x only for testing and diagnostics. So some of the details are still a bit new.
Also unfortunately, I'm out of time.

If anyone else can reproduce the failure to block web bugs on untrusted with Fx 8.0 or 8.01, and latest NS, please jump in!
I will check back in a day or two. But one way or another, it won't be unsolved for long.

Posted: **Tue Dec 06, 2011 3:04 pm**

foobar wrote: Umm... If my understanding and remembrance is correct, previous version of NoScript could block images within <noscript> element.

Your understanding is correct, and NoScript is still capable to do that.
Unfortunately, recent Firefox versions are unable to support it because of this feature, which cannot apparently be disabled either.

I'll probably remove "Forbid Web Bugs" entirely from next dev build, since there's currently no way to implement it reliably.
Anyway I always thought it was kind of fragile and not entirely "on topic" with NoScript's focus, which is security rather than privacy.

Posted: **Thu Dec 08, 2011 9:57 am**

Giorgio Maone wrote:
foobar wrote: Umm... If my understanding and remembrance is correct, previous version of NoScript could block images within <noscript> element.
Your understanding is correct, and NoScript is still capable to do that.
Unfortunately, recent Firefox versions are unable to support it because of this feature, which cannot apparently be disabled either.

IIUC, you've given me yet another reason (the 159th? losing count) to stay on Fx 3.6.x as long as possible, as discussed in this other thread. (both before and after the linked post, but no need to read the whole thread, if at all.)

Giorgio Maone wrote:I'll probably remove "Forbid Web Bugs" entirely from next dev build, since there's currently no way to implement it reliably.

False sense of security (or privacy) is worse than no security ... thanks for the revelation.

Giorgio Maone wrote:Anyway I always thought it was kind of fragile and not entirely "on topic" with NoScript's focus, which is security rather than privacy.

Another reason to use also RequestPolicy, no?

(perhaps a mention in NoScript FAQ and/or NoScript "Features" Page, since it's important to understand a tool's limitations as well as its capabilities? suggesting the combo, while emphasizing what's said above: NS focuses on security; for additional privacy protection, consider RP. perhaps it adds add'l CSRF protection also? -- but the novice who can tackle only one of the two needs to know that NS is the absolute first priority. more advanced users will appreciate the info and the combo. just another humble opinion.)

Posted: **Thu Dec 08, 2011 5:04 pm**

Sorry for the delay again...

Tom T. wrote:No need to apologize! We have users from all over the world, and we appreciate their best effort to keep this board in the language that is spoken as a first or second language by the largest number of Internet users worldwide, according to statistics. The fact that it is my native language is only an accident of birth.

What a generous-hearted person, you are... Thank you for warming my heart.

Giorgio Maone wrote:Your understanding is correct, and NoScript is still capable to do that.
Unfortunately, recent Firefox versions are unable to support it because of this feature, which cannot apparently be disabled either.

Thank you for clarification. I see, there was a reason for that.
Finally, my question has cleared up! As Tom T. said "it won't be unsolved for long..".

Giorgio Maone wrote:I'll probably remove "Forbid Web Bugs" entirely from next dev build, since there's currently no way to implement it reliably.
Anyway I always thought it was kind of fragile and not entirely "on topic" with NoScript's focus, which is security rather than privacy.

Indeed, this conclusion makes sense.
Advantage of "Web bugs" feature pales compared to main security feature of NoScript. (But I feel a bit of regret...)
Maybe alternative tool will be necessary for that purpose.
(For example, add-on like Karma Blocker, or content-filtering local proxy like Privoxy? I'm not sure exactly whether these are capable.)
However, I'll continue using NoScript. I regard NoScript is worth it.

Thanks Tom T. & Mr.Maone! It was a great help.
Deep appreciation

Posted: **Fri Dec 09, 2011 9:30 am**

foobar wrote:Indeed, this conclusion makes sense.
Advantage of "Web bugs" feature pales compared to main security feature of NoScript. (But I feel a bit of regret...)
Maybe alternative tool will be necessary for that purpose.
(For example, add-on like Karma Blocker, or content-filtering local proxy like Privoxy? I'm not sure exactly whether these are capable.)
However, I'll continue using NoScript. I regard NoScript is worth it.

Please see my reply to Mr. Maone's post above:

Giorgio Maone wrote:Anyway I always thought it was kind of fragile and not entirely "on topic" with NoScript's focus, which is security rather than privacy.

Tom T. wrote:Another reason to use also RequestPolicy, no?

foobar, I respectfully encourage you to consider RequestPolicy add-on. It does not compete with NoScript, as its developer will tell you; rather, it blocks *all* requests from one site to another, regardless of whether they are executable (scripting, Flash, etc.) or non-executable (1-pixel still image .gif "web-bug"). You may allow selectively to or from any given source or destination. So if you are at goodsite.com, and RP's flag is red, open its menu and see request from goodsite.com to yieldmanger.net. Of course, you will not allow it.

To the best of my knowledge, this, combined with blocking all 3rd-party scripting via NS, defeats all third-party web bugs, as they have been defined in this discussion.

A Google cookie (for example), can still be used as a tracker if other sites allow Google to read it. (That's an oversimplification, but good enough for our purposes.) So the cookies you *do* allow should be for "session only", then either close and restart the browser, or clear all stored items with Ctrl -Shift - Delete before going to another site. (And cookies are not required for Google searches, anyway.)

Thanks Tom T. & Mr.Maone! It was a great help.
Deep appreciation

You're very welcome. And we both learned something ugly -- that Mozilla is cutting Mr. Maone's feet out from under him.

I think I will stay on Fx 3.6.x. IMHO. YMMV.

Cheers.

InformAction Forums

Regression of "Forbid Web Bugs" feature?

Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?

Re: Regression of "Forbid Web Bugs" feature?