Page 1 of 1

Though Google is blocked still a connection to a Google-IP

Posted: Wed Feb 13, 2013 6:23 am
by bege
Hi,

on www.domaintools.com Addblock Plus shows three Google entries:

ajax.googleapis.com
apis.google.com
www.google-analytics.com

All these entries are scripts and are blocked by NoScirpt. The IP of www.domaintools.com is 198.78.208.254.
Nevertheless there is a connection to 173.194.44.X (last number varies), which is a Google IP muc03s07-in-f5.1e100.net

Please, can anybody tell me why there is a connection to the Google IP when loading the domaintools page?
Thank you very much.
Regards

Re: Though Google is blocked still a connection to a Google-

Posted: Wed Feb 13, 2013 10:27 am
by Thrawn
NoScript does not block all cross-site requests. For that, you want RequestPolicy.

If there is an image tag, or a stylesheet, or some other non-active content hosted at that address, then NoScript will not block it. NoScript only cares about active content.

Re: Though Google is blocked still a connection to a Google-

Posted: Wed Feb 13, 2013 2:15 pm
by bege
Thrawn wrote:NoScript does not block all cross-site requests. For that, you want RequestPolicy.

If there is an image tag, or a stylesheet, or some other non-active content hosted at that address, then NoScript will not block it. NoScript only cares about active content.
Thank you very much.
Though there is no other but active content from Google Sites, I understand that e.g. an allowed script from domaintools.com can call a Google URL. Is that correct? The domains that NoScript blocks are scripts OF that domain, not such scripts that come from an allowed domain and connect TO a not whitelisted domain? But isn't that exactly what the defense of cross-site-scripting should block? However, Google is allowed for XSS by default.
I am not sure whether I correctly understand the difference between the XSS protection of NoScript and that of RequestPolicy. As far as I understood NoScript protects only against domains that have been set as untrusted.
Unbelievable how complex it is to achieve privacy.
Regards

Edit after installing RequestPolicy: Does RequestPolicy replace the ABE-rules of NoScript?

Well, now it's getting even more complicated:
logging in on secure.domaintools.com is possible with google-analytics.com blocked in NoScript and RequestPolicy not installed. As soon as RequestPolicy is installed, logging in is not possible until google-analytics.com is allowed in either RequestPolicy or NoScript. That doesn't make sense to me.
If it is blocked by NoScript, why does it make a difference if it is allowed in RequestPolicy? It is blocked! Or not?
Why is it enough to allow it in either extension? Does the other one block google-analytics.com not reliably?
:?:
:? Thanks for lighting up my confusion.

Re: Though Google is blocked still a connection to a Google-

Posted: Wed Feb 13, 2013 11:25 pm
by Thrawn
bege wrote:
Thrawn wrote:NoScript does not block all cross-site requests. For that, you want RequestPolicy.

If there is an image tag, or a stylesheet, or some other non-active content hosted at that address, then NoScript will not block it. NoScript only cares about active content.
Thank you very much.
Though there is no other but active content from Google Sites, I understand that e.g. an allowed script from domaintools.com can call a Google URL. Is that correct? The domains that NoScript blocks are scripts OF that domain, not such scripts that come from an allowed domain and connect TO a not whitelisted domain?
It depends. If a whitelisted script attempts to download active content from a non-whitelisted domain, then NoScript will block it. But if it requests non-active content, NoScript will allow it.
But isn't that exactly what the defense of cross-site-scripting should block?
Not at all! Cross-site scripting doesn't mean 'calling scripts from other domains'. It means 'sending carefully-crafted requests that inject scripts into pages on other domains, so that those scripts bypass the same-origin policy restriction and run with the privileges of the other domains'. Eg 'evil.com' could inject its own script into 'bank.com', so that it could then perform any operation it wanted at bank.com, reading your session cookie at bank.com (if you happen to be logged in) and impersonating you to transfer money etc.

Calling scripts that are hosted on other domains is normal. XSS, on the other hand, is an attack.
I am not sure whether I correctly understand the difference between the XSS protection of NoScript and that of RequestPolicy.
NoScript's XSS filter attempts to detect the carefully-crafted requests that are used to inject scripts, and sanitise them so that they won't work.

RequestPolicy blocks all cross-site requests, harmful or not, until you've decided to trust them. The philosophy is similar to NoScript, but whereas NoScript focuses on active content, including on the site you visited, RequestPolicy focuses on cross-site requests, active or not.
As far as I understood NoScript protects only against domains that have been set as untrusted.
No, everything is blocked by default. Specifically marking a site as untrusted is mostly cosmetic: it hides sites from the menu if you're sure you'll never want to trust them. The only difference is if you use blacklist mode, 'Scripts Globally Allowed', which is not recommended. 'Untrusted' sites will still be blocked when in this mode.
Unbelievable how complex it is to achieve privacy.
Yeah, the internet is like that...privacy is not the default. I'm primarily concerned about security, with privacy being a desirable second.
Edit after installing RequestPolicy: Does RequestPolicy replace the ABE-rules of NoScript?
Not quite, but there is a lot of overlap.

ABE is more powerful - it can do things like anonymizing and sandboxing requests, distinguishing between HTTP GET and HTTP POST etc, using regular expressions to identify sites...but RP has a much easier interface.
logging in on secure.domaintools.com is possible with google-analytics.com blocked in NoScript and RequestPolicy not installed. As soon as RequestPolicy is installed, logging in is not possible until google-analytics.com is allowed in either RequestPolicy or NoScript. That doesn't make sense to me.
If it is blocked by NoScript, why does it make a difference if it is allowed in RequestPolicy? It is blocked! Or not?
Why is it enough to allow it in either extension? Does the other one block google-analytics.com not reliably?
Probably related to the Google Analytics surrogate script.

In a nutshell: some (poorly-designed) sites break if you remove Google Analytics entirely, so if you block GA, then NoScript will insert a fake script to keep the sites happy. Probably RP is getting there first and preventing NoScript from doing it, because NoScript deliberately runs after other extensions.

Not sure why it works when NoScript allows it and RP blocks it.

Re: Though Google is blocked still a connection to a Google-

Posted: Thu Feb 14, 2013 3:46 pm
by bege
Thrawn,
thank you very much for your detailed answer.
Regards