Hacker News new | ask | show | jobs
by AndrewUnmuted 1978 days ago
Sorry to go off-topic slightly, but can any INFOSEC people confirm that this idea below makes any sense? The conventional thinking, as far as I am aware, has always been that JavaScript increases your attack vector and diminishes your security coverage.

> Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

5 comments

I think they're looking at two different notions of security: security of Google's services against bots (which is probably what Google is trying to check with Javascript), and security of users' browsers against malware (which is an attack surface that can be limited by turning off Javascript).

It might be like thinking about whether a "TSA lock" increases security. One might say that it increases security because it allows TSA to check the contents of people's belongings more easily, or that it decreases security because it can allow anyone with brief physical access to a bag to steal its contents.

Edit: the sibling comment also points out a likely use about recognizing your own devices. If you let Google spy on you more, it can more accurately determine what is usual or unusual for you, in order to distinguish you from an impersonator. You might also not want Google or others to have this information.

Dirty little secret: when software vendors speak, they will frequently blur the purpose of a given security measure and who, exactly, it protects.

This measure helps protect Google. And much like a politician stretching the definition of the national interest to include themselves, Google might say that they're protecting you by protecting themselves.

If Google can use this to rate limit sign-ins more effectively, then it does protect users, since the limiting factor on password security is time to crack.
I want the ability to change these types of settings for my account. They can be buried in an advanced menu somewhere.

I have a password manager. My Google password is a long, unique string of random characters that I don't use on any other service. If someone does break into my Google account, it will be because they broke into my password manager and/or successfully phished me (or hit me on the head with a $5 wrench). Number of retries will have nothing to do with it, unless they have a computer from the future.

I am much more concerned about Google locking me out of my account some day in an attempt to stop someone from breaking in, then I am about someone else actually breaking in.

Upvoted for the subtle xkcd reference :)
There's probably more here, but one thing I can think of is fingerprinting the client as part of the automated risk assessment, deciding whether and when to block attempts, trigger MFA, and recognize specific devices (and potentially tie them to specific users for whatever reason).
You are correct. This is just for Google's benefit, as you can imagine. They are Google, after all.
Phishing is accessible to anyone with basic web development skills, while JavaScript sandbox escapes for major browsers are the domain of pretty sophisticated actors.