Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

271–280 of 529 posts

Re: JavaScript is now required to sign in to Google

#271

ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS. They're probably right that not running JS is privacy accretive, but only if you consider their individual privacy, and not the net increase in privacy for all users by being able to defend accounts against cred stuffing using JS. The privacy loss…

If by ‘cred stuffing’ you mean brute forcing accounts, that’s what short lockouts and 2 factor authentication are for. JavaScript is just a layer of obfuscation and doesn’t fundamentally help.

I'm not up to speed with the latest and greatest of what java-script can do, but isn't the source code fundamentally user-visible?

We always used to laugh at people who did website security with javascript, the whole idea was that security processing had to be done server-side.

Re: JavaScript is now required to sign in to Google

#272
post #159

Earlier quoted context omitted.

You are wrong. Client-side hashing CAN be a silly thing, but it can also prevent a (compromised) server from seeing your password which you probably use on other websites (which is what most people do unfortunately).

>but it can also prevent a (compromised) server from seeing your password If the server is compromised, then there is no protection of your cleartext password at all. This is because the entity that compromised the server can replace the original JS with anything, including new JS that sends your cleartext password off to their own host as you type each character. The only activity on your part that can save you agai…

Again, this is wrong depending on how the client is implemented, if updates are signed, if we are talking about a protocol, etc.

Re: JavaScript is now required to sign in to Google

#273

Earlier quoted context omitted.

You are wrong. Client-side hashing CAN be a silly thing, but it can also prevent a (compromised) server from seeing your password which you probably use on other websites (which is what most people do unfortunately).

and if said "compromised" server simply decides to not supply the js that hashes the password?

The answer is that it depends. We could be talking about protected js with SRI, signed updates with an electron client, a browser plugin or native hashing, a protocol similar to SSH that hashes the client pw, etc.

Re: JavaScript is now required to sign in to Google

#274
"When your username and password are entered on Google’s sign-in page, we’ll run a risk assessment and only allow the sign-in if nothing looks suspicious."

In my experience (it is already the case with gmail and outlook up and now), this means I will not be able to login to my account when in holiday in another city, country, or when I use a borrowed device, or when I am behind VPN/Tor, etc, unless I give google my phone number, and can afford to get a call / sms at that point of time and unblock the account.

It should be my choice, as it is my account that is at risk, to turn on/off such dubious security measures. It is fine to have these features on by default, but I would like to turn this particular feature off for my account. Any clever "risk assessment" thing where a computer decides without an option to turn if off/on is problematic.

I have sometimes the feeling they know this and it is on purpose. They want not only to collect data, they want to collect high quality data and these measures help to clean their data sets at time of collection.

Re: JavaScript is now required to sign in to Google

#275
post #271

Earlier quoted context omitted.

If by ‘cred stuffing’ you mean brute forcing accounts, that’s what short lockouts and 2 factor authentication are for. JavaScript is just a layer of obfuscation and doesn’t fundamentally help.

I'm not up to speed with the latest and greatest of what java-script can do, but isn't the source code fundamentally user-visible? We always used to laugh at people who did website security with javascript, the whole idea was that security processing had to be done server-side.

Javascript can be served dynamic as well, per user/connection specific even. So an attacker would have to investigate and counter each new version of the scripts. Even if this could be done automatic it greatly increases the cat/mouse factor for Google.

Re: JavaScript is now required to sign in to Google

#276
post #185

Earlier quoted context omitted.

I can speak from experience regarding FastMail because that's exactly what I did. In fact, I migrated off a grandfathered Google Apps account with my custom domain to FastMail with that same domain. Yeah, it's a bunch of steps, but I'm very comfortable with making DNS changes. My wife and I have an account; it's worth every penny. Also, FastMail allows for subdomain handling. I use this feature with nearly every site…

Another very happy user of FastMail here, with our own domain. I initially was excited by subdomain handling, but switched back to only using my main account. Using FastMail-specific features will lock you into this specific vendor once again, one of the main reasons to switch in the first place!

To be fair, how FastMail does catch-all delivery like this is standard and easily reproduced st any mail vendor (except Office 365) that supports catch-all, which is most of them. I use a catch-all address with FastMail that is @asubdomainichose.mydomain.org and it is the same subdomain I used with my previous setup before moving to FastMail.

Using a subdomain for catch-all is great because spammers can’t easily discover and flood the subdomain.

Re: JavaScript is now required to sign in to Google

#277

"When your username and password are entered on Google’s sign-in page, we’ll run a risk assessment and only allow the sign-in if nothing looks suspicious." In my experience (it is already the case with gmail and outlook up and now), this means I will not be able to login to my account when in holiday in another city, country, or when I use a borrowed device, or when I am behind VPN/Tor, etc, unless I give google my p…

> In my experience (it is already the case with gmail and outlook up and now), this means I will not be able to login to my account when in holiday in another city, country, or when I use a borrowed device, or when I am behind VPN/Tor, etc, unless I give google my phone number, and can afford to get a call / sms at that point of time and unblock the account.

That's exactly it, there's already two Gmail accounts from high school I can't access despite knowing the passwords.

Re: JavaScript is now required to sign in to Google

#278

ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS. They're probably right that not running JS is privacy accretive, but only if you consider their individual privacy, and not the net increase in privacy for all users by being able to defend accounts against cred stuffing using JS. The privacy loss…

So what about a opt-out at account level? Something in the account settings, like this:

[check] Allow sign-in from javascript disabled browsers. WARNING etc. (usual warnings about security etc.)

Edit: because users who know to use long passwords and 2FA do exist and don't need all that extra security stuff ...

Re: JavaScript is now required to sign in to Google

#279
post #16
post #2

> But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users (0.1%) choose to keep it off. This might make sense if you are reading static content, but we recommend that you keep Javascript on while signing into your Google Account so we can better protect you. They don’t seem to explain why though? Did I miss it? Are they fingerprinting the JavaScript environment of my browser?…

Additionally they imply the only motivation for disabling JavaScript is to increase performance and decrease bandwidth. They conveniently don’t mention the other, arguably more prevalent motivations: to increase privacy and security.

Yeah, it struck me as extremely disingenuous; while I like the other benefits, I disable JS mostly because I hate being tracked and noticed that many (most?) browser exploits require JS to run.

Re: JavaScript is now required to sign in to Google

#280
post #165

Earlier quoted context omitted.

He's not the only one. It's a recurring comment here on hacker news and a problem I've encountered as well, and I'm running the latest stable release.

Same here, I run the latest Firefox on both Windows and Linux. Gmail always takes at least 5 seconds to load.

If you experience a reproducible Firefox performance problem, please consider using the Firefox profiler add-on [1] to record a profile and file a bug with "[qf]" to the whiteboard field. These "[qf]" Firefox performance bugs get reviewed by engineers twice a week. Having a profile makes the bugs much easier to diagnose.

[1] https://perf-html.io/docs/#/

Post reply on HN