Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

Post reply on HN
Print view View original

371–380 of 529 posts

Re: JavaScript is now required to sign in to Google

#371

Post by whack »

xg15 wrote: post #358
mike_hearn wrote: post #311

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…

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.

Like the blog post mentioned, 99.9% of users already have JS enabled, and this number is only going to go up as websites rely more and more on JS. For them, this is a purely beneficial change, with no downsides. It's somewhat selfish for you to ask that your system be made more secure, even at the cost of security for 99.9% of other users.

Re: JavaScript is now required to sign in to Google

#372

Post by Nasrudith »

brunoTbear wrote: post #41

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…

Passwords are obsolete - actual security would involve keys. The fact they have to care about automation for security instead of availability is a sign they have already lost. If you have a disposable EC2 server administration password accessible you are already doing it horribly wrong because you /will/ get attacked frequently.

Javascript is opening an attack surface for what will certainly turn into an arms race anyway instead of ending it.

Given that they aren't pushing a new standard for what has already been a problem for a long time while introducing a vector for abuse both to and from it google can be criticized for both of those sins far more.

Re: JavaScript is now required to sign in to Google

#373

Post by yanonymous2 »

Phlarp wrote: post #171
lisper wrote: 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?

Throttle based on what? IP address? This works for domestic IT departments looking to shut out automated attempts from specific ranges but at Google's scale IP based filtering could end up shutting out an entire country.

md5sum(userid + ip)

That way you don't log private user data (EU laws etc) and it can't be used to lock someone out of their account.

The only way around this is to attack from a lot of different IPs and that, too, is very easily detectable and solvable in a user friendly way.

Really, how hard is it? I would expect this to be the default for big companies by now.

Re: JavaScript is now required to sign in to Google

#374

Post by teddyfrozevelt »

anon1252 wrote: post #345
kibwen wrote: post #71

Earlier quoted context omitted.

Being allowed to pay for services with money, rather than being required to pay for services with your personal data. I browse the web via a proxy when I'm on public wifi, and Google is nigh unusable with how many captchas it forces you to solve to do a single Google search. Fortunately Bing and DDG still work, for now.

I would absolutely subscribe to a email service with a 5/10/15 dollars one time payment.

Email has recurring costs to run. They need to process every email you receive and send and therefore any email service that actually wants to continue running will need to charge a subscription fee.

Re: JavaScript is now required to sign in to Google

#375

Post by jandrese »

superkuh wrote: post #24
amanzi wrote: 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'm on ~5 years of temp-whitelist only for JS domains. I have acquired a third sense for which CDN and assort domains are really required for what. Sure, it does take some back and forth testing, and some sites like wix.com sites are terrible no matter what, but in general it's a better browsing experience.

My favourite are pages that embed videos using a huge collection of different third party embedding tools. It usually takes 2 or 3 rounds of whitelisting to get the video to even show up, and another to get it to play.

Re: JavaScript is now required to sign in to Google

#376

Post by exikyut »

mike_hearn wrote: post #311

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…

Thanks so much for chiming in here.

Admittedly, bot detection is really interesting to me as a subject. It's not the kind of thing you can throw infinite ML at and expect it to break even in terms of scaling; you need careful tuning and optimization baked in from the ground up, which means a fundamentally "manual" approach involving lots of lateral creativity and iteration. That creativity and one-upmanship (along maybe with the gigantic piles of money, because manual ;)) is what makes the field so interesting to me - but alas, I cannot pepper you with questions/topics/discussion/anecdotes/stories for two hours for obvious reasons :)

So, instead, a couple of questions, considering datapoints likeliest to benefit others, and perhaps (hopefully) provide some appropriately dissuading signals as well.

- How does Botguard detect Chromium running in headless X sessions? By looking at the (surely very wonky) selection of pages visited, or...? (Obviously IP range provenance is a major factor, considering the unusable experience Tor users reportedly have)

- Regarding the note about "bending over backwards", while playing with some old VMs very recently I observed with amusement that google.com works in IE 5.5 on Win2K but not IE 6 on Win2K3SP4 (https://imgur.com/a/zg7FoAW), entirely possibly due to broken client-side config, I'm not sure. In any case, I've also observed that Gmail's Basic HTML uses very very sparing XHR so as not to stackoverflow JScript, so I know the bending-over-backwards thing has stuck around for a long time. Besides general curiousity and interest in this practice, my question is, I wonder if this'll change going forward? Obviously some large enterprises are still stuck on IE6, which is hopefully only able to reach google.com and nothing else [external] :)

- I wonder if a straightforward login API could be released that, after going through some kind of process, releases Google-compatible login cookies. I would not at all be surprised if such ideas have been discussed internally and then jettisoned; what would be most interesting is the ideation behind _why_ such an implementation would be a bad idea. On the surface the check sequence could be designed to be complex enough that Google would always "win" the ensuing "outsmart game", or at least collect sufficient entropy in the process that they could rapidly detect and iterate. My (predictable) guess as to why this wasn't implemented is high probability to incur technical debt, and unfavorable cost-benefit analysis.

I ultimately have no problem that JS is necessary now; if anything, it gives me more confidence in my security. Because what other realistic interpretation is there?

Re: JavaScript is now required to sign in to Google

#377

Post by fweespeech »

brunoTbear wrote: post #41

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…

> ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS.

Password are effectively obsolete and everyone should be using multi-factor authentication of some kind. Keys with passphrases. 2FA auth. Whatever.

Making 2FA auth mandatory would be substantially more effective than bot signaling.

> tl; dr: Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses. I think there's a shortsightedness and self-centeredness to a lot of these comments.

If they were, 2FA auth would be mandatory with additional phone-based (i.e. SMS) whenever you try to login from a new geographic area. That would stop anything short of a targeted hack.

Instead, they created an attack on the bot maker's profit margins. Cloudflare, Google, et al. are really just trying to increase the cost of making bots. They are not really trying to _stop_ bots.

Stopping bots requires making unpopular choices.

Re: JavaScript is now required to sign in to Google

#378

Post by neolefty »

arendtio wrote: post #367

When Javascript becomes the new pillar of security something has gone terribly wrong. Background: I love building Single Page Applications, Progressive Web Apps and have JS always enabled. So no hate for JS in general, but when your security depends on the correct evaluation on the client side, you are starting a dangerous cat and mouse game.

They've been playing a dangerous cat and mouse game the whole time — I'm sure the old tools are not being discarded; just added to.

Re: JavaScript is now required to sign in to Google

#379

Post by relic »

ankit219 wrote: post #289
ifdefdebug wrote: post #278

Earlier quoted context omitted.

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

I used a long and supercomplicated password for one of my accounts that i access intermittently. Why I have it is a long story, but I only log into it once or twice a month to check if there is something that needs my attention. Usually the login is in incognito, guest mode, and even from different locations and machines. Google asks for a second factor (i dont have it on for my accounts) like phone verification for…

It's probably the switching of devices that raises the level of security.

Re: JavaScript is now required to sign in to Google

#380

Post by dwringer »

skunkworker wrote: post #189
gpm wrote: post #88

Earlier quoted context omitted.

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

Use a password manager and don't reuse passwords. If your randomly generated, unique password has good enough entropy then why go through all of the trouble of the rest of the client side hashing? There's nothing stopping you from hashing your own passwords client side and sending your bcrypt hash up to the server except some sites still truncate the passwords to 32/16 chars etc. When you have the need for the level…

worshipping an arbitrarily contrived measure of password entropy makes for good security theatre, but there's a lot that goes into maintaining anything resembling actual security. How many people use "password generators" and trust that they'll come up with "random" words? What about that old saying about putting eggs in a basket?
Post reply on HN