Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oauth2 support for GMail

pmail.com

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Oauth2 support for GMail

#81

Post by tptacek »

sneak wrote: post #21

Users should not be subjecting all of their correspondents' communications to US warrantless surveillance anyway; Google is doing the world a service by making their service harder and harder to interoperate with. Gmail and other huge centralized points of censorship and surveillance must be destroyed. If you are a user, move away. If you are a developer, do not support these closed systems.

Moving your data out of US jurisdiction doesn't shield it from US warrantless surveillance, but rather maximizes its exposure. The USG ostensibly requires due process (a warrant, whatever) to obtain information from US servers. It does not require any due process to obtain data from foreign servers. Coercively obtaining data from foreign servers is literally the chartered job of the NSA (of all signals intelligence agencies around the world, really).

This is a super common misapprehension people have about data locality and surveillance, and it's no surprise that marketing plays off it ("keep your mail in Switzerland, so it's subject to Switzerland's strict privacy laws!").

There are other reasons to house things in Switzerland (or the Lesser Antilles or wherever). I'm not saying you should use GMail (unless security is a concern of yours, in which case you should use GMail).

Re: Oauth2 support for GMail

#82

Post by Fizzadar »

Alex3917 wrote: post #73
Fizzadar wrote: post #25

I’ve gone through this process for my email client Kanmail [1]. The third party audit is not required for email clients that run on end users computers and store credentials locally. By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience). [1] https://kanmail.io

> The third party audit is not required for email clients that run on end users computers and store credentials locally. It might not be required for applications that run locally, but they don't tell you whether or not it will be required until after you've already done the work to create the app. The exact wording from the FAQ is: "Local Data Storage: Local client applications don't need to undergo a security asses…

The OAuth verification FAQs state:

> Ensure your app complies with the Google APIs Terms of Service, Google's API Services User Data Policy, and the Additional Requirements for Specific Scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users data from or through a third-party server.

In the case of an email client data is transmitted directly from/to Google's own IMAP/SMTP servers and not a third party, and is thus exempt from the assessment.

Re: Oauth2 support for GMail

#83

Post by morganvachon »

sneak wrote: post #37
morganvachon wrote: post #34

Earlier quoted context omitted.

I agree wholeheartedly in principle, but the reality is that it's nearly impossible to escape Google getting their hands on yours and your correspondents' messages at some point. So many businesses (and third party email providers!) use Google's services on the back end, and many relays out there are owned by Google/Alphabet even if it's not readily apparent, that the only way to even attempt to avoid them is using e…

No, the perfect is the enemy of the good here. "Email is insecure anyway and Google is big, therefore it's ok to give the adversary 100% of the plaintext" is not sound logic. This is not some principled stance, it is a clear and practical command: stop using these services. If your personal email address ends in @gmail.com, you are doing it wrong.

I'm not saying you shouldn't give up Google services; I did. I'm just saying the unfortunate reality is that you'll never fully escape them.

Re: Oauth2 support for GMail

#84

Post by Fizzadar »

undecisive wrote: post #51
Fizzadar wrote: post #25

I’ve gone through this process for my email client Kanmail [1]. The third party audit is not required for email clients that run on end users computers and store credentials locally. By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience). [1] https://kanmail.io

The wording seems to imply that if, on a yearly whim, someone at Google decides to "empanel" a security assessment team, you have no choice, you will not necessarily be asked permission and you will be paying that invoice whether or not you needed that assessment. Do you have evidence - in writing - to the contrary from a Google official? Abridged wording and my non-lawyer interpretation below in case I'm not clear:…

Not sure where this is from but there's a critical part of the quote missing here:

> Every app that requests access to restricted scope Google user’s data and has the ability to access data from or through a third party server is required to go through a security assessment

An email client that only transmits data to/from Google's own IMAP/SMTP servers does not have the ability to access data through any third party server, and thus does not require the audit.

Source: https://support.google.com/cloud/answer/9110914?hl=en#zippy=...

Re: Oauth2 support for GMail

#85

Post by yxhuvud »

jeroenhd wrote: post #71
superkuh wrote: post #69

