Sign in with Google has been removed for your privacy(slimvoice.co)
slimvoice.co
Sign in with Google has been removed for your privacy
https://slimvoice.co/login
166 comments
If you use SSO with the account you were going to use your e-mail address with, it makes little difference whether you used OAuth2 vs traditional e-mail based authentication. You're locked out.
If something happens, like OAuth2 stops working, most websites allow password reset to the e-mail address connected to the account, and then can log-in without OAuth2.
The concern here is probably related to some Log-in with Google scripts that run on the frontend, although if they were just using normal OAuth2, then I think they are wasting their time: whatever sensitive information Google gets via OAuth2 they also get via the unencrypted e-mails you're sending to them anyways...
If something happens, like OAuth2 stops working, most websites allow password reset to the e-mail address connected to the account, and then can log-in without OAuth2.
The concern here is probably related to some Log-in with Google scripts that run on the frontend, although if they were just using normal OAuth2, then I think they are wasting their time: whatever sensitive information Google gets via OAuth2 they also get via the unencrypted e-mails you're sending to them anyways...
No. It makes a massive difference. Even if you're locked out from your email account, you can still login no problem to any website using your username/email and password.
Except those that make you click a link or copy a code from your email if your IP changes
Having goggles oauth doesn't preclude a secondary login method such as username/password.
They just didn't want to support it and found some reason to justify the removal, that's as much as you can get from the given facts
They just didn't want to support it and found some reason to justify the removal, that's as much as you can get from the given facts
Yes, to be fair, that's still a marginal improvement, assuming you aren't forced to validate your email address at any point, which might be the case for lower security stuff. On the other hand, either way, you can often use an existing session to do the same thing without needing to reauthenticate.
I use a custom domain and forward all mail to a web based email provider for this reason. If my provider drops me, I can move to another and update my forwarding. There’s still a risk I could lose the domain somehow, but I don’t hear about that happening nearly as often.
I do this as well. I encourage people to own their own domain and use that for email; it is more complex to set up, but you have far more control long term.
I do this as well but with anonaddy.com which acts more like a proxy than forwarding. The yearly price is low (something like $12) to use your own domain and much lower than paid email plans.
I have a Gmail rule set up to forward all of my mail to a Protonmail account as a back up. So I can still perform password resets, etc
I'm pretty sure they reject incoming mail when your gmail gets locked. so those forwarding rules will stop working
source?
Whether they reject it or not, it’s less likely they would follow forwarding rules.
Based on what?
If you wanna gamble on this solution, that's definitely your prerogative. I think it's unreasonable to assume that any function of your account will continue to work if it becomes locked, inaccessible, or possibly compromised. A better backup is a custom domain. Which, of course, is not really great with Gmail.
There’s no reason to believe email delivery would stop working just because your account is locked. Such misinformation lol.
Arguably if you can prove to the provider that the email is FUBAR and you own the account, it might be easier for them to change out the email on you. Maybe a good reason to support login via email and / or phone number. If you lose both, you're screwed.
F-ing Google locked me out of my account and my email because I broke my cell, and then traded it in for a new one but Google kept sending the verification to my broken cell. There's no one to call for assistance!
That sucks and this is something Google needs to fix, but for everyone else: make sure to get backup codes for your Google Account and place them in a password manager.
Good reminder, thanks for sharing.
Make sure to get backup codes for your MFA-protected accounts, and then keep them out of your password manager at all costs. Print them out on paper and store them in a fire-safe location, preferably one copy off-site.
Or host your own domain with google and buy google workspace for enterprises so you can use your android with your own domain.
I hate to be that guy but this seems like a user problem
The inability to recover an account is bullshit regardless. It’d be like if you lost your bank card, and the bank didn’t have a service desk.
Just because google is free, doesn’t mean they don’t have a responsibility to users. Savings accounts where I live are pretty much free too.
Just because google is free, doesn’t mean they don’t have a responsibility to users. Savings accounts where I live are pretty much free too.
Email accounts from big providers need some safe-guard legislation (a bit like FDIC for banks), given how much every other service wants your email address. Even my power utility wants my email address.
It is made abundantly clear when you set up 2FA that you need to backup your 2FA or it may not be possible to recover. What did you expect? Personal responsibility is important.
Yes and what I’m saying is that is not an okay solution. If you lost absolutely all your proof of ID and bank cards, there is still ways to sufficiently prove your identity and recover access to your assets and bank accounts. An email address is an asset.
That is just your opinion. Those "ways to sufficiently prove your identity" are also ways that identity theft happen every single day. Some people prefer to take personal responsibility over opening themselves up to compromise.
In any case, if you thought that is not acceptable to you, you should not have set up 2FA because the conditions were clearly communicated.
In any case, if you thought that is not acceptable to you, you should not have set up 2FA because the conditions were clearly communicated.
[deleted]
It’s not possible to completely disable 2FA with paid Google domain accounts either. I’ve explicitly turned off 2FA for my paid Google account and it continues to ask me to type a text code or YouTube code.
Crazy how you can’t even pay to get rid of these “lose your phone lose account forever” features.
My mother had an account inaccessible as the mfa backup workflow did not work, my email was the second factor but it refused any codes I provided. I assume this is a functional bug but google has no inbound communications so I could never resolve it. My mum ended up requesting her old number from a phone provider who obliged.
The world will be a better place when legislation requires these evilcorps to at least have some baseline responsibilities to the people who they are supposedly helping while making trillions in revenue.
The world will be a better place when legislation requires these evilcorps to at least have some baseline responsibilities to the people who they are supposedly helping while making trillions in revenue.
This website does not have any information about owners or legal entity behind it. Who is running this? What is their physical address? Where are they registered?
Honest question: how do I know and verify they really care about privacy and they are not one doing shady things?
This is really honest question. How can anybody trust that company x care about privacy without even know anything about company x?
Honest question: how do I know and verify they really care about privacy and they are not one doing shady things?
This is really honest question. How can anybody trust that company x care about privacy without even know anything about company x?
When it comes to SaaSes, absolutely nothing. It's all social. Even knowing the owners doesn't give you much more assurance that it's legit, unless they're very well known.
That said, most liars are really really bad at lying. "We care about your privacy! Now let us load 1000 tracking libraries, kthxbai" is pretty easy to spot.
I think the scarier case is when dealing with a government adversary. They're simply not as stupid, and you never know when it could happen: https://archive.ph/rI8mE
For those cases, I get unnerved when things seem too good to be true. If I didn't know former Mullvad employee(s), I'd be deeply concerned about them, too.
That said, most liars are really really bad at lying. "We care about your privacy! Now let us load 1000 tracking libraries, kthxbai" is pretty easy to spot.
I think the scarier case is when dealing with a government adversary. They're simply not as stupid, and you never know when it could happen: https://archive.ph/rI8mE
For those cases, I get unnerved when things seem too good to be true. If I didn't know former Mullvad employee(s), I'd be deeply concerned about them, too.
It is not about liar. The owner of the web site is probably nice and all these things. Some social proof (LinkedIn, address etc) is really needed. I always check LinkedIn’s to see where that person worked, what does it do, etc. Not a good test but it is better than nothing.
But on the other hand, the owner can be NK. Or what if it gets taken over by NK? Or what if somebody starts claiming that they were running this business and it was hijacked?
But on the other hand, the owner can be NK. Or what if it gets taken over by NK? Or what if somebody starts claiming that they were running this business and it was hijacked?
Thankfully, most people shouldn't consider "government adversary" high in their "threat assessment".
I think "targeted government adversary" shouldn't be. But government in general?
https://www.pcmag.com/news/fbi-sold-criminals-fake-encrypted...
Maybe.
https://www.pcmag.com/news/fbi-sold-criminals-fake-encrypted...
Maybe.
I mean, "government in general" is kind of meaningless, some governments are much more of a threat to some people than others.
Also, while your example is great (and I think I have seen it predicted !), criminal organizations aren't "most" nor "people" (more like businesses ?).
Also, while your example is great (and I think I have seen it predicted !), criminal organizations aren't "most" nor "people" (more like businesses ?).
> This website does not have any information about owners or legal entity behind it.
I searched for Sensor Station LLC. That points to this company: https://www.sensorstation.co/
This company seems to be making embedded software for sensors. Now I’m concern.
This company seems to be making embedded software for sensors. Now I’m concern.
It's a digital agency. https://clients.sensorstation.co/
> We specialize in custom software projects above and beyond the typical web agency: realtime interactive experiences, high-concurrency backends, and everything in between.
Appears to be a husband-and-wife team whose personal projects include tech to support their permaculture lifestyle, but whose portfolio appears to be mostly brand related.
Took about five minutes of reading, but I know that's not the point you're trying to make, you just don't want to say Slimvoice is an unprofessionally run service.
> We specialize in custom software projects above and beyond the typical web agency: realtime interactive experiences, high-concurrency backends, and everything in between.
Appears to be a husband-and-wife team whose personal projects include tech to support their permaculture lifestyle, but whose portfolio appears to be mostly brand related.
Took about five minutes of reading, but I know that's not the point you're trying to make, you just don't want to say Slimvoice is an unprofessionally run service.
[deleted]
But what about the privacy of the people not using google at all. All other trackers are (or should) be blocked by my adblocker, but my adblocker can't block the google sign-in button because some people use that. So another way to defeat anti-tracking software.
Plus those google sign-in buttons have recently become extra-obnoxious, opening a modal window over every page I visit to invite me to sign-in with google. This is really back to the 90s!
Plus those google sign-in buttons have recently become extra-obnoxious, opening a modal window over every page I visit to invite me to sign-in with google. This is really back to the 90s!
I don't care. I don't want to maintain a bunch of passwords for rarely-used Web sites.
Not just Google themselves, I still use my old university email and they decided recently ("for security") to block using it to log in to other sites, along with a million other things, so their own staff can't even open Search Console. Fortunately, a lot of them allow "forgot my password" to go to email if you can't login through Google, but a few required new accounts.
This is true for most email addresses as well. If you use a domain name for your email that is owned by another company, then you you can be locked out of your email (and any downstream accounts).
I work in tech and 99% of my contacts are with @gmail (or some other free email host).
I work in tech and 99% of my contacts are with @gmail (or some other free email host).
Most sites that require an email for sign-up only verify the email address once right after sign-up.
So if Google ever locks my account, my other website passwords continue to work, while SSO using Google is instantly broken.
Of course I won't be able anymore to reset my third party passwords through my Gmail mailbox, but many sites allow to change the email address if you know the password...
So if Google ever locks my account, my other website passwords continue to work, while SSO using Google is instantly broken.
Of course I won't be able anymore to reset my third party passwords through my Gmail mailbox, but many sites allow to change the email address if you know the password...
I judge the likelihood of this happening rather low and, anyway, considering how many services don't let you change your e-mail address, what's the difference?
I have the same problem with Tailscale only supporting providers
"Your 2FA authentication has been downgraded to email/password for ideological reasons."
Well, only if the person has 2FA set up in their Google account, which most people don't in my experience.
That aside, do you have a recommendation for auth that provides good privacy while also having wide adoption and ease of integration similar to Google or Facebook auth? And also 2FA of course.
If there are no options then I think our problem is bigger than this particular dev's ideology.
That aside, do you have a recommendation for auth that provides good privacy while also having wide adoption and ease of integration similar to Google or Facebook auth? And also 2FA of course.
If there are no options then I think our problem is bigger than this particular dev's ideology.
It's not that difficult to roll your own secure auth, this website is halfway there. Add TOTP and Webauthn and they're basically done (there's plenty of good libraries out there for both).
They also really should switch from bcrypt to something more modern like argon2, but bcrypt is a lot better than the unsalted MD5 I've seen in a lot of places.
They also really should switch from bcrypt to something more modern like argon2, but bcrypt is a lot better than the unsalted MD5 I've seen in a lot of places.
Username and password:
Factor #1 - Thing you have: encrypted password vault.
Factor #2 - Thing you know: password to said vault.
Of course, this is only 2FA from the user's perspective. Meddling websites cannot ensure that you didn't memorize their password, or write it down unencrypted.
Factor #1 - Thing you have: encrypted password vault.
Factor #2 - Thing you know: password to said vault.
Of course, this is only 2FA from the user's perspective. Meddling websites cannot ensure that you didn't memorize their password, or write it down unencrypted.
Multifactor authentication is a combination of 2 or more of the following factors.
- Something you know: password.
- Something you have: your phone or a physical key.
- Something you are: Biometrics (finger-print, eye pattern, gait of your walk, etc.)
Using 2 passwords, such as the case of knowing the password to your vault of passwords, is only 1 factor.
- Something you know: password.
- Something you have: your phone or a physical key.
- Something you are: Biometrics (finger-print, eye pattern, gait of your walk, etc.)
Using 2 passwords, such as the case of knowing the password to your vault of passwords, is only 1 factor.
I think the GP was implying that the vault would store a random string, which would be unreasonable for anyone to possibly guess. This isn't either of the factors - just a proof you had both of them.
The 2 factors are then the vault itself and the vaults password.
It should be noted, though, this is significantly weaker than "real" 2FA, as normally that would involve some sort of challenge, rather than just storing a hard secret.
The 2 factors are then the vault itself and the vaults password.
It should be noted, though, this is significantly weaker than "real" 2FA, as normally that would involve some sort of challenge, rather than just storing a hard secret.
[deleted]
Google have enabled 2FA by default.
That's exactly my impression too. Authentication is hard. And this isn't some random site wanting to store user data, they're doing invoice management! (So... not quite handling money on behalf of users, but pretty darn close in terms of liability.)
Regardless of your feelings on Big Tech and Privacy and whatnot, this absolutely looks like a security downgrade to me. If I were someone looking for para-financial services like this to phish with fake users for fraud purposes, I'd probably start with a site like Slimvoice.
Personally I think there's a good argument to be made about the benefits and tradeoffs to allowing giant cloud companies to control the idea of "identity" on the internet. But if there's any market segment where big companies with deep pockets and extensive technical resources bring value, it's this one.
Regardless of your feelings on Big Tech and Privacy and whatnot, this absolutely looks like a security downgrade to me. If I were someone looking for para-financial services like this to phish with fake users for fraud purposes, I'd probably start with a site like Slimvoice.
Personally I think there's a good argument to be made about the benefits and tradeoffs to allowing giant cloud companies to control the idea of "identity" on the internet. But if there's any market segment where big companies with deep pockets and extensive technical resources bring value, it's this one.
> Authentication is hard.
No, it’s not.
It’s certainly not harder or more complicated than the OAuth protocol used support Google-based sign-in.
Exactly what unique value do you believe these big companies bring, exactly?
No, it’s not.
It’s certainly not harder or more complicated than the OAuth protocol used support Google-based sign-in.
Exactly what unique value do you believe these big companies bring, exactly?
It actually is very hard. There’s a long tail of concerns that make it difficult to do authentication as well as a major player in the space.
What exactly about it is hard?
The part where you guarantee to your users that the person you authenticated is who they seem to be. In this particular example: "Is this invoice I'm about to pay for the service I purchased, or is it fraud?"
Farming that responsibility off to Google or Facebook and letting them handle the edge cases (for free, I might add) has genuine security value.
Farming that responsibility off to Google or Facebook and letting them handle the edge cases (for free, I might add) has genuine security value.
Do we know that they haven't implemented another 2FA mechanism behind that email/password?
It takes all of 30 seconds to sign up an account and check. I was not offered 2FA during sign up, and cannot find anywhere on the site to enable it after logging in. If you don't believe me or think that I somehow missed it, feel free to create your own account and test.
And your can clearly see from the "Code" section in the same page as the privacy policy that this is only ideological and that this guy just likes to push his bad practices on others.
It's cool, people are entitled to their opinions and ideas.
I too don't like third party sign ups, I think they are bad for privacy and the user.
I too don't like third party sign ups, I think they are bad for privacy and the user.
"Google will no longer know you use our app! Hooray for privacy"
"... but you still send me app related mails to my gmail account, what does this change".
"...... FREEEDOM!!!"
"... but you still send me app related mails to my gmail account, what does this change".
"...... FREEEDOM!!!"
It may be surprising, but there are people who live outside of the google ecosystem too.
Okay, then. That was always allowed.
Nobody was discussing replacing plain old login with google, just having an option.
Try understanding the thread before answering next time please, this is a very low effort bait
Try understanding the thread before answering next time please, this is a very low effort bait
Except that now they have an unblockable google tracking beacon wherever they go. So my question is what about their privacy?
That’s hardly the only information Google gets from managing logins. Trivially they can get time stamps for actual logins, that could be very valuable information for stock brokers for example.
Aside from the privacy improvement, what a beautifully functional site.
The developer made a nice article on how he did it with almost none javascript. Interesting read: https://javascript.works-hub.com/learn/a-javascript-free-fro...
Thanks for the link. I read it and I too desire for minimal/javascript-less world. However,
> The Checkbox/Label Trick
I'm hesitant to use this. It just doesn't feel right to use this hack.
Also somewhat related to the <details>/<summary>, I try using native html elements as much as possible. One time I used the <meter> element for a meter bar, but it was called out immediately by QA because the design doesn't match the one created by the UI/UX team. I really wish html elements were more customizable.
> The Checkbox/Label Trick
I'm hesitant to use this. It just doesn't feel right to use this hack.
Also somewhat related to the <details>/<summary>, I try using native html elements as much as possible. One time I used the <meter> element for a meter bar, but it was called out immediately by QA because the design doesn't match the one created by the UI/UX team. I really wish html elements were more customizable.
indeed, the about page also is not your usual legal boilerplate either
Never use Google anything for --including login-- for anything important. The company continues to cause damage to people and businesses through their customer-no-service stance regarding accounts, their suspension or cancellation. I know people who's small businesses suffered a great deal of damage because of this. Talk about a need for a congressional hearing!
Besides, single sign-on is a security disaster. In an ideal world every single login you have should have a different user ID and password. I do my best to approach this. Of course, you have to rely on password management software to be able to do this.
There is no such thing as absolute security. However, making every login ID and pwd different goes a long way towards ensuring you don't experience a chain reaction of breaches because someone hacked into one account.
Yes, the password manager could be considered to be the weak point then. Encryption and a long and secure password are the keys there. And, if you can, one that is accessible online.
Besides, single sign-on is a security disaster. In an ideal world every single login you have should have a different user ID and password. I do my best to approach this. Of course, you have to rely on password management software to be able to do this.
There is no such thing as absolute security. However, making every login ID and pwd different goes a long way towards ensuring you don't experience a chain reaction of breaches because someone hacked into one account.
Yes, the password manager could be considered to be the weak point then. Encryption and a long and secure password are the keys there. And, if you can, one that is accessible online.
Couldn't disagree more. Password managers have the same single point of failure that an SSO would. The only difference is that you can't automate onboarding/offboarding of an employee's SaAS applications.
Correction: is not accessible online
Who is slimvoice.co and why do we even care about their opinions or reasonings?
If the goal is protecting users from themselves, the owner should go the extra mile and reject signups with @gmail/@outlook emails, to gently encourage them not use services that don't value their privacy.
I left google. After half a year I have received dmarc reports from a site other than google just once. So did it matter if 99% of people I email are still using google? They have every email I have sent anyway.
Can't wait for the rise of libre hardware keys so more people can escape to FIDO instead of being chained to adtech.
You might want to check out https://solokeys.com/ then. They're pretty new (shipping for about a year) but they do full FOSS firmware & software as well as most hardware being FOSS as well.
I have a couple of these and they work well. Unfortunately it seems like most sites that I use (with a few notable exceptions) don't bother to support hardware tokens for 2FA, I suspect because of the ubiquity of phone-based methods.
If you want something now and don't mind a virtual FIDO device, you could try out my solution Bulwark Passkey (https://bulwark.id). It's open source and allows you to export your credentials, so it's pretty user-freedom friendly.
This doesn't increase anyone's privacy
Before: When signing up with Google the owner gets your name, email, and profile picture
After: When signing up without Google the owner gets your name and email, but the owner can make an API request to get your profile picture.
In both scenarios the same amount of information is accessible by the site.
Before: When signing up with Google the owner gets your name, email, and profile picture
After: When signing up without Google the owner gets your name and email, but the owner can make an API request to get your profile picture.
In both scenarios the same amount of information is accessible by the site.
If I sign in with Google, won't Google know I have an account on that site? I would consider that a privacy issue.
If you put email account in the login they will know on the first e-mail the site sends to your email
Not if I don't use a Google email address. :)
Yes but then you wouldn't have been able to use Sign in with Google anyway.
Why is Google just knowing you have an account on that site a privacy issue?
I think it's to do with these new 'Signals' they seem to be building profiles of interest based on services.
https://support.google.com/analytics/answer/9445345?hl=en#zi...
https://support.google.com/analytics/answer/9445345?hl=en#zi...
Oh Google doesn't need to go so far to know you have an account on that site.
A single tracking cookie shared with their one of their many many partners is enough
A single tracking cookie shared with their one of their many many partners is enough
The can just scan for signup emails and get the same thing
And Here's Why That's a Good Thing
Agree with it or not, it's about limiting the information Google gets about you.
svnpenn(4)
> We wanted to prove that it was possible to deliver an amazing user experience while bucking the trend of JavaScript-heavy bullshit web apps.
Preach
Preach
This website does not have any information about owners or legal entity behind it. Who is running this? What is their physical address? Where are they registered?
Meaning they are managing invoices: the above informantion is very important.
This seems more like Google ban them than they did something about “privacy”.
Meaning they are managing invoices: the above informantion is very important.
This seems more like Google ban them than they did something about “privacy”.
Their company "Sensor Station LLC" is mentioned multiple times in the Terms: https://slimvoice.co/terms
Data on that company can be found here: https://opengovus.com/virginia-business/S8451587
Data on that company can be found here: https://opengovus.com/virginia-business/S8451587
This should be listed in about page and privacy page. Note that GDPR requires physical address also to be listed on privacy page: but I guess they do not care about that stupid GDPR privacy thing.
Fwiw, I've been using them since 2016 and have sent hundreds of invoices. Simple and functional tool.
That is not my point. My point is that you can not (and you must not) just blindly trust random entities claiming “I’m about privacy” without being transparent who they are, where they are from and all these company informations required by GDPR or California privacy protection laws.
[deleted]
You make a good point, however there is a wide-world outside the borders of Europe and California.
This post gives me an opportunity to ask a question. What if I am locked out of my gmail id? Would I be able to use services, such as Github or Pocket, which I log in through gmail id?
It depends on the service. Github lets you add a backup email address to manage password resets, etc.
nit: on their reasoning page: - non-existant should be non-existent
I can take care of myself, thanks.
Encouraging worse security practices (dumping SSO for password logins) for an ideological goal that helps no one's privacy.
Passkeys becoming prevalent makes dropping BigTech SSO for personal use more palatable.
Google will still store and sync the keys for users of Android and Chrome, but their code won’t run on sites who opt out of Login with Google. It’s an evolution of the security model. This is arguably superior considering the ability to migrate passkeys elsewhere. You have improved sovereignty over your auth story (versus “haha google locked you out of everything and you have no recourse”).
TLDR PKI > consumer federated identity
Google will still store and sync the keys for users of Android and Chrome, but their code won’t run on sites who opt out of Login with Google. It’s an evolution of the security model. This is arguably superior considering the ability to migrate passkeys elsewhere. You have improved sovereignty over your auth story (versus “haha google locked you out of everything and you have no recourse”).
TLDR PKI > consumer federated identity
I use a hardware security token to log into my Google account and then use that to log in to several other services. If I were to lose my token, I would still have my backup tokens, and could update this account to use a new token and unenroll the old token.
If instead, every site I had ever logged into kept track of my tokens I would need to visit each of them and do the same thing.
(It's already messier than that because some accounts I have--GitHub and Facebook--don't accept SSO but are important enough to be worth protecting with hardware tokens. But I don't want to go farther in this direction!)
If instead, every site I had ever logged into kept track of my tokens I would need to visit each of them and do the same thing.
(It's already messier than that because some accounts I have--GitHub and Facebook--don't accept SSO but are important enough to be worth protecting with hardware tokens. But I don't want to go farther in this direction!)
We’re not talking a loss of a hardware authenticator, we’re talking the loss of access to your Google account. Worst case with passkeys is you lose access to the cloud corpus of your keys due to loss of account access while still having them on your device (and/or a passkey manager).
I think I'm much much more likely to lose a hardware authenticator than my Google account
And that's not necessarily universally true.
* Securing hardware authenticators is much more within our control than the whims of Google are.
* Most of us aren't ex-Googlers with contacts and reach (which are the only way to get reliable support when one's account does get borked), so that side of the risk is also much higher for normal people than for you.
* Securing hardware authenticators is much more within our control than the whims of Google are.
* Most of us aren't ex-Googlers with contacts and reach (which are the only way to get reliable support when one's account does get borked), so that side of the risk is also much higher for normal people than for you.
https://hn.algolia.com/?q=google+account+locked+out
https://news.ycombinator.com/item?id=30771057
And that’s just HN participants, not the unknown layman cohort.
https://news.ycombinator.com/item?id=30771057
And that’s just HN participants, not the unknown layman cohort.
I read through the links, and there were about 15 posts where people got locked out of their Google account over a 12-year period. Many of these are links to articles on other sites not written by the submitter, but we'll count them anyway. So that's ~1 per year.
According to dang, there are ~100k monthly active logged-in HN users [1]. In a population that size of 25-54 year-old Americans, you'd expect around 290 to die each year [2].
Getting locked out of my Google account is pretty low on my list of things to worry about.
[1] https://news.ycombinator.com/item?id=9219581 (and that was in 2015 - I assume it's grown since then)
[2] https://www.cdc.gov/nchs/products/databriefs/db427.htm
According to dang, there are ~100k monthly active logged-in HN users [1]. In a population that size of 25-54 year-old Americans, you'd expect around 290 to die each year [2].
Getting locked out of my Google account is pretty low on my list of things to worry about.
[1] https://news.ycombinator.com/item?id=9219581 (and that was in 2015 - I assume it's grown since then)
[2] https://www.cdc.gov/nchs/products/databriefs/db427.htm
On the other hand, if the yearly amount is so small, a service (a single dedicated human) to fix/reset/correct those issues should be affordable by Google.
This is not specific about Google, a lot of services/apps/whatever like (and it is probably true) to state how they are in practice error-free, at least with account management, yet when this extremely rare event happens there are no (or extremely complex) ways to fix the problem, short of posting to HN or to a social and hope that some good soul working at that company notices the issue and decides to solve it.
This is not specific about Google, a lot of services/apps/whatever like (and it is probably true) to state how they are in practice error-free, at least with account management, yet when this extremely rare event happens there are no (or extremely complex) ways to fix the problem, short of posting to HN or to a social and hope that some good soul working at that company notices the issue and decides to solve it.
If you look through those they are almost all about people forgetting their password or losing whatever they are using for 2FA: that is exactly what I'm worried about!
In my particular case, I am happy with my 2FA setup for Google (three security keys, across multiple locations) so I think that category of lockout is pretty unlikely.
And I've already lost my keys once in my life, about 20 years ago.
In my particular case, I am happy with my 2FA setup for Google (three security keys, across multiple locations) so I think that category of lockout is pretty unlikely.
And I've already lost my keys once in my life, about 20 years ago.
How do you think that compares to "lost my keys" or "lost my wallet"?
What I'm advocating for above is that people get multiple hardware tokens, and keep them in separate safe places. What Doreen is running into is that if you use your phone as your only second factor you have a problem if your phone stops working. I don't see how these are in tension?
I think our expectations are simply out of alignment. What you're advocating for is unreasonable if a loss of hardware tokens means a permanent loss of account access with no recourse, and I don't think that's a hard case to make to legislators and regulators.
I didn't say anywhere that loss of a hardware token should mean "permanent loss of account access with no recourse"?
What resource can Doreen go to at Google to get access to their accounts if Google’s security algorithm is requiring access to devices or authenticators they no longer have? I’m trying to be reasonable, but all I see is a tech company who enforces strong security practices with no exception handling. Great for Google and keeping costs down from an infosec and customer service perspective, but highly detrimental to those who lose what is very valuable to them (their emails and digital identity), and humans will lose valuable items (including devices, authenticators, and recovery codes) all the time.
I don’t expect for us to solve this here, and I’m sure my perspective will differ substantially from those affiliated with Google or tech professionals in general (who don’t fully internalize the layman’s experience). I do believe I’ve provided sufficient evidence this is a real problem, and it’s likely going to require federal statute or FTC guidance to require tech companies to recalibrate their customer service and infosec ops around access and identity.
Regardless, I appreciate the discourse on this topic.
I don’t expect for us to solve this here, and I’m sure my perspective will differ substantially from those affiliated with Google or tech professionals in general (who don’t fully internalize the layman’s experience). I do believe I’ve provided sufficient evidence this is a real problem, and it’s likely going to require federal statute or FTC guidance to require tech companies to recalibrate their customer service and infosec ops around access and identity.
Regardless, I appreciate the discourse on this topic.
I don't understand why you're arguing this with me? It doesn't seem to relate to anything I've said above
For passkeys, I think allowing users to migrate their credentials wherever they want is key. I know Google/Apple/etc are working on a potential solution for that, but I think third-party solutions would be best from an "incentive alignment" perspective (Google and Apple don't want you moving away from their ecosystem).
As an aside, I would like to plug my own passkey solution, Bulwark Passkey (https://bulwark.id) which is open source and allows credential exports. Whatever passkey solutions people end up using, managing credentials is going to be the key challenge (pun intended).
As an aside, I would like to plug my own passkey solution, Bulwark Passkey (https://bulwark.id) which is open source and allows credential exports. Whatever passkey solutions people end up using, managing credentials is going to be the key challenge (pun intended).
> Encouraging worse security practices (dumping SSO for password logins) for an ideological goal that helps no one's privacy.
It hardly seems reasonable or rational to attack the mere thought of handing out all auth responsibilities to a shady monopoly with a track record of dubious practices and government tie-ins for being "an ideological goal that helps no one's privacy".
It hardly seems reasonable or rational to attack the mere thought of handing out all auth responsibilities to a shady monopoly with a track record of dubious practices and government tie-ins for being "an ideological goal that helps no one's privacy".
The pervasiveness of any Google code running on webpages across the net has been a danger to everyone's privacy. I think this is a worthwhile tradeoff though I'm sure many like you will disagree.
I don't see why the page would be the one deciding that tradeoff for user. As long as you can pick plain old user/password there is no ham offering other options
* There is nothing wrong with password logins if they are used properly.
* Google does not have a good track record of customer service, not putting all your eggs in their unreliable basket seems like a good idea from a security point of view.
* The privacy argument is a bit of a hot take in this case, and is probably not as valid as a reason to dump Google SSO as eggs-in-unreliable-basket argument.
* Google does not have a good track record of customer service, not putting all your eggs in their unreliable basket seems like a good idea from a security point of view.
* The privacy argument is a bit of a hot take in this case, and is probably not as valid as a reason to dump Google SSO as eggs-in-unreliable-basket argument.
password logins are better security than phone verification in many cases.
Password logins are 1-factor, while password logins that use phone verification are 2-factor. In what cases does the security from 1-factor exceed the security from 2-factors?
Phone verification is 1-factor in most implementations on every popular website. It's just that the factor is now your phone, and your password can be changed with your phone number. Your password might as well not exist. The problem with phone verification is that phones are less secure than passwords. This isn't even a 1 factor vs 2 factor discussion. Again, Phone verification is 1 factor.
To be more specific, if the implementation of 2 factors requires both factors, then it is indeed more secure. If it's a form of 2 factor that requires only one factor, it's less secure, because now you have more attack surface.
To be more specific, if the implementation of 2 factors requires both factors, then it is indeed more secure. If it's a form of 2 factor that requires only one factor, it's less secure, because now you have more attack surface.
> In what cases does the security from 1-factor exceed the security from 2-factors?
1. If you consider the loss of a phone number to be a more likely event than a forgotten password (non-obvious example - if you have no extra money to keep the phone number working).
2. If some powerful contractors can capture the data coming to your phone.
3. Also, if there is some kind of banhammer (Google is famous for banning for no reason) in the "2-factor" and no banhammer in the 1-factor (Bitcoin has no third-parties who might steal or freeze your funds), then your chance of encountering a banhammer in your face is infinitely greater in the first case.
More than 1 factor creates more problems than usefullness tbh if you are enough responsible for never lose your credentials.
1. If you consider the loss of a phone number to be a more likely event than a forgotten password (non-obvious example - if you have no extra money to keep the phone number working).
2. If some powerful contractors can capture the data coming to your phone.
3. Also, if there is some kind of banhammer (Google is famous for banning for no reason) in the "2-factor" and no banhammer in the 1-factor (Bitcoin has no third-parties who might steal or freeze your funds), then your chance of encountering a banhammer in your face is infinitely greater in the first case.
More than 1 factor creates more problems than usefullness tbh if you are enough responsible for never lose your credentials.
> 1. If you consider the loss of a phone number to be a more likely event than a forgotten password (non-obvious example - if you have no extra money to keep the phone number working).
That's silly. If you lost your phone number, why would you attempt to log into a service and have it text or call your lost phone number? The provider in question here (along with many others), Google, provides backup codes for this situation. Besides, if you are more likely to constantly lose phone numbers, it's best not to use those for authentication/authorization.
> 2. If some powerful contractors can capture the data coming to your phone.
That doesn't matter to 2-factor. That "powerful contractor" would be in possession of a time-bound pin that can only be used by the device and account that had just had the credentials entered. It is useless to anyone else.
> 3. Also, if there is some kind of banhammer (Google is famous for banning for no reason) in the "2-factor" and no banhammer in the 1-factor (Bitcoin has no third-parties who might steal or freeze your funds), then your chance of encountering a banhammer in your face is infinitely greater in the first case.
This also doesn't apply. Google provides backup codes that can be used in such a case. As do digital ocean and others...
> More than 1 factor creates more problems than usefullness tbh if you are enough responsible for never lose your credentials.
Except that isn't true. I noticed that you placed 2-factor in quotes, showing that you likely do not understand 2-factor is formed from any two out of the three possible security factors. There is also 1.5 factor authentication, which is acceptable to put in quotes, since it is pseudo-2factor.
What you know. What you have. What you are.
> (Bitcoin has no third-parties who might steal or freeze your funds)
I'm not sure your comment was serious... Bitcoin and the entire crypto ecosystem are full of third-parties who steal or freeze funds.
That's silly. If you lost your phone number, why would you attempt to log into a service and have it text or call your lost phone number? The provider in question here (along with many others), Google, provides backup codes for this situation. Besides, if you are more likely to constantly lose phone numbers, it's best not to use those for authentication/authorization.
> 2. If some powerful contractors can capture the data coming to your phone.
That doesn't matter to 2-factor. That "powerful contractor" would be in possession of a time-bound pin that can only be used by the device and account that had just had the credentials entered. It is useless to anyone else.
> 3. Also, if there is some kind of banhammer (Google is famous for banning for no reason) in the "2-factor" and no banhammer in the 1-factor (Bitcoin has no third-parties who might steal or freeze your funds), then your chance of encountering a banhammer in your face is infinitely greater in the first case.
This also doesn't apply. Google provides backup codes that can be used in such a case. As do digital ocean and others...
> More than 1 factor creates more problems than usefullness tbh if you are enough responsible for never lose your credentials.
Except that isn't true. I noticed that you placed 2-factor in quotes, showing that you likely do not understand 2-factor is formed from any two out of the three possible security factors. There is also 1.5 factor authentication, which is acceptable to put in quotes, since it is pseudo-2factor.
What you know. What you have. What you are.
> (Bitcoin has no third-parties who might steal or freeze your funds)
I'm not sure your comment was serious... Bitcoin and the entire crypto ecosystem are full of third-parties who steal or freeze funds.
[deleted]
[deleted]
How many sites are out there with a "Sign In with Google" form that solely exists to harvest peoples' Google credentials?
That's not how OAuth works, which is what "Sign In with Google" utilizes. In order to Sign In with Google through a third-party software, Google and the third-party software must both agree to the arrangement.
In the event they do, the third-party software adds a Google Sign In flow to their software, whereas their users can press a call-to-action for signing in with Google, which would trigger an opening of a separate Google-owned domain in a new min-browser window that the third-party software cannot access (and therefore not harvest information from). This min-window then sends the user back to the third-party software domain upon completion with an authentication token - which could be in the form of a URL query string, an HTTP method, a cookie, or even collection of arbitrary browser information for fingerprinting. The third-party site then sends that authentication token back to Google via their API, and Google sends back ONLY what that authentication token is permitted to grant access to - which would not be Google credentials.
In the event they do, the third-party software adds a Google Sign In flow to their software, whereas their users can press a call-to-action for signing in with Google, which would trigger an opening of a separate Google-owned domain in a new min-browser window that the third-party software cannot access (and therefore not harvest information from). This min-window then sends the user back to the third-party software domain upon completion with an authentication token - which could be in the form of a URL query string, an HTTP method, a cookie, or even collection of arbitrary browser information for fingerprinting. The third-party site then sends that authentication token back to Google via their API, and Google sends back ONLY what that authentication token is permitted to grant access to - which would not be Google credentials.
You seem like you might know why the option to pick the authentication company (like Google, but also choose your own that follows the protocol) seems to have disappeared from these boxes, and instead boxes ties to a specific company have multiplied ?
Because those companies incentivize it. For one, you can't use an Oauth integration on your app if you deploy in on the Apple App Store unless you offer Apple as an option, so there's a vector for Apple Oauth hegemony right there. And for Google, it really just makes sense for most users - it's an ethic-neutral option that you know everyone already has and uses daily. Facebook is still a popular Oauth option as well, but has lost a lot of collective conscious trust, so a lot of services don't play ball with supporting them.
It's really as easy as these companies that support Oauth incentivizing third-party devs to use them.
It's really as easy as these companies that support Oauth incentivizing third-party devs to use them.
Yes, that's the way it works. But what's stopping a bad actor from putting up a bogus "Sign in with Google" form on their website solely to harvest credentials?
I'm confused. In your first comment you seemed to refer to legitimate sites harvesting credentials using Google SSO (whatever that means)
Now you're talking about phishing sites.
Can you clarify which kind of websites you're referring to?
Now you're talking about phishing sites.
Can you clarify which kind of websites you're referring to?
I was always talking about bad actors (i.e. phishing sites).
[deleted]
What credentials could they harvest?
If I'm asked to sign in with google via oauth, I never type in my password (or username!).
If I'm asked to sign in with google via oauth, I never type in my password (or username!).
true, but that's only the case if you're currently authenticated with Google. Not true after deleting cookies and/or local storage. But more importantly, less savy tech folks might not be aware that they should not have to re-enter credentials if they have recently logged into gmail or other google owned services.
If Google decides to lock your account for any reason, all your third party accounts using Google's SSO are mostly fubar, as it's currently almost impossible to get your Google account back.