> But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users (0.1%) choose to keep it off. This might make sense if you are reading static content, but we recommend that you keep Javascript on while signing into your Google Account so we can better protect you.
They don’t seem to explain why though? Did I miss it? Are they fingerprinting the JavaScript environment of my browser? Why? The 0.1% are the people who would like to know why they need it, but this message is written ironically for those who don’t know what JavaScript is.
Additionally they imply the only motivation for disabling JavaScript is to increase performance and decrease bandwidth. They conveniently don’t mention the other, arguably more prevalent motivations: to increase privacy and security.
...and speed, and decreasing the amount of arbitrary code execution on your machine.
Most people don't disable JS entirely, but use something like uMatrix or noscript. It takes more work, but you can turn off a significant number of things that just don't need to be executed and get around a lot of annoying modals and paywalls (or see a lot of blank pages; that happens a lot too).
Yeah, it struck me as extremely disingenuous; while I like the other benefits, I disable JS mostly because I hate being tracked and noticed that many (most?) browser exploits require JS to run.
They are trying to detect state actor hacking and track individual devices and whether they are new or impersonations of devices.
Some states have mitm certs on all their domestic machines but (hopefully) not much competence except on whatever schedule they buy updates.
I would be implenting a u2f soft client in js if I were Google. IMO you need a private key a state would need to retrieve by tampering with js and that isn't being sent over the wire with every connection. (Just to give them their first level of headache, when it comes to transitioning from observing to impersonation.)
> Are they fingerprinting the JavaScript environment of my browser?
No, they are fingerprinting YOU and YOUR BEHAVIOR so it can be tracked across the entire internet. Intelligence agencies will use this information to track you across the web as well.
I'm not sure about you, but most people with js "disabled" don't browse with javascript disabled entirely, but instead use a whitelisting/blacklisting plugin, otherwise they don't be able to access many essential sites (eg. banks). under this setup, whitelisting google isn't going to decrease security unless you think they're going to serve a 0day when you sign in.
Passwords can be hashed directly client-side with javascript, which is way more secure than sending them clear on the wire, so i dont disagree with Google's stance here and dont understand the hate
How is sending the password to the server over HTTPS bad? What would you do otherwise? Hash it on the client? So are you not using salted hashes for your password store? That's far worse. Or you're hashing twice, the first with no salt client-side, then again with salt on the server side, which is fine, but the client-generated hash must be unsalted so is basically just the password itself: steal the client-generated hash instead of the original password, just as good with only minor loss in value (might not be able to reuse it on other sites for the victim; but actually maybe still could if you can build a reverse index of common passwords hashed using whatever algo is in use.)
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?
> Hash it on the client? So are you not using salted hashes for your password store?
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.
Almost any http site with a login form is sending your password in cleartext. Thankfully, initiatives like Let's Encrypt have made plain http sites much less common than they used to be.
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.
I think totony meant sending passwords without pre-hashing, but yeah it doesn't make sense to send any confidential information in clear text that should be sent via E2E encrypted TLS channels.
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.
Yes I meant sending the password cleartext inside the transport protocol*
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
Really your back end should just treat password's hashed just like any password.
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.
Indeed. And: who is hashing passwords on the client? As this would require either not using a salted hash, or sharing the server's salt with the client, in order to obtain identical hash values for comparison. In either case that system's entire password inventory would be a lot more vulnerable.
TLDR don't do that, send passwords over SSL and use a good password hashing algorithm on the server like BCrypt.
Yep. Proper password hashing requires per-credential salt, pepper (for all credentials) and a strong algorithm (IV, iterations etc.) Revealing all those information is a leak and arguably making client side hashing less secure (by giving away a lot of parameters for attackers to attack)
Yes, adding pepper is a recommendation not a mandatory step. But a lot of sites do, I.E. PagerDuty [1], paired with PBKDF2
as many apps requires to meet FIPS certification or enterprise support on many platforms.[2]
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.
No, the password is whatever you send over the wire. If a website processes your attempt to type "password" into "5f4dcc3b5aa765d61d8327deb882cf99" before sending that to the server, then your password for that website is 5f4dcc3b5aa765d61d8327deb882cf99. That's what the server sees and how it recognizes you. The only effect of this is to make it less likely that the user knows his own password.
If user password is "passsword" he may be reusing it across 50 other websites. If you leak information that "password" is linked to "email@gmail.com" I can hack the 50 other websites. If you never knew that the user password is "password" you can not leak it and I can not use it to log in into 50 other websites. Leaking "5f4dcc3b5aa765d61d8327deb882cf99" is useless to hackers, because he cant go and use it to login into another website.
So, there are properties that differentiate "password" and "5f4dcc3b5aa765d61d8327deb882cf99", even if for the server it's all the same.
The distinction you're trying to draw vanishes as soon as this becomes a standard practice. Passwords are already stored hashed and salted. They get compromised anyway, because the data is valuable. Under the circumstances you describe, cracking 5f4dcc3b5aa765d61d8327deb882cf99 (which takes less than a second) is just as valuable as cracking a password database entry is now, because the underlying issue -- reuse of credentials -- hasn't gone away. (In fact, you're encouraging it, so it's probably somewhat worse.) As long as people are reusing credentials across multiple websites, those credentials will have value greater than that associated with their use on any particular site, and other people will put in the effort to crack them. Even when you're generating and submitting a cryptographically secure salted hash, you haven't improved on the situation now, where databases store a secure salted hash of the password.
Hashing passwords client side has no benefit if a site uses HTTPS.
If a site uses HTTP, then hashing the password client-side and sending it up to the server is equivalent to sending a clear text password. If an attacker can already read your traffic, what is stopping them from using your password's hash to log-in to your account?
It stops them from using the password to log in to your other accounts.
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.
Use a password manager and don't reuse passwords. If your randomly generated, unique password has good enough entropy then why go through all of the trouble of the rest of the client side hashing?
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.
A password manager is a client side method that only works for people who opt into it, Google needs to deploy a server side method. Likewise with hashing my own passwords client side. HSMs.
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.
worshipping an arbitrarily contrived measure of password entropy makes for good security theatre, but there's a lot that goes into maintaining anything resembling actual security. How many people use "password generators" and trust that they'll come up with "random" words? What about that old saying about putting eggs in a basket?
This is completely wrong. HTTPS is what secures this, not client side password hashing. If you don't use HTTPS, you can just get MITM'd to disable any kind of client side hashing.
> It stops a compromised server from silently leaking unhashed passwords
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.
> - That is auditable - it is impossible for a malicious site to do so without risking being caught.
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.
You are wrong. Client-side hashing CAN be a silly thing, but it can also prevent a (compromised) server from seeing your password which you probably use on other websites (which is what most people do unfortunately).
The answer is that it depends. We could be talking about protected js with SRI, signed updates with an electron client, a browser plugin or native hashing, a protocol similar to SSH that hashes the client pw, etc.
>but it can also prevent a (compromised) server from seeing your password
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).
Not true in modern architectures, that situation only applies to more traditional file & api server combo's. If you statically serve your site with a service like s3 and have a backend running on lambda or ec2 - the attacker cannot modify the static assets and the client side hashing will prevent them from seeing the plaintext password.
This is only true when client-side hashing is under control of the client. In a web browser, it is not. The browser will happily run whatever JS the server sends it. So if the server is compromised, it can send compromised JS, and there goes your client-side hashing protections.
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.
It can protect you against non-malicious issues on server-side. If I recall correctly, twitter recently discovered that they were logging passwords in plaintext by accident. With hashed password you reduce exposure of actual passwords in this type of situation.
If the client hashes the password then the hash itself is the password. Meaning stealing the hashes passwords is the same as stealing the plain text password for which they're based, since you can post them direct.
Blizzard entertainment does half client half server hashing which is rather clever, one of the few examples where client hashing makes sense.
I'm curious, how is half-hashing the password different from really hashing it?
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
0.1% of roughly 4 billion would be about 4 million. Somewhat more in pageviews.
Of course, this fails to account for self-selection, a beehaviour has encountered before, in which increasing Youtube performance slowed average load times ... because users who'd previously found the site intolerably slow now found it slow, but tolerable.
(I've looked for the story, can't find it.)
Much as those who prefer to avoid use of Google won't appear in site use metrics. And enforced JS could well prove a deterrant.
I'm sure this is on me, but I'm genuinely not sure what the difference is between your suggested title and what was used. (Obviously, I can see which words you changed, but I'm missing the significance)
For about a month or so I tried browsing with JavaScript turned off but gave up after having to modify settings for just about every single site I visited to get pages working, often with them silently failing in the background leaving me wondering what was going on. Sometimes I'd get halfway through a payment transaction before realising that the lack of JavaScript was preventing it from going through and then changing settings and reloading the page would break my session. Long story short, I gave up on this and have succumbed to running JavaScript for all sites again.
I browse with javascript blocked by default and also often need to enable a script for proper functionality. However when I enable that one script, I will almost always see numerous other blocked scripts that can remain suppressed without a problem for me. Most of these are related to tracking/advertising. For me blocking the rest of the scripts is well worth having to play around a bit when I first visit a new website.
I'm on ~5 years of temp-whitelist only for JS domains. I have acquired a third sense for which CDN and assort domains are really required for what.
Sure, it does take some back and forth testing, and some sites like wix.com sites are terrible no matter what, but in general it's a better browsing experience.
My favourite are pages that embed videos using a huge collection of different third party embedding tools. It usually takes 2 or 3 rounds of whitelisting to get the video to even show up, and another to get it to play.
I use two profiles of browser. One with uMatrix, which is allowing only first-party js, other without addons for special cases like banking. I do not browse random pages with the second profile, just those which I decided to be trusted ones.
I went through the same pain but took an opposite approach. I've just started using the internet less. I allow us for Amazon and Gmail(which I am moving off of), but for 99% of the rest of my personal use I only read text only sites. I guess I have internet traffic for Spotify too, but that's an app so I've already let them onto my system
Umatrix is build around reactionary settings, and once you're reacting it's usually too late to fix a failed payment attempt.
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?
Google has becoming increasingly annoying. Every time I browse from work, where I have to use Internet Explorer, I have to suffer Chrome ads. They also require me to solve a Captcha every time I change the number of results per page via the search settings.
Recent new version of Google Mail flat out doesn't work to any usable standard in Firefox. Ten seconds to open a new 'compose mail' window. A context menu does a multi-second HTTP fetch before showing. The previous version worked great.
Either the dev team has just given up on quality or they're intentionally goading me into installing Chrome. I'm not going to play that game -- at this point Thunderbird works better.
What version of Firefox are you running? You are either exaggerating greatly or have other issues with your system. I run the latest stable release of Firefox and the performance of Gmail (particularly the features you mention) is fine. I’d be happy to upload a screen recording to verify.
I have a lot of issues with google apps for business.
Sometimes I have to refresh the browser 5-6 times before it will display any email in the primary inbox as well.
It's just horrible to use in firefox (in arch linux) and I'm currently looking for a new provider.
Protonmail is great but doesnt offer custom domains. If you need domains people mostly mention fastmail but i think there are far better choices like mailbox.org and kolabnow. Mailbox does not look like much from their homepage but it has awesome web client and it extremly reliable private provider thats in bussiness from 90s. I had account there for last 5 years without single problem.
I think that Chrome also suffers on this front? But it's better at doing pre-fetching than Firefox is
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
If you experience a reproducible Firefox performance problem, please consider using the Firefox profiler add-on [1] to record a profile and file a bug with "[qf]" to the whiteboard field. These "[qf]" Firefox performance bugs get reviewed by engineers twice a week. Having a profile makes the bugs much easier to diagnose.
I've experienced both very fast and very slow with the new Gmail on the same machine with Firefox on Linux. It's currently faster than Chromium, but maybe tomorrow I'll see ten-second load times. Who knows? For the record, I use uMatrix (and uBlock Origin on easy mode for client-side cleanup), which might be affecting it somewhat.
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.
Switching email providers is reasonably painless, fwiw. Set up forwarding, migrate mail when you can.
Even better if you set up the majority of your non-security-essential mail to be at your own domain, hosted by Fastmail/etc. Then you can easily change your email provider and your contacts don't even care. I've yet to implement this is in my own life, I just switched to fast mail - so I can't speak from personal experience on the domain portion of it.
NOTE: I mentioned non-security-essential email in reference to things like, your bank login or things that could threaten your life essentials. I say this because theoretically (and has happened before), using your own domain increases the attack surface area. My personal plan is to setup custom domain email with Fastmail, but still use the plain me@fastmail.com for my security focused emails. The majority of my email will still be based on my custom domain for easy portability, but I plan to avoid that for my bank, for example... assuming fast mail lets me.
I switched to Fastmail years ago and it was the best mail-related thing I ever did. I was dreading the migration but it literally took ten minutes, switch DNS records (I have my own domain), run Fastmail's import, done.
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 use Radicale and find it great, but there's no UI, so you need to use whatever client you want that supports CalDAV (I use Lightning and the calendar on my phone). Lately I've been liking Nextcloud a lot, and that's a one-stop solution for lots of things, so nowadays I would recommend that if you have a home server or want to pay someone to host it.
Yeah, you do. As I said above, Fastmail's calendar is very good too, and you can load your self-hosted/CalDAV calendars into it, so that's a good option.
FastMail supports CalDAV. I use my FastMail calendar with Thunderbird (Lightning) and on my iPhone; works great. They also support CardDAV for contacts. /satisfied FM customer since ~2008 or so
Why is jjawssd's (sister) comment dead? Davdroid works great and is free (as in beer and speech), though I would encourage people to donate if it's useful to you.
I can speak from experience regarding FastMail because that's exactly what I did. In fact, I migrated off a grandfathered Google Apps account with my custom domain to FastMail with that same domain. Yeah, it's a bunch of steps, but I'm very comfortable with making DNS changes. My wife and I have an account; it's worth every penny.
Also, FastMail allows for subdomain handling. I use this feature with nearly every site. You can have *@<YourFastMailId>.<YourDomain>.com route to <YourFastMailId>@<YourDomain>.com just as you'd expect. The way this handling works is even configurable.
I'm in the weird Google Apps for Your Domain limbo right now myself. I've wondered what would happen if I switched to something other than GMail but kept my google account with that email address.
I know a long time ago you could set up a Google account using a non-GMail email address but I'm not sure if that's even a thing anymore. That's what I want though. Keep the email address with my own domain that I've used for 17 years and just have a regular old Google account using that email (and keep all my Google services and purchases associated with it).
Google has been absolutely terrible to Google Apps for Your Domain users (who were often Google's biggest supporters back in the day). They've been shoved into this weird second class status where their Google accounts only partially work with Google services. I completely regret ever setting it up.
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.
You can continue using your email address for your Google account even if you've got someone else handling the mail now. You can also sign up for a Google account with an email account from any domain or provider.
Another very happy user of FastMail here, with our own domain. I initially was excited by subdomain handling, but switched back to only using my main account.
Using FastMail-specific features will lock you into this specific vendor once again, one of the main reasons to switch in the first place!
To be fair, how FastMail does catch-all delivery like this is standard and easily reproduced st any mail vendor (except Office 365) that supports catch-all, which is most of them. I use a catch-all address with FastMail that is @asubdomainichose.mydomain.org and it is the same subdomain I used with my previous setup before moving to FastMail.
Using a subdomain for catch-all is great because spammers can’t easily discover and flood the subdomain.
FastMail is standards-based, so it does not support labels. This is a good thing, and you should stop depending on Google-specific proprietary features. Even when I was on Gmail, I had a lot of issues with labels because the third party mail clients I needed to use didn't support them. The inbox tabs I ended up replacing in Gmail with rules/filters, that moved my social updates, for instance, to an actual social folder which worked properly on third party clients.
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.
I've recently switched to MacOS's built in mail client with IMAP to Gmail, never have to wait for my UI to do something. So count me in as surprised how far gmail has gone downhill.
That's the thing that gets me. So many optimisations have gone into user interface software over the years. And some of the stories of early Apple work, like 'round rects [0]' are truly inspirational.
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.
> A context menu does a multi-second HTTP fetch before showing.
Where? The only one I can trigger that does any kind of network is in the inbox, and that's only to get some icons. The text for the options is already loaded.
Same issue here. Mails not loading, poor initial load time. That is with zero extensions enabled.
I am now using mutt/notmuch/mbsync to prevent having to go through their horrendously slow web interface, and eventually move away from Gmail completely (probably to ProtonMail or fastmail).
I’m a little surprised to read this because Google Mail works fine for me in Firefox (ArchLinux). In fact it’s smoother than some of the Electron-based clients I’ve tried and less painful than trying to get push messages on Thunderbird working (sure, there is always IMAP but that requires regular fetches).
FIY, IMAP actually allows "push messages" via the IDLE extension. If you use K9 on android, it's enabled by default. I never used gmail, but I'd be surprised if the gmail imap server didn't support it (and I would dismiss gmail entirely if it didn't).
Is this a new thing? I don't recall seeing an option for that in Thunderbird (desktop version by the way; not the mobile / Android version) the last time I looked (~9 months ago).
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'm currently using mutt with "getmail" (which does support IDLE), which I can recommend -- it's an excellent client, but only if you're fine with tweaking.
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.
What is especially interesting is that this will allow Google to track you on more pages, but that in this case, you can by definition not block the tracker. I've checked, but reCAPTCHA just falls under the general Google Terms of Service.
I don't believe this to be done with that goal, but it is an unfortunate side-effect.
ReCaptcha is like Cloudflare's free DDoS protection: we like to point at these services and complain how people are "ruining the web" by using them because that's what we do on HN. We ignore the big picture and whine.
But I encourage everyone to consider a darker reality: that centralized services by large companies are becoming more and more necessary in a world where it's becoming easier and easier to be an attacker. The internet is kinda broken. Like how half the ISPs in the world don't filter their egress for spoofed IPs because there's no real incentive. That every networked device in every household could unknowingly be part of a botnet because we aren't billed for externalities.
Yeah, maybe it's kinda spooky that now ReCaptcha v3 wants to be loaded on every page. But is that really the take-away? What about the fact that this is what's necessary to detect the next generation of attacker? That you can either use Google's omniscient neural-network to dynamically identify abuse or you can, what? Roll your own? What exactly is the alternative?
Do HNers think this stuff is a non-issue because nobody has every attacked their Jekyll blog hosted on Github Pages (btw, another free service by a large company)?
That is exactly what I was trying to say with the final line in my comment: I do believe that this is necessary; it's just unfortunate that it comes with the tracking side-effect.
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.
reCAPTCHA can go frick off into a hole. I've stopped using all websites that use reCaptcha because it takes me sometimes 10 minutes to login to them. I also don't feel right providing free data so Google can help a military drone bomb children on busses one day.
They are such a pain point. Especially if you fill out a form accidentally, and have to go through the re-captcha again, and again and again for the most mundane of services.
I'm genuinely curious who actually browses the web in 2018 with JS disabled, though. Wouldn't 99.9999% of the web basically break? Like, if you do, do you only stick to a few basic sites, or?
You're misunderstanding: you browse with JS disabled by default. Random sites shouldn't be running programs on your computer. If you trust the site, you whitelist it.
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 assessment of the risk of JavaScript running in a browser is higher than it actually is.
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.
And I'm not sure how secure I am against those entities. There are active and unsuccessful attacks against my computer every day, and none of those attacks rely exclusively on running JavaScript in a browser sandbox.
... They break about as often as they work. [0][1]
There are a lot of vulnerabilities that appear in web browser protections, and almost all of them get exploited via JavaScript. Running untrusted software is not safe.
This is factually incorrect. It is entirely safe to run JavaScript in your browser. Your definition of "a lot" doesn't fit this conversation, because it doesn't represent constant and regular vulnerabilities.
Browsers are very safe. Not perfectly safe, but very safe. Thinking otherwise is paranoia, just like not running JavaScript by default in your browser is paranoid.
I have JavaScript disabled by default (incidentally I also disable cookies). I do this for page load speeds, security from malicious JavaScript, disabling of most advertisements, and privacy from ad tracking networks. Best practices is to serve static content and then progressively enhance that content with browser features like JavaScript. Unfortunately many sites disregard this. I routinely encounter things like an entirely blank page, missing images, broken forms (of course if I am logging on to a site I will re-enable cookies). If I think the site is trustworthy enough and I really am interested in the content I will whitelist that site. Otherwise I just hit back.
I browse with JavaScript disabled (NoScript) with a few sites that I care about whitelisted. Most web sites work fine although their layout is sometimes not what the web designer intended. Some sites don't work at all... for those sites I generally hit the "back" button. When I enable JS to view "JS required" sites, I usually hit the "back" button before it finishes loading anyway so why bother.
NoScript makes a big difference with my laptop and a HUGE difference with my phone.
I browse same as you: Firefox & NoScript, very few sites on by default. My experience matches yours with one other thing you didn't mention:
When I get a blank page, I do:
View
Page Style
No Style
usually fixes things quite well. E.g. seattletimes.com is blank by default but turning off Page Style gives me both text and images. Just not formatted very well, but I'm willing to accept that tradeoff.
I do sometimes. Mostly to read articles on sites with a poorly implemented paywall that simply doesn't work with JS disabled and shows the whole content. As a bonus often half of the ads are not served as well.
It's a pretty extreme practice, and only something a tiny fraction of very technical users will do. I think in general the people who turn off JS do it in a way that they allow it on sites they really have to use that really don't work without it.
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'm not sure if it quite qualifies as browsing with JS disabled but I run UMatrix with the default settings set to disable all scripts on a site. Then I've set some common domains I trust that greatly improve usability (things like ytimg, paypal, some common 3rd party scripts).
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.
> Firstly because the web does work much nicer when you just turn scripts on and say 'to hell with the privacy and security concerns'.
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.
Most websites work fine, you have to be truly incompetent to make a text+image heavy website that doesn't work without JS. Web apps are a different story.
The ones that do break tend to be the ones invading your privacy.
I used to think the same thing about people who browse with auto-loading plugins. Then browsers caught on and started click-to-play'ing them.
Javascript is the new plugins (so much host OS functionality exposed now) and it requires a new click-to-play. I'd like to think they'll eventually integrate something like NoScript into the browser as a standard. This free for all code running is too much now that the browser is an OS.
But it's difficult to get browser companies to understand something when their income depends on not understanding it.
I browse with 3rd party frames and JS disabled. Not as extreme as all JS so it doesn't break most things. Occasionally I need to whitelist a CDN or related domain for that site to get things working.
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.
I have umateix installed and set to block 3rd party scripts. Almost all websites work fine or even better like this but sometimes I have to enable a CDN to get the website to work.
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.
I find it kind of humorous that the "mobile demo" seems to have been made on a Mac, complete with a cursor, and then resized to have a mobile border around it.
As others have mentioned, nearly the entire internet breaks without javascript - it's a sad state of affairs.
One protection I like to use is to disable javascript that is loaded over plaintext http - this breaks nearly nothing, and is easy to do via Chrome settings: https://i.imgur.com/NRVg5Xf.png
Chrome will always block an HTTP javascript call by an HTTPS page. So given the growing prevalence of HTTPS, I think this setting is probably doing less and less for you.
I browse without javascript all the time, sometimes i need to switch to another browser to buy something from some random site, but generally its just a faster better internet with very dodgey sites self selecting themselves out of my usage.
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?
Chrome team members have said that preventing modern web browsers from leaking enough entropy to uniquely identify users across sessions (fingerprinting) is impractical with all of the features that the modern web provides.
This sentiment has probably lead to some at Google to think that it is justifiable impose pervasive tracking and surveillance technologies as a condition for using Google services.
Look at the new ReCAPTCHA v3 to see how fingerprinting is trending at Google.
Being allowed to pay for services with money, rather than being required to pay for services with your personal data. I browse the web via a proxy when I'm on public wifi, and Google is nigh unusable with how many captchas it forces you to solve to do a single Google search. Fortunately Bing and DDG still work, for now.
> Being allowed to pay for services with money, rather than being required to pay for services with your personal data
One possible big disadvantage for a site owner in letting people pay with money instead of data is dealing with taxes.
I'm not actually sure how most jurisdictions tend to classify it when someone comes to your site and you charge them to access your content. My guess would be it would be taxed the same way they tax digital goods such as downloadable software that does not include any physical components.
For such goods most jurisdictions that tax them seem to base the tax on the buyer's location rather than the seller's location, so the seller has to deal with charging the appropriate tax and filing returns for potentially a large number of jurisdictions.
If the seller is providing the content for "free" and making their money selling visitor data to advertisers then their income will probably only be subject to taxation in their own jurisdiction. It will simply be ordinary business income.
My experience with taxation out side of the US, currently Australia, is that they are ridiculously reasonable and probably more on my, that is the business owners, side that I would like them to be.
It would be a net benefit for everyone, including the US, if it's broken taxation system becomes a national emergency and finally gets fixed.
And for the "this is a real person" service, they really don't have to charge much. I should be able to go to the store and pay a dollar for a PIN that gets anonymized on use and lasts a long time if not indefinitely when not abused.
Email has recurring costs to run. They need to process every email you receive and send and therefore any email service that actually wants to continue running will need to charge a subscription fee.
But an attack that keeps rate limits saturated doesn’t require much bandwidth (you know, because rate limits) and is therefore easy to keep up. Most services would consider it unacceptable if a script kiddie with a botnet and a generic list of usernames were able to prevent even 1% of their users from logging in.
Background: I spent years developing a product that currently defends F500 websites against automated attacks. If you live in the US you've more than likely used my software this week without knowing it.
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.
> This is only truly necessary as a mechanism to prevent automated signups.
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.
Honeypots take care of most basic bots.
If you need captcha, you can use Math Question like in http://random.irb.hr/signup.php
You can also add extra security with time elapsed between loading the page and form submission, if it's less than 5 seconds it's most likely a bot.
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.
Blogger (which is what hosts this article) includes a copy of the whole article within <noscript> tags. If you completely disable Javascript, the browser shows the content of these tags, so the article is visible. If you have Javascript enabled, even if all domains are blocked, the content of these tags is hidden, so the article show as a blank page. You have to unblock the third-party domains where Blogger hosts its scripts to make the article appear again.
This seems reasonable to me. JavaScript is being used everywhere and most people are okay with it. As a business decision I don’t see why Google would support such a small edge case. That being said, if they feel like explaing why they should maybe try a little harder. I assume most people with JavaScript turned off might appreciate more details so they can decide how to respond to the requirement. Then again, their current approach actually seems reasonable to me.
Thus only 0.1% of users know what javascript is and it's okay with it. That is an interesting random stats, seems pretty realistic. I at least liked it.
Then if we take this 0.2% as representative (and 6 million out of three billion users probably is), it would be fair to say that this 50% split would scale if more people learned about javascript.
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.
You're right. My comment is out of place in this particular instance. But there are plenty of other examples where Google does have too much power and influence.
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.
I wouldn't blame Google for this phenomenon, though. They provided a solution, others were quick to jump to and use said solution. Might be better to complain to the sites following the herd then?
"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."
ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS.
They're probably right that not running JS is privacy accretive, but only if you consider their individual privacy, and not the net increase in privacy for all users by being able to defend accounts against cred stuffing using JS. The privacy loss of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated.
tl; dr: Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses. I think there's a shortsightedness and self-centeredness to a lot of these comments.
I'll be the guy who says that while I recognize those are insults, they are also sufficiently descriptive of a point of view... it's not like he called someone Mr. Poopypants.
> The privacy loss of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated.
That's quite the hand-wave. How do you even measure privacy loss? And given that browsing history is not in your inbox, why are you so confident that one compromised email account is a bigger deal?
Your first statement is incompatible with your second. (I think the second statement is reasonable, although I disagree with the conclusion).
People aren't underestimating the risk to _their_ accounts, they are discounting the risk to _others_ accounts.
That is, they're essentially saying, 'well, other users chose to have bad passwords, so bully them'.
I think that's a fair viewpoint to have. We've entered a world in which computer literacy is a basic requirement in order to, well, exist.
That said, what's reasonable, and what actually occurs, are two different things. A company isn't going to ideologically decide "screw the users that use bad passwords" if it loses them money.
So we get _seemingly_ suboptimal solutions like this.
I think you may be giving people more credit than they deserve, but I'm willing to accept that they're making that argument. Even if that's their argument, that their personal habits around password use and being attentive to not being phished are so good they don't need Google's help defending themselves, so bully for everyone who does, I'm not convinced it's a good one.
There are a few things needed for that to be a good argument
1) Their security really is so good (I'd bet it isn't. I saw a tenured security professor/former State Department cyber expert get phished on the first go by an undergrad.)
2) Google isn't improving their security posture on top of that (I'd be shocked if Google isn't improving theirs, and I'm certain having JS required to sign into gmail closes a major hole in observability of automation)
3) There are real harms from the JS being there for their security/privacy posture (as I've said elsewhere, I'm unconvinced Google is allowed by their own privacy policy from doing anything untoward here)
As to your point about computer literacy and existence, I think the sad truth is that computer engagement is required, but literacy is optional. When that's the case, large companies are in the position of having to defend even the least computer literate against the most vicious of attackers.
> I think the sad truth is that computer engagement is required, but literacy is optional.
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.
> The population is expected to operate vehicles without putting others in danger, not credentialize in how cars work.
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.
XSS vulnerabilities are everywhere. You obliviously don’t realize that.
Note that I do use js, because it makes life easier. But you got to realize that not using js will at some point protect you against an XSS vuln. They are that prevalent.
Throttle based on what? IP address? This works for domestic IT departments looking to shut out automated attempts from specific ranges but at Google's scale IP based filtering could end up shutting out an entire country.
All of Qatar's traffic used to be routed through 82.148.97.69, though that was back in 2006-2007. At one point it was banned from Wikipedia, which unintentionally affected the whole country.
That's the first obvious countermeasure and will prevent hackers targeting a specific account. But there are other ways to crack passwords, one is to try the same password but iterate over user ids instead. As hackers would start with the most common password you can't throttle globally on same password attempts either because well yeah, it is by definition the most commonly used one which should have a lot of traffic.
This has nothing to do with anything but I don't know how else to get in touch with you. Could you upload your zero spam email setup guide somewhere? Your site was hacked so the link I had doesn't work:
"Credential stuffing" as I've heard it used refers to taking username/password combos from one breached site and trying them in other sites.
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.
That's a terrible idea. Back when MSN was one of the most common instant messengers, there was a common prank that was called "freezing" where you just continuously kept trying to log into someones account and it would lock itself out for 15mins or more depending how long you kept doing it.
Modern cred stuffing is done by botnets. When I see a cred stuffing attack, it's maybe 1-3 attempts per IP address spread over 100-500k IP addresses.
Often you'll have a family of legitimate users behind an IP address that's cred stuffing you at the same time.
Throttling by IP address may have worked 10 years ago, unfortunately it's not an effective measure anymore.
Modern cred stuffing countermeasures include a wide variety of exotic fingerprinting, behavioral analysis, and other de-anonymization tech - not because anyone wants to destroy user privacy, but because the threat is that significant and has evolved so much in the past few years.
To be entirely honest, I'm kinda surprised Google didn't require javascript enabled to log in already.
A relatively successful company in the area is Shape Security. Their marketing is a bit painful, but they invented the concept of cred stuffing. Disclaimer: I worked there for four years.
Unfortunately I don't have much reading material to provide. It's a bit of an arms war, so the latest and greatest countermeasures are typically kept secret/protected by NDA. The rabbit hole can go very deep and can differ from company to company.
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
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.
And indeed it's time to give up on the web being a document format only. The internet is about loading remote applications in your local sandbox. That's what it is. It sucks, but it is what it is. As part of loading remote applications, we now might be asked to compute whatever anti-abuse puzzles are required. So it goes.
If something shitty is happening, you don't have to shrug your shoulders coswhatyagonnado. Understanding the human reason why something shitty is happening doesn't mean you have to accept it. So it goes, until it doesn't.
Running JavaScript means parsing text from outside source plus executing the program from outside source. Both requires really complicated code counted by the unit of M LOC(Mega Line of Code).
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.
Javascript can be served dynamic as well, per user/connection specific even. So an attacker would have to investigate and counter each new version of the scripts. Even if this could be done automatic it greatly increases the cat/mouse factor for Google.
Can't you use Javascript to implement challenge-response authentication, which meaningfully improves security by:
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...
>1. Preventing interception of passwords on the wire
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.
I find the idea of detecting someone's trying to bust your login page with some kind of automated system and deciding to serve them a ridiculously aggressive Bitcoin miner rather amusing.
Whats stopping that war from happening at any other time? If a attacker has the resources and carelessness to mount such an attack at a whim you should be prepared for it?
> Can't you use Javascript to implement challenge-response authentication
> 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.
security through obscurity may be no security at all, but security without obscurity is probably not as good as security with obscurity for many security scenarios that one can imagine.
Obscurity is just another layer you add onto your security. As with all security methods, no one is perfect and its always a balance with usability.
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.
Credential stuffing more commonly refers to the practice of getting valid sets of creds from various password database dumps and retrying them across common/popular systems.
2FA is a good defence against it, but lockouts are less as they attacker will be going broad and not deep (could be a single request per user account)
I don’t see how JavaScript is anything more than a bandaid for that. The assumption is the attacker has the usercode and password combination and then you want to prevent him from logging in.
Ip based lockouts as opposed to account based lockouts do better against cred stuffing. Because there is a cost to getting more IP adresses. Maybe carrier grade NAT would lead to too many false positives?
Most bad actors doing abuse at scale have access to large networks of proxies on residential or mobile IPs, usually backed by malware on workstations, laptops and mobile phones.
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).
/64 and /48 are pretty much on the same order of magnitude as IPv4s in terms of difficulty of acquisition, and I don't know why you would ever look at more than /64 when most major operating systems randomize the last 64 bits anyway (RFC4941).
I used a long and supercomplicated password for one of my accounts that i access intermittently. Why I have it is a long story, but I only log into it once or twice a month to check if there is something that needs my attention.
Usually the login is in incognito, guest mode, and even from different locations and machines. Google asks for a second factor (i dont have it on for my accounts) like phone verification for my usual accounts (not so complicated password) but not for the one with complex password. So I think the level of extra steps/security is linked with how complex your password is. Not so sure if this is a good thing or bad. But, I hope they should continue basing their security measures based on the security measures you take.
I asked LastPass to generate me a long and complicated password for a new Office 365 account only to have it rejected as too long because it was over 16 characters. Sigh.
Maybe one reason is because google doesn’t know which account is trying to login before the login page, so how could they remember that security setting before attempting to serve JS?
I don't understand why anybody concerned about having JS on a login screen would want to log into Google in the first place. I imagine there's a tiny overlap between "Runs NoScript" and "Trusts Google"
> So what about a opt-out at account level? Something in the account settings, like this:
> [check] Allow sign-in from javascript disabled browsers. WARNING etc. (usual warnings about security etc.)
It sounds a bit like what Gmail's doing with their "allow less secure apps" login option, except that's more for allowing IMAP logins using password instead of OAuth.
Passwords are obsolete - actual security would involve keys. The fact they have to care about automation for security instead of availability is a sign they have already lost. If you have a disposable EC2 server administration password accessible you are already doing it horribly wrong because you /will/ get attacked frequently.
Javascript is opening an attack surface for what will certainly turn into an arms race anyway instead of ending it.
Given that they aren't pushing a new standard for what has already been a problem for a long time while introducing a vector for abuse both to and from it google can be criticized for both of those sins far more.
To be fair, Google released their own OTP hardware keys and have already 2FA login mandatory for accounts that they deem "high risk."
I don't think it's fair to blame them for the facts that most folks are not willing to give up passwords yet. Given that passwords are the current reality, shouldn't they do everything in their power to make them as secure as possible?
> ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS.
Password are effectively obsolete and everyone should be using multi-factor authentication of some kind. Keys with passphrases. 2FA auth. Whatever.
Making 2FA auth mandatory would be substantially more effective than bot signaling.
> tl; dr: Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses. I think there's a shortsightedness and self-centeredness to a lot of these comments.
If they were, 2FA auth would be mandatory with additional phone-based (i.e. SMS) whenever you try to login from a new geographic area. That would stop anything short of a targeted hack.
Instead, they created an attack on the bot maker's profit margins. Cloudflare, Google, et al. are really just trying to increase the cost of making bots. They are not really trying to _stop_ bots.
It's surprising to me how many users on HN can only think as far as their own browser.
Really the question here is not "what's the harm of JS across the web" but rather what is the specific privacy cost of running JS on a sign in page and what is the security benefit of the same.
The worst case cost of JS on a browser is that you get a drive by download and your endpoint is owned. This seems unlikely on a Google domain.
The other, more normal, case is that a user is concerned about ad tracking. Providing an ad tracker on a sign in page seems pretty lame, and I'd be surprised, again, if Google was doing that.
The security upsides are likely several: anti-automation, anti-phishing, and an opportunity to track state-level adversaries who target users' Google accounts.
I don't know how others weigh these factors, but to me it seems entirely obvious that this is a good idea. Could the blog post have better laid out this case? Sure.
Why would google not at least have an incentive they'd have to work against, to add tracking into their sign in pages? They make all of their money off of ads and they do that by tracking people to target ads.
You might as well say people shouldn't take precautions swimming around sharks, because it's rare and be surprising if they attacked
> Hacker News works perfectly fine without Javascript.
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.
Ctrl f. But yes hacker news doesn't have the greatest UI.
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.
I'm sure tracking everyone and controlling exactly what they can do will make them safer. Why don't we put surveillance cameras everywhere and make them record 24/7 too? </s>
Authoritarian ideology like this is what turned me off the whole "security industry" years ago.
Google already controls exactly what you can do... on Google.
You're arguing against ubiquitous surveillance, when the OP is arguing for company surveillance of the way in which you interact with their login screen, on their site.
This makes perfect sense for Google. This will objectively greatly increase the account security of their users. Remember 99% of Google users are not at all like people on HN. Google is helping the 99% at the expense of the people paranoid about tracking - but if you have a Google account, you've already lost that battle.
This is a completely reasonable business decision and trade-off.
What a bunch of, excuse the language, paternalist fear-mongering bullshit. Of course Google wants you to enable JS, because it allows them to monitor and track everything about you more easily. Twisting it into "this will make you safer" is sad and undeniably repugnant.
I've noticed a lot of other sites practically begging you to "enable JavaScript for a better experience", when all their content is static text and images. I fell for that once, a long time ago --- enabled JS briefly to see what the big deal was --- and was promptly bombarded with popups, slide-overs, and even more ads. No thank you, I'll keep it off.
For many years I used IE6 with JS off (and a whitelist for a very, very small number of selected and highly-trusted sites. IE has a "security zone" feature which to my knowledge no other browser comes with by default.) Not a single malware infection, and that's despite often visiting the... shadier parts of the Internet.
Browser exploits are almost all JS-based, and even the few that aren't, are in practice deployed using obfuscation involving JS, to make analysis and detection harder. Turning off JS effectively kills those risks as well as other annoyances (blocking right-click, text selection, injecting crap into copied content, etc.)
IMHO the advantages of not having JS on by default are underrated. I'd consider ~99% of the sites I come across when searching for content to not require it at all, which certainly is a stark contrast from the "you'll break the Internet!" screams of the JS-advocates and "web designers". Sites that "break" from not having JS, and which aren't specifically "appsites" but mostly content-sites, are not worth visiting anyway.
Perhaps it's time to raise a counter-movement, and add (via <script> tags, of course) "you have JavaScript turned on in your browser, this is a security risk! Click <here> (link to appropriate page with all the risks and how to turn it off) to learn more." Or "You have JavaScript enabled, please disable it for a better experience."
If a certain vocal minority managed to demonise Flash (another powerful technology that had major uses) to almost completely kill it, maybe the same can happen for JavaScript?
> Browser exploits are almost all JS-based, and even the few that aren't, are in practice deployed using obfuscation involving JS, to make analysis and detection harder.
Go take a look through Pwn2Own. Most browser exploits do not involve JavaScript. JavaScript can be a delivery mechanism for a certain class of payloads, but it's not the substantial weakness in browser vulnerabilities (as opposed to web application vulnerabilities).
Given that this isn't familiar to you, I'd recommend you reevaluate how confident you are in the JavaScript-focused defenses you've outlined in the rest of your comment.
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:
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.)
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.
Of the first 28 vulnerabilities listed on that page (representing the past 5 years of CVEs for Chrome), I count only 7 that don't mention V8, JavaScript, PDFs, plugins, or "unspecified vectors".
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.
But the vast majority are memory corruption and sandbox escape issues.
...which require JS to exploit. (What is a "sandbox escape" if there isn't code to... escape it?)
I went through the 50 vulnerabilities on that page and looked at the nature of them and inspected any PoC code if any. This is the results:
PDF,JS,JS,WebGL(JS),JS,CSS,JS,JS,extension,HTML(but PoC needs JS),JS,PDF,PDF,MIDI(JS),AppCache(JS),PDF,JS,UI,WebRTC(JS),JS,JS(speech recognition!?),JS,JS,JS,JS,JS,JS,JPEG(rendering uninitialised memory --- not exploitable without JS to read that data),JS(WebWorker),HTTP/SSL(!),SVG+JS,UI,JS,XML(!),SVG+JS,JS(audio),Fonts(actually Windows font renderer bug),UI,??(no details available),IndexedDB(JS),WebGL(JS),UI,JS(WebSockets),NaCl(extension),extension,PNG,WebGL(JS),?,JS,WebGL(JS)
That's 32/50 confirmed to require JS to exploit, and only 3/50 stood out as being "visit a page with all plugins/JS/extensions disabled, and still get pwned", of which 1 is actually a Windows bug.
Disabling JavaScript insulates you from a nontrivial - but nontheless minority - subset of browser vulnerabilities.
Look at all the replies. Everybody is ignoring the elephant in the room, instead desperately focusing on socially acceptable ridicule of OP's diatribe on security.
Wake up people.
> Of course Google wants you to enable JS, because it allows them to monitor and track everything about you more easily. Twisting it into "this will make you safer" is sad and undeniably repugnant.
What Google is evolving into, whether consciously or not, is the equivalent of IBM punch card compatible identification tattoos that were were part of the system of Jewish identification in Nazi camps. Pretty soon your every action will be tracked throughout the Internet and you will be uniquely identified at every site you go to whether you want it or not. Intelligence agencies will know exactly what you are thinking all the time with a nice RabbitMQ feed from major internet sites that downloads your mouse movement and key stroke pattern fingerprint along with your post contents and associates it with your https://en.wikipedia.org/wiki/XKeyscore account. You will have lost all anonymity. Online access will be increasingly restricted and major sites will only become accessible to those deemed worthy by a central social credit score rating agency. Research the consequences of China's social credit system if you want a taste of the future and don't care to learn about what the Nazis did to Jews. Downvote me at your own peril. Downvoters are useful idiots and next on the chopping block. The 21st century equivalent of Nazi concentration camp gate keepers who were just "doing their job."
Google's tracking everything you do on _their properties_ to begin with because they're a marketing company. Use DuckDuckGo if you don't like that. The pearl clutching in this thread is unreal.
I tried to live with javascript disabled by default but gave up after two months because all I did was white-listing every page I opened. Gave up on my own side projects too. Building something that works with and without javascript is just to much work for me and it becomes ugly quickly.
I still think modern websites over use javascript too often and should use markup over code whenever possible.
And of course no one wants to go back to iframes to load dynamic content. Or should we?
I try hard not to be a luddite as I age, but this level of automation and machine learning is so concerning.
It is SO frustrating to accidentally appear as a bot and get stuck at the mercy of an automated system. I was on some random site the other day and spent 3+ minutes solving Captchas until it finally let me through. I thought I was losing my mind. I don't spam, I don't automate queries, I come from an IP that has two residential users (netflix, xbox traffic dominate everything). Who knows what I did to offend the algorithm.
I was getting a persistent but unhelpful error message from an airline website while trying to change my reservation shortly after midnight. I assumed at first I just hit the maintenance window and should try again in the morning, but now I am reading this thread and wondering if it's a deliberate obfuscation that it deemed my connection suspicious.
Google captchas appears (to me) to be designed to identify individuals, not to separate anonymous users from machines. Google want to know exactly who you are, when they harvest your visits and behavior on almost all sites on the Internet.
I don't understand what this has to do with the fact that I repeatedly am having to prove that I'm not a bot despite doing nothing that ought to be triggering Captcha checks.
But hey, I guess mentioning this simple observation is worthy of numerous downvotes here. Always lovely.
528 comments
[ 2.8 ms ] story [ 483 ms ] threadThey 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.)
No, they are fingerprinting YOU and YOUR BEHAVIOR so it can be tracked across the entire internet. Intelligence agencies will use this information to track you across the web as well.
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.
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.
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?
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
[1] https://perf-html.io/docs/#/
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.
Oh wait, they do, and they work, so you're wrong.
You realize the bulletproof vest is the sandbox, right? You've just made an argument against enabling all javascript.
"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 assessment of the risk of JavaScript running in a browser is higher than it actually is.
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.
... They break about as often as they work. [0][1]
There are a lot of vulnerabilities that appear in web browser protections, and almost all of them get exploited via JavaScript. Running untrusted software is not safe.
[0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chromium
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox
Browsers are very safe. Not perfectly safe, but very safe. Thinking otherwise is paranoia, just like not running JavaScript by default in your browser is paranoid.
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:
usually fixes things quite well. E.g. seattletimes.com is blank by default but turning off Page Style gives me both text and images. Just not formatted very well, but I'm willing to accept that tradeoff.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.
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?
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.
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.
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."
Conveniently those both work with either fastmail, gmail, or any other popular IMAP-compatible email provider.
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?
https://simple.wikipedia.org/wiki/User_talk:82.148.97.69
User Id?
http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/
http://qasimk.io/2016/absolutely-zero-email-spam/
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!
That way you don't log private user data (EU laws etc) and it can't be used to lock someone out of their account.
The only way around this is to attack from a lot of different IPs and that, too, is very easily detectable and solvable in a user friendly way.
Really, how hard is it? I would expect this to be the default for big companies by now.
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.
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.
https://news.ycombinator.com/newsguidelines.html
This is a completely reasonable business decision and trade-off.
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.
Wake up people.
> Of course Google wants you to enable JS, because it allows them to monitor and track everything about you more easily. Twisting it into "this will make you safer" is sad and undeniably repugnant.
What Google is evolving into, whether consciously or not, is the equivalent of IBM punch card compatible identification tattoos that were were part of the system of Jewish identification in Nazi camps. Pretty soon your every action will be tracked throughout the Internet and you will be uniquely identified at every site you go to whether you want it or not. Intelligence agencies will know exactly what you are thinking all the time with a nice RabbitMQ feed from major internet sites that downloads your mouse movement and key stroke pattern fingerprint along with your post contents and associates it with your https://en.wikipedia.org/wiki/XKeyscore account. You will have lost all anonymity. Online access will be increasingly restricted and major sites will only become accessible to those deemed worthy by a central social credit score rating agency. Research the consequences of China's social credit system if you want a taste of the future and don't care to learn about what the Nazis did to Jews. Downvote me at your own peril. Downvoters are useful idiots and next on the chopping block. The 21st century equivalent of Nazi concentration camp gate keepers who were just "doing their job."
You're saying soon the computers that make up the internet will gain the capabilities of IBM machinery of the 1930s?
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?
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.