Note that this "OAuth2" support is only for gmail. OAuth 2 is not really an open protocol like OAuth (1) was. It's just something the megacorps shoved down the IETF's throat and every implementation is different enough to need different software. OAuth2 is not good for the health of the internet and will lead to even more lock in. When Google disables imap at the end of the month for gmail (only allowing OAuth2+imap,…

OAuth is hardly Google only, it's part of RFC7628. There are very good reasons why a simple password login isn't necessarily what you want for your email protocol. IMAP and 2FA are often at odds, for example, usually leading to vulnerable application passwords that bypass security requirements out of necessity. I don't think many email clients support OAuth2 (Thunderbird does, but that could be Gmail specific?) but t…

> Thunderbird does, but that could be Gmail specific

No, it definitely works on Office 365 too.

Re: Oauth2 support for GMail

#86

Post by malinens »

There is only one thing why this is done: to make impossible to move from gmail (also with custom domains) to another provider. We have the same problem. We spent hundreds of hours implementing their legacy auth (less secure apps), gmail oauth2 and domain-wide delegation to be later stuck in approval process. Until our app is not approved users can not use e-mail import/migration tool to our inbox.eu service. And there is lot of demand for that because people do not want to pay so much for e-mail. Shame on google... they also do not provide reas-only access to IMAP which is more than enough to export your mailboxes to other e-mail providers

Re: Oauth2 support for GMail

#87

Post by tptacek »

malinens wrote: post #86

There is only one thing why this is done: to make impossible to move from gmail (also with custom domains) to another provider. We have the same problem. We spent hundreds of hours implementing their legacy auth (less secure apps), gmail oauth2 and domain-wide delegation to be later stuck in approval process. Until our app is not approved users can not use e-mail import/migration tool to our inbox.eu service. And the…

This isn't true at all. The reason Google does this is that there is a huge ecosystem of random apps that request full access to people's mail accounts, which are the most sensitive accounts on the entire Internet, and many of those apps were hot garbage that generated a huge account takeover problem. It's perfectly fair to not like the policy (I don't like some things about it), but it's not reasonable to caricature it.

Re: Oauth2 support for GMail

#88

Post by mikeklaas »

qwerty456127 wrote: post #20

I have one question in this regard: will I still be able to access my mail through my own script I myself wrote? I understand I will probably have to make some changes and click some things in GMail settings but is this still going to be possible or will I too have to "publish app" even if I only mean it for my own private usage?

Development apps are exempt from the requirement. (They are also limited to 100 accounts)

Re: Oauth2 support for GMail

#89

Post by malinens »

tptacek wrote: post #87
malinens wrote: post #86

There is only one thing why this is done: to make impossible to move from gmail (also with custom domains) to another provider. We have the same problem. We spent hundreds of hours implementing their legacy auth (less secure apps), gmail oauth2 and domain-wide delegation to be later stuck in approval process. Until our app is not approved users can not use e-mail import/migration tool to our inbox.eu service. And the…

This isn't true at all. The reason Google does this is that there is a huge ecosystem of random apps that request full access to people's mail accounts, which are the most sensitive accounts on the entire Internet , and many of those apps were hot garbage that generated a huge account takeover problem. It's perfectly fair to not like the policy (I don't like some things about it), but it's not reasonable to caricatur…

You seem to had never gone trough this approval process. There are many dark patterns there:

* Asking for huge amount of money in the of the process (after you wasted hundreds of hours of expensive developer time) * forcing to use restricted scope (read,White,delete) for standard IMAP access even if you need only read-only access or use their proprietary API with read-only scope with unknown rate limits and which is difficult and time-consuming to use * cryptic messages why app is not approved and ignoring arguments made for their questions * often changing APIs (access token formats)

They do everything to avoid competition not making better product but by locking existing customers to their ecosystem.

And this is not only google. We had similar issues Apple and Meta.

Re: Oauth2 support for GMail

#90

Post by Alex3917 »

tptacek wrote: post #87
malinens wrote: post #86

There is only one thing why this is done: to make impossible to move from gmail (also with custom domains) to another provider. We have the same problem. We spent hundreds of hours implementing their legacy auth (less secure apps), gmail oauth2 and domain-wide delegation to be later stuck in approval process. Until our app is not approved users can not use e-mail import/migration tool to our inbox.eu service. And the…

This isn't true at all. The reason Google does this is that there is a huge ecosystem of random apps that request full access to people's mail accounts, which are the most sensitive accounts on the entire Internet , and many of those apps were hot garbage that generated a huge account takeover problem. It's perfectly fair to not like the policy (I don't like some things about it), but it's not reasonable to caricatur…

> many of those apps were hot garbage that generated a huge account takeover problem

Are there any publicly known examples of this? I'm not doubting that it's happened, I've just never actually heard about any cases of this with respect to the Gmail OAuth API specifically.

Post reply on HN