3 ms·

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 yo

by dcow 5y ago

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 could be made that it’s more secure than a browser in many cases. Local (wouldn't even mind if it was limited to open source) apps should be given unrestricted access to the Gmail OAuth scopes. Until then, I can’t see how this is anything other than a platform control play under the guise of user safety to lock down API access to blessed google clients and services.

jefftk 5y ago
> 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)
- dcow 5y ago
  > 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.
- dcow 5y ago
  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 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?

by dcow 5y ago

jefftk 5y ago

> 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)

dcow 5y ago
> 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.
dcow 5y ago
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 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?