511–520 of 529 posts
Earlier quoted context omitted.
This is true. Google has explicitly never put the user first. We should be grateful to give them our information in the first place in the way they deem is best.
Sorry if I don't agree that giving Google a throwaway email address is a significant concession of personal information. Which free services do you recommend that do things better?
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…
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…
Earlier quoted context omitted.
There's nothing about specifically that requires a central signing authority. You could just as well generate a public/private pair, feed the website your public key, and sign challenges with the privkey to log in.
You can also create a public-private key pair using JavaScript. Only problem is that when you go to another site, it wont let you identify yourself using the public key you generated on another site. And the browser won't answer the challenge automatically. Lets say we make a browser plugin, as a proof of concept. Then when it has "product market fit" browsers can make it a built in functionality. It will however be…
1. Education for and purchase of U2F keys 2. Key loss recovery mechanism 3. Key stolen defense (you can't just rely on the U2F key alone, there must be a pw or other type of second factor) 4. Widespread browser & device support (without it, a user/pass is required as a backstop)
Nevertheless, it is progress.
Earlier quoted context omitted.
Sorry, but at this point it is pretty obvious that big tech companies care about account security only as far as it impact their services. The late revelation about Facebook abusing 2FA phone numbers for marketing is a great demonstration of how that works. Google too does some really funny things to make it nearly impossible to create and maintain an anonymous accounts not tied to a phone number. Even when those acc…
> Pushing JavaScript everywhere increases the attack surface for every single user on the web. I understand where you're coming from, but most users browse the web with Javascript = on. Even as a NoScript user I have Google whitelisted because most of their services are unusable without Javascript. Even automated tools have good Javascript engines now thanks to headless mode in popular browsers. I suspect the next st…
Earlier quoted context omitted.
You can't give it a throwaway email address - they want your phone number now and will accept nothing less in my experience. If that doesn't appear true for you, try over Tor and you'll see what happens to many people...
I am surprised to see a long thread about nothing. Google does force you to give them your phone number and they do not let you register new emails after you hit some limit.
How does Google know you've hit a limit when you've registered new emails? And, not to belabor the point, but why should they be expected to give you unlimited number of free accounts -- or, what service do you recommend that will be that generous?
Earlier quoted context omitted.
You can also create a public-private key pair using JavaScript. Only problem is that when you go to another site, it wont let you identify yourself using the public key you generated on another site. And the browser won't answer the challenge automatically. Lets say we make a browser plugin, as a proof of concept. Then when it has "product market fit" browsers can make it a built in functionality. It will however be…
FWIW, this is something U2F somewhat solves. There is still the following exhaustive list of problems: 1. Education for and purchase of U2F keys 2. Key loss recovery mechanism 3. Key stolen defense (you can't just rely on the U2F key alone, there must be a pw or other type of second factor) 4. Widespread browser & device support (without it, a user/pass is required as a backstop) Nevertheless, it is progress.
Earlier quoted context omitted.
I am surprised to see a long thread about nothing. Google does force you to give them your phone number and they do not let you register new emails after you hit some limit.
I just tried creating a new account from a VPN, using a browser that I haven't used to log into Google previously. It allowed me to create a new account without a backup phone or email, and allowed me to send an email. How does Google know you've hit a limit when you've registered new emails? And, not to belabor the point, but why should they be expected to give you unlimited number of free accounts -- or, what servi…
Oh that’s right, they’ll never give the consumer power over their data because that’s google’s entire value proposition.
Earlier quoted context omitted.
Nope, the password is what people type in. They may type the same things at many websites. We should not care what that exactly is. 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,…
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.
So, there are properties that differentiate "password" and "5f4dcc3b5aa765d61d8327deb882cf99", even if for the server it's all the same.
Earlier quoted context omitted.
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 i…
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.