4 ms·

It's interesting how words can be strung together to avert scrutiny of relevant facts pertaining to the message being communicated—and sometimes even used to ma

by cxr 5y ago

It's interesting how words can be strung together to avert scrutiny of relevant facts pertaining to the message being communicated—and sometimes even used to mask dishonesty.* The terse form of the advisory states: > To help keep your account secure, starting May 30, 2022, Google will no longer support the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password. It's the innuendo that's interesting. The message in the subtext of this statement is, Look at these apps! They want you to use them for e.g. checking your email, but look at what they do! Isn't it awful? In order to let you check your email, they make you give them the password for your _whole_ Google account! Of course, the only one who's responsible for the current arrangement is Google. Google, not third-party developers, are to blame (and _solely_ to blame) for why access to the various Google services is consolidated into a single account. Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password, which is the same as your YouTube password, which is the same as the password you use to mark your phone as needing to be locked out of your account after it's stolen. * This is why I'm skeptical of the whole "writing forces you to be honest because it means you have to actually think things through well enough to put them into words that can be put into coherent sentences" meme. Nobody seems to talk about how writing and the revision process that's inherent to it also provides the opportunity to finesse words. Some idea can be made to appear as if it's sound and backed by solid reasoning even when the truth is actually much less straightforward—or even contradictory.

md_ 5y ago
> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password… Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.
- striking 5y ago
  Yeah, and for those that don't, app passwords are not hard to use. Slightly cumbersome, maybe, but I bet it'd take less time than GP took to write their comment.
- superkuh 5y ago
  If an email provider does not offer standard pop3 or imap it is not an email provider. It's just some web shit.
  - 0xCMP 5y ago
    they offer both. they simply require more secure authentication. something which doesn't require the app to know the username or password. it's that simple.
  - md_ 5y ago
    IMAP with OAuth is standard. What am I missing?
    - superkuh 5y ago
      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 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, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.
      - tialaramex 5y ago
        > 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.
        superkuh 5y ago
        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.
- habosa 5y ago
  In some cases yeah but not for mail. The GMail API is great but to use it you have to spend like $75k on a security review that Google has to approve.
  - md_ 5y ago
    You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).
    - tialaramex 5y ago
      You should be able to use the Bearer Token standard from RFC7628 rather than XOAUTH which is something Microsoft cobbled together, but either will probably work on most systems, just one of them is better documented.
- corobo 5y ago
  e: fyi the ringfence bit in this post is incorrect. Leaving for posterity but don't believe this comment, see replies :) -- Could just set up an app password limited to accessing gmail, been able to do that for like 10 years now and it's not going away with this change different password: check ringfenced access: check
  - md_ 5y ago
    App passwords are not limited in scope, AFAIK.
    - corobo 5y ago
      It said it was when I created one before posting to make sure I was thinking of Gmail and not Fastmail. Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought! I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!
- dcow 5y ago
  If Google granted arbitrary and fair access to those OAuth scopes then sure, but they don’t. I have personal experience with this, trust me.
- martius 5y ago
  Google provides the App passwords feature: > An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords. Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.
jstanley 5y ago
> This is why I'm skeptical of the whole "writing forces you to be honest because it means you have to actually think things through well enough to put them into words that can be put into coherent sentences" If you're making an earnest effort to think truthful thoughts, then trying to put your thoughts into writing is genuinely helpful. Writing doesn't stop you from deceiving others, but it helps to stop you from deceiving yourself.
dcow 5y ago
Conveniently Google also controls the allowed usages for “proper” OAuth access to Gmail. If your client is performing a function they don’t like then you’re screwed. I would expect that to be fair Google would have to also allow arbitrary access to the Gmail API to these now untouchable clients, but snowballs chance in hell Google will be so rational.
- jptech 5y ago
  I am willing to think that Google performs fingerprinting on the OAUTH login dialog window, which if prevented, similar to the comment above regarding Firefox being unsafe, it would block login through OAUTH as it pleases.
  - dcow 5y ago
    It also straight up doesn't allow you to publish an OAuth application that uses “restricted” scopes (like `gmail.*`) without a review process subject to arbitrary usage guidelines determined by the Google APIs team. That’s the catch. It doesn't even matter how you run the OAuth flow (though I agree I suspect they fingerprint that too). You get blocked earlier.
