Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

81–90 of 529 posts

Re: JavaScript is now required to sign in to Google

#82

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…

Calling other people, or their opinions, shortsighed and self-centered is usually not the start of a good conversation.

You're right. I was shortsighted and self-centered.

Re: JavaScript is now required to sign in to Google

#83
post #32

I'm getting tired of Google dictating how the web should work. That's the job of standards bodies. Google is increasingly taking the place of overbearing overlord that Microsoft embodied in the 90's and early 2000's.

Is there a standard relating to whether JavaScript should be optional?

Re: JavaScript is now required to sign in to Google

#85
post #57

Earlier quoted context omitted.

Do you have a better solution for differentiating yourself as an actual user from a robot spammer?

This is only truly necessary as a mechanism to prevent automated signups. It is less necessary, but can be useful, to prevent repeated login attempts (rate limiting works there). For accessing a website it's completely inexcusable.

Rate limiting login attempts means I can prevent you from logging in indefinitely by pushing your account into the rate limited status.

Re: JavaScript is now required to sign in to Google

#86
post #69

How is this nonsense upvoted on hackernews..?

It's surprising to me how many users on HN can only think as far as their own browser. Really the question here is not "what's the harm of JS across the web" but rather what is the specific privacy cost of running JS on a sign in page and what is the security benefit of the same. The worst case cost of JS on a browser is that you get a drive by download and your endpoint is owned. This seems unlikely on a Google doma…

Why would google not at least have an incentive they'd have to work against, to add tracking into their sign in pages? They make all of their money off of ads and they do that by tracking people to target ads.

You might as well say people shouldn't take precautions swimming around sharks, because it's rare and be surprising if they attacked

Re: JavaScript is now required to sign in to Google

#87
post #57

Earlier quoted context omitted.

Do you have a better solution for differentiating yourself as an actual user from a robot spammer?

This is only truly necessary as a mechanism to prevent automated signups. It is less necessary, but can be useful, to prevent repeated login attempts (rate limiting works there). For accessing a website it's completely inexcusable.

Background: I spent years developing a product that currently defends F500 websites against automated attacks. If you live in the US you've more than likely used my software this week without knowing it.

Rate limiting is completely ineffective in preventing credential stuffing attacks from determined adversaries. The challenge is not brute-forcing, but credential leaks and password reuse. Attackers have access to vast seas of IP addresses and in my past life doing the defending, we would see an IP address involved in automation twice, and then it would go away forever.

Re: JavaScript is now required to sign in to Google

#88
post #37

Earlier quoted context omitted.

Passwords can be hashed directly client-side with javascript, which is way more secure than sending them clear on the wire, so i dont disagree with Google's stance here and dont understand the hate

Hashing passwords client side has no benefit if a site uses HTTPS. If a site uses HTTP, then hashing the password client-side and sending it up to the server is equivalent to sending a clear text password. If an attacker can already read your traffic, what is stopping them from using your password's hash to log-in to your account?

It stops them from using the password to log in to your other accounts.

It stops a compromised server from silently leaking unhashed passwords.

It makes password hashing user auditable.

You could even do a call and response model to stop the hashed password to log in at all. Here is a primitive scheme for such a model (public key crypto probably enables more clever schemes, not sure):

- Upon signup, generate hashes of "$password$site$i" for i in 1 to 1000. Send these to the server and have the server hash them again.

- Upon login, after the user has entered their password into the box, send an integer from i from 1 to 1000 to the browser, have the browser send back the hash of "$password$site$i".

Now a compromised hash can only let you log in 1 time in 1000. Combine that fact with the other available signals for "is this who we think it is" and you should be able to reject people who stole the hash reasonably reliably. Meanwhile since you are still hashing the password on the server (again) you have lost literally nothing but a tiny bit of computation time.

Re: JavaScript is now required to sign in to Google

#89
post #6

For about a month or so I tried browsing with JavaScript turned off but gave up after having to modify settings for just about every single site I visited to get pages working, often with them silently failing in the background leaving me wondering what was going on. Sometimes I'd get halfway through a payment transaction before realising that the lack of JavaScript was preventing it from going through and then chang…

I went through the same pain but took an opposite approach. I've just started using the internet less. I allow us for Amazon and Gmail(which I am moving off of), but for 99% of the rest of my personal use I only read text only sites. I guess I have internet traffic for Spotify too, but that's an app so I've already let them onto my system

Re: JavaScript is now required to sign in to Google

#90
post #54

Earlier quoted context omitted.

Recent new version of Google Mail flat out doesn't work to any usable standard in Firefox. Ten seconds to open a new 'compose mail' window. A context menu does a multi-second HTTP fetch before showing. The previous version worked great. Either the dev team has just given up on quality or they're intentionally goading me into installing Chrome. I'm not going to play that game -- at this point Thunderbird works better.

What version of Firefox are you running? You are either exaggerating greatly or have other issues with your system. I run the latest stable release of Firefox and the performance of Gmail (particularly the features you mention) is fine. I’d be happy to upload a screen recording to verify.

I've experienced both very fast and very slow with the new Gmail on the same machine with Firefox on Linux. It's currently faster than Chromium, but maybe tomorrow I'll see ten-second load times. Who knows? For the record, I use uMatrix (and uBlock Origin on easy mode for client-side cleanup), which might be affecting it somewhat.
Post reply on HN