111–120 of 529 posts
The correct, non-editorialized title is: "Announcing some security treats to protect you from attackers’ tricks"
Both are editorialized. I think a better, more neutral title would be "Google now requiring JavaScript to be enabled to sign in".
Earlier quoted context omitted.
Both are editorialized. I think a better, more neutral title would be "Google now requiring JavaScript to be enabled to sign in".
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)
Earlier quoted context omitted.
Lots. But even those that don’t tend to send the password to the server, which is still bad.
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…
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.
Chrome team members have said that preventing modern web browsers from leaking enough entropy to uniquely identify users across sessions (fingerprinting) is impractical with all of the features that the modern web provides. This sentiment has probably lead to some at Google to think that it is justifiable impose pervasive tracking and surveillance technologies as a condition for using Google services. Look at the new…
Do you have a better solution for differentiating yourself as an actual user from a robot spammer?
Earlier quoted context omitted.
Who is sending passwords in cleartext on the wire?
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…
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.
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 i…
> 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 v…
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.
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.
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…
Also, FastMail allows for subdomain handling. I use this feature with nearly every site. You can have *@..com route to @.com just as you'd expect. The way this handling works is even configurable.
Is there an alternative to gMail? Just tried Protonmail and Fastmail, both require JS.
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…
Authoritarian ideology like this is what turned me off the whole "security industry" years ago.
Earlier quoted context omitted.
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…
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
You're signing in. That's literally asking them to identify you across pages so you can have access to them.