briffle 5y ago
> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password, which is the same as your YouTube password, which is the same as the password you use to mark your phone as needing to be locked out of your account after it's stolen. You mean like google's "Application Specific Passwords" that have been around for a VERY long time, and are not affected by this announcement? https://support.google.com/accounts/answer/185833?hl=en https://support.google.com/accounts/answer/185833?hl=en
- andreareina 5y ago
  Application specific passwords require two-factor auth being on, which means either giving google your phone number or having to pay for e.g. a yubikey.
  - amscanne 5y ago
    Or using a free authenticator app for time-based codes?
    - l72 5y ago
      How do you enable this without first giving google your phone number? My understanding is you have to set up SMS 2 factor auth first before you can change it to TOTP.
      - folmar 5y ago
        On a Workspace account you only need U2F token emulator (https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f woks fine) and thenn you can setup u2f first and add normal TOTP in second step. But u2f must stay there. I don't have a personal account to try if it works the same.
- cxr 5y ago
  I am familiar with that page. (Although I'm not sure how to interpret your "You mean like[...]" phrasing. It doesn't make sense in response to what I wrote.) There's good reason not to go along with the security theater it describes. App Passwords are not really passwords in the conventional sense. The format makes it difficult to actually use them like a password. They're 16-digit sequences that Google generates for you (you have more control over your child's SSN than you do over these non-passwords)—hard to remember, and that's because you're pretty much not expected to. You're expected to key it in approximately once and configure the relevant app to save it in perpetuity, rather than typing it in. What these things actually are should be familiar to the people here. They're API tokens (and pretty weak ones at that, relatively speaking)—just billed under a different, more familiar name, for a non-technical audience who wouldn't understand that term. If you are currently using a strong but nonetheless memorable password for Gmail and have your mail client set up to always prompt you for it rather than storing its own copy, then switching to one of these app-specific tokens will actually make your email less secure. Furthermore, in comparison, a 16-digit sequence has less entropy than a passphrase comprising 6 words chosen from even a very small 1000-word dictionary. In summary: - worse experience than an actual password - less secure A less cumbersome approach to address the threat Google is pretends to be concerned about here? Allow people to deconsolidate their accounts. This would actually have other happy knock-on effects, such as mitigating the impact of the now-familiar phenomenon where people get locked out of significant parts of their online and offline lives when something goes wrong with their account. Also wouldn't hurt their image in the current conversations about legally imposed breakup.
deleted 5y ago
[deleted]

by cxr 5y ago

md_ 5y ago

> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password… Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.

striking 5y ago
Yeah, and for those that don't, app passwords are not hard to use. Slightly cumbersome, maybe, but I bet it'd take less time than GP took to write their comment.
superkuh 5y ago
If an email provider does not offer standard pop3 or imap it is not an email provider. It's just some web shit.
- 0xCMP 5y ago
  they offer both. they simply require more secure authentication. something which doesn't require the app to know the username or password. it's that simple.
- md_ 5y ago
  IMAP with OAuth is standard. What am I missing?
  - superkuh 5y ago
    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 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, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.
    - tialaramex 5y ago
      > 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.
      - superkuh 5y ago
        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.
habosa 5y ago
In some cases yeah but not for mail. The GMail API is great but to use it you have to spend like $75k on a security review that Google has to approve.
- md_ 5y ago
  You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).
  - tialaramex 5y ago
    You should be able to use the Bearer Token standard from RFC7628 rather than XOAUTH which is something Microsoft cobbled together, but either will probably work on most systems, just one of them is better documented.
corobo 5y ago
e: fyi the ringfence bit in this post is incorrect. Leaving for posterity but don't believe this comment, see replies :) -- Could just set up an app password limited to accessing gmail, been able to do that for like 10 years now and it's not going away with this change different password: check ringfenced access: check
- md_ 5y ago
  App passwords are not limited in scope, AFAIK.
  - corobo 5y ago
    It said it was when I created one before posting to make sure I was thinking of Gmail and not Fastmail. Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought! I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!
