InformAction Forums

@ralphE:
may I ask you which site was broken for you, exactly?

yes toggling the setting in the about:config noscript.surrogate.enable to false corrected the issue.

the issue still persists in the latest build. instead of reverting to the "disabled" setting after attempting to select a new option it simply reverts to whatever it previously was set. a minor improvement but not fully functional you could say.

Please answer the question of which site was broken exactly so he can see which surrogate could have possibly been the issue. When you confirm the disabling of surrogates fixed your problem, then the site you are using must have triggered one of those surrogates causing your issue. So give him the site so he can find out which relevant surrogate was involved and debug it, otherwise what is he supposed to debug against?

had a similar issue on http://discworld.atuin.net/ where some of the drop-down menu contents vary depending on a cookie value. The restricted items weren't visible with vanilla 2.0.3 until I set noscript.surrogate.enabled to false. It looks like a problem with cookie handling in the surrogate code.

Guest wrote:had a similar issue on http://discworld.atuin.net/ where some of the drop-down menu contents vary depending on a cookie value. The restricted items weren't visible with vanilla 2.0.3 until I set noscript.surrogate.enabled to false. It looks like a problem with cookie handling in the surrogate code.

Can you detail more precisely what's the issue, in terms of "what should happen" and "what actually happens"?

Firstly, sorry about straying off topic. I misread the thread title, and posted a 2.0.3 issue in a 2.0.2.3 thread.

On the discworld site there are some drop-down menus (on the left on the home page). Some of the menu items are available always, but some only show up when logged in to the site. This is controlled by a cookie value. There's a script (discworld.js) which gets loaded with the page, and which contains a function cookieVal. It looks as though this always returns 0 when the surrogates are active, as if it can't find the cookie to get the value from it. Without the surrogate it correctly returns (in my case) 1, and extra menu items appear on the 'Playing' menu.

If you look a bit further down discworld.js you'll see the menus being built with a whole series of statements along the lines of if(cookieVal('Type') >= 0) submenuItem("... . These all work when the test value is 0, so the main script is working ok, but fail when the test is if(cookieVal('Type') >= 1), implying that the problem is local to the cookieVal function.

The result is that on the 'Playing' menu I see the first 5 items (as far down as 'Atlases'), but items from 'Who is Online' downwards don't show up.

Guest wrote:If you look a bit further down discworld.js you'll see the menus being built with a whole series of statements along the lines of if(cookieVal('Type') >= 0) submenuItem("... . These all work when the test value is 0, so the main script is working ok, but fail when the test is if(cookieVal('Type') >= 1), implying that the problem is local to the cookieVal function.

The cookieVal() function is buggy, because it doesn't take in account that document.cookie name-value pairs are actually separate by colon + space ("; "), rather than just colon, and it fails if any cookie is found before the "User" one.
This is the reason way, since NoScript's popunder surrogate injects some cookies in the beginning of the document.cookie string just before it's read (those cookies are never sent to the server, though), cookieVal always fails.

This happens in 2.0.3 only, because previous versions of the surrogate used to append the additional cookies in the trailing position, instead.
I believed the new behavior had more chance to be compatible (if a script adds a cookie with document.cookie="some=thing" and immediately checks it, it always finds it to be the rightmost one), but as this and other reports are demonstrating, I was probably wrong.

Therefore I'm restoring the old behavior (inserting the extra cookies in the beginning) in latest development build.

Thanks,
I've filed a bug report on the script quoting your analysis. I'll try the development build later.

Giorgio Maone wrote:NoScript's popunder surrogate injects some cookies in the beginning of the document.cookie string just before it's read (those cookies are never sent to the server, though)

What is the reason for injecting these cookies? Is there a specific JS library the reads and reacts to them? Why on every page?

al_9x wrote:

Giorgio Maone wrote:NoScript's popunder surrogate injects some cookies in the beginning of the document.cookie string just before it's read (those cookies are never sent to the server, though)

What is the reason for injecting these cookies?

They're checked by many website to tell if they've already opened a popunder: if they "believe" they already have done it, they won't again.

al_9x wrote: Is there a specific JS library the reads and reacts to them? Why on every page?

Nope, the targets are inline scripts, very variable too.
Otherwise the surrogate sources could have been more specific.
However they're not injected on every page, but only on pages loaded through plain HTTP (secure pages are exempted).

Giorgio Maone wrote:

al_9x wrote: Is there a specific JS library the reads and reacts to them? Why on every page?

Nope, the targets are inline scripts, very variable too.
Otherwise the surrogate sources could have been more specific.
However they're not injected on every page, but only on pages loaded through plain HTTP (secure pages are exempted).

If not a lib why would different pages agree on the cookies?

There should be an friendlier/easier way to toggle surrogates, than modifying sources in about:config. What do you think of some UI (list with checkboxes) with maybe a bit of explanation text for each?

al_9x wrote:If not a lib why would different pages agree on the cookies?

I'm not the one you should ask to
However, the cookie names are quite self-explanatory and I'm not surprised are used in more than one place: popunder, popundr and setover18.

al_9x wrote: There should be an friendlier/easier way to toggle surrogates, than modifying sources in about:config. What do you think of some UI (list with checkboxes) with maybe a bit of explanation text for each?

Maybe, but it doesn't seem a priority ATM.

Giorgio Maone wrote:

al_9x wrote:If not a lib why would different pages agree on the cookies?

I'm not the one you should ask to
However, the cookie names are quite self-explanatory and I'm not surprised are used in more than one place: popunder, popundr and setover18.

How many different sites per keyword did you encounter? Why did you decided to do this on every http page? Why not limit it to a know set, at least? The author of a page could have a reasonable expectation of being in full control of the cookies, to the point of not doing any parsing, and expecting "document.cookie === 'test'" to be true after "document.cookie = 'test'" which it is on an otherwise cookieless page without NS. This universal cookie patching does not seem to me a good idea, which is why I was asking for a more convenient way to toggle surrogates.

al_9x wrote:

Giorgio Maone wrote:

al_9x wrote:If not a lib why would different pages agree on the cookies?

I'm not the one you should ask to
However, the cookie names are quite self-explanatory and I'm not surprised are used in more than one place: popunder, popundr and setover18.

How many different sites per keyword did you encounter?

A lot. The whole "livejasmin" porn affiliate network uses variants of the same inlined script with cookies in this range.
Obviously I didn't go after each affiliate site, but had many reports of popunders out of control and most of them belonged to this network.

al_9x wrote:Why did you decided to do this on every http page? Why not limit it to a know set, at least?

Because I can't tell in advance how many website implement this stuff, but it's annoying enough for many NoScript users (the site doesn't work with script off, and when you enable top-level scripts you get a porn popunder on first click). Fortunately, all these sites are served through plain HTTP, and the patching cost is negligible.

al_9x wrote:The author of a page could have a reasonable expectation of being in full control of the cookies, to the point of not doing any parsing, and expecting "document.cookie === 'test'" to be true after "document.cookie = 'test'" which it is on an otherwise cookieless page without NS.

No, it's not a reasonable expectation on public sites.
Cookies may have been turned off by user, e.g. using one of the many extensions with this aim, or extraneous cookies may be injected by a 3rd party (an ad inclusion, a widget, a proxy, or even the ISP).
Furthermore, this setup has been working nicely for at least 9 months now, and the only (rare) breakages happened with latest release because I inverted the patching order (prefixed vs appended). Now that I baked it out I expect things to work nicely again.