JavaScript is now required to sign in to Google
security.googleblog.com
security.googleblog.com
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.
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.
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.
In other words, the bot developers are still getting through, and meanwhile it's the actual humans who don't want JS which get screwed. Reminds me of DRM... honest customers are the most inconvenienced, while crackers still break it.
There's no perfect solution but any solution is still better than none. Why do you keep a lock on your door if I can break it in 30 seconds? Your computer is even there! I can easily add a key logger there, why do you have a password then if all I need is to do that? You aren't stopping me thus any protection you add is meaningless.
Let say that having a full web browser takes 50% more resources (if you block javascript, you probably already use the argument that it use 99% of your phone battery so you can agree that 50% is pretty conservative), than you just blocked 50% of the tentative JUST by requiring it. That's seems pretty effective already and you haven't done much yet.
Now add all the information that you can gather using Javascript. Aren't you also blocking Javascript because it's capacity to fingerprint you? Again another easy gain you can get.
> honest customers are the most inconvenienced
A tiny fraction of the honest customers are inconvenienced, a huge portion of them allow Javascript. They probably inconvenienced more by blocking older versions of TLS.
The point I'm trying to get across is that companies use these techniques because they are effective - it isn't as simple as "some junk that was beaten ages ago" - and the collateral damage is very small, relative to other techniques. Far fewer users run with JS disabled than the number of users who struggle with CAPTCHAs.
We can see the direction things are going with reCAPTCHA v3, which appears to be the logical end of the path Google started walking 8 years ago - reCAPTCHA v3 is nothing but risk analysis of anti-automation signals.
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)
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."
How would that work for sites like Hacker news, reddit, and twitter? Does every single user have to preview and approve every single other user on the website? That doesn't scale at all.
These days with browser/mobile sync, maybe it's actually possible. But like a synced password manager, it makes a primary account breach that much more devastating.
1. Education for and purchase of U2F keys 2. Key loss recovery mechanism 3. Key stolen defense (you can't just rely on the U2F key alone, there must be a pw or other type of second factor) 4. Widespread browser & device support (without it, a user/pass is required as a backstop)
Nevertheless, it is progress.
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...
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.
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.
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.
If that doesn't appear true for you, try over Tor and you'll see what happens to many people...
How does Google know you've hit a limit when you've registered new emails? And, not to belabor the point, but why should they be expected to give you unlimited number of free accounts -- or, what service do you recommend that will be that generous?
Oh that’s right, they’ll never give the consumer power over their data because that’s google’s entire value proposition.
But this is just cringe worthy. How do you propose getting your cash to said company? I mean, most methods will leak personal information the company could then use anyway.
I am not 100% whether they use geolocation, or just trigger this when your new IP doesn't match the last IP you logged in with.
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.
If you don't know the technologies the website is built upon or how much it will be impacted by increased barrier of entry for users, this statement is baseless.
I mean, some site do ask for way more than they need here and that's often bad. In the end, I think it's a reasonable trade off for end-use convenience. Which I often am.
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.
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.
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.
> 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.
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.
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.
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.
Sometimes one just wants an accurate depiction of a situation -- and those might still be totally accurate characterizations...
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?
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.
You're right on, but I wouldn't call it sad.
The population is expected to operate vehicles without putting others in danger, not credentialize in how cars work. There are endless amounts of things we could demand people spend their precious time deeply understanding. We just like to demand tech-savviness because it's self-aggrandizing.
Like everything else, the solution is to help people on their own behalf.
At an online casino I once worked at, we ended up generating random passwords for our users. We had to, because otherwise attackers would lookup usernames in the large password dumps online and log in as our users. No amount of warnings on our /register page stopped password reuse. So we decided we could do better than that, and that "well, we warned you" was not an appropriate response.
If you look around at everyday objects, everything is designed to protect the user. But for some reason in computing we're still in the dark ages of snickering and rolling our eyes at users for making mistakes.
Exactly! We require "car literacy" in drivers before we allow them to use them. Pretty much every advanced economy has mandatory driver licensing.
A driver can trivially press a few levers and slam themselves into a barrier at 100mph. But they don't do that, because they know, through experience and education, that it's a terrible idea.
That's the exact opposite of the approach that would have cars restrict their own usage into a narrow set of patterns and refuse to function otherwise.
WRT the last half of your comment: I think that's reasonable. Generating random passwords for users is a fair approach.
Account security exists on a spectrum. I don't think anyone (reasonable) is arguing against that, we're talking about mutable state here, actual _actions_.
What I'm railing against, is this idea that every webpage on the internet needs to be behind a CAPTCHA that does a bunch of invasive data collection including probably asking the user to perform a Mechanical Turk task in order to _access a website_ without even logging in.
It happens all the time. A website doesn't like my IP block -> forced through a bunch of nonsense. The site operator probably isn't even aware because they're using an upstream service which does it for them.
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.
Why is it not sufficient simply to throttle logins at the server?
User Id?
So for example LinkedIn has a breach, which reveals to evildoers that user 'johnsmith@example.com' uses the password 'smith1234' then they test that username and password in Amazon, Netflix, Steam and so on.
They only make one attempt per account, because they only have one leaked password per account. Hence, throttling per account isn't an option.
There was automated tools that did this too!
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.
The most drastic example I can think of was an unverified rumor that a certain company would "fake" log users in when presented with valid credentials from a client they considered suspicious. They would then monitor what the client did - from the client's point of view it successfully logged in and would begin normal operation. If server observed the device was acting "correctly" with the fake login token, they would fully log it in. If the client deviated from expected behavior, it would present false data to the client & ban the client based on a bunch of fancy fingerprinting.
Every once in awhile, someone will publish their methods/software; Salesforce and their SSL fingerprinting software comes to mind: https://github.com/salesforce/ja3
https://link.springer.com/chapter/10.1007%2F978-3-319-07536-...
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.
It's still under-esitmating.
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.
1. Preventing interception of passwords on the wire
2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because the web site chooses what they do and could make them mine Bitcoins) or rewrite their brute-forcer each time the JS-driven network communication channel is altered
It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification...
Isn't this solved by https? I have no idea, but I hope at least that https protects my passwords.
>2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
I don't want to wait for a login more than a second. Actually, I don't want to wait at all.
>3. ... or rewrite their brute-forcer each time the JS-driven network communication channel is altered
How is this different from altered HTML/CSS? An attacker has to adapt to the altered login page. It is not an argument for javascript.
>It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification...
You say it: a protocol! not a piece of javascript.
Neither do I. But I also accept that, given the sheer volume of stolen creds and bots out there, sites that damage their bang/buck performance, even at the cost of very minor inconvenience to users, are likely to be targeted less frequently and in lower volume. Even if I wasn't begrudgingly willing to pay that price, I'd at least admit to the logic of making the process more time-consuming as a deterrent.
Do you log in that often?
"Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.
> 1. Preventing interception of passwords on the wire
It can, but challenge-response that isn't PKI based requires the remote side to have the secret stored or the local side to know how to generate the value that is stored instead, which goes against other recommended practise (with PKI the remote side can store the public key and ask for something to be signed with the private key).
Protecting passwords on the wire is better done with good encryption and key exchange protocols - in the case of web-based systems that is provided by HTTPS assuming it is well configured.
> 2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
Could you give an example of that? If you are tuning difficulty based on the computation power of the other side, surely the other side could lie about being low powered and get an easier challenge?
> 3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because...)
A knowledgable attacker doing this would be safe: they'd make sure the interpreter was properly sandboxed (to avoid reverse hacking) and given execution resource limits (to avoid resource waste). Then if the site/app is important enough that they really want in, they modify their approach if the resource limits are hit.
> or rewrite their brute-forcer each time the JS-driven network communication channel is altered
If your method is only used by you (and you aren't a Google or similar so you are big enough to be a juicy target on your own) and you enter into this arms race you might find it takes so much resource that it gets in the way of your other work. You are only you, the attackers are legion: put one off and another will come along later. Also there is the danger in rolling your own scheme that you make a naive mistake rendering it far less useful (potentially negatively useful: helpful to the attacker!) than your intention.
If the method is more globally used then it is worth the attackers being more persistent.
> It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification.
It can, though often only against simple fully automated attacks. Cleverer automated attacks may still succeed, as may more manual ones, and targetted manual attacks will win by inspection & replication.
Or they get in through an XSS, injection, or session hijacking bug elsewhere (bypassing the authentication mechanisms completely) that you missed because you spent so much time writing an evolving custom authentication mechanism.
Have the server side not know the password
And be secure against replay attacks given attacker access to plain text.
The scheme is something like:
Setup
Server generates key (x, xG) where G is some elliptic curve base point. It stores x and sends xG to the client.
The client computes y = H(password) and sends yG to the server.
The server stores the shared secret. x (yG)
Authentication:
Server generates nonce r and sends r xG.
Client computes y = H(password) and responds with y r xG
Server verifies that the response equals r (x yG).
End
In this protocol, an attacker with access to plain text, even during setup, still can't do anything.
This method is weak against MitM, but that can be solved on auth by doing a fully ephemeral diffie helman there.
I concocted this scheme on like 10 minutes, so there might be mistakes, and it os probably suboptimal.
Client-side js will always be readable, even if you obfuscate it, you can't trust it to never being decompiled.
But server-side js never has to reach the client, it can be used to dynamically generate basically anything.
But with security at this level nowadays every added layer helps. Even if it is not even used in the initial authentication step. Think of classifying certain patterns in the attacks and retroactive de-authorizing after login, increasing the time-cost for the attacker.
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)
Even as a newcomer without the right contacts on the black market you can get started with very little upfront investment, using services like https://luminati.io/ (they pay software developers to bundle their proxy endpoints within their apps).
[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 ...
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.
> [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.
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?
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.
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.
It's just horrible to use in firefox (in arch linux) and I'm currently looking for a new provider.
I might just go all in and use protonmail.
https://protonmail.com/support/knowledge-base/custom-domain-...
This could really just be that part. I have a hard time imagining explicit sabotage of FF on the gmail frontend. The likeliest explanation is that perf testing and the like only happens in Chrome
It's tricky to share a screen recording because there's personal information. But I just did two for my own curiosity. From a fresh load, once the "Loading Gmail" screen has gone away, it took 8 seconds and 11 seconds respectively from clicking 'Compose' to having a new window open.
Maybe there is variability. There are a million combinations of factors out there. I suppose as an engineer you make the trade off of "do I hope for the best case" vs "do I make something that works for a broad audience". The previous version shows that they can make something that works for my own anecdatapoint if they want to.
>ten seconds to load your inbox
>16 GB, i7, SSD, 100 MB/s internet etc.
>fine
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 still can't believe how fast the UI is. It's by far the fastest web app I've ever used, and the same goes for the service in general.
Seriously, just ditch Gmail now, the alternatives are great.
I've looked at nextcloud, but IIRC, you have to have the whole suite installed, right? I'd love a way to just use the calendar function.
It does let you, you can create as many aliases as you want (I'm assuming) on any of their or your domains.
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.
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.
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.
Using FastMail-specific features will lock you into this specific vendor once again, one of the main reasons to switch in the first place!
Using a subdomain for catch-all is great because spammers can’t easily discover and flood the subdomain.
That being said, FastMail is also the leading developer/champion of a new mail standard called JMAP, which supports both labels and folders. I suspect, therefore, if it takes off, they may consider supporting labels themselves.
That’s what I eventually switched to and it works fine.
Thunderbird might be superior, but I really like that App because it's so light and fast.
I wrote software using Cocoa about a decade ago (so I may be out of touch), and it was clear how much thought and effort had gone into making the user interface responsive. And it generally shows.
The idea that you would just give up on that precedence is baffling. And let's face it, email's important but it's not rocket science.
[0] https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
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.
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).
I don't use Thunderbird myself - was just following the discussion on from the OP who did use it. However I've yet to find a client I like so genuinely interested in any suggestions you might have.
I used TB until two years ago, but I gave up with it's unfixed bugs and quirks. I do prefer graphical clients, but not if they are clunky or buggy.
I used Silpheed and Claws for years, but Silpheed locks (or used to lock) the UI during fetch (unacceptable IMHO) while Claws has some critical bugs in the filter/rule logic that made me lose mail in several occasions by refiling into the wrong folder while processing a lot of messages. If you arent't a heavy filter user you might be fine with it though, I think Claws gets a lot of things right.
KMail wasn't bad when I used it, but it was too long ago to make an honest comment today.
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)?
So no: the take-away is that this improves reCAPTCHA. A side remark to that is that it also improves Google's ability to track you, and hampers your ability to fight that.
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.
That's exactly it, there's already two Gmail accounts from high school I can't access despite knowing the passwords.
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)
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?
Google™ employees have come in and found mind-bending ways to excuse it when I've mentioned this before.
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.)
I don't particularly care that Google isn't letting you sign in without JS, but the message is just plain wrong..
And if you don't trust HTTPS to protect sensitive information, why would you send the auth cookies over it that have virtually as much power the password that was given in exchange for them in the first place?
There is no reason you can't also salt on the client. Salts do not need to be secret. The substantial constraint you outlined in your comment isn't a problem.
If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.
E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.
Take a look here: https://arstechnica.com/information-technology/2018/05/twitt...
Of course, a hash that you will recive from client should be treated as a normal password including all good practices.
Hashing the password before sending it doesn't really help you much - the naïve approach is vulnerable to "pass-the-hash" (where you basically send the hash instead of the password as the authentication token). The secure approach involves either some kind of challenge-response or a nonce salt, but these aren't as easy to implement correctly.
So, not cleartext over the wire then.
Furthermore, pre-hashing doesn't necessarily make transmitting confidential information safer, as one would argue that your client side javascript can be reverse-engineered and give the attacker more information about how you hash your data.
pre-hashing doesn't prevent an attacker from stealing your account if it can read the communication, but it prevents it from having your password and using it everywhere else where you might re-use the password or a permutation of it
Ideally, if TLS was being MITMed somehow such as a dodgy root cert. It would shield the users plaintext password so it could not be used to login into other services. The problem is as soon there is TLS issue an attacker can modify the Js to just send the password in the clear. It really would require code that can't be modified by attacker. This means that there would have to be some sort of browser support. Otherwise it does nothing against the attack it would protect against.
The main benefit is offloading some computation workload on the clients machine. This could allow you to increase the work load required to brute force the password hashes assuming your database leaks. (aka increase iterations or memory requirements)
You last argument is security through obscurity if exposing how you hash makes it easier to brute force the passwords your password hashing sucks.
TLDR don't do that, send passwords over SSL and use a good password hashing algorithm on the server like BCrypt.
None of bcrypt, scrypt, or Argon2 use them and are not materially worse for it.
[1]: https://sudo.pagerduty.com/for_engineers/
[2]: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Your password _is_ whatever you send over the wire. Doing a hash in JavaScript before sending it won't obscure the user's password from anyone who can see their traffic; it will obscure the user's password from the user.
Why would you want to see actual user password if you can just not see it?
If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.
E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.
Take a look here: https://arstechnica.com/information-technology/2018/05/twitt....
Of course, a hash that you will receive from client should be treated as a normal password including all good practices.
So, there are properties that differentiate "password" and "5f4dcc3b5aa765d61d8327deb882cf99", even if for the server it's all the same.
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?
It stops a compromised server from silently leaking unhashed passwords.
It makes password hashing user auditable.
You could even do a call and response model to stop the hashed password to log in at all. Here is a primitive scheme for such a model (public key crypto probably enables more clever schemes, not sure):
- Upon signup, generate hashes of "$password$site$i" for i in 1 to 1000. Send these to the server and have the server hash them again.
- Upon login, after the user has entered their password into the box, send an integer from i from 1 to 1000 to the browser, have the browser send back the hash of "$password$site$i".
Now a compromised hash can only let you log in 1 time in 1000. Combine that fact with the other available signals for "is this who we think it is" and you should be able to reject people who stole the hash reasonably reliably. Meanwhile since you are still hashing the password on the server (again) you have lost literally nothing but a tiny bit of computation time.
There's nothing stopping you from hashing your own passwords client side and sending your bcrypt hash up to the server except some sites still truncate the passwords to 32/16 chars etc.
When you have the need for the level of security, client side hashing will not be as good as dedicated HSMs that many services now use on authentication.
Writing your own crypto flows can be extremely dangerous as you open yourself to all kinds of side channel attacks.
As for writing my own crypto. Indeed, if anyone actually used the scheme I suggested they would be making a mistake. I wrote it not to be used but to demonstrate that we can do better in an easy to understand way. Unlike me, Google has the resources to read the papers, do the math, carefully implement this, and do it properly.
Keywords for how to do it properly include "zero knowledge password proof" and "password authenticate key exchange".
PS. It's irrelevant to this conversation, but putting all my passwords into one program has always struck me as a monumentally stupid idea. I use one for passwords I don't care about, I memorize unique passwords for passwords I do care about.
If you trust the site to deploy correct JavaScript to do this, then that's the same level of trust that they implemented password salting and hashing server side. You don't gain any robustness by moving this to JavaScript.
Your scheme is just a weak salting technique. You'd be better off with just using a longer salt and hash function.
I can trust the site to deploy the correct javascript more than I can trust it not to steal passwords because
- That is auditable - it is impossible for a malicious site to do so without risking being caught.
- The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.
Hardly. Minimization and obfuscation is trivial, and you can ensure the output is always different in order to defeat auditing. Not great for caching obviously, but 'auditability' is not achievable if the server is determined to fool you.
> - The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.
Password are simply not where you want to leverage your security. If you can find a document example of a real threat that this approach would have mitigated, then I'll take it seriously.
The downside is not a tiny bit of computation time. It's also increased latency for the customer.
If the server is compromised, then there is no protection of your cleartext password at all. This is because the entity that compromised the server can replace the original JS with anything, including new JS that sends your cleartext password off to their own host as you type each character.
The only activity on your part that can save you against comprimised servers is having a unique password per server (i.e., not reusing any passwords).
An example of where it might work is in an app, where you're getting the client code from a separate channel like an app store.
About client side benefits. I'm not advocating for JS in the browser but there are benefits to doing some work client side.
Blizzard entertainment does half client half server hashing which is rather clever, one of the few examples where client hashing makes sense.
The best protocol I know of is to derive a signing keypair from your (salted, stretched) password, and store the public key on the server instead of a password hash. Then during login, the server sends a challenge to the client, and the client signs it. The server never sees any secret material at all. Keybase uses a version of this protocol.
Unfortunately all the magical client side crypto in the world doesn't save you if the attacker can compromise your server and then send clients bad JS :p
Why would you want to see actual user password if you can just not see it?
If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.
E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.
Take a look here: https://arstechnica.com/information-technology/2018/05/twitt....
Of course, a hash that you will receive from client should be treated as a normal password including all good practices.
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.
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.
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.
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.
I can keep you out of your account indefinitely with a curl loop and a rotation of proxies?
Rate limiting is completely ineffective in preventing credential stuffing attacks from determined adversaries. The challenge is not brute-forcing, but credential leaks and password reuse. Attackers have access to vast seas of IP addresses and in my past life doing the defending, we would see an IP address involved in automation twice, and then it would go away forever.
Only if there isn't some shared knowledge between the website and prospect.
For example some niche websites that I use have locally-based challenges such as 'how many engines can be fitted to a Boeing 747-400'* or a short mathematical algebra to solve.
Both approaches work without Javascript and without external support, just with a two-column table and a trusted group of challenge-creators.
* it's more than four
Because the reason why https://en.wikipedia.org/wiki/Hashcash wasn't useful for anti-spam after all is because attackers have access to the cheapest compute in the world: botnets and devices that aren't their own.
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?
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.
That's exactly what I'm saying --- in the real world, exploits tend to be wrapped in JS even if they don't technically need it.
but it's not the substantial weakness in browser vulnerabilities
Then what is? My real-world experience also correlates.
HTML (non-JS) parsing, memory corruption, image processing, filetype validation and process isolation/sandboxing.
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 including exploits in extensions/plugins like Flash or PDF viewers.)
...is also JavaScript-related: https://bugzilla.mozilla.org/show_bug.cgi?id=1348168
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.
If someone is choosing to disable JavaScript in their browser, I think it is reasonable to expect they are also disabling plugins for other formats like Flash and PDF.
We might disagree about whether to include disabling plugins as part of disabling JavaScript, or how to count the "unspecified vectors" CVEs, but the clearest minority is this 25% of vulnerabilities that a JavaScript (and plugins) disabling user would fail to insulate themselves from.
...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.
Google will be in hot water if humanity ever decides to take on javascript.. assuming the source for those states aren't someone's ass.
Which, of course, isn't true to begin with.
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.
I've faced the same problem a lot, and what I really need is a way in ublock/umatrix to turn it off for the current tab, even as it jumps across several domains. But this doesn't seem to be an option. Am I missing something?
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.
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.
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.
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?
Most websites are made of text, I usually want the text, not whatever program they're running.
NoScript makes a big difference with my laptop and a HUGE difference with my phone.
When I get a blank page, I do:
View
Page Style
No Style
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.
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.
OTOH, web works faster with uMatrix. You can probably get an extra couple years of your computer if you're aggressive about disabling ads and superfluous JS.
The ones that do break tend to be the ones invading your privacy.
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.
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.
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.
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.
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.
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.
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
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 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).
>"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.
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.
They already pop up messages trying to trick you into logging in to "adjust your settings" or "improve your privacy" or some such.
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.
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_...
Conveniently those both work with either fastmail, gmail, or any other popular IMAP-compatible email provider.
I get my apps from F-Droid, or I write them myself.
That's a gross misrepresentation, isn't it?
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.
But hey, I guess mentioning this simple observation is worthy of numerous downvotes here. Always lovely.
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.
Google is increasingly taking the place of overbearing overlord that Microsoft embodied in the 90's and early 2000's.
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.
https://html.spec.whatwg.org/multipage/scripting.html
"Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting."
"Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support."
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.
You might as well say people shouldn't take precautions swimming around sharks, because it's rare and be surprising if they attacked
You're signing in. That's literally asking them to identify you across pages so you can have access to them.
Signing in is literally asking them to identify you on one page so you can have access to that page.
keyword being "too".
> In fact, I don't think I've ever enabled Javascript here on Hacker News.
I mean, that's super, but it's just one more point in the column of how HN's population is out of touch with any regular person. It's really annoying to wait for the page reload on even a fast network, and good luck finding your place again if a thread is even moderately busy.
Back to your main point. I don't think it's out of touch. It's different information or values. Do you think it's not annoying for me to not have JavaScript and have slow or broken pages? I know and feel the same thing, and I imagine anyone using no script does as well. It's just not worth it to me to let privacy be degraded for some speed.
I think this is due more heavily to being more informed about the situation than the average person, rather than different values. When Facebook starting getting in the news about all their privacy violations, Facebook MAU went down and the number of accounts deleted went up. That indicates that once people are aware of what is going on, they make similar choices about interacting with the companies.
The difference between many people on hacker news and the average populace is that we can both install something like noscript, and have a rough idea of how to interpret the options on it.
In any case, you don't have to search for your place again, because the browser reloads with that comment on the top.
Authoritarian ideology like this is what turned me off the whole "security industry" years ago.
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.
This is a completely reasonable business decision and trade-off.
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. :)
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.
"javascript adoption in the browser will increase in future, therefore we will enforce javascript"
is like saying:
"more people will have passports in future, therefore we require passports to get a bus pass".
By doing that; you make it true.
I bet you've also installed client side applications that came from the web, on a vendor installed OS that came from the web, and drivers for your machine that came from the web.
??
??????
Really? You honestly don't see a difference? I have a chain of trust with my OS manufacturer (apple) and a defecto trust with a centralised entity for most of my applications (IE; my company for things that we build, or the home-brew project for most other packages)
I should not have that trust with any idiot who manages to get a signed SSL certificate; IE: the whole internet.
https://developers.google.com/web/fundamentals/security/csp/
To quote the signature section:
'<hash-algorithm>-<base64-value>'
A sha256, sha384 or sha512 hash of scripts or styles. The use of this source consists of two portions separated by a dash: the encryption algorithm used to create the hash and the base64-encoded hash of the script or style. When generating the hash, don't include the <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace. See unsafe inline script for an example. In CSP 2.0 this applied only to inline scripts. CSP 3.0 allows it in the case of script-src for external scripts.
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.
Javascript being enforced allows for a sub-par slew of web development which does not cater for performance(minor) or accessibility(major).
I dislike the trend of _forcing_ people to do something that doesn't benefit them. Even if I'm not personally affected.
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.
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.
The heck?
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.
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.
> 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.
I would rather have more control over what gets scraped from who-knows-where and ran on my machine than not.
You have not lost that control.
Why does this matter in the context of this discussion?
If you choose to visit that news site, you're trusting their web developers. You can always manually go and setup tools and systems to block those 3rd party requests (like I mentioned earlier, an ad blocker is a great first step, because it's easy and automatic). If you're not willing to take those steps...
Don't use the site.
This would be accurate, if watering hole attacks[1] weren't a thing.
To reframe - my statement is akin to saying: the single safest thing you can do while driving is to pay attention to the road.
And you responding with: "This would be accurate, if trees falling on you weren't a thing."
Sure it's a risk, it's not the primary risk.
This seems like a fundamental misrepresentation of how malware is distributed, and how privacy is compromised. People are responsible for the sites they choose to visit. They're not responsible for what those sites serve them, because they can't evaluate it until it's already been served. I don't know what a page will serve me until I visit that page. I can't.
Holding people responsible for whatever content they're served on a page is the same sort of "suck it and see" logic we rightly rejected with "by opening this package, you have consented to the terms of this license". It's a concept that's fundamentally incompatible with informed agreement.
If you want to hold people responsible for clicking "crack DRM now!" ads on the Pirate Bay, fine. But malware doesn't necessarily require outbound clicks, and doesn't necessarily come from dubious sites. Forbes locked out adblockers and served malware through their ad network. Xfinity, the NYT, ebay, Youtube, the Atlantic, and a dozen others major sites have served malware. Newegg, British Airways, and probably Ticketmaster were hit by Magecart, which infected even users with adblockers running.
Why do I disable Javascript? It's not because I don't think I'm responsible for my safety online. Precisely the opposite - it's because I'm not relying on other parties! Magecart was running on major sites two months ago. Adblock, an up-to-date browser, and responsible surfing didn't keep people safe, but uBlock did. A framing where users are accepting any code that ever appears on any site they visit is a framing where we all ought to abandon the internet outright.
The difference is that I can interact with any number of people, yet only trust a few to drive my car.
You seem to suggest that I should trust everyone I interact with to drive my car, and since that's risky, I should limit my interactions to a few people.
> You're shifting the responsibility from yourself to a different entity for the choices you're making.
Not trusting a site's code is taking responsibility for what it might do to me. Trusting their code is giving them the responsibility to do what's right.
> 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.
This is good, practical advice for non-tech people. But fundamentally there is no reason the web needs to be unsafe. Viewing a series of hypertext documents is safe, no matter who wrote them. The web is totally safe if you browse it using curl. It's only when we assume that "of course you're going to run that stranger's code" that things become dangerous.
It's great that we can have web applications. It's not great if every page is an application. There should be an explicit step from "I'm casually looking at your page" to "now I want to trust you and run your code".
> That said, modern browsers do a really, really good job at isolating the code running in that page from anything you care about.
That code can't wipe my hard drive, but it can track me everywhere if I let it.
The reason we need content security policies and cross-site request forgery tokens and cross-site scripting protection etc, etc is that our browsers are constantly eval'ing whatever code they're given.