dcow 5y ago
If Google granted arbitrary and fair access to those OAuth scopes then sure, but they don’t. I have personal experience with this, trust me.
martius 5y ago
Google provides the App passwords feature: > An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords. Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.

jstanley 5y ago

> This is why I'm skeptical of the whole "writing forces you to be honest because it means you have to actually think things through well enough to put them into words that can be put into coherent sentences" If you're making an earnest effort to think truthful thoughts, then trying to put your thoughts into writing is genuinely helpful. Writing doesn't stop you from deceiving others, but it helps to stop you from deceiving yourself.

dcow 5y ago

Conveniently Google also controls the allowed usages for “proper” OAuth access to Gmail. If your client is performing a function they don’t like then you’re screwed. I would expect that to be fair Google would have to also allow arbitrary access to the Gmail API to these now untouchable clients, but snowballs chance in hell Google will be so rational.

jptech 5y ago
I am willing to think that Google performs fingerprinting on the OAUTH login dialog window, which if prevented, similar to the comment above regarding Firefox being unsafe, it would block login through OAUTH as it pleases.
- dcow 5y ago
  It also straight up doesn't allow you to publish an OAuth application that uses “restricted” scopes (like `gmail.*`) without a review process subject to arbitrary usage guidelines determined by the Google APIs team. That’s the catch. It doesn't even matter how you run the OAuth flow (though I agree I suspect they fingerprint that too). You get blocked earlier.

briffle 5y ago

> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password, which is the same as your YouTube password, which is the same as the password you use to mark your phone as needing to be locked out of your account after it's stolen. You mean like google's "Application Specific Passwords" that have been around for a VERY long time, and are not affected by this announcement? https://support.google.com/accounts/answer/185833?hl=en https://support.google.com/accounts/answer/185833?hl=en

andreareina 5y ago
Application specific passwords require two-factor auth being on, which means either giving google your phone number or having to pay for e.g. a yubikey.
- amscanne 5y ago
  Or using a free authenticator app for time-based codes?
  - l72 5y ago
    How do you enable this without first giving google your phone number? My understanding is you have to set up SMS 2 factor auth first before you can change it to TOTP.
    - folmar 5y ago
      On a Workspace account you only need U2F token emulator (https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f woks fine) and thenn you can setup u2f first and add normal TOTP in second step. But u2f must stay there. I don't have a personal account to try if it works the same.
cxr 5y ago
I am familiar with that page. (Although I'm not sure how to interpret your "You mean like[...]" phrasing. It doesn't make sense in response to what I wrote.) There's good reason not to go along with the security theater it describes. App Passwords are not really passwords in the conventional sense. The format makes it difficult to actually use them like a password. They're 16-digit sequences that Google generates for you (you have more control over your child's SSN than you do over these non-passwords)—hard to remember, and that's because you're pretty much not expected to. You're expected to key it in approximately once and configure the relevant app to save it in perpetuity, rather than typing it in. What these things actually are should be familiar to the people here. They're API tokens (and pretty weak ones at that, relatively speaking)—just billed under a different, more familiar name, for a non-technical audience who wouldn't understand that term. If you are currently using a strong but nonetheless memorable password for Gmail and have your mail client set up to always prompt you for it rather than storing its own copy, then switching to one of these app-specific tokens will actually make your email less secure. Furthermore, in comparison, a 16-digit sequence has less entropy than a passphrase comprising 6 words chosen from even a very small 1000-word dictionary. In summary: - worse experience than an actual password - less secure A less cumbersome approach to address the threat Google is pretends to be concerned about here? Allow people to deconsolidate their accounts. This would actually have other happy knock-on effects, such as mitigating the impact of the now-familiar phenomenon where people get locked out of significant parts of their online and offline lives when something goes wrong with their account. Also wouldn't hurt their image in the current conversations about legally imposed breakup.

deleted 5y ago

[deleted]