
JavaScript is now required to sign in to Google - amaccuish
https://security.googleblog.com/2018/10/announcing-some-security-treats-to.html
======
mike_hearn
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.

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

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

~~~
z3t4
I'm hijacking this thread to say we need a better ID system for the web! That
preferably work without JS. Something built into browsers, that also allow you
to create as many identities you want. When a id-signup header is detected,
the user see a signup button, and can chose what information is sent to the
web site/app. The user can login to any site with the push of a button, or
even automatically. With a built in public-private key ID solution your
friends will have the same ID-public-key on both site A and site B. The
contact list can even be inside the browser, and web site's can ask for it,
allowing for example white-listing in messenger apps, or let the user pick who
are allowed to see their family pictures, etc. And web sites/app no longer
have to store, username/password/keys, they only have to make a "challenge"
where the browser automatically proves the ID. The private key should be
exportable and standardized, and it should be possible to also use smart-cards
and second factor logins. Having ID built into the browser means every
site/app no longer have to build and manage all this functionality
independently.

~~~
plankers
This is brilliant! Has the IETF put out any proposals for a standard of this
sort or is this just an idea you had?

~~~
mikepurvis
Unsure if sarcasm, but OpenID has been a thing for over ten years, and the
only place it's ever gained significant traction is with Facebook and Google
as the providers:
[https://en.wikipedia.org/wiki/OpenID#History](https://en.wikipedia.org/wiki/OpenID#History)

Other than StackExchange, I can think of no other major site who looked at the
over-engineered protocol, the implementation headaches, the confusing user
experience (nascar board of provider logos), and said "yes, that is definitely
what we want to have rather than a validated user email address."

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

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

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

~~~
linker3000
I asked LastPass to generate me a long and complicated password for a new
Office 365 account only to have it rejected as too long because it was over 16
characters. Sigh.

------
c487bd62
This is coming right after the reCAPTCHA v3 announcement

[https://news.ycombinator.com/item?id=18331159](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.

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

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

~~~
nathanaldensr
I _can_ speak from experience regarding FastMail because that's exactly what I
did. In fact, I migrated off a grandfathered Google Apps account with my
custom domain to FastMail with that same domain. Yeah, it's a bunch of steps,
but I'm very comfortable with making DNS changes. My wife and I have an
account; it's worth every penny.

Also, FastMail allows for subdomain handling. I use this feature with nearly
every site. You can have *@<YourFastMailId>.<YourDomain>.com route to
<YourFastMailId>@<YourDomain>.com just as you'd expect. The way this handling
works is even configurable.

~~~
eco
I'm in the weird Google Apps for Your Domain limbo right now myself. I've
wondered what would happen if I switched to something other than GMail but
kept my google account with that email address.

I know a long time ago you could set up a Google account using a non-GMail
email address but I'm not sure if that's even a thing anymore. That's what I
want though. Keep the email address with my own domain that I've used for 17
years and just have a regular old Google account using that email (and keep
all my Google services and purchases associated with it).

Google has been absolutely terrible to Google Apps for Your Domain users (who
were often Google's biggest supporters back in the day). They've been shoved
into this weird second class status where their Google accounts only partially
work with Google services. I completely regret ever setting it up.

~~~
snowwrestler
You absolutely can set up a Google account with any email address you want.

[https://accounts.google.com/SignUpWithoutGmail](https://accounts.google.com/SignUpWithoutGmail)

I use Google services heavily at work, all on a Google account that was
created with my work email address. And we are not a Google shop; my
employer's email is self-hosted Exchange.

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

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

~~~
Bartweiss
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?

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

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

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

------
mattcoles
To keep your account secure, turn on Javascript?? If anything is making your
web browsing less secure, it's JS.

I don't particularly care that Google isn't letting you sign in without JS,
but the message is just plain wrong..

~~~
totony
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

~~~
NeoBasilisk
Who is sending passwords in cleartext on the wire?

~~~
yetanotherjosh
Indeed. And: who is hashing passwords on the client? As this would require
either not using a salted hash, or sharing the server's salt with the client,
in order to obtain identical hash values for comparison. In either case that
system's entire password inventory would be a lot more vulnerable.

TLDR don't do that, send passwords over SSL and use a good password hashing
algorithm on the server like BCrypt.

~~~
devy
Yep. Proper password hashing requires per-credential salt, pepper (for all
credentials) and a strong algorithm (IV, iterations etc.) Revealing all those
information is a leak and arguably making client side hashing less secure (by
giving away a lot of parameters for attackers to attack)

~~~
eropple
NIST may say that you should use "peppers" for passwords, but nobody else
does.

None of bcrypt, scrypt, or Argon2 use them and are not materially worse for
it.

~~~
devy
Yes, adding pepper is a recommendation not a mandatory step. But a lot of
sites do, I.E. PagerDuty [1], paired with PBKDF2 as many apps requires to meet
FIPS certification or enterprise support on many platforms.[2]

[1]:
[https://sudo.pagerduty.com/for_engineers/](https://sudo.pagerduty.com/for_engineers/)

[2]:
[https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)

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

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

~~~
mrep
Do you have a better solution for differentiating yourself as an actual user
from a robot spammer?

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

~~~
tzs
> Being allowed to pay for services with money, rather than being required to
> pay for services with your personal data

One possible big disadvantage for a site owner in letting people pay with
money instead of data is dealing with taxes.

I'm not actually sure how most jurisdictions tend to classify it when someone
comes to your site and you charge them to access your content. My guess would
be it would be taxed the same way they tax digital goods such as downloadable
software that does not include any physical components.

For such goods most jurisdictions that tax them seem to base the tax on the
buyer's location rather than the seller's location, so the seller has to deal
with charging the appropriate tax and filing returns for potentially a large
number of jurisdictions.

If the seller is providing the content for "free" and making their money
selling visitor data to advertisers then their income will probably only be
subject to taxation in their own jurisdiction. It will simply be ordinary
business income.

~~~
antt
My experience with taxation out side of the US, currently Australia, is that
they are ridiculously reasonable and probably more on my, that is the business
owners, side that I would like them to be.

It would be a net benefit for everyone, including the US, if it's broken
taxation system becomes a national emergency and finally gets fixed.

------
userbinator
What a bunch of, excuse the language, paternalist fear-mongering bullshit. _Of
course_ Google wants you to enable JS, because it allows them to monitor and
track everything about you more easily. Twisting it into "this will make you
safer" is sad and undeniably repugnant.

I've noticed a lot of other sites practically _begging_ you to "enable
JavaScript for a better experience", when all their content is static text and
images. I fell for that once, a long time ago --- enabled JS briefly to see
what the big deal was --- and was promptly bombarded with popups, slide-overs,
and even more ads. No thank you, I'll keep it off.

For many years I used IE6 with JS off (and a whitelist for a very, _very_
small number of selected and highly-trusted sites. IE has a "security zone"
feature which to my knowledge no other browser comes with by default.) Not a
_single_ malware infection, and that's despite often visiting the... shadier
parts of the Internet.

Browser exploits are almost all JS-based, and even the few that aren't, are in
practice deployed using obfuscation involving JS, to make analysis and
detection harder. Turning off JS effectively kills those risks as well as
other annoyances (blocking right-click, text selection, injecting crap into
copied content, etc.)

IMHO the advantages of not having JS on by default are underrated. I'd
consider ~99% of the sites I come across when searching for content to not
require it at all, which certainly is a stark contrast from the "you'll break
the Internet!" screams of the JS-advocates and "web designers". Sites that
"break" from not having JS, and which aren't specifically "appsites" but
mostly content-sites, are not worth visiting anyway.

Perhaps it's time to raise a counter-movement, and add (via <script> tags, of
course) "you have JavaScript turned on in your browser, this is a security
risk! Click <here> (link to appropriate page with all the risks and how to
turn it off) to learn more." Or "You have JavaScript enabled, please disable
it for a better experience."

If a certain vocal minority managed to demonise Flash (another powerful
technology that had major uses) to almost completely kill it, maybe the same
can happen for JavaScript?

~~~
throwawaymath
_> Browser exploits are almost all JS-based, and even the few that aren't, are
in practice deployed using obfuscation involving JS, to make analysis and
detection harder._

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.

~~~
dane-pgp
The security bugs found during Pwn2Own are usually kept under embargo, and
only published later by the browser developers. Here's an article about a
Chrome bug found in 2017's Pwn2Own:

[https://www.computerworld.com/article/3186686/web-
browsers/g...](https://www.computerworld.com/article/3186686/web-
browsers/google-patches-chrome-bug-from-fizzled-pwn2own-hack.html)

and it does involve JavaScript. Could you provide some recent examples of the
sort of browser exploits you mean, that don't require JavaScript? (I assume
you're not including exploits in extensions/plugins like Flash or PDF
viewers.)

~~~
throwawaymath
Sure: [https://www.cvedetails.com/vulnerability-
list/vendor_id-1224...](https://www.cvedetails.com/vulnerability-
list/vendor_id-1224/product_id-15031/opec-1/Google-Chrome.html). Also look at
Google Project Zero writeups, and similar CVE details for Firefox and Safari.

Some are related to JavaScript (notably, it's hard to exploit V8 if the
browser isn't processing any JavaScript!). But the vast majority are memory
corruption and sandbox escape issues.

Disabling JavaScript insulates you from a nontrivial - but nontheless minority
- subset of browser vulnerabilities.

~~~
userbinator
_But the vast majority are memory corruption and sandbox escape issues._

...which require JS to exploit. (What is a "sandbox escape" if there isn't
code to... escape it?)

I went through the 50 vulnerabilities on that page and looked at the nature of
them and inspected any PoC code if any. This is the results:

PDF,JS,JS,WebGL(JS),JS,CSS,JS,JS,extension,HTML(but PoC needs
JS),JS,PDF,PDF,MIDI(JS),AppCache(JS),PDF,JS,UI,WebRTC(JS),JS,JS(speech
recognition!?),JS,JS,JS,JS,JS,JS,JPEG(rendering uninitialised memory --- not
exploitable without JS to read that
data),JS(WebWorker),HTTP/SSL(!),SVG+JS,UI,JS,XML(!),SVG+JS,JS(audio),Fonts(actually
Windows font renderer bug),UI,??(no details
available),IndexedDB(JS),WebGL(JS),UI,JS(WebSockets),NaCl(extension),extension,PNG,WebGL(JS),?,JS,WebGL(JS)

That's 32/50 confirmed to require JS to exploit, and only 3/50 stood out as
being "visit a page with all plugins/JS/extensions disabled, and still get
pwned", of which 1 is actually a Windows bug.

 _Disabling JavaScript insulates you from a nontrivial - but nontheless
minority - subset of browser vulnerabilities._

Looks more like a majority to me.

------
todd3834
This seems reasonable to me. JavaScript is being used everywhere and most
people are okay with it. As a business decision I don’t see why Google would
support such a small edge case. That being said, if they feel like explaing
why they should maybe try a little harder. I assume most people with
JavaScript turned off might appreciate more details so they can decide how to
respond to the requirement. Then again, their current approach actually seems
reasonable to me.

~~~
dimgl
99.9% of users are okay with JavaScript.

~~~
cm2187
99.8% of users don't know what javascript is.

~~~
lerax
Thus only 0.1% of users know what javascript is and it's okay with it. That is
an interesting random stats, seems pretty realistic. I at least liked it.

~~~
ekianjo
Thats the wrong take on the stats. It means among the ones who know, half of
them dont want it. This is more telling that looking at the 0.1%.

~~~
paulcole
I think you’re confusing “numbers some guy made up” with “stats.”

~~~
ekianjo
No, I'm just following on the assumptions of the previous posts. Of course the
numbers are fictional.

------
amanzi
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 changing settings and reloading the
page would break my session. Long story short, I gave up on this and have
succumbed to running JavaScript for all sites again.

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

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

------
kps
Amusingly, the article is perfectly readable with javascript off, but with
only first-party js allowed, it's blank.

~~~
yesenadam
Ohh that _is_ interesting. Anyone know why that is?

~~~
cesarb
Blogger (which is what hosts this article) includes a copy of the whole
article within <noscript> tags. If you completely disable Javascript, the
browser shows the content of these tags, so the article is visible. If you
have Javascript enabled, even if all domains are blocked, the content of these
tags is hidden, so the article show as a blank page. You have to unblock the
third-party domains where Blogger hosts its scripts to make the article appear
again.

------
bonsai80
"But, because it may save bandwidth or help pages load more quickly, a tiny
minority of our users choose to keep it off"

Yeeaaah Google. Thaaaat's why we don't load JavaScript from you ;)

I get it they can't make this opt-in and expect many to use it, but it'd be
nice to see an opt-out be made available.

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

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

------
ddoolin
0.1% of Google's users is still quite a lot of users, is it not? Somewhere
over a billion, perhaps, which would mean 1 million+ with JS off.

~~~
dredmorbius
0.1% of roughly 4 billion would be about 4 million. Somewhat more in
pageviews.

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.

~~~
EpicEng
You stopped reading the single sentence in the comment you responded to about
half way through.

------
h43z
I tried to live with javascript disabled by default but gave up after two
months because all I did was white-listing every page I opened. Gave up on my
own side projects too. Building something that works with and without
javascript is just to much work for me and it becomes ugly quickly.

I still think modern websites over use javascript too often and should use
markup over code whenever possible.

And of course no one wants to go back to iframes to load dynamic content. Or
should we?

~~~
singularity2001
try again with noscript allowing main page by default but not 3rd party.

~~~
h43z
I think that most of the annoying (but non breaking) javascript is already
covered by ublock.

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

~~~
gvb
I browse with JavaScript disabled (NoScript) with a few sites that I care
about whitelisted. Most web sites work fine although their layout is sometimes
not what the web designer intended. Some sites don't work at all... for those
sites I generally hit the "back" button. When I enable JS to view "JS
required" sites, I usually hit the "back" button before it finishes loading
anyway so why bother.

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

~~~
PhantomGremlin
I browse same as you: Firefox & NoScript, very few sites on by default. My
experience matches yours with one other thing you didn't mention:

When I get a blank page, I do:

    
    
       View
          Page Style
             No Style
    

usually fixes things quite well. E.g. seattletimes.com is blank by default but
turning off Page Style gives me both text and images. Just not formatted very
well, but I'm willing to accept that tradeoff.

------
duxup
I'm not really sure how it works if you don't want to use JavaScript, do you
then whitelist sites that you're ok with it?

Wouldn't the solution for folks who don't want to run JavaScript just to
whitelist it for Google?

Maybe I'm missing something but that seems pretty simple, would let Google do
their thing and the folks who don't want to run it run it just for Google and
places they want to.

If someone already doesn't trust Google, I gotta think they abandoned their
products entirely already. Google's data collecting is so complete that JS or
not, same objections.

~~~
hnzix
_> pretty simple, [] let Google do their thing_

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.

~~~
duxup
It certainly is it's on monopoly, but at least for personal use folks who
don't like JavaScript can avoid it if they really want.

Just generally this decision for logins and javascript seems pretty... not a
huge deal IMO for folks who aren't a fan of JavaScript, whitelisting google
seems like a pretty simple choice.

------
arkadiyt
As others have mentioned, nearly the entire internet breaks without javascript
- it's a sad state of affairs.

One protection I like to use is to disable javascript that is loaded over
plaintext http - this breaks nearly nothing, and is easy to do via Chrome
settings: [https://i.imgur.com/NRVg5Xf.png](https://i.imgur.com/NRVg5Xf.png)

~~~
snowwrestler
Chrome will always block an HTTP javascript call by an HTTPS page. So given
the growing prevalence of HTTPS, I think this setting is probably doing less
and less for you.

~~~
yjftsjthsd-h
And therefore, this setting is safer and safer to enable:)

------
enriquto
This is a sad state of affairs. However, notice that once you are logged-in
into gmail, you can still disable all javascript and go to
[https://mail.google.com/mail/h/](https://mail.google.com/mail/h/) for a
somewhat reasonable user experience.

It is best to run gmail on a separate, private browsing window, so that it
does not interfere with normal web browsing (i.e., make sure that other
websites such as google search cannot see that you are actually logged into
gmail).

------
h2onock
I don't get the same behaviour as what is shown in the screenshots of the
google blog. If I go to Google, disable JS and click on 'sign in' I go to an
'account chooser' page. From there, no matter what I do I end up being
redirected to that same page. Not great UX from Google if others experience
the same as me.

------
bogomipz
The post states:

>"When your username and password are entered on Google’s sign-in page, we’ll
run a risk assessment and only allow the sign-in if nothing looks suspicious.
We’re always working to improve this analysis, and we’ll now require that
JavaScript is enabled on the Google sign-in page, without which we can’t run
this assessment."

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

------
ouid
I don't want google to protect me in this way. Can I opt out?

~~~
ravenstine
Don't use Google?

~~~
Figs
That is unfortunately not a practical option for many people whose school or
workplace forces use of GMail.

------
kakarot
We can argue back and forth about the pros and cons of requiring JS. But one
thing we can't argue about is the loss of security for political dissidents
and other non-protected groups who access Gmail or other Google services
through systems like Tor.

No, this isn't Google's problem, but it illuminates what kind of purpose
Google believes its products should serve, and what kind of people it should
serve.

------
monochromatic
I don’t remember the last google story that made me think “wow, what a cool
idea.” That used to be the norm. Now it’s “ugh what happened to y’all??”

------
martin1975
JavaScript is fast becoming, if it hasn't already, the next rich GUI
framework... It was supposed to be just touch up on HTML, now you can't sign
in anymore w/out JS enabled. What if I wanted to do a rich client in C# or Qt?
Do I need a JavaScript engine to sign in?

~~~
Spivak
Yes, plenty of apps allow you to sign in with Google -- they open up an
embedded web browser for the sign-in dialog and oauth permission screen.

------
dcow
Google is not in my internet hot path anymore. So, good for them. DDG &
ProtonMail work just fine.

------
Animats
How long until you have to sign into Google to search?

They already pop up messages trying to trick you into logging in to "adjust
your settings" or "improve your privacy" or some such.

------
lucb1e
So I'm wondering, all these automated detections and CAPTCHAs... how does that
tie in with automated decisions being made about you under GDPR? They're
trying to protect us from bots, but those decisions are also made by bots.
What if their bot makes a mistake? Does that count as an automated decision
under GDPR, for which I should be able to ask a human for a second opinion?

------
PeterHK
i have javascript disabled mostly to save bandwidth against nasty ads. Most
sites that requires JS i usually ignore if possible (seriously why do some
content provider think its ok to require JS?). For certain things like soon
google login i do just whitelist them. But by default if i do not trust your
site enough and/or its not that important in the end ill just close my tab

------
sireat
Thank you Google for making me investigate alternatives.

I am serious, I've been using gmail since 2004.

I realize some day my main account is going to be permanently inaccessible
just because I will be in the "wrong" country or will be using the wrong
browser in the wrong cafe.

There should be no need for Javascript with proper 2FA.

Your algorithms already make me solve ridiculous captchas "some" of the time.

------
marcrosoft
This reads like an April fools joke.

------
CivBase
Yah, but what if I _want_ to be able to log into my account using a script? I
know I'm in a tiny minority, but I have on several occasions had to use
selenium to automate actions on a web app. For this reason, captchas are
similarly annoying to me.

~~~
tetromino_
If you want to automate your actions, you should get an API key and use the
official APIs.

~~~
CivBase
I wish official APIs were available for everything I want to do.

------
ghop02
What many of the comments seem to be missing is that you don't need to enable
javascript on all google sites, only the sign-in page. With that in mind, I
don't think there needs to be as much concern as we're seeing here.

~~~
pdkl95
This kind of apology for a problematic change misses how allowing small
changes eventually _normalizes the change_ [1], allowing another similarly
"small" step to be taken in the future. Today it's "just the sign-in page";
tomorrow it will expand to cover something else because "it's already
something you're used to using on the sign-in page".

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_...](https://en.wikibooks.org/wiki/Professionalism/Diane_Vaughan_and_the_normalization_of_deviance)

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

------
rinchik
Is there an alternative to gMail? Just tried Protonmail and Fastmail, both
require JS.

~~~
TheDong
Yeah, use mutt or thunderbird.

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

------
scoot_718
Okay. No more Google account. So that means I miss out on... What exactly?

~~~
aembleton
The Play store if you're on Android

~~~
jgaa
I don't have a Google account on my new Android phone.

I get my apps from F-Droid, or I write them myself.

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

That's a gross misrepresentation, isn't it?

------
saagarjha
I find it kind of humorous that the "mobile demo" seems to have been made on a
Mac, complete with a cursor, and then resized to have a mobile border around
it.

------
coldacid
If you're an Amiga user, Google is now dead to you. As far as I can tell, none
of the browsers available for the Amiga platform support JavaScript.

------
colemickens
I try hard not to be a luddite as I age, but this level of automation and
machine learning is so concerning.

It is SO frustrating to accidentally appear as a bot and get stuck at the
mercy of an automated system. I was on some random site the other day and
spent 3+ minutes solving Captchas until it finally let me through. I thought I
was losing my mind. I don't spam, I don't automate queries, I come from an IP
that has two residential users (netflix, xbox traffic dominate everything).
Who knows what I did to offend the algorithm.

~~~
jgaa
Google captchas appears (to me) to be designed to identify individuals, not to
separate anonymous users from machines. Google want to know exactly who you
are, when they harvest your visits and behavior on almost all sites on the
Internet.

~~~
colemickens
I don't understand what this has to do with the fact that I repeatedly am
having to prove that I'm not a bot despite doing nothing that _ought_ to be
triggering Captcha checks.

But hey, I guess mentioning this simple observation is worthy of numerous
downvotes here. Always lovely.

------
justtopost
Goodbye google. Wanted to leave, but was lazy. Thanks for focing my hand, and
those of thousands more.

------
jgaa
Why would anyone who cares even a tiny bit about security or privacy ever want
to sign in to Google?

------
hpcjoe
This is unfortunate. On all my phones, I find the most annoying malware is
spread via javascript. I'll get onto a page I read a few times a day, and
suddenly, thanks to ads, I am served some javascript malware that attempts to
tell me "my PC is infected" or other such garbage.

I grouse, turn off javascript, clean my caches, and then everything is
copacetic for a bit.

If this means that, thanks to google's decision, that I _must_ in no uncertain
terms, have javascript on in order to interact with their product line, then I
need to weigh risks and benefits. Not proclaim loudly that I will run away
from the google ecosystem, as many are likely proclaiming in this forum.

But weigh the risks of using products which _require_ me to be vulnerable to
attacks, versus alternatives.

From the viewpoint of google, you don't want your customer to ever be in that
position. As it is an arms race against bad actors, and forcing users to
effectively lower their defensive posture means you really ... REALLY ... need
to up your game on value for this to be even net neutral relative to previous
state.

Given how completely horrendous google's customer support is, and how
incredibly hard it is to administer basic stuff (it took me more than 1/2
hour! to search and find out how to close an unused business g-suite account,
which I couldn't do, until I manually disconnected from a marketplace product
... where this disconnection was also hidden ... google doesn't do ux/ui worth
a crap, and has no real support for smaller users), I am not sure this is in
their best interests. I am sure there is a product manager trying to pull them
back from this ... somewhere ...

Or at least I hope so.

Basically the risk calculation is when where you look at something
holistically. Is using the google universe worth the risk that universe forces
you to accept?

Part of the reason that facebook is in user count freefall, is this inherent
risk. You are volunteering info that advertisers are dying to get, and they
are the ones paying facebook. You are a packaged product, you can be
microtargeted, and various bits of self-serving posturing over election non-
interference and account termination aside, they haven't quite grasped that
this intimate relationship brings substantial risk for participants.

I've dropped messenger from my phone, and am about a few months away from
dropping facebook from the phone. I don't need it there, and the risk to me is
far higher than the "value" it brings.

Back to google. You don't want customers thinking this. You want them happily
and securely playing in your garden. You don't want to force them to go out
without their armor. Turning off javascript strengthens that armor. Forcing it
on strips users of their most important armor.

Put more simply, bad google, bad.

------
Zelphyr
I'm getting tired of Google dictating how the web should work. That's the job
of standards bodies.

Google is increasingly taking the place of overbearing overlord that Microsoft
embodied in the 90's and early 2000's.

~~~
Operyl
Google is dictating how signing into their account system on their properties
works, not login forms for _every single site_.

~~~
greglindahl
Google's policies get exported.

For a long time it was OK to drop email that came from a server without rDNS.
Then gmail started allowing such emails, and then legit sites started sending
email from servers without rDNS.

In this case the export mechanism is Captcha v3.

~~~
asdfasgasdgasdg
So you're saying you're getting tired of everyone else copying Google's
behavior?

------
amelius
Just remember that CSS3 is already Turing complete.

------
largehotcoffee
Death to n o s c r i p t

~~~
Kiro
I agree. I instantly IP ban anyone using noscript on my site.

~~~
yjftsjthsd-h
If you're serious, I would much appreciate an explanation for why you would do
such a thing.

~~~
Kiro
I love JavaScript and hate NoScript.

------
modzu
coming soon: we noticed you are in private browsing mode. to keep your
browsing secure, please sign in with history enabled.

~~~
ndnxhs
Nooo, google wants you to think you are in private browsing mode so you share
more secrets with them. They will just collect it all no matter what you do.

------
draw_down
The correct, non-editorialized title is: "Announcing some security treats to
protect you from attackers’ tricks"

~~~
saagarjha
Both are editorialized. I think a better, more neutral title would be "Google
now requiring JavaScript to be enabled to sign in".

~~~
Wowfunhappy
I'm sure this is on me, but I'm genuinely not sure what the difference is
between your suggested title and what was used. (Obviously, I can see which
words you changed, but I'm missing the significance)

~~~
saagarjha
The title has been changed recently; the old one was significantly more
inflammatory.

------
throwawaynpc123
AI should be able to defeat it by copying real users, it would require a full
browser running tho.

------
naijabb
Talking of protection.

------
kwoff
How is this nonsense upvoted on hackernews..?

~~~
brunoTbear
It's surprising to me how many users on HN can only think as far as their own
browser.

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.

~~~
userbinator
I'm sure tracking everyone and controlling exactly what they can do will make
them safer. Why don't we put surveillance cameras everywhere and make them
record 24/7 too? </s>

Authoritarian ideology like this is what turned me off the whole "security
industry" years ago.

~~~
untog
Google already controls exactly what you can do... on Google.

You're arguing against ubiquitous surveillance, when the OP is arguing for
company surveillance of the way in which you interact with their login screen,
on their site.

------
dijit
I think this is a really braindead argument. Of course users are going to use
javascript more, the more the internet demands it, the more people will be
willing to allow it.

When I first started using noscript there were few exceptional sites which
didn’t work and I didn’t bother with them after, if that was the majority of
sites, I would probably just disable noscript.

The idea that I _have_ to let your site run code on my machine is only
laughable when it’s an exception, the problem is the industry. And google is
telling the industry that it’s ok.

edit: yes, I understand; I'm over the hill and you all absolutely love shoving
javascript down peoples throats, I get it. But please take a moment to
consider... not? maybe you have a financial incentive to avoid thinking about
the ramifications you inflict on others, maybe you're paid to be a JS dev. But
really, if you're making the web worse, I will not cry for being downvoted,
just know that I hate you. :)

~~~
horsawlarway
Sorry, but you're out of touch.

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.

~~~
nathan_long
> That said, I'd be willing to wager a fair bit that literally every line of
> code you've run on your machine (probably ever if it's been bought in the
> last few years) outside of the vendor installed OS and drivers came from the
> internet.

We explicitly decide to install software and we know where we're getting it
from. We may not be careful enough, but I certainly trust `brew install` a lot
more than I trust a random site I happen to visit.

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

I bought my car to drive it, but that doesn't mean that every person I pass on
the street gets to drive my car.

You seem to think that visiting a web site establishes a trusting relationship
with that site. I think that downloading a site's HTML and running its
JavaScript are quite different levels of trust. Especially when the content
and the code come from very different entities - eg, the journalist writing
the article vs the advertising network the publication uses.

Clearly if I'm using Gmail, I'm trusting Gmail and I don't mind running their
JavaScript. But the blanket statement that "if you don't want to run code that
sites serve you on the internet, don't visit them" seems out of touch with how
pervasively nasty the internet is.

Taking a walk on a city sidewalk does not require eating whatever you find
there.

~~~
horsawlarway
I think this is a reversal of responsibility. You're shifting the
responsibility from yourself to a different entity for the choices you're
making.

The single safest thing you can do while using the web is to simply be aware
of what you're clicking on, and what sites you visit.

> I bought my car to drive it, but that doesn't mean that every person I pass
> on the street gets to drive my car.

Damn right you don't let random people drive your car! just like I expect you
not to click every link you see!

I'd also love it if you'd install an ad blocker, remove just about every other
extension you have in your browser (ABSOLUTELY do this for old firefox
extensions and IE BHOs) and trust your browser when it tells you that maybe
visiting that particular site isn't the best idea.

That said, modern browsers do a really, really good job at isolating the code
running in that page from anything you care about.

~~~
plankers
Correct me if I'm wrong, but it seems that your personal philosophy places
absoluely none of the onus for the internet being dangerous and unfriendly on
the people who actually develop things for the internet. You instead blame the
layman who has no power to control how websites are constructed.

The heck?

~~~
horsawlarway
I'd disagree entirely. I'd argue that I'm aware of how much effort has gone
into making the web much, Much, MUCH more convenient and less risky for the
average, day to day user.

It's frankly stunning how much the ecosystem has changed just over the last
5-10 years. And I mean that as a developer who works in the security industry
with a focus on browsers/extensions. It's ludicrous how much more secure the
web of today is over the web of the past.

That said, it's not yet _secure_. There's always a risk/reward decision for
using the web, especially around _HOW_ you - the user - uses the web.

So to make an analogy: The infrastructure in place between root authorities,
the IETF, browser vendors, ISRG (Let's Encrypt is just one), and website
developers has done a DAMN good job in making the web less vulnerable than it
was.

It's a nicely paved two lane road that goes nearly everywhere.

That said, you are interacting with the entity hosting the site you visit, NOT
THOSE GROUPS, when you visit a site.

It's your responsibility to make sure you trust that entity, and do your due
diligence.

Just like I wouldn't try to drive my crappy 1998 Mazda Protege offroad - It's
dangerous and I would be unprepared.

Its your responsibility to make decisions for yourself (or at least I fucking
hope it is... that's a fundamental aspect of a democratic society that I
STRONGLY believe in). That means living with the consequences.

It can also mean choosing different service providers that are less convenient
if you deem the easy ones too risky. If you're not willing to do that (aka:
switch away from gmail if you want js disabled everywhere) and you still want
to complain... I find it hard to treat you seriously.

~~~
nathan_long
> It's your responsibility to make sure you trust that entity, and do your due
> diligence.

What does this entail? I mean, ask the average person if they trust the New
York Times, the London Stock Exchange, or Spotify. Those are well-known names
- sure we trust them. We trust that, as an organization, they are not plotting
to steal our identities.

But trusting them means trusting their business people, their IT people, and
their advertising partners, not only to be moral but also to be competent. And
whoops, all of them have served malvertising in the past.

Nobody has the time and expertise to evaluate every site's JavaScript every
time they visit. The "due diligence" you describe would be a very specialized
full-time job.

Whereas turning off JavaScript in the browser takes about 10 seconds.

~~~
horsawlarway
> It's your responsibility to make sure you trust that entity, and do your due
> diligence.

> What does this entail?

My whole point is that that's up to you to decide. No one else can make that
choice for you.

The VAST majority of people have decided that the risks they face today are
worth it, and continue to use the web with js enabled.

If you're not one of them, I absolutely respect that decision, but it means
you'll have to accept that companies are making financial and security based
decisions based on the behaviors of normal people.

That means that when spotify (and lets be honest, every other streaming
service) doesn't work without js, you go somewhere else, and use something
different.

That's the whole point I'm making. You can make any decision you'd like with
regards to your own security, you can make any decision you'd like with
regards to the sites you visit. But that site is free to act in it's own
interests, including adding features and services that target the majority of
their uses.

------
Ensorceled
A lot of the arguments in this thread sound like the people who don’t want to
vaccinate their kids. Right down to not giving a shit about “herd immunity” -
not caring if their hacked account is used to attack their less informed
friends and family.

