Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

61–70 of 529 posts

Re: JavaScript is now required to sign in to Google

#61
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.

...and speed, and decreasing the amount of arbitrary code execution on your machine.

Most people don't disable JS entirely, but use something like uMatrix or noscript. It takes more work, but you can turn off a significant number of things that just don't need to be executed and get around a lot of annoying modals and paywalls (or see a lot of blank pages; that happens a lot too).

Re: JavaScript is now required to sign in to Google

#62

Earlier quoted context omitted.

Who is sending passwords in cleartext on the wire?

Literally almost everyone. (Wrapped in a TLS connection of course.)

> (Wrapped in a TLS connection of course.)

So, not cleartext over the wire then.

Re: JavaScript is now required to sign in to Google

#63
post #37

To keep your account secure, turn on Javascript?? If anything is making your web browsing less secure, it's JS. I don't particularly care that Google isn't letting you sign in without JS, but the message is just plain wrong..

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

If the client hashes the password then the hash itself is the password. Meaning stealing the hashes passwords is the same as stealing the plain text password for which they're based, since you can post them direct.

Blizzard entertainment does half client half server hashing which is rather clever, one of the few examples where client hashing makes sense.

Re: JavaScript is now required to sign in to Google

#64

Earlier quoted context omitted.

Who is sending passwords in cleartext on the wire?

Indeed. And: who is hashing passwords on the client? As this would require either not using a salted hash, or sharing the server's salt with the client, in order to obtain identical hash values for comparison. In either case that system's entire password inventory would be a lot more vulnerable. TLDR don't do that, send passwords over SSL and use a good password hashing algorithm on the server like BCrypt.

if you're in the position to or are developing an app use argon2!

Re: JavaScript is now required to sign in to Google

#65
post #48

Earlier quoted context omitted.

Who is sending passwords in cleartext on the wire?

I think totony meant sending passwords without pre-hashing, but yeah it doesn't make sense to send any confidential information in clear text that should be sent via E2E encrypted TLS channels. Furthermore, pre-hashing doesn't necessarily make transmitting confidential information safer, as one would argue that your client side javascript can be reverse-engineered and give the attacker more information about how you…

Yes I meant sending the password cleartext inside the transport protocol*

pre-hashing doesn't prevent an attacker from stealing your account if it can read the communication, but it prevents it from having your password and using it everywhere else where you might re-use the password or a permutation of it

Re: JavaScript is now required to sign in to Google

#66

Earlier quoted context omitted.

Who is sending passwords in cleartext on the wire?

Lots. But even those that don’t tend to send the password to the server, which is still bad.

How is sending the password to the server over HTTPS bad? What would you do otherwise? Hash it on the client? So are you not using salted hashes for your password store? That's far worse. Or you're hashing twice, the first with no salt client-side, then again with salt on the server side, which is fine, but the client-generated hash must be unsalted so is basically just the password itself: steal the client-generated hash instead of the original password, just as good with only minor loss in value (might not be able to reuse it on other sites for the victim; but actually maybe still could if you can build a reverse index of common passwords hashed using whatever algo is in use.)

And if you don't trust HTTPS to protect sensitive information, why would you send the auth cookies over it that have virtually as much power the password that was given in exchange for them in the first place?

Re: JavaScript is now required to sign in to Google

#67

I'm genuinely curious who actually browses the web in 2018 with JS disabled, though. Wouldn't 99.9999% of the web basically break? Like, if you do, do you only stick to a few basic sites, or?

I do sometimes. Mostly to read articles on sites with a poorly implemented paywall that simply doesn't work with JS disabled and shows the whole content. As a bonus often half of the ads are not served as well.

Re: JavaScript is now required to sign in to Google

#68

Earlier quoted context omitted.

You're misunderstanding: you browse with JS disabled by default . Random sites shouldn't be running programs on your computer. If you trust the site, you whitelist it.

You're acting like "running programs on your computer" is a bad thing. It's not.

Running untrusted code on your machine _is_ a bad thing though.

Re: JavaScript is now required to sign in to Google

#70
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 have a lot of issues with google apps for business. Sometimes I have to refresh the browser 5-6 times before it will display any email in the primary inbox as well.

It's just horrible to use in firefox (in arch linux) and I'm currently looking for a new provider.

I might just go all in and use protonmail.

Post reply on HN