[HN Gopher] Oauth2 support for GMail
___________________________________________________________________
Oauth2 support for GMail
Author : edward
Score : 316 points
Date : 2022-05-18 08:28 UTC (14 hours ago)
(HTM) web link (www.pmail.com)
(TXT) w3m dump (www.pmail.com)
| Fizzadar wrote:
| 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
| antisthenes wrote:
| Your client seems interesting
|
| Is there any reason it can't work on Windows 7?
| Alex3917 wrote:
| > 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 assessment because data is run, stored, and
| processed only on the user's device. Local client applications
| that only allow user- configured transmissions of Restricted
| Scope data from the device may be exempt from this
| requirement."
|
| Keep in mind that any email client that allows you to reply to
| (or forward) an email would count as transmitting restricted
| scope data from the user's device.
| Fizzadar wrote:
| 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.
| joshuamorton wrote:
| > Keep in mind that any email client that allows you to reply
| to (or forward) an email would count as transmitting
| restricted scope data from the user's device.
|
| Not if it does so only via the oauth api?
| undecisive wrote:
| 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:
|
| > Every app that [accesses Gmail and also accesses other
| servers] is required to go through a security assessment from
| Google empanelled security assessors. [...]
|
| > In order to maintain access to restricted scopes, the app
| will need to undergo this security assessment on an annual
| basis, [... costs usually] between $10,000 - $75,000 (or more)
| [...]
|
| > This fee may be required whether or not your app passes the
| assessment and will be payable by the developer."
| ed wrote:
| > you will be paying that invoice whether or not you needed
| that assessment
|
| They don't just send you a bill for $10k. You can opt-out of
| the yearly audit by removing your use of restricted scopes.
|
| But yes, it is a yearly required audit, and they're serious
| about it. This limits the kind of apps that can be built on
| Gmail (basically - no free apps), but it is undoubtedly
| better for end users.
|
| Having gone through the process, which checks among other
| things that data can't be resold, tokens are encrypted, user
| data is really deleted when you say it is, and that Gmail API
| access is auditable in the event of a breach; these are all
| good things for users.
|
| (My auditor was so thorough they actually found a high-impact
| XSS bug in Firefox - the bounty covered part of their fees.)
| yoaviram wrote:
| It's not necessarily better for the users. I'm one of the
| founders of a free and open source service which simplifies
| the process of sending CCPA/GDPR data deletion requests. A
| common request from our users is to give them good
| recommendation on who to opt out from.
|
| A new compatitor has implemented a feature where they use
| the Gmail API to analyse a user's email exchange (from
| their servers) in order to recommend who to opt out from.
| It's very effective, and even though I would never give a
| 3rd party access to my email account most people do.
|
| Now we thought of implementing a similar feature, but from
| the client side (which is a bit less effective but much
| more privacy respecting). Now I'm not sure from what I read
| if we need a security audit or not, but the risk and the
| extra work isn't worth it for us. We're a nonprofit.
|
| Our compatitors on the other hand are a VC backed
| commercial organization. They make money buy providing a
| service to the companies they help people opt out of. The
| whole opt out side is just a way of manufacturing demand,
| so you can guess where their loyalty lies. But because they
| are well funded and because sending opt out emails is
| basically marketing for them, it makes sense for them to
| pay for an audit.
|
| At the end of the day, the user suffers.
| onphonenow wrote:
| Google SHOULD NOT promise anything else. This is critical for
| users security.
|
| Yes, developers and business claim they make user data,
| privacy and security a top priority. As we have seen from
| plenty of developers on the facebook platform, if not
| checked, they far to often lie, betray users trust or are
| just totally incompetent.
|
| At least on the business side, giving restricted scopes
| access (ie, enabling a third party server to read all emails
| in a domain) is a major permission. It needs to be treated
| like this. In many cases a problem here unlocks a LOT more
| because email is used the default password for everything
| (via password reset options and more).
|
| I hope google holds a firm line here and doesn't bow to
| hacker news type social media pressures - we have too much
| evidence of bad and poor behavior by developers to just trust
| them.
| ForHackernews wrote:
| Yeah, imagine if users didn't have benevolent Google
| protecting them, some unscrupulous company full of
| unethical developers might scan all their personal email,
| or monitor what websites they visit, or even collect
| biometric data and then track their every waking movement
| in the real world.
| userbinator wrote:
| Google is also one to "betray users trust"!
| Fizzadar wrote:
| 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=...
| pferde wrote:
| What about e-mail clients which allow you to configure
| multiple accounts at different e-mail providers? Those will
| be able to access your Gmail data, and also "data from or
| through third-party servers" in form of receiving or
| sending e-mail via different mail servers.
| tiernano wrote:
| Is it not "proxy" like servers they are talking about?
| You login and the details are stored on a server which
| does push notifications and the like... instead of your
| phone polling or pulling email all the time, the proxy
| server sends a push to the app to update when new mail
| arrives... is this what they mean?
| dal wrote:
| So basically when your application resolves gmail.com you
| will access other servers. :P
| sir wrote:
| If you don't have the time or resources to go through this
| process you can also use this simple proxy of mine, which
| intercepts the non-OAuth IMAP/SMTP commands and adds OAuth in the
| background: https://github.com/simonrob/email-oauth2-proxy/
| dividuum wrote:
| Ah yes. The "Just use FTP + curlftpfs + SVN" approach for
| solving this problem ;-)
|
| That really doesn't help OP as their customers most likely
| won't be capable to run that.
| sir wrote:
| Oh, it's certainly not an excuse for Google requiring this
| process. However, if you _do_ want to use Pegasus Mail (or
| any other non-OAuth app /script/email tool, etc) after the
| end of May, this is a way to do so. I think it's quite a safe
| assumption that many of the HN audience are capable of using
| it, too ;-)
| throwaway787544 wrote:
| Pegasus Mail, wow!!!! There's a blast from the past! I remember
| using this over 20 years ago!
| pantulis wrote:
| The Good Pegasus.
| tpmx wrote:
| Yeah! It was my first ever email client back in 1994/1995.
|
| More details on the developer:
|
| https://en.wikipedia.org/wiki/David_Harris_(software_develop...
| dugmartin wrote:
| We used it on our LAN around 1993 hooked to a local mail server
| (which ran on a Windows box using Netware I think - it was
| sitting on a filing cabinet next to my desk) that in turned
| fetched mail from the campus mail server. It worked really well
| and the local mail server let us easily share/email large
| attachments within the department as they never left the LAN.
| gommm wrote:
| Same here :) It was my client of choice back 20 years ago when
| I used windows... Very nice to see that it still lives on
| djbusby wrote:
| In a DOS terminal-window on my NT4 box.
| userbinator wrote:
| Moves like this from Big Tech deeply disturb me. I wonder how
| long it will be until _everything_ you do with them will require
| their approval. We 're already seeing this in the form of
| "supported browsers" (i.e. Chrome) and their efforts at painting
| everything else as "less secure" or "insecure". It's time we
| started pushing more for freedom over "security", before things
| become even more dystopian...
| acatton wrote:
| I'm confused... Why do they want to support the OAUTH flow when
| they can just the normal app password flow without any change in
| their code, just documentation for their users.
|
| https://support.google.com/accounts/answer/185833?hl=en
| rob74 wrote:
| Maybe because the first line on the page you linked reads:
|
| > _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._
|
| So, for Google, App Passwords are clearly "second class
| citizens", deemed insecure and not recommended. And, as an app
| developer, you probably don't want to be seen as recommending
| an insecure authentication method?
| NoGravitas wrote:
| This also strongly implies to me that Google is going to drop
| support for App Passwords in at most a few years.
| baisq wrote:
| I assume that users of Pegasus Mail are advanced enough to
| know that that is bullshit.
| kevincox wrote:
| The OAuth flow is better. It is easier for users and supports
| many more methods of authentication.
|
| Really the biggest downside about the OAuth flow is that it
| requires a relationship with Google (a client key). If this
| could be a fully decentralized standard it would be fantastic.
| sneak wrote:
| If you have advanced protection enabled on your Google Account
| (and you should) then app passwords are no longer available.
| awinter-py wrote:
| > 'Publishing the app' in Google terms requires a quite
| astonishing number of steps
|
| this is my main gripe with oauth for login -- the amount of
| overhead for getting it working is absurd. it's not private (goog
| knows which users use which sites) and there's too much
| preapproval (company consuming oauth has to have a dedicated
| google project for each login system)
|
| better, simpler system would be 1) client site issues random
| token, 2) user forwards token to google, 3) google signs bundle
| with user's email address + client token, 4) client site verifies
| bundle with goog's public key
|
| all communication should be through the client, the three way
| handshake is absurd and some legit sites don't implement the
| standard correctly
|
| oauth for access federation _maybe_ should require more setup but
| idk -- I feel like we haven 't thought through access federation
| as a society
| masukomi wrote:
| this implies you won't be able to use Firefox, or Safari, to
| access Gmail unelss they're willing to fork over their source
| code and pay the $$$ because all of those are
|
| >...[an] 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
| relaxatorium wrote:
| I'm sympathetic to the extremely legitimate security concerns
| here, but it's pretty rich for the "open, we're so open" company
| to be running a classic 90s Microsoft Embrace Extend Extinguish
| playbook on SMTP/IMAP which, for all its faults, is one of the
| more important open protocols undergirding the internet.
| londons_explore wrote:
| _I_ was aware of the security-audit-at-your-own-expense
| requirement, and I am not a gmail app developer, I just did a
| drive by of the documentation 1+ year ago...
|
| As a gmail user, this actually seems like a sensible thing. Gone
| are the days when users are trusted to just click 'allow' to let
| some random third party access all your data. It turns out, users
| don't fully understand the ramifications of that, and complain
| loudly when the 'free personality quiz' they allowed goes and
| downloads every private email to use for marketing.
|
| So, if I can't give access to my mail to a random untrusted third
| party, the next best thing seems to be to give access to someone
| who has at least had their systems audited and who at least has
| enough money to pay for an audit, meaning they probably have some
| business plan and can be tracked down by the courts if they
| mishandle the data.
| Saris wrote:
| Is gmail removing IMAP too? Why support OAUTH at all when you can
| use the normal method of logging in with IMAP and an app
| password?
| [deleted]
| nemothekid wrote:
| They are likely removing IMAP. IMAP support is already disabled
| by default in Gmail
| Mailtemi wrote:
| Can you share a link for this statement. As far as I know
| IMAP works ok, you just need to use XOAUTH IMAP
| authentication.
| planede wrote:
| App passwords are only available for 2fa enabled accounts,
| while OAUTH is available for everyone. So far I didn't get a
| clear answer if "the end of less secure authentication methods"
| means the end of app passwords as well, or only the end of
| signing into IMAP with your main google credentials.
| dewey wrote:
| There's a bunch of third party "indie" email apps, how are they
| doing it? Is this potentially just some boilerplate text and they
| evaluate the rate based on the size of the project in the end?
|
| I'm currently using https://mimestream.com/ and I somehow doubt
| all of them had to pay that kind of upfront money.
| sigzero wrote:
| Why the hell would they need to submit to that?! That's crazy.
| malinens wrote:
| 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
| NavinF wrote:
| Eh why not ask users to upload their takeout files and forward
| their incoming mail to the new address?
| https://takeout.google.com/
|
| Read only access to the user's inbox is enough to reset every
| password so I'm unsurprised that they make this hard.
| tptacek wrote:
| 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.
| Alex3917 wrote:
| > 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.
| w3ll_w3ll_w3ll wrote:
| Searching "gmail oauth malicious"
|
| https://duo.com/blog/gmail-oauth-phishing-goes-viral
| malinens wrote:
| 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.
| nullcipher wrote:
| Wow, is this the software that ran on Novell Netware? I had no
| idea this was still around.
| paxys wrote:
| Why can't I just enter my own Google client ID/secret on the app
| and auth against that? There's no approval from Google needed in
| that case, since I'm not publishing it anywhere.
| wiradikusuma wrote:
| Does anyone has a link for that ToC? I'm curious what kind of use
| cases that need such payment. E.g. if I want to make my app to
| use Google login, I think it's completely free?
| corentin88 wrote:
| Not ToC but that's where you will find all the details of the
| security assessment:
| https://support.google.com/cloud/answer/9110914?hl=en
| Tepix wrote:
| Once again, i'm glad not to be using GMail.
| enriquto wrote:
| Yep. All these anti-google complaints sound so useless. What
| did they expect? These issues are always an entirely self-
| inflicted problem. Google's terms of service are public, clear,
| and completely unacceptable. Why people keep using their
| services is beyond me.
| blagie wrote:
| Legacy.
|
| For example, my email is in Google. There are things related
| to e.g. evidence for litigation from many years back. I have
| documents shared with me in Google Docs.
|
| Google used to be pretty good about "don't do evil." I've
| degooglified what I can, but I can't degooglify 100%.
| hackmiester wrote:
| It seemed like a good idea in 2005, and switching costs. But
| yeah, I bit the bullet and left this year.
| adrianpthomas wrote:
| Went through this process with Mail Designer 365. Luckily as we
| only need sending access, the requirement was less arduous, but
| the process was not great.
|
| After submitting it took ages to get reviewed and even when it
| had been processed the status wasn't entirely clear.
|
| At the time it was made clear that using app passwords was
| considered a risk and users were receiving emails about it being
| a security risk.
| nickdothutton wrote:
| Any takers for a bet on when Google will axe App Passwords?
| CyanBird wrote:
| I'd say, no more than 3 years
| NickRandom wrote:
| I haven't seen a single comment (at time of posting this)
| touching on the cost aspect
|
| _The cost of the assessment typically varies between $10,000
| -$75,000 (or more) depending on the size and complexity of the
| application_
|
| As he says, even if Google classed his as a small app (unlikely)
|
| "Regrettably, these kinds of fees are far beyond what I can
| afford, given that I rely on donations from my users to make ends
| meet: even the $4,500 fee is well beyond what I could find on an
| annual basis. "
|
| I get that doing proper auditing is expensive and the costs are
| within industry rates but to me it reeks of slowing turning the
| screws by boiling the frog on the slow path to monetization.
| (many mixed metaphors I know)
| jijji wrote:
| It looks like this pay-for-play method is going to have a
| chilling effect on any developer creating an alternative Gmail
| interface. Same with removing IMAP.
| xbar wrote:
| And so it is time to relegate my Gmail account to an auto-
| forwarder.
| tut-urut-utut wrote:
| If you own your mail domain, it's the time to move off from
| Gmail.
|
| If not, make a clear cut, purchase domain, and never ever be at
| the mercy of mail provider.
| mawise wrote:
| This is so hard. I bought a domain and even started paying
| for (non-google) email on it over a year ago. But I can't
| bring my self to start the painful process of migrating
| everything.
| hackmiester wrote:
| At least you will only have to do it once. I migrated from
| G Suite to Fastmail, but because I had a custom domain, it
| was basically entirely painless.
| r00fus wrote:
| What it'll take is likely a cost/benefit for keeping your
| non-gmail-website workflow (and taking the leap to jump off
| gmail) vs. complying and using their (mostly usable)
| webmail site.
|
| They likely figure most will choose option#2 since it's so
| painful/expensive to do #1.
| qwerty456127 wrote:
| 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?
| vivekv wrote:
| For now app passwords
| mikeklaas wrote:
| Development apps are exempt from the requirement. (They are
| also limited to 100 accounts)
| pagutierrezn wrote:
| misunderstanding?
| https://twitter.com/wilbowma/status/1526697254140071936?t=45...
| jaapz wrote:
| I don't think the problem here is that users can still use app
| passwords instead of OAuth2 - it's that the developer went
| through the trouble of developing a OAuth2 implementation, went
| through the necessary laborious steps to submit the application
| and then was faced with this message:
|
| > The cost of the assessment typically varies between $10,000
| -$75,000 (or more) depending on the size and complexity of the
| application; smaller applications may see costs at a lower
| threshold of $4,500
|
| That's just bad, but pretty typically google.
| tssva wrote:
| The Google documentation regarding Oauth access to Google
| APIs including Gmail explicitly mentions this requirement. It
| should not have been a shock to the author. Also this
| requirement only applies if the app is intended to store the
| data on a server. An email client which directly accesses and
| locally stores the email would not require a security audit.
| Pegasus would not be the 1st email client to use OAuth2 with
| Gmail and others have not required an audit. Some of the
| newer email client services which implement advance features
| by downloading email directly from Gmail to their own servers
| on the backend to do processing of the email would require a
| security audit.
| sneak wrote:
| 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.
| tptacek wrote:
| 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).
| morganvachon wrote:
| 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 encrypted
| email. Unless everyone you communicate with (including
| companies, governments, and other organizations) is willing to
| only communicate via encrypted email as well, it's a lost
| cause.
| sneak wrote:
| 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.
| morganvachon wrote:
| 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.
| solar-ice wrote:
| > and has the ability to access data from or through a third
| party server
|
| So Pegasus Mail accesses your email from their servers? For
| reference, they have an entire flow designed so that the auth
| credentials never touch the app developer's server for desktop
| and mobile apps -
| https://developers.google.com/identity/protocols/oauth2/nati...
| snthd wrote:
| Most mail clients can connect to both a google email account
| and a "third party server" email account.
|
| It's easier to rule out undetectable-by-google data
| exfilteration if the app can only connect to Google.
|
| The obvious way around this is to make a Google-only edition.
|
| Yuck.
| oefrha wrote:
| This is about the OAuth server-side flow vs client-side flow.
| Nothing to do with third party email accounts whatsoever.
|
| My unfounded guess is that just like the parent here, OP
| isn't very knowledgeable about OAuth and chose the wrong
| flow.
| solar-ice wrote:
| I don't think that's what Google are saying here. I think the
| sentence is referring to Google user data; as long as the
| Google user data or credentials to access it does not touch
| another server, the entire thing does not apply.
|
| In fact, in Google's guidance on this subject, they say:
|
| > Local client applications that only allow user-configured
| transmissions of Restricted Scope data from the device may be
| exempt from this requirement [to get a Letter of Assessment].
|
| And in another FAQ:
|
| > Local Data Storage: Local client applications don't need to
| undergo a security assessment because data is run, stored,
| and processed only on the user's device. Local client
| applications that only allow user-configured transmissions of
| Restricted Scope data from the device may be exempt from this
| requirement.
|
| My feeling is that the author of Pegasus Mail has checked a
| checkbox incorrectly somewhere, or alternatively has not
| implemented the desktop oauth2 flow correctly.
| easton wrote:
| I'm super confused about this too, there's tons of open source
| apps that use Sign in with Google. Shoot, I've used the SDK
| myself in little apps and never saw this.
| rjzzleep wrote:
| The SDK on android or ios you mean? Cause that would be
| vastly different from adding a web authentication flow such
| as oauth to a legacy application.
| Alex3917 wrote:
| "Sign in with Google" is just a button that apps are required
| to use when they allow the user to interact with Google in
| some capacity, but don't have their own account management
| system. Most apps with that button don't have the ability to
| get any data from Google other than your name and email
| address though; for apps where you are granting OAuth access
| to your Gmail, it is very obvious that you are doing so, so
| it's not likely that you have done it accidentally in the
| past. (Although you can obviously check on
| myaccount.google.com)
| mbwgh wrote:
| I had a similar brick wall moment after having written a tool to
| sync Google Calendar events with the `when` calendar tool
| (http://www.lightandmatter.com/when/when.html).
|
| Which is why I never published it (although I have been using it
| for almost two years), and setting it up requires a series of
| laborious steps of activating the Google Developer Console,
| creating API keys etc., which I found just to embarrassing to put
| in a README :)
| VTimofeenko wrote:
| I don't think it would be embarassing. Other tools use the same
| approach, like rclone:
|
| https://rclone.org/drive/
| corentin88 wrote:
| I believe many comments here will criticize Google. But
| objectively, Google is at its best here:
|
| - in terms of privacy, applications that have access to your
| Gmail inbox now require a security audit.
|
| - the audit is not required for MVP (<100 users) or applications
| internal to a Google Workspace org.
|
| Of course, you have to pay for the audit. But:
|
| - it's only required when you ask for restricted user data (i.e.
| reading my emails).
|
| - Google doesn't take 30% of your revenue to use its API - which
| is free by the way.
|
| To me, Google has created the perfect world for developers here.
| And that says a lot when I read the developer of Pegasus Mail
| doesn't want to record a 2min long YouTube screencast to get
| approved.
|
| Also, just wanted to kudos the Google OAuth team that has greatly
| improved their process in the past years. If you follow the
| guidelines, you can get approved within a day now.
| lozenge wrote:
| Is it my inbox or Google's inbox?
| charcircuit wrote:
| Google will be blamed if someone's data is misused even if
| that person authorized giving permissions to that app. If you
| want evidence supporting that, take a look at how much flak
| Facebook received with the Cambridge Analytica scandal.
| scrapheap wrote:
| If it's Gmail then it's Google's inbox, they're just letting
| you use it.
| dangrigsby wrote:
| Is it your car or the government's?
| jtbayly wrote:
| If you _want_ to create a video, you're one of the 17
| developers in the world that does.
|
| Your criticism was completely unnecessary. It doesn't say
| anything about the Pegasus dev except that he's normal.
| corentin88 wrote:
| You _have_ to create a video. That's a requirement. You don't
| event have to talk or show your face on it though. I agree
| many people doesn't like to record videos, I'm one of them,
| but you are a developer and your app is going to be available
| to 1.5 billion users of Gmail. Complaining about having to
| record a video (which is what Pegasus dev did) is not
| _normal_.
| irishsultan wrote:
| > You _have_ to create a video. That's a requirement.
|
| How is that in any way related to your comment that he
| shouldn't complain about it? If it wasn't a requirement
| then there would be no reason to complain in the first
| place.
|
| And that's not even what his main complaint, his main
| complaint is that he shouldn't have had to record the video
| in the first place because the warning about this feature
| costing money should have been documented somewhere
| together with all other requirements.
|
| Basically Google is behaving like that website that tells
| you "your password should be more than 8 characters",
| change password submit, "your password should be less than
| 16 chararcters", change password submit, "should contain at
| least one upper character", change password submit, "should
| contain a special character", change password submit,
| "should not contain single quotes or other characters that
| are too special", repeat ad nauseam. If you have
| requirements document them up-front and all in one place.
| Alex3917 wrote:
| > the audit is not required for MVP (<100 users)
|
| 100 lifetime signups isn't anywhere near enough to know whether
| or not an app is commercially viable. If the cap were something
| like 10,000, or even 2,500, then there would be a lot less
| complaints.
| wila wrote:
| > And that says a lot when I read the developer of Pegasus Mail
| doesn't want to record a 2min long YouTube screencast to get
| approved.
|
| Congrats on misreading the article. That's not the problem. The
| problem is having to spend a lot of money for a security audit
| for free software.
| kenmacd wrote:
| My issue with this is that to access my own email I get
| countless warnings, and always have a 'You have recommended
| actions' Security Checkup for 'Remove risky access to your
| data'.
|
| This is after jumping through a bunch of hoops to create a GCP
| app. It even complains about the pseudo-app being from an
| 'Unverified developer' despite that developer being me.
| janandonly wrote:
| I am wondering if it is really legal for Google to even ask any
| money from 3rd party developers to use GMAIL (what _should_ be)
| open standards like SMTP and IMAP.
|
| I guess I am so naive...
| richsouth wrote:
| It might be immoral, but if you're trying to make money using
| their service I can't see there being a legal reason to prevent
| them doing this. I meant, they (Google) need the money right?
| Companies like this seem to get to the point where they feel
| justified in charging for every little thing that wouldn't kill
| them to give for free.
| derbOac wrote:
| If you're in the EU:
|
| https://en.m.wikipedia.org/wiki/Antitrust_cases_against_Goog.
| ..
| superkuh wrote:
| 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, which is not imap) that's the end of gmail
| for me.
| fivre wrote:
| OAuth2 is a suite of protocols and standards you can use to
| build an auth system from people who have been working on auth
| systems for a while. it isn't strictly designed for federated
| auth, and arguably is targeted at internal systems because
| there are so many parts are "you need a system that does this,
| but how is up to you"
|
| OIDC builds on OAuth2 to fill in those gaps with prescribed
| details and add additional systems necessary for a workable
| federated auth system. it _should_ be possible to use it
| entirely provider-agnostic fashion, but in practice it's like
| any complex protocol with optional parts in that
| implementations have incorrect bits or idiosyncrasies (why does
| Azure's provider sometimes serve public keys it doesn't
| actually use to sign tokens in some modes? god only knows) and
| you'll probably only provide integrations for a subset of
| providers, not just let anyone with a discovery link show up
| and use it.
| superkuh wrote:
| I don't even mean federated auth.
|
| I mean if you take some email client application that went
| out of it's way to support OAuth2+imap for google via a
| plugin then even if you replace all of google's info in the
| plugin it won't work for other OAuth2+imap implementations.
| Every OAuth2 implementation is a different thing, as you say.
| But the megacorps are pretending it's some standard protocol.
| It's not and the fallout will be much worse than people
| having issues because they picked easy passwords.
|
| This is massively different than actual protocols like pop3
| or imap where all you do is change the info but the protocol
| stays the same.
| paxys wrote:
| I have no idea what you are talking about. Every Google service
| (not just GMail), and every major service provider on the
| internet, uses OAuth 2 as the standard for authorizing API
| access.
| jeroenhd wrote:
| 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 the concept isn't
| inherently bad, in my opinion.
|
| I don't really see the problem with OAuth2 itself, the email
| space is just very very slow at accepting new standards.
| Dovecot and UTF8 email addresses still don't play well
| together, for example. The lack of proper on-the-fly
| application registration for mail servers is annoying, but
| supporting them should be easy enough if the mail service isn't
| run by complete doofuses.
| superkuh wrote:
| >OAuth is hardly Google only,
|
| To be clear, I never said OAuth2 was google only. I said the
| standard OAuth2 is so much _not a standard_ that an
| implementation written for Google 's imap+OAuth2 will not
| work for any other email provider's imap+OAuth2.
| yxhuvud wrote:
| > Thunderbird does, but that could be Gmail specific
|
| No, it definitely works on Office 365 too.
| tatoalo wrote:
| > [...] including even having to prepare a Youtube video showing
| my code in action.
|
| What?!
| uniqueuid wrote:
| This is unfortunately not unprecedented. When you apply for API
| access to facebook's graph API, you also need to document your
| app including videos.
| Alex3917 wrote:
| The video isn't really that hard. You just make a screencast of
| yourself downloading email while saying "now I'm using the
| download email scope", and then sending email while saying "now
| I'm using the send email scope."
|
| They don't care if the videos are terrible quality, it's only
| for them to understand what they're approving, and to have some
| documentation if a developer later changes an app to do
| something nefarious.
___________________________________________________________________
(page generated 2022-05-18 23:01 UTC)