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.
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...
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?
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.
> This website does not have any information about owners or legal entity behind it.
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 work in tech and 99% of my contacts are with @gmail (or some other free email host).
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...
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.
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.
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.
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.
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?
I too don't like third party sign ups, I think they are bad for privacy and the user.
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
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!)
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).
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".
* 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.
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.
A single tracking cookie shared with their one of their many many partners is enough
"... but you still send me app related mails to my gmail account, what does this change".
"...... FREEEDOM!!!"
Try understanding the thread before answering next time please, this is a very low effort bait
Meaning they are managing invoices: the above informantion is very important.
This seems more like Google ban them than they did something about “privacy”.
Data on that company can be found here: https://opengovus.com/virginia-business/S8451587
> 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.
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.
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.
Sign in with Google has been removed for your privacy.
Click here to create a password for your account.Preach