[RESOLVED] Dictionary.com website question related to NS

[Thrawn]

Anyway, it's probably not a matter of where the Google Tag Manager surrogate is applied, but rather, its contents may not be enough in this case. Barbaz, do you think that we can replicate CrowdControl's extension?

[barbaz]

Barbaz, do you think that we can replicate CrowdControl's extension?

I tried, but once I implemented what was used by this portion of the page code to a certain extent, it stopped recognizing any of it - the error message became the same as without any surrogate, and there was no error in the surrogate.

[Thrawn]

Or is it possible that the real functionality of Google Tag Services is needed for this?

I ask because what you're clicking on is a link to an MP3, so the default behavior would be the 'bug' you're describing: navigating to the URL of the object and downloading/playing it there. I think that playing it on the same page is an extra feature that is being provided by the scripts that are being blocked.

[barbaz]

Or is it possible that the real functionality of Google Tag Services is needed for this?

No it's not

I think that playing it on the same page is an extra feature that is being provided by the scripts that are being blocked.

I don't think so; in any case, some of the other NoScript surrogates do provide minimal shims for the features in the blocked scripts if it doesn't require too much code and/or effort to do so.

[barbaz]

I tried, but once I implemented what was used by this portion of the page code to a certain extent, it stopped recognizing any of it - the error message became the same as without any surrogate, and there was no error in the surrogate.

Just remembered NoScript's awkward default behavior for writing surrogates... I forgot to turn on surrogate.debug

[barbaz]

@lakrsrool & Thrawn: see PM
(I'm open to more elegant suggestions...)

[lakrsrool]

@lakrsrool & Thrawn: see PM
(I'm open to more elegant suggestions...)

Your first suggestion (set of code) did the trick, Dictionary.com now works as intended without having to allow "googletagservices.com". Great job barbaz!!!

For the record, I'm assuming that as long as one add-on, in this case NoScript, is blocking "googletagservice.com" then this will take care of the privacy and security concerns in this case, am I correct in this regard? (it makes sense that if one add-on is blocking the site then this accomplishes the task and it doesn't matter at that point as far as what any other add-ons might happen to be doing, see below for more specifics).

I ask this because if not, then it ultimately does no good if either of the two other add-ons (in this case, Disconnect and/or Avast On-line Security) happen to be undoing what NoScript is successfully not allowing.

[barbaz]

Cool!
I'll forward that to Giorgio.

For the record, I'm assuming that as long as one add-on, in this case NoScript, is blocking "googletagservice.com" then this will take care of the privacy and security concerns in this case, am I correct in this regard? (it makes sense that if one add-on is blocking the site then this accomplishes the task and it doesn't matter at that point as far as what any other add-ons happen to be doing, see below for more specifics).

I ask this because if not then it does no good if either of the two other add-ons (in this case, Disconnect and/or Avast On-line Security) are undoing what NoScript is successfully not allowing.

Yes, what one addon blocks another won't allow in such a way the "blocking" addon is overridden (unless you're dealing with a malicious or REALLY badly designed addon).

Note however that as NoScript is a security tool not a privacy tool, you still need to run Disconnect/Avast/etc to really block googletagservices.com; by default NoScript will ignore images and other non-active content, letting it through and thus not fully protecting your privacy.

[lakrsrool]

Cool!

For the record, I'm assuming that as long as one add-on, in this case NoScript, is blocking "googletagservice.com" then this will take care of the privacy and security concerns in this case, am I correct in this regard? (it makes sense that if one add-on is blocking the site then this accomplishes the task and it doesn't matter at that point as far as what any other add-ons happen to be doing, see below for more specifics).

I ask this because if not then it does no good if either of the two other add-ons (in this case, Disconnect and/or Avast On-line Security) are undoing what NoScript is successfully not allowing.

Yes, what one addon blocks another won't allow in such a way the "blocking" addon is overridden (unless you're dealing with a malicious or REALLY badly designed addon).

Note however that as NoScript is a security tool not a privacy tool, you still need to run Disconnect/Avast/etc to really block googletagservices.com; by default NoScript will ignore images and other non-active content, letting it through and thus not fully protecting your privacy.

Yep, that's what I figured regarding any other add-on..... but then.... Hmmm, I was about to post back that both Disconnect and Avast have to "not block Google" and "Allow ad tracking", respectively (which is why I joked about you're needing to fix the other two add-ons). , however upon testing once again to make sure this remained the case I am now finding that I am able to both block "Google" in Disconnect and also block "add tracking" in Avast and this specific issue does not return regarding the "Dictionary.com" website. I had originally posted the opposite scenario at the start of this topic thread that both add-ons had to be "disabled". so to speak .in regards to "google" for this website in order to have the website work properly. Apparently you've fixed all the add-ons in one fell swoop , seriously I'm a bit confused since it seems to me that I do recall that all add-ons had to be addressed previously, oh well as long as it works and with the added bonus that the other two add-ons are providing the added security as well is that much better.

