Comment Re:Color me dubious. (Score 1) 172
You are absolutely correct.
The hacker controlled/malicious browser simply morphs the incoming JS as it comes off the wire (e.g. a filter on the socket data) to do whatever is necessary to bypass any real security check and return the "I am safe" result.
It could (e.g.) simply reverse the sense of:
if (bad_security_here())
Into:
if (! bad_security_here())
Or, do whatever else is necessary to nullify the security check.
Client side security checks are largely meaningless! If you control the browser, you can hack it any way you want, and you control what the JS does/can do.
A native app might be harder to morph, but, ultimately, the same technique can be applied [by patching binary bytes] to nullify the security checks.
They are only useful as a "health checkup" for a legitimate user's browser. But, Google's stated goal was:
The reason is that Google uses JavaScript to run risk assessment checks on the users accessing the login page, and if JavaScript is disabled, this allows crooks to pass through those checks undetected.
As I mentioned above, [real] crooks can easily get around this, so this is faux security at best.
At worst [as others have mentioned], foisting Javascript on users that do not want it, opens a gigantic Pandora's box of security holes for other sites that might download malicious javascript code.