JavaScript is now required to sign in to Google

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.

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.

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

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?

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.

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.

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.

Why is it not sufficient simply to throttle logins at the server?

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.

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

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?

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.

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.

I miss old captchas.

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.

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

Go take a look through Pwn2Own. Most browser exploits do not involve JavaScript. JavaScript can be a delivery mechanism for a certain class of payloads, but it's not the substantial weakness in browser vulnerabilities (as opposed to web application vulnerabilities).

Given that this isn't familiar to you, I'd recommend you reevaluate how confident you are in the JavaScript-focused defenses you've outlined in the rest of your comment.

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.

Of course, this fails to account for self-selection, a beehaviour has encountered before, in which increasing Youtube performance slowed average load times ... because users who'd previously found the site intolerably slow now found it slow, but tolerable.

(I've looked for the story, can't find it.)

Much as those who prefer to avoid use of Google won't appear in site use metrics. And enforced JS could well prove a deterrant.

NoScript makes a big difference with my laptop and a HUGE difference with my phone.

Asking this question on HN will have an extreme selection bias, sort of like asking "who really thinks aliens are vising Earth and abducting people?" in the Roswell UFO museum staff meeting.

Javascript is the new plugins (so much host OS functionality exposed now) and it requires a new click-to-play. I'd like to think they'll eventually integrate something like NoScript into the browser as a standard. This free for all code running is too much now that the browser is an OS.

But it's difficult to get browser companies to understand something when their income depends on not understanding it.

I'd say I browse the web normally. Plenty of sites load normally with scripts disabled (and may even be more pleasant to browse). Maybe a 25 to 40% of sites I hit I'll happily enable 1st party scripts and a couple of known CDNs that'll will be enough to have the site working. For I'd say 5% or less of sites I'll have to actually engage and think if the calls to a 3rd party api are required or if the cloudflare/amazon are actually part of the domain and there for a good purpose or may be being used to serve up nefarious code.

One of the things to consider about the above numbers is that they only really apply for the first time I visit a site. With exceptions for when a site changes how it's implemented (or a3rd party script calls a new domain) which is nice to know anyway. (Or when the tool I'm using to block scripts changes (3-4 times over the last 15 years + another couple for not transferring whitelist data to new machines)).

I wouldn't really recommend my approach as something to get into for 2 main reasons. Firstly because the web does work much nicer when you just turn scripts on and say 'to hell with the privacy and security concerns'. Secondly there is a fair bit of otherwise useless knowledge built up over the years of doing this that mean this set up is significantly less onerous than it would be for someone who only just starts doing it and needs to look up every 3rd party domain.

Having said that I would highly recommend that you should install some script management with the default more permissible settings (rather than my more draconian ones) as it breaks very little, takes little effort to fix most of the things it does break and will stop well known tracking and malicious sites.

The ones that do break tend to be the ones invading your privacy.

Most sites I use works fine without js. The few sites I need, that require js, are accessed from isolated, virtual machines dedicated to just that site. The sites I don't absolutely need, that require js, don't really exist in my world. That was a choice they made.

What leads you to a number like that? I can tell you that you're wrong, but I'm much more interested in how you got there.

Youtube needs javascript, and images or sometimes body text on badly-designed blogs need javascript. Most sites are fine. HN is fine, for the most obvious example.

Unfortunately El Goog is now a de facto monopoly both for makers (organic traffic) and users (AMP, discovery, federated logins etc).

I'm not angry at Goog for winning, they did it by (mostly) being 100x more awesome than the competition and surfing the network effects into the endgame. But here's the elephant in the room: outside walled gardens, Goog runs da tubes, and they're not as fluffy as Mr Cutts would have you believe. Mandatory JS and AMP are the not-even thin end of the wedge.

If there is one or two sites i really want to use in my main browser that need JS i can white list that site - but only exactly that site.

I am not an expert but it seems a better experience to me and i don't really think it make me less secure?

It's rare for major changes to arrive all at once. Small steps are taken, with each eventually becoming the new normal that allows another small step to be taken[2]. This isn't always intentional - each small step can seem rational at the time, in isolation.

[any replies complaining about "slippery slopes" will be ignored; the normalization of deviance does not mean change necessarily will follow, just that normalizing incremental changes allows people to support changes without noticing the larger picture]

[1] https://en.wikibooks.org/wiki/Professionalism/Diane_Vaughan_...

[2] https://en.wikipedia.org/wiki/Overton_window

Conveniently those both work with either fastmail, gmail, or any other popular IMAP-compatible email provider.

Really the question here is not "what's the harm of JS across the web" but rather what is the specific privacy cost of running JS on a sign in page and what is the security benefit of the same.

The worst case cost of JS on a browser is that you get a drive by download and your endpoint is owned. This seems unlikely on a Google domain.

The other, more normal, case is that a user is concerned about ad tracking. Providing an ad tracker on a sign in page seems pretty lame, and I'd be surprised, again, if Google was doing that.

The security upsides are likely several: anti-automation, anti-phishing, and an opportunity to track state-level adversaries who target users' Google accounts.

I don't know how others weigh these factors, but to me it seems entirely obvious that this is a good idea. Could the blog post have better laid out this case? Sure.

https://news.ycombinator.com/newsguidelines.html

This is a completely reasonable business decision and trade-off.

Almost everyone wants the features that JS enables. Literally: Almost everyone. I understand you don't, and I absolutely respect that decision, but it means that you're not worth developing for. Full stop. It's not a matter of mal-intent, it's a matter of financial logistics.

You bought that machine to run code. If you don't want to run code that sites serve you on the internet, don't visit them.

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.

I think you have this backwards; the vast majority of users like the benefits of js-enabled sites, so they get built. That ship has sailed long ago.