Thanks a lot for the help.

[barbaz]

Apparently you've fixed all the add-ons in one fell swoop , seriously I'm a bit confused since it seems to me that I do recall that all add-ons had to be addressed previously, oh well as long as it works and with the added bonus that the other two add-ons are providing the added security as well is that much better.

All as expected:

+ [Surrogate] External script surrogates are now triggered whenever a
matching script fails to load, no matter the reason, e.g. NoScript
permissions, ABE, ABP or RequestPolicy (thanks bonanza for RFE)

Thanks a lot for the help.

You're welcome

[Thrawn]

Apparently you've fixed all the add-ons in one fell swoop , seriously I'm a bit confused since it seems to me that I do recall that all add-ons had to be addressed previously,

The explanation lies in the way surrogates work. The idea of them is that the site stays blocked, but NoScript runs a little piece of user-controlled script instead, designed to create an illusion that the site was allowed. The illusion doesn't actually do anything, except prevent a poorly-designed page from crashing.

So, it doesn't matter exactly what blocked the site. Script-blocking, ABE, Disconnect, regardless. The important thing is, NoScript recognises that the site wanted to run a script, and that the script didn't actually run, so it runs the surrogate and fixes the page.

@Barbaz, the googletagmanager surrogate that you sent me works for me, without needing crwdcntrl.net

[lakrsrool]

Apparently you've fixed all the add-ons in one fell swoop , seriously I'm a bit confused since it seems to me that I do recall that all add-ons had to be addressed previously,

The explanation lies in the way surrogates work. The idea of them is that the site stays blocked, but NoScript runs a little piece of user-controlled script instead, designed to create an illusion that the site was allowed. The illusion doesn't actually do anything, except prevent a poorly-designed page from crashing.

So, it doesn't matter exactly what blocked the site. Script-blocking, ABE, Disconnect, regardless. The important thing is, NoScript recognises that the site wanted to run a script, and that the script didn't actually run, so it runs the surrogate and fixes the page.

Where I'm confused is that while NoScript runs a "surrogate" script so that the site performs as if there is nothing blocking it, so to speak, and works as expected as a result. On the other hand however it is my understanding that neither Disconnect nor Avast runs a "surrogate" script to do their job but rather both simply blocks in this case "Google" altogether in regards to Disconnect and in the case of Avast blocks Google "add tracking" altogether which is why as I recall I had experienced the need to "disable" the blocking in both Disconnect and Avast regarding "Google" and Google "add tracking", respectively, to get the Dictionary.com web site to work properly.

However while I would expect both Disconnect and Avast to still require disabling their respective settings as was the case before for the website in question for some reason now that the Noscript surrogate script allows Dictionary.com to work properly without the need to actually "Allow googletagservices.com", coincidentally I find that neither of these other two other add-ons have any further need to disable the blocking that is done by their respective application on the website in question which again is what is confusing to me as to how this has changed in regards to these other two add-ons. But as I said, the fact the website now works properly and the protection is retained as well in regards to all add-ons involved thankfully (which I'm considering a bonus really), I've got no complaints. (or perhaps I'm not understanding how the other two add-ons work )

[Thrawn]

It doesn't matter whether the other two addons are blocking the site. NoScript provides a surrogate that does everything necessary for the page to work.

[barbaz]

@lakrsrool: The suggested change is now part of NoScript

[Thrawn]

However while I would expect both Disconnect and Avast to still require disabling their respective settings as was the case before for the website in question for some reason now that the Noscript surrogate script allows Dictionary.com to work properly without the need to actually "Allow googletagservices.com", coincidentally I find that neither of these other two other add-ons have any further need to disable the blocking that is done by their respective application on the website in question which again is what is confusing to me as to how this has changed in regards to these other two add-ons. But as I said, the fact the website now works properly and the protection is retained as well in regards to all add-ons involved thankfully (which I'm considering a bonus really), I've got no complaints. (or perhaps I'm not understanding how the other two add-ons work )

Imagine the blocked piece of script as a bridge over a river. If anything breaks down that bridge - whether it's NoScript, or Disconnect, or Ghostery, or ABP, or anything else - once the bridge is gone, anything that tries to cross will fall in. So, ordinarily you would need to tell each of those tools to leave it alone, and once they all do, the bridge stays intact and the site can cross and do whatever it does.

Now, a surrogate script takes away the need to do that. Imagine it as a man sitting in a booth at the river, who spots incoming travellers, turns them around, and modifies their memories so they *think* they crossed the river and transacted business on the other side. In reality, they don't go anywhere. So, Disconnect and Ghostery and NoScript can burn the bridge to ashes and it doesn't matter.

Of course, if the site was going to do something important on the other side of the river, then that may not be adequate; it may still be broken. It's possible to write surrogates to perform real work, but that's not the usual case. Normally they just give the page false information and send it on its way.