381–390 of 529 posts
Earlier quoted context omitted.
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).
and if said "compromised" server simply decides to not supply the js that hashes the password?
When I was at Google I started both the login risk analysis project and the Javascript-based bot detection framework they're now enforcing, so it's a pity to see so many angry comments. Maybe a bit of background will make it seem more reasonable. Firstly, this isn't some weird ploy to boost ad revenue. This is the login page - users are typing in a long term stable identifier already! The Javascripts they are requiri…
Javascript ist also required for the vast majority of web-based exploits. I find it somewhat strange that you ask me to make my system less secure so you can better secure my account.
I'm not really sure how it works if you don't want to use JavaScript, do you then whitelist sites that you're ok with it? Wouldn't the solution for folks who don't want to run JavaScript just to whitelist it for Google? Maybe I'm missing something but that seems pretty simple, would let Google do their thing and the folks who don't want to run it run it just for Google and places they want to. If someone already does…
> pretty simple, [] let Google do their thing Unfortunately El Goog is now a de facto monopoly both for makers (organic traffic) and users (AMP, discovery, federated logins etc). I'm not angry at Goog for winning, they did it by (mostly) being 100x more awesome than the competition and surfing the network effects into the endgame. But here's the elephant in the room: outside walled gardens, Goog runs da tubes, and th…
Just generally this decision for logins and javascript seems pretty... not a huge deal IMO for folks who aren't a fan of JavaScript, whitelisting google seems like a pretty simple choice.
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…
So what about a opt-out at account level? Something in the account settings, like this: [check] Allow sign-in from javascript disabled browsers. WARNING etc. (usual warnings about security etc.) Edit: because users who know to use long passwords and 2FA do exist and don't need all that extra security stuff ...
Earlier quoted context omitted.
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?
IPv6 addresses aren’t really scarce.
Earlier quoted context omitted.
Javascript ist also required for the vast majority of web-based exploits. I find it somewhat strange that you ask me to make my system less secure so you can better secure my account.
Like the blog post mentioned, 99.9% of users already have JS enabled, and this number is only going to go up as websites rely more and more on JS. For them, this is a purely beneficial change, with no downsides. It's somewhat selfish for you to ask that your system be made more secure, even at the cost of security for 99.9% of other users.
Earlier quoted context omitted.
Thats the wrong take on the stats. It means among the ones who know, half of them dont want it. This is more telling that looking at the 0.1%.
I think you’re confusing “numbers some guy made up” with “stats.”
Earlier quoted context omitted.
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
I had to purchase a CalDAV and CardDAV app (which were extremely cheap, mind) for Android, so it's not quite as plug'n'play there.
Earlier quoted context omitted.
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)
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?
Earlier quoted context omitted.
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 exp…
Last time I tried fast mail they didn’t really support labels, only folders. Is that still the case, or is there a good workaround?
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.