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 requiring here are designed to detect tools, not people. All mass account hijacking attacks rely on bots that either emulate or automate web browsers, and Google has a technology that has proven quite effective at detecting these tools. There's a little bit of info on how it works scattered around the internet, but none of the explanations are even remotely complete, and they're all years old now too. Suffice it to say: no JS = no bot signals.
Google had the ability to enforce a JS-required rule on login at least 6 years ago and never used it until now. Without a doubt, it's being enforced for the first time due to some large account hijacking attack that has proven impossible to stop any other way. After so many years of bending over backwards to keep support for JS blocking users alive, it's presumably now become the weakest link in the digital Maginot line surrounding their network.
For the people asking for the risk analysis to be disable-able: you used to be able to do that by enabling two-factor authentication. You can't roll back your account to just username and password security though: it's worth remembering that account hijacks are about more than just the immediate victim. When an account is taken over it's abused and that abuse creates more victims. Perhaps the account is used to send phishing mails to your contacts, or financial scams, or perhaps it's used to just do normal spamming which can - at enough volume - cause Gmail IPs to get blocked by third party spam filters, and user's emails to get bounced even if their own account is entirely secure. The risk analysis is mostly about securing people's accounts, but it's also about securing the products more generally too.
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 accounts are just used for browsing and bookmarking, without sending any outgoing information.
>When an account is taken over it's abused and that abuse creates more victims.
Pushing JavaScript everywhere increases the attack surface for every single user on the web. Except it doesn't happen overnight, and big companies who do it (by affecting standards, or by doing stuff like this ^) aren't affected by client-side exploits and privacy loss.
If someone hijacks my browser through some clever JS API exploit and steals my credentials, what is Google's response? "Just use our 2FA." What about smaller websites that don't have resources to maintain 2FA? "They should authenticate through us." All roads seem to conveniently lead to centralization.
BTW, it is worth noting that the impact of a compromised account isn't nearly as significant if a single account doesn't hold keys to pretty much everything you do online. Somehow this is rarely factored in during such discussions.
> 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.
Well yes, these kind of accounts are highly susceptible to being bot accounts. What obligation does Google have to be the place for people's free, anonymous accounts? In any case, I haven't had a problem with the number of secondary accounts I've created that are tied to me only by another email address (which can point to another provider, like Yahoo).
> BTW, it is worth noting that the impact of a compromised account isn't nearly as significant if a single account doesn't hold keys to pretty much everything you do online. Somehow this is rarely factored in during such discussions.
How should this be factored into the current discussion? The use of JS is to ostensibly make it more difficult for automated hijacking to prey on users.
> 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.
> "Just use our 2FA." What about smaller websites that don't have resources to maintain 2FA?
I'm not going to say that providing 2FA is "free" in the time sense (both in implementing it initially and supporting people who lock themselves out) but on the surface 2FA requires just a library to verify 2FA codes and a column in your users table to store the shared secret.
Not to detract from your work there, but there's actually some great research papers about how Botguard itself is easy to bypass and google cookies provide most of the heavy lifting when it comes to bot detection.
I've snooped around a bit myself and it doesn't seem like botguard does anything much more advanced than other fingerprinting solutions.
I just don't buy that this is all about detecting more bots; every sophisticated bot I've seen in the ad world runs javascript as it's better to pose as a normal user, and only a tiny fraction of users would have javascript disabled.
To be honest, I also don't think requiring javascript is a bad thing either.
Ah, you're assuming it's the same strength on all places it's used - and also that it actually has been bypassed.
There didn't used to be any public bots that can beat the strongest version and from a quick Googling around I don't see that it's changed. Someone took apart a single program manually, years ago, but the programs are randomly generated and constantly evolve. So that's not sufficient to be able to bypass it automatically/repeatedly.
every sophisticated bot I've seen in the ad world runs javascript as it's better to pose as a normal user, and only a tiny fraction of users would have javascript disabled
It's a lot faster and more scalable to not automate a full web browser. Bot developers would rather not do it, they only do because they're forced to. Forced to ... by requiring Javascript, like this.
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.
> This is the login page - users are typing in a long term stable identifier already!
There are so many other considerations at work here though, and I can't imagine that they're not obvious to you as well? For starters, we're creatures of convenience, and this makes it significantly inconvenient to block google scripts on other websites even when not signed in. It also guarantees that you have the chance to produce a (likely unique) JS-based fingerprint of every google user that can then be used for correlation and de-anonymization of other data.
But really the most basic point that probably makes folks here suspicious: if this were really only about preventing malicious login attempts by bots, then why not give users a clear, explicitly stated choice: either JS or 2FA.
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.
It's unfortunate that your work is being used in such a massively economically wasteful manner.
The core issue is - it's all computers. The reason you can't reliably detect the difference between an average user using a computer to log in to your computer versus a fairly sophisticated computer using a computer to log in to your computer is that the transition between user and tool is not smooth. It is always going to be easier to find the various boundary points between user and tool than it is to construct a passable simulation of the user using that tool.
Yes, bot detection does make account hijacking attempts more expensive, but it makes all logins more expensive, and the rate of expense increases faster for you than it does the account hijackers.
so the way I understand it, roughly it works like this: JS tries to gather some set of information about browser's environment (capabilities, network access, reaction to edge-cases, …) sends it to google and google decides if they should allow user to continue authentication (by providing crypto signature of request+nonce or smth.like that… or just by flipping key in session)
> All mass account hijacking attacks rely on bots that either emulate or automate web browsers, and Google has a technology that has proven quite effective at detecting these tools
It sounds untrue and short-sighted. Even Google provides the tools for anyone to automatically navigate in a javascript-enabled website with Chrome Headless. All this will do is to provide a short-term security before the bots can again perfectly mimic humans with JavaScript enabled, this time.
Most "mass bots" can be stopped by logging the access attempts on the server side, with plain old HTML on the client side.
I'd be curious if the tools are only effective because of the fringe requirement of them. That is to say, right now, many malicious users are easy to spot using these, precisely because they don't have to be hard to spot.
That is to say, in the long run, it will be interesting if this actually reduces malicious use. Seems like it would be just as easy to avoid.
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?
I'm glad you're interested! The world could use more people tackling spam.
I'm not going to discuss signals for obvious reasons. Suffice it to say web browsers are very complex pieces of software and attackers are often constrained in ways you might not expect. There are many interesting things you can do.
I have no idea how much effort Google will make to support old browsers going forward, sorry. To be double-super-clear, I haven't worked there for quite a while now. Over time the world is moving to what big enterprises call "evergreen" software, where they don't get involved in approving every update and things are kept silently fresh. With time you'll see discussion of old browsers and what to do about being compatible with old browsers die out.
Straightforward login API: that's OAuth. The idea is that the login is always done by the end user, the human, and that the UI flow is always directly with the account provider. So if you're a desktop app you have to open an embedded web browser, or open a URL to the login service and intercept the response somehow. Then your app is logged in and can automate things within the bounds set by the APIs. It's a good tradeoff - whilst more painful for developers than just asking for a username/password with custom UI each time, it's a lot more adaptable and secure. It's also easily wrapped up in libraries and OS services, so the pain of interacting with the custom web browser needs be borne by only a small number of devs.
> Firstly, this isn't some weird ploy to boost ad revenue.
Everything Google does is a ploy to boost ad revenue. That's the whole business model.
> Without a doubt, it's being enforced for the first time due to some large account hijacking attack that has proven impossible to stop any other way. After so many years of bending over backwards to keep support for JS blocking users alive, it's presumably now become the weakest link in the digital Maginot line surrounding their network.
You're doing two things here:
1. Reasoning from no evidence, and ignoring a much simpler reason in the process.
2. Acting like the honest web users, the ones blocking malware-laden JS, are the ones who are wrong.
It's much simpler to conclude that Google engineers simply got lazy and decided to punt the hard work of security to some JS library, instead of looking at it honestly.
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 of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated.
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.
Your first statement is incompatible with your second. (I think the second statement is reasonable, although I disagree with the conclusion).
People aren't underestimating the risk to _their_ accounts, they are discounting the risk to _others_ accounts.
That is, they're essentially saying, 'well, other users chose to have bad passwords, so bully them'.
I think that's a fair viewpoint to have. We've entered a world in which computer literacy is a basic requirement in order to, well, exist.
That said, what's reasonable, and what actually occurs, are two different things. A company isn't going to ideologically decide "screw the users that use bad passwords" if it loses them money.
So we get _seemingly_ suboptimal solutions like this.
I think you may be giving people more credit than they deserve, but I'm willing to accept that they're making that argument. Even if that's their argument, that their personal habits around password use and being attentive to not being phished are so good they don't need Google's help defending themselves, so bully for everyone who does, I'm not convinced it's a good one.
There are a few things needed for that to be a good argument
1) Their security really is so good (I'd bet it isn't. I saw a tenured security professor/former State Department cyber expert get phished on the first go by an undergrad.)
2) Google isn't improving their security posture on top of that (I'd be shocked if Google isn't improving theirs, and I'm certain having JS required to sign into gmail closes a major hole in observability of automation)
3) There are real harms from the JS being there for their security/privacy posture (as I've said elsewhere, I'm unconvinced Google is allowed by their own privacy policy from doing anything untoward here)
As to your point about computer literacy and existence, I think the sad truth is that computer engagement is required, but literacy is optional. When that's the case, large companies are in the position of having to defend even the least computer literate against the most vicious of attackers.
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.
Credential stuffing more commonly refers to the practice of getting valid sets of creds from various password database dumps and retrying them across common/popular systems.
2FA is a good defence against it, but lockouts are less as they attacker will be going broad and not deep (could be a single request per user account)
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 variety of exotic fingerprinting, behavioral analysis, and other de-anonymization tech - not because anyone wants to destroy user privacy, but because the threat is that significant and has evolved so much in the past few years.
To be entirely honest, I'm kinda surprised Google didn't require javascript enabled to log in already.
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.
And indeed it's time to give up on the web being a document format only. The internet is about loading remote applications in your local sandbox. That's what it is. It sucks, but it is what it is. As part of loading remote applications, we now might be asked to compute whatever anti-abuse puzzles are required. So it goes.
If something shitty is happening, you don't have to shrug your shoulders coswhatyagonnado. Understanding the human reason why something shitty is happening doesn't mean you have to accept it. So it goes, until it doesn't.
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.
To be fair, Google released their own OTP hardware keys and have already 2FA login mandatory for accounts that they deem "high risk."
I don't think it's fair to blame them for the facts that most folks are not willing to give up passwords yet. Given that passwords are the current reality, shouldn't they do everything in their power to make them as secure as possible?
I'll be the guy who says that while I recognize those are insults, they are also sufficiently descriptive of a point of view... it's not like he called someone Mr. Poopypants.
> 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.)
It sounds a bit like what Gmail's doing with their "allow less secure apps" login option, except that's more for allowing IMAP logins using password instead of OAuth.
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 my usual accounts (not so complicated password) but not for the one with complex password. So I think the level of extra steps/security is linked with how complex your password is. Not so sure if this is a good thing or bad. But, I hope they should continue basing their security measures based on the security measures you take.
Maybe one reason is because google doesn’t know which account is trying to login before the login page, so how could they remember that security setting before attempting to serve JS?
I don't understand why anybody concerned about having JS on a login screen would want to log into Google in the first place. I imagine there's a tiny overlap between "Runs NoScript" and "Trusts Google"
> 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.
XSS vulnerabilities are everywhere. You obliviously don’t realize that.
Note that I do use js, because it makes life easier. But you got to realize that not using js will at some point protect you against an XSS vuln. They are that prevalent.
Running JavaScript means parsing text from outside source plus executing the program from outside source. Both requires really complicated code counted by the unit of M LOC(Mega Line of Code).
> The privacy loss of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated.
That's quite the hand-wave. How do you even measure privacy loss? And given that browsing history is not in your inbox, why are you so confident that one compromised email account is a bigger deal?
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.
Switching email providers is reasonably painless, fwiw. Set up forwarding, migrate mail when you can.
Even better if you set up the majority of your non-security-essential mail to be at your own domain, hosted by Fastmail/etc. Then you can easily change your email provider and your contacts don't even care. I've yet to implement this is in my own life, I just switched to fast mail - so I can't speak from personal experience on the domain portion of it.
NOTE: I mentioned non-security-essential email in reference to things like, your bank login or things that could threaten your life essentials. I say this because theoretically (and has happened before), using your own domain increases the attack surface area. My personal plan is to setup custom domain email with Fastmail, but still use the plain me@fastmail.com for my security focused emails. The majority of my email will still be based on my custom domain for easy portability, but I plan to avoid that for my bank, for example... assuming fast mail lets me.
I've recently switched to MacOS's built in mail client with IMAP to Gmail, never have to wait for my UI to do something. So count me in as surprised how far gmail has gone downhill.
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’m a little surprised to read this because Google Mail works fine for me in Firefox (ArchLinux). In fact it’s smoother than some of the Electron-based clients I’ve tried and less painful than trying to get push messages on Thunderbird working (sure, there is always IMAP but that requires regular fetches).
Same issue here. Mails not loading, poor initial load time. That is with zero extensions enabled.
I am now using mutt/notmuch/mbsync to prevent having to go through their horrendously slow web interface, and eventually move away from Gmail completely (probably to ProtonMail or fastmail).
> A context menu does a multi-second HTTP fetch before showing.
Where? The only one I can trigger that does any kind of network is in the inbox, and that's only to get some icons. The text for the options is already loaded.
When we have time we'll have to trace through what it's doing and what components of RFP are causing the failure. (If anyone wants to do that and report in the bug, we (Mozilla/Tor) would much appreciate the contributions!)
Google has becoming increasingly annoying. Every time I browse from work, where I have to use Internet Explorer, I have to suffer Chrome ads. They also require me to solve a Captcha every time I change the number of results per page via the search settings.
In the past few months all our domestic devices have gradually hit that notional condition with Google Search. All the laptops one by one, and then last night my phone. My wife's phone is the only one that can still use their search without a ten-round Recaptcha challenge.
As each device was locked-out from Google I switched the default over to DDG.
What is especially interesting is that this will allow Google to track you on more pages, but that in this case, you can by definition not block the tracker. I've checked, but reCAPTCHA just falls under the general Google Terms of Service.
I don't believe this to be done with that goal, but it is an unfortunate side-effect.
ReCaptcha is like Cloudflare's free DDoS protection: we like to point at these services and complain how people are "ruining the web" by using them because that's what we do on HN. We ignore the big picture and whine.
But I encourage everyone to consider a darker reality: that centralized services by large companies are becoming more and more necessary in a world where it's becoming easier and easier to be an attacker. The internet is kinda broken. Like how half the ISPs in the world don't filter their egress for spoofed IPs because there's no real incentive. That every networked device in every household could unknowingly be part of a botnet because we aren't billed for externalities.
Yeah, maybe it's kinda spooky that now ReCaptcha v3 wants to be loaded on every page. But is that really the take-away? What about the fact that this is what's necessary to detect the next generation of attacker? That you can either use Google's omniscient neural-network to dynamically identify abuse or you can, what? Roll your own? What exactly is the alternative?
Do HNers think this stuff is a non-issue because nobody has every attacked their Jekyll blog hosted on Github Pages (btw, another free service by a large company)?
reCAPTCHA can go frick off into a hole. I've stopped using all websites that use reCaptcha because it takes me sometimes 10 minutes to login to them. I also don't feel right providing free data so Google can help a military drone bomb children on busses one day.
They are such a pain point. Especially if you fill out a form accidentally, and have to go through the re-captcha again, and again and again for the most mundane of services.
"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.
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?
> 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.
I get this on my own computer that I've been using for 6 years on a static IP. It happens at least once a month, sometimes several times. Each time they ask for a phone number confirmation when no phone number is linked to the account (and never will be).
Google™ employees have come in and found mind-bending ways to excuse it when I've mentioned this before.
I also have no faith in their risk assessment. For a very long time I have only used one computer from one location to log into my Gmail account and every time I log in they consider it a suspicious activity. They even forced me to confirm my identity on my last login. What's their risk assessment doing if it can't get the baseline right?
It used to be the case that these checks are not in place when you're using 2FA. The downside is that you cannot use it without using a phone to register in the first place (though you can use your own generators afterwards)
They're giving you a free account to burst out mails with. Your account will most likely contain a lot of private or privileged information about other people, e.g. their mails, pictures, contact data, etc. You have a responsibility so why should you be allowed to reduce the security of your account?
> 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? Why? The 0.1% are the people who would like to know why they need it, but this message is written ironically for those who don’t know what JavaScript is.
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.
...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).
They are trying to detect state actor hacking and track individual devices and whether they are new or impersonations of devices.
Some states have mitm certs on all their domestic machines but (hopefully) not much competence except on whatever schedule they buy updates.
I would be implenting a u2f soft client in js if I were Google. IMO you need a private key a state would need to retrieve by tampering with js and that isn't being sent over the wire with every connection. (Just to give them their first level of headache, when it comes to transitioning from observing to impersonation.)
I'm not sure about you, but most people with js "disabled" don't browse with javascript disabled entirely, but instead use a whitelisting/blacklisting plugin, otherwise they don't be able to access many essential sites (eg. banks). under this setup, whitelisting google isn't going to decrease security unless you think they're going to serve a 0day when you sign in.
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?
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.
It is so difficult to explore anything that Google announces without passing it through the lens shaded by their ad business model. It doesn't matter with what intention they implement a change or if those intentions are pure.
Sure, this will make the login secure by preventing credential stuffing. But doesn't this also help them get more data from users who preferred not to by disabling JS? And was this the best and only solution to tackle this problem?
I believe internally too, Google must struggle with this perception.
Chrome team members have said that preventing modern web browsers from leaking enough entropy to uniquely identify users across sessions (fingerprinting) is impractical with all of the features that the modern web provides.
This sentiment has probably lead to some at Google to think that it is justifiable impose pervasive tracking and surveillance technologies as a condition for using Google services.
Look at the new ReCAPTCHA v3 to see how fingerprinting is trending at Google.
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.
Honeypots take care of most basic bots.
If you need captcha, you can use Math Question like in http://random.irb.hr/signup.php
You can also add extra security with time elapsed between loading the page and form submission, if it's less than 5 seconds it's most likely a bot.
Readit News
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 requiring here are designed to detect tools, not people. All mass account hijacking attacks rely on bots that either emulate or automate web browsers, and Google has a technology that has proven quite effective at detecting these tools. There's a little bit of info on how it works scattered around the internet, but none of the explanations are even remotely complete, and they're all years old now too. Suffice it to say: no JS = no bot signals.
Google had the ability to enforce a JS-required rule on login at least 6 years ago and never used it until now. Without a doubt, it's being enforced for the first time due to some large account hijacking attack that has proven impossible to stop any other way. After so many years of bending over backwards to keep support for JS blocking users alive, it's presumably now become the weakest link in the digital Maginot line surrounding their network.
For the people asking for the risk analysis to be disable-able: you used to be able to do that by enabling two-factor authentication. You can't roll back your account to just username and password security though: it's worth remembering that account hijacks are about more than just the immediate victim. When an account is taken over it's abused and that abuse creates more victims. Perhaps the account is used to send phishing mails to your contacts, or financial scams, or perhaps it's used to just do normal spamming which can - at enough volume - cause Gmail IPs to get blocked by third party spam filters, and user's emails to get bounced even if their own account is entirely secure. The risk analysis is mostly about securing people's accounts, but it's also about securing the products more generally too.
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 accounts are just used for browsing and bookmarking, without sending any outgoing information.
>When an account is taken over it's abused and that abuse creates more victims.
Pushing JavaScript everywhere increases the attack surface for every single user on the web. Except it doesn't happen overnight, and big companies who do it (by affecting standards, or by doing stuff like this ^) aren't affected by client-side exploits and privacy loss.
If someone hijacks my browser through some clever JS API exploit and steals my credentials, what is Google's response? "Just use our 2FA." What about smaller websites that don't have resources to maintain 2FA? "They should authenticate through us." All roads seem to conveniently lead to centralization.
BTW, it is worth noting that the impact of a compromised account isn't nearly as significant if a single account doesn't hold keys to pretty much everything you do online. Somehow this is rarely factored in during such discussions.
Well yes, these kind of accounts are highly susceptible to being bot accounts. What obligation does Google have to be the place for people's free, anonymous accounts? In any case, I haven't had a problem with the number of secondary accounts I've created that are tied to me only by another email address (which can point to another provider, like Yahoo).
> BTW, it is worth noting that the impact of a compromised account isn't nearly as significant if a single account doesn't hold keys to pretty much everything you do online. Somehow this is rarely factored in during such discussions.
How should this be factored into the current discussion? The use of JS is to ostensibly make it more difficult for automated hijacking to prey on users.
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.
I'm not going to say that providing 2FA is "free" in the time sense (both in implementing it initially and supporting people who lock themselves out) but on the surface 2FA requires just a library to verify 2FA codes and a column in your users table to store the shared secret.
I've snooped around a bit myself and it doesn't seem like botguard does anything much more advanced than other fingerprinting solutions.
I just don't buy that this is all about detecting more bots; every sophisticated bot I've seen in the ad world runs javascript as it's better to pose as a normal user, and only a tiny fraction of users would have javascript disabled.
To be honest, I also don't think requiring javascript is a bad thing either.
There didn't used to be any public bots that can beat the strongest version and from a quick Googling around I don't see that it's changed. Someone took apart a single program manually, years ago, but the programs are randomly generated and constantly evolve. So that's not sufficient to be able to bypass it automatically/repeatedly.
every sophisticated bot I've seen in the ad world runs javascript as it's better to pose as a normal user, and only a tiny fraction of users would have javascript disabled
It's a lot faster and more scalable to not automate a full web browser. Bot developers would rather not do it, they only do because they're forced to. Forced to ... by requiring Javascript, like this.
Do you have a source for that? As far as I know, most web based exploit came from any external plugin such as flash, pdf, videos, etc...
So are browsers...
> This is the login page - users are typing in a long term stable identifier already!
There are so many other considerations at work here though, and I can't imagine that they're not obvious to you as well? For starters, we're creatures of convenience, and this makes it significantly inconvenient to block google scripts on other websites even when not signed in. It also guarantees that you have the chance to produce a (likely unique) JS-based fingerprint of every google user that can then be used for correlation and de-anonymization of other data.
But really the most basic point that probably makes folks here suspicious: if this were really only about preventing malicious login attempts by bots, then why not give users a clear, explicitly stated choice: either JS or 2FA.
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.
Dead Comment
Dead Comment
The core issue is - it's all computers. The reason you can't reliably detect the difference between an average user using a computer to log in to your computer versus a fairly sophisticated computer using a computer to log in to your computer is that the transition between user and tool is not smooth. It is always going to be easier to find the various boundary points between user and tool than it is to construct a passable simulation of the user using that tool.
Yes, bot detection does make account hijacking attempts more expensive, but it makes all logins more expensive, and the rate of expense increases faster for you than it does the account hijackers.
so the way I understand it, roughly it works like this: JS tries to gather some set of information about browser's environment (capabilities, network access, reaction to edge-cases, …) sends it to google and google decides if they should allow user to continue authentication (by providing crypto signature of request+nonce or smth.like that… or just by flipping key in session)
It sounds untrue and short-sighted. Even Google provides the tools for anyone to automatically navigate in a javascript-enabled website with Chrome Headless. All this will do is to provide a short-term security before the bots can again perfectly mimic humans with JavaScript enabled, this time.
Most "mass bots" can be stopped by logging the access attempts on the server side, with plain old HTML on the client side.
That is to say, in the long run, it will be interesting if this actually reduces malicious use. Seems like it would be just as easy to avoid.
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?
I'm not going to discuss signals for obvious reasons. Suffice it to say web browsers are very complex pieces of software and attackers are often constrained in ways you might not expect. There are many interesting things you can do.
I have no idea how much effort Google will make to support old browsers going forward, sorry. To be double-super-clear, I haven't worked there for quite a while now. Over time the world is moving to what big enterprises call "evergreen" software, where they don't get involved in approving every update and things are kept silently fresh. With time you'll see discussion of old browsers and what to do about being compatible with old browsers die out.
Straightforward login API: that's OAuth. The idea is that the login is always done by the end user, the human, and that the UI flow is always directly with the account provider. So if you're a desktop app you have to open an embedded web browser, or open a URL to the login service and intercept the response somehow. Then your app is logged in and can automate things within the bounds set by the APIs. It's a good tradeoff - whilst more painful for developers than just asking for a username/password with custom UI each time, it's a lot more adaptable and secure. It's also easily wrapped up in libraries and OS services, so the pain of interacting with the custom web browser needs be borne by only a small number of devs.
https://support.google.com/accounts/answer/6010255
Um ... this should terrify everyone.
'We had the power to impose this, and we graciously chose not to. You should be thankful for what we have done.'
No. Just ... no.
Deleted Comment
Everything Google does is a ploy to boost ad revenue. That's the whole business model.
> Without a doubt, it's being enforced for the first time due to some large account hijacking attack that has proven impossible to stop any other way. After so many years of bending over backwards to keep support for JS blocking users alive, it's presumably now become the weakest link in the digital Maginot line surrounding their network.
You're doing two things here:
1. Reasoning from no evidence, and ignoring a much simpler reason in the process.
2. Acting like the honest web users, the ones blocking malware-laden JS, are the ones who are wrong.
It's much simpler to conclude that Google engineers simply got lazy and decided to punt the hard work of security to some JS library, instead of looking at it honestly.
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 of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated.
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.
People aren't underestimating the risk to _their_ accounts, they are discounting the risk to _others_ accounts.
That is, they're essentially saying, 'well, other users chose to have bad passwords, so bully them'.
I think that's a fair viewpoint to have. We've entered a world in which computer literacy is a basic requirement in order to, well, exist.
That said, what's reasonable, and what actually occurs, are two different things. A company isn't going to ideologically decide "screw the users that use bad passwords" if it loses them money.
So we get _seemingly_ suboptimal solutions like this.
There are a few things needed for that to be a good argument 1) Their security really is so good (I'd bet it isn't. I saw a tenured security professor/former State Department cyber expert get phished on the first go by an undergrad.) 2) Google isn't improving their security posture on top of that (I'd be shocked if Google isn't improving theirs, and I'm certain having JS required to sign into gmail closes a major hole in observability of automation) 3) There are real harms from the JS being there for their security/privacy posture (as I've said elsewhere, I'm unconvinced Google is allowed by their own privacy policy from doing anything untoward here)
As to your point about computer literacy and existence, I think the sad truth is that computer engagement is required, but literacy is optional. When that's the case, large companies are in the position of having to defend even the least computer literate against the most vicious of attackers.
2FA is a good defence against it, but lockouts are less as they attacker will be going broad and not deep (could be a single request per user account)
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.
Why is it not sufficient simply to throttle logins at the server?
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 variety of exotic fingerprinting, behavioral analysis, and other de-anonymization tech - not because anyone wants to destroy user privacy, but because the threat is that significant and has evolved so much in the past few years.
To be entirely honest, I'm kinda surprised Google didn't require javascript enabled to log in already.
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.
I don't think it's fair to blame them for the facts that most folks are not willing to give up passwords yet. Given that passwords are the current reality, shouldn't they do everything in their power to make them as secure as possible?
Sometimes one just wants an accurate depiction of a situation -- and those might still be totally accurate characterizations...
[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 ...
> [check] Allow sign-in from javascript disabled browsers. WARNING etc. (usual warnings about security etc.)
It sounds a bit like what Gmail's doing with their "allow less secure apps" login option, except that's more for allowing IMAP logins using password instead of OAuth.
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 my usual accounts (not so complicated password) but not for the one with complex password. So I think the level of extra steps/security is linked with how complex your password is. Not so sure if this is a good thing or bad. But, I hope they should continue basing their security measures based on the security measures you take.
The majority of Google's customers also don't pay for an account.
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.
Note that I do use js, because it makes life easier. But you got to realize that not using js will at some point protect you against an XSS vuln. They are that prevalent.
It's still under-esitmating.
That's quite the hand-wave. How do you even measure privacy loss? And given that browsing history is not in your inbox, why are you so confident that one compromised email account is a bigger deal?
https://news.ycombinator.com/item?id=18331159
Sorry, you don't have enough Google Points to browse the web. Please enable JavaScript and install Google Chrome.
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.
Even better if you set up the majority of your non-security-essential mail to be at your own domain, hosted by Fastmail/etc. Then you can easily change your email provider and your contacts don't even care. I've yet to implement this is in my own life, I just switched to fast mail - so I can't speak from personal experience on the domain portion of it.
NOTE: I mentioned non-security-essential email in reference to things like, your bank login or things that could threaten your life essentials. I say this because theoretically (and has happened before), using your own domain increases the attack surface area. My personal plan is to setup custom domain email with Fastmail, but still use the plain me@fastmail.com for my security focused emails. The majority of my email will still be based on my custom domain for easy portability, but I plan to avoid that for my bank, for example... assuming fast mail lets me.
I am now using mutt/notmuch/mbsync to prevent having to go through their horrendously slow web interface, and eventually move away from Gmail completely (probably to ProtonMail or fastmail).
Where? The only one I can trigger that does any kind of network is in the inbox, and that's only to get some icons. The text for the options is already loaded.
When we have time we'll have to trace through what it's doing and what components of RFP are causing the failure. (If anyone wants to do that and report in the bug, we (Mozilla/Tor) would much appreciate the contributions!)
In the past few months all our domestic devices have gradually hit that notional condition with Google Search. All the laptops one by one, and then last night my phone. My wife's phone is the only one that can still use their search without a ten-round Recaptcha challenge.
As each device was locked-out from Google I switched the default over to DDG.
I don't believe this to be done with that goal, but it is an unfortunate side-effect.
But I encourage everyone to consider a darker reality: that centralized services by large companies are becoming more and more necessary in a world where it's becoming easier and easier to be an attacker. The internet is kinda broken. Like how half the ISPs in the world don't filter their egress for spoofed IPs because there's no real incentive. That every networked device in every household could unknowingly be part of a botnet because we aren't billed for externalities.
Yeah, maybe it's kinda spooky that now ReCaptcha v3 wants to be loaded on every page. But is that really the take-away? What about the fact that this is what's necessary to detect the next generation of attacker? That you can either use Google's omniscient neural-network to dynamically identify abuse or you can, what? Roll your own? What exactly is the alternative?
Do HNers think this stuff is a non-issue because nobody has every attacked their Jekyll blog hosted on Github Pages (btw, another free service by a large company)?
I miss old captchas.
reCAPTCHA v4: please click on all the pictures of insurgents.
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.
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?
That's exactly it, there's already two Gmail accounts from high school I can't access despite knowing the passwords.
Google™ employees have come in and found mind-bending ways to excuse it when I've mentioned this before.
But just as you said, they are giving it away for free, so it is technically theirs, we are not paying customers. (Except for G-Suite users)
They don’t seem to explain why though? Did I miss it? Are they fingerprinting the JavaScript environment of my browser? Why? The 0.1% are the people who would like to know why they need it, but this message is written ironically for those who don’t know what JavaScript is.
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).
Some states have mitm certs on all their domestic machines but (hopefully) not much competence except on whatever schedule they buy updates.
I would be implenting a u2f soft client in js if I were Google. IMO you need a private key a state would need to retrieve by tampering with js and that isn't being sent over the wire with every connection. (Just to give them their first level of headache, when it comes to transitioning from observing to impersonation.)
Dead Comment
I don't particularly care that Google isn't letting you sign in without JS, but the message is just plain wrong..
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?
Blizzard entertainment does half client half server hashing which is rather clever, one of the few examples where client hashing makes sense.
Sure, this will make the login secure by preventing credential stuffing. But doesn't this also help them get more data from users who preferred not to by disabling JS? And was this the best and only solution to tackle this problem?
I believe internally too, Google must struggle with this perception.
This sentiment has probably lead to some at Google to think that it is justifiable impose pervasive tracking and surveillance technologies as a condition for using Google services.
Look at the new ReCAPTCHA v3 to see how fingerprinting is trending at Google.
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.