Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

261–270 of 529 posts

Re: JavaScript is now required to sign in to Google

#262
post #9

This is coming right after the reCAPTCHA v3 announcement 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.

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.

Re: JavaScript is now required to sign in to Google

#263
post #17

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…

That's why agent randomizers were invented

Re: JavaScript is now required to sign in to Google

#264

Earlier quoted context omitted.

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

Sure: https://www.cvedetails.com/vulnerability-list/vendor_id-1224... . 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 m…

[deleted]

Re: JavaScript is now required to sign in to Google

#265
post #123

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

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

Re: JavaScript is now required to sign in to Google

#266

Earlier quoted context omitted.

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…

Any advice on where to read more about these modern cred stuffing countermeasures? I'd love to learn more.

Fundamentally it's a question of fingerprinting the behaviours of humans versus bots. The problem is that it's becoming increasingly difficult to distinguish them, particularly when bots are running headless chrome or similar, and real users are automating their sign-ins with password managers.

I don't do much of this sort of thing, but numerous things come to mind. Aim to identify and whitelist obviously human browsers, blacklist obviously robot browsers, and mildly inconvenience/challenge the rest.

For example, an obvious property of a real human browser is that it had been used to log in successfully in the past. Proving that is left as an exercise for the reader, though it inevitably requires some state/memory on the server side.

Re: JavaScript is now required to sign in to Google

#267
post #223

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.

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

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

Re: JavaScript is now required to sign in to Google

#268

Earlier quoted context omitted.

>Do you wear a bulletproof vest every time you go outside? No? Interesting. You realize the bulletproof vest is the sandbox, right? You've just made an argument against enabling all javascript.

No, it's not. The lack of availability of guns is the sandbox, the cultural more of not killing people is the access controls. "Bulletproof vest" in this analogy is "extraordinary activity designed to keep you safe". You don't "wear a bulletproof vest" (a stand-in for "take extraordinary measures") to prevent yourself from "getting shot" (a stand-in for "thing that happens very rarely"). In other words, your assessme…

I'm not sure you understand how many entities are trying to get into your computer to track you/steal data/mine bitcoin/etc. These are active attacks against your computer every day if you are a regular user clicking viral shit on Facebook, random ads for things, etc.

Look at how many 3rd party JS libraries get loaded from remote sites for metrics, frameworks, tracking, ads, etc for something like a newspaper site. There are probably 15 servers involved, most of which run by companies with limited security expertise (if any) so frequently they end up compromised to inject garbage into visitors' browsers.

There is absolutely no lack of availability of guns or people attempting to use them on you in this analogy. The bullet proof vests are good, but that doesn't mean there isn't someone attempting to shoot you in the chest every time you go out.

Look at spectre/meltdown. Arbitrary code execution is not safe. Not in a browser sandbox, not in a kernel namespace, not in a hypervisor. You're protected from common thugs most of the time, but your bullet proof vest will fail if someone with a powerful gun takes aim.

There is a reason the CIA doesn't use the same AWS servers as the public and it's the same reason you can't view Facebook from inside a secure military network. Sandboxes are just a protection mechanism from well-understood attacks, they don't provide anything near the level of real isolation that Internet companies would love you to believe.

Re: JavaScript is now required to sign in to Google

#269
post #57
post #17

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…

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

There's a solution here that's being used in email. The user has to provide a proof of work.

Re: JavaScript is now required to sign in to Google

#270

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…

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.
Post reply on HN