Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

471–480 of 529 posts

Re: JavaScript is now required to sign in to Google

#471

When I was at Google I started both the login risk analysis project and the Javascript-based bot detection framework they're now enforcing, so it's a pity to see so many angry comments. Maybe a bit of background will make it seem more reasonable. Firstly, this isn't some weird ploy to boost ad revenue. This is the login page - users are typing in a long term stable identifier already! The Javascripts they are requiri…

Sorry, but at this point it is pretty obvious that big tech companies care about account security only as far as it impact their services. The late revelation about Facebook abusing 2FA phone numbers for marketing is a great demonstration of how that works. Google too does some really funny things to make it nearly impossible to create and maintain an anonymous accounts not tied to a phone number. Even when those acc…

> Pushing JavaScript everywhere increases the attack surface for every single user on the web.

I understand where you're coming from, but most users browse the web with Javascript = on. Even as a NoScript user I have Google whitelisted because most of their services are unusable without Javascript. Even automated tools have good Javascript engines now thanks to headless mode in popular browsers.

I suspect the next steps in browser security will not be to blanket-deny scripting, but instead focus on containers and sandboxing to make script-based attacks less worthwhile.

Re: JavaScript is now required to sign in to Google

#472
post #139

Earlier quoted context omitted.

> Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses Why is it not sufficient simply to throttle logins at the server?

Modern cred stuffing is done by botnets. When I see a cred stuffing attack, it's maybe 1-3 attempts per IP address spread over 100-500k IP addresses. Often you'll have a family of legitimate users behind an IP address that's cred stuffing you at the same time. Throttling by IP address may have worked 10 years ago, unfortunately it's not an effective measure anymore. Modern cred stuffing countermeasures include a wide…

But you don't have thousands of families logging in from thousand of different servers: in your case a max of 10 login attempts would prevent it.

Re: JavaScript is now required to sign in to Google

#473
post #382
post #358

Earlier quoted context omitted.

Javascript ist also required for the vast majority of web-based exploits. I find it somewhat strange that you ask me to make my system less secure so you can better secure my account.

Then just turn Javascript on to log in, then turn it back off again. You just need Javascript for the sign-on page.

Then just get your wallet out to use the ATM in the dodgy neighbourhood and put it away again. You just need your wallet for the ATM in the dodgy neighbourhood.

Re: JavaScript is now required to sign in to Google

#474
post #473
post #382

Earlier quoted context omitted.

Then just turn Javascript on to log in, then turn it back off again. You just need Javascript for the sign-on page.

Then just get your wallet out to use the ATM in the dodgy neighbourhood and put it away again. You just need your wallet for the ATM in the dodgy neighbourhood.

How else are you supposed to get to your money?

Re: JavaScript is now required to sign in to Google

#475

Earlier quoted context omitted.

> That said, I'd be willing to wager a fair bit that literally every line of code you've run on your machine (probably ever if it's been bought in the last few years) outside of the vendor installed OS and drivers came from the internet. We explicitly decide to install software and we know where we're getting it from. We may not be careful enough, but I certainly trust `brew install` a lot more than I trust a random…

I think this is a reversal of responsibility. You're shifting the responsibility from yourself to a different entity for the choices you're making. The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit. > I bought my car to drive it, but that doesn't mean that every person I pass on the street gets to drive my car. Damn right you don't let ra…

> You're shifting the responsibility from yourself to a different entity for the choices you're making. The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit.

This seems like a fundamental misrepresentation of how malware is distributed, and how privacy is compromised. People are responsible for the sites they choose to visit. They're not responsible for what those sites serve them, because they can't evaluate it until it's already been served. I don't know what a page will serve me until I visit that page. I can't.

Holding people responsible for whatever content they're served on a page is the same sort of "suck it and see" logic we rightly rejected with "by opening this package, you have consented to the terms of this license". It's a concept that's fundamentally incompatible with informed agreement.

If you want to hold people responsible for clicking "crack DRM now!" ads on the Pirate Bay, fine. But malware doesn't necessarily require outbound clicks, and doesn't necessarily come from dubious sites. Forbes locked out adblockers and served malware through their ad network. Xfinity, the NYT, ebay, Youtube, the Atlantic, and a dozen others major sites have served malware. Newegg, British Airways, and probably Ticketmaster were hit by Magecart, which infected even users with adblockers running.

Why do I disable Javascript? It's not because I don't think I'm responsible for my safety online. Precisely the opposite - it's because I'm not relying on other parties! Magecart was running on major sites two months ago. Adblock, an up-to-date browser, and responsible surfing didn't keep people safe, but uBlock did. A framing where users are accepting any code that ever appears on any site they visit is a framing where we all ought to abandon the internet outright.

Re: JavaScript is now required to sign in to Google

#476
The post states:

>"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. We’re always working to improve this analysis, and we’ll now require that JavaScript is enabled on the Google sign-in page, without which we can’t run this assessment."

Is the idea that an actual browser will be able to have a fingerprint whereas a bot would not? Is the check for a javascript a way to short-circuit responding to a non-browser based request? It wasn't clear to me.

Re: JavaScript is now required to sign in to Google

#477
post #473

Earlier quoted context omitted.

Then just get your wallet out to use the ATM in the dodgy neighbourhood and put it away again. You just need your wallet for the ATM in the dodgy neighbourhood.

How else are you supposed to get to your money?

Fish tickling

Re: JavaScript is now required to sign in to Google

#478

When I was at Google I started both the login risk analysis project and the Javascript-based bot detection framework they're now enforcing, so it's a pity to see so many angry comments. Maybe a bit of background will make it seem more reasonable. Firstly, this isn't some weird ploy to boost ad revenue. This is the login page - users are typing in a long term stable identifier already! The Javascripts they are requiri…

I understand what you're saying and it makes sense. I think in my mind it's the fact that javascript has the potential to do so many things, not that it's being used that way today. To use a bad car analogy, the in-car entertainment used to be just a dumb radio. Now that it's a computer connected to the main car network, it has a lot more potential to do things, whether it's a feature, bug, or an exploit.

Agreed, guts in the haggis.

Re: JavaScript is now required to sign in to Google

#479

"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…

I travel frequently and have multiple Google accounts (3x G-Suite and one Gmail) and have never had any problems accessing any of them anywhere in the world. I do occasionally get alerts saying that they've blocked a login attempt from India or South America, though. It seems their system works pretty well.

This is actually surprising enough that I'm glad to hear it even as an anecdote.

My experience with changing devices or cities (or god forbid both at once) is that it always requires further authentication, and often fails outright. I have an account which is simply disabled because I didn't set a recovery phone # or email and then changed machines. Everyone I've ever discussed the topic with has described similarly pervasive problems.

Which makes me wonder: what's so different between usage patterns? Obvious Google's auth approach is working for lots of people, so what's distinctive about this block of users who it's constantly failing for?

Re: JavaScript is now required to sign in to Google

#480

Earlier quoted context omitted.

>2FA is a very cheap solution If you don't know the technologies the website is built upon or how much it will be impacted by increased barrier of entry for users, this statement is baseless.

Who uses malbolge to create servers?

I take offense at your tone, and the implied judgement. Malbolge was the right tool for us, and let us tap into a talent pool that was otherwise going unused.
Post reply on HN