Translation: Every account must be tied to mobile number. No more privacy
Translation: throwaway5486nv has poor reading comprehension
Its not about what's written. Its about the intention behind this.
Less secure apps and your Google Account
261–270 of 272 posts
Re: Less secure apps and your Google Account
#262Oops. I have small web apps that use gmail accounts to send mail via SMTP, but this requires turning on "allow less secure apps". Will this break those apps? I suspected this would happen eventually and it's been finicky the past year or so anyway. It was a lazy solution to begin with -- so, I'm setting a reminder about this for May 20th.
Sadly I believe it will stop working. I'm in the same boat and have been putting off moving to a Google blessed solution because of the effort required to navigate the bewildering array of documentation, client libraries and authentication mechanisms Google offers. Much of the documentation and examples Google makes available are targeted at accessing Gmail on behalf of a human user (who has access to a browser) rath…
Thank you for that comment, very helpful.
Re: Less secure apps and your Google Account
#263Earlier quoted context omitted.
I really think Google needs to make a distinction between sending your credentials to a foreign 3rd party service/domain vs a “3rd party” client that runs on your machine. Sending your credentials somewhere else is understandably best avoided. Using a different “3rd party” user agent than the top 3 browsers to access some google services, on the other hand, really isn’t less secure at all and I even think an argument…
> Local (wouldn't even mind if it was limited to open source) apps How could a rule like that be enforced? > lock down API access to blessed google clients and services. What's wrong with application specific passwords? (Still speaking only for myself)
> How could a rule like that be enforced?
Considering the review process is currently subjective, then subjectively I guess. If you say in the review that you're an open source app and that you only do native OAuth locally then you get approval. Google already requires a link to your project's homepage maybe additionally you have to provide one to your source code so the reviewers can verify. If you prove to be untrustworthy and in violation at some point in the future then your access gets pulled.
Maybe the problem is that google is trying to enforce client behavior in the first place? I thought the point of OAuth was that the user gets to approve or deny access to granularly scoped resources on their account, not google.
Re: Less secure apps and your Google Account
#264Earlier quoted context omitted.
I really think Google needs to make a distinction between sending your credentials to a foreign 3rd party service/domain vs a “3rd party” client that runs on your machine. Sending your credentials somewhere else is understandably best avoided. Using a different “3rd party” user agent than the top 3 browsers to access some google services, on the other hand, really isn’t less secure at all and I even think an argument…
> Local (wouldn't even mind if it was limited to open source) apps How could a rule like that be enforced? > lock down API access to blessed google clients and services. What's wrong with application specific passwords? (Still speaking only for myself)
Re app passwords: aren't you still a "less secure app" then? Really it's the messaging https://support.google.com/accounts/answer/185833?hl=en:
> Tip: App Passwords aren’t recommended and are unnecessary in most cases. To help keep your account secure, use "Sign in with Google" to connect apps to your Google Account.
>
> An App Password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App Passwords can only be used with accounts that have 2-Step Verification turned on.
So e.g. I'm trying to build a "more secure" app that uses sign-in with google like it's supposed to and Google says "sorry your use case isn't approved". My recourse is just be a less secure app? Isn't that a little unfair? More-so, according to google's messaging, doesn't that make the user less secure?
Re: Less secure apps and your Google Account
#265Earlier quoted context omitted.
Sadly I believe it will stop working. I'm in the same boat and have been putting off moving to a Google blessed solution because of the effort required to navigate the bewildering array of documentation, client libraries and authentication mechanisms Google offers. Much of the documentation and examples Google makes available are targeted at accessing Gmail on behalf of a human user (who has access to a browser) rath…
Thank you for that comment, very helpful.
I should add, as many others have pointed out, that moving to use app passwords is a _much_ easier solution in the short term (how long they will be supported I have no idea) so I suggest you try that first.
This should have been the first thing I tried but, rather unhelpfully, the Google page where you create app passwords says "You'll only need to enter it once so you don't need to remember it" and later "You won't need to remember it, so don't write it down or share it with anyone.". This suggested to me that these passwords are single use (i.e. a OTP) but testing suggests that this is not the case. Also, whilst using app passwords requires that you enable 2FA on the account, they do _not_ require you to enter the 2nd factor when logging in with the app password (obvious in hindsight, but not made clear by the documentation).
I just tested that these work even when "less secure apps" is disabled at the domain admin level (and by extension the individual account). Indeed, after enabling 2FA for the account the option to enable/disable "less secure apps" is removed. So it seems that you can either have no-2FA + (optional) less-secure apps OR 2FA + app passwords.
Re: Less secure apps and your Google Account
#266Earlier quoted context omitted.
Here's one survey of alternatives: https://restoreprivacy.com/google-alternatives/ Personally, I use: * DDG for search. * gmx.com as my main email server (not sure it's that great for privacy, ProtonMail is probably better). * OpenStreetMap for maps (caveat: Some info is on Google Maps and not on there) * HereWeGo for car navigation * Thunderbird as my mail client + calendar * I don't publish videos, but otherwise pr…
GMX exposes your IP address in email headers.
Well, I wasn't expecting it to hide my IP address. By default, the Received headers should show the chain of transmission back to my IP.
Re: Less secure apps and your Google Account
#267Earlier quoted context omitted.
Googles 2fa requires the user to give google his phone number before being able to add a totp authenticatior. That alone is reason for me to never use it for my google account. The popup also doesn't come up if you haven't signed up with google on your phone, obviously. There is nothing stopping them from just allowing anyone to add a normal totp 2fa generator, they just chose to not do that to get more of that sweet…
Does Google fall back to SMS if you tell it you lost your totp authenticator? That’s problematic in its own way, but it would explain the phone number requirement.
Not if you remove the phone number afterwards. It just requires the phone number before enabling the normal otp.
Re: Less secure apps and your Google Account
#268Earlier quoted context omitted.
Indeed: this is a hard compatibility break, without a simple workaround. The thing is, this is nowhere near new: it's been announced years ago, and slowly rolled out since 2019. Actually, IIRC, the rollout has been postponed at least once in 2020, due to covid (in order to not cut people off). I recall implementing Xoauth for IMAP, specifically for this.
If you have two factor auth on and generate an "app-specific password" doesn't this allow you to do the same thing still? You just use your email and app-specific password to login and it should work still shouldn't it?
No idea how it works now, tbh - but the problem I was trying to solve, in 2019, was "there isn't always a live human at hand, available to solve two-factor challenges." I distinctly recall that we had to go for xoauth, for lack of other hands-off options.
Re: Less secure apps and your Google Account
#269Earlier quoted context omitted.
Suggestion? Start now. I moved my primary email to a custom domain a bit over a year ago, and it takes a while to slowly migrate everything over. You don't want to be doing that while under pressure from whatever it is that forces you off.
Any suggestions for good privacy-centric email providers?
If you want serious protection you should probably use one NOT based in the country you live in.
Re: Less secure apps and your Google Account
#270Earlier quoted context omitted.
It is not, in fact, a standard. It's a proprietary complicating thing that megacorps do and everyone else assumes is standard. https://datatracker.ietf.org/doc/html/rfc6749 "The OAuth 2.0 Authorization Framework" >This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope. So now you have HTTP protocol being used for IMAP, or worse and more common,…
> It is not, in fact, a standard. It's a proprietary complicating thing Nope, it's a standard. Standards you don't like aren't proprietary, they're just standards which superkuh doesn't like.
It it were standard the same OAuth 2.0 module could be used with every provider of services. The reality is you need a custom implementation for every single megacorp and their local twist. It's not even a defacto standard by collective use.