You are still missing my point, which is frustrating, because I tried to make it clearer last comment. I am not saying Google will try to screw you. I am not even saying the author of the specific Javascript that provides an easy NoScript evasion will be trying to screw you. I am saying that it is not uncommon to find DOM corruption flaws in clientside JS libraries, and if those libraries are hosted on whitelisted CDNs, those flaws are all NoScript evasions.
Two things that may not be intuitively clear to every reader:
1. No way do all of those sites actually do full security audits for every .js file on their domain. (Google comes close.)
2. The specific kind of security flaw we're talking about is not necessarily "interesting" outside the context of NoScript. There are plenty of clientside DOM corruption bugs that don't even get documented, let alone fixed, because they can't easily be used to compromise a user session. But they will work fine for getting the right chunk of malicious JS delivered to end-users.
I'm not anti-NoScript. But don't kid yourself about its utility against browser JS vulns. Before you get your dad to install NoScript, make sure he's patched. Try to get him to switch to Chrome while you're at it.
Two things that may not be intuitively clear to every reader:
1. No way do all of those sites actually do full security audits for every .js file on their domain. (Google comes close.)
2. The specific kind of security flaw we're talking about is not necessarily "interesting" outside the context of NoScript. There are plenty of clientside DOM corruption bugs that don't even get documented, let alone fixed, because they can't easily be used to compromise a user session. But they will work fine for getting the right chunk of malicious JS delivered to end-users.
I'm not anti-NoScript. But don't kid yourself about its utility against browser JS vulns. Before you get your dad to install NoScript, make sure he's patched. Try to get him to switch to Chrome while you're at it.