Is there an alternative to gMail? Just tried Protonmail and Fastmail, both require JS.
Conveniently those both work with either fastmail, gmail, or any other popular IMAP-compatible email provider.
81–90 of 529 posts
Is there an alternative to gMail? Just tried Protonmail and Fastmail, both require JS.
Conveniently those both work with either fastmail, gmail, or any other popular IMAP-compatible email provider.
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…
Calling other people, or their opinions, shortsighed and self-centered is usually not the start of a good conversation.
I'm getting tired of Google dictating how the web should work. That's the job of standards bodies. Google is increasingly taking the place of overbearing overlord that Microsoft embodied in the 90's and early 2000's.
Earlier quoted context omitted.
Do you have a better solution for differentiating yourself as an actual user from a robot spammer?
This is only truly necessary as a mechanism to prevent automated signups. 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.
How is this nonsense upvoted on hackernews..?
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 doma…
You might as well say people shouldn't take precautions swimming around sharks, because it's rare and be surprising if they attacked
Earlier quoted context omitted.
Do you have a better solution for differentiating yourself as an actual user from a robot spammer?
This is only truly necessary as a mechanism to prevent automated signups. 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.
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.
Earlier quoted context omitted.
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
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 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.
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 chang…
Earlier quoted context omitted.
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.