This is all about getting users off of the fantastic native mail apps and onto googles own. You can’t get realtime mail notifications without gmail.app or the soon to be deprecated Google sync. I hate it. I pay Google for workspace and I hate it. At least Mimestream still works on desktop but I bet they’re coming for that soon too.
Oauth isn't that hard to implement. It requires a WebView as part of the setup process, but after that the mail app just needs to store a token as a password and it'll keep working.
Oauth for email is part of the various RFCs pertaining to email authentication and has been around for years.
Thunderbird and various mobile apps support Gmail just fine using Oauth. I think the bigger problem is that many desktop apps seem to have stopped implementing changes to IMAP and SMTP about ten years ago.
If you have an email app that's no longer maintained, use app passwords (generated per-app passwords), like Google is indicating in the linked article. Those will still work. It's just the hardcoded username/password for the main account that's going away.
This will be a major pain for the Office 2016 users, as 30 september is still about nine months before their Outlook goes out of support, but for most users this will be quite a easy fix.
Why does it require a WebView, btw? Is there a good technical reason for that, or is it just what they happened to do?
Doesn't google explicitly forbid a WebView for oauth?
The point is to not have users entering their google credentials into third-party apps, and a WebView is still entering your credentials into a third-party app. The app has to open the google login page in a real browser, not a WebView.
Oh, I see. BTW don't hardware keys (e.g. Yubikey) solve that problem entirely?
No.
Hardware keys are a second factor. But if you allow passwords to be compromised just because there is a second factor, then you're back down to one-factor auth and you've solved nothing
Fido keys can also be used without password or even an account name (but with pin which becomes the second factor in that scenario). They are very resistant to phishing because they do a challenge response every time that's bound to the domain name of the requesting site. So typosquatting tricks won't work. The private key is generated and stored in the token and they are very resistant to extraction.
In general it's way safer than a password that can be intercepted and reused by anyone who knows it.
Well. Hardware keys are just hardware keys. They can be used as a second factor, they can be used as a third factor, they can be used as the only factor. It's not immediately obvious that using only a password is less secure than using only a hardware key.
So you can't read your mail from a platform that doesn't have a web browser installed...
Edit: to be more clear: so you can't read your mail from a platform that can't run or embed a modern web browser. For example... a command line only system without a GUI.
They want the power to add arbitrary extra steps in the login flow.
For example, maybe they want to force the user to change a compromised password, or hand over their phone number, or complete a captcha, or accept a load of legalese.
You can do this without a webview in your application, but it usually means giving the user an URL to open in their own browser.
I suppose it technically doesn't require a WebViee, but that's the easiest solution in most cases.
I'm not sure how you're going to implement Google's 2FA in a non-WebView solution, but if you can get the right UI and data flows to work, I'm sure you can do without.
What's the point of an app password?
Your account password is too powerful, for example, it allows anyone who knows it and can provide the 2FA to change non-email settings, such as the preferred languages, the list of bank cards attached to the account, see the places visited, read and modify Google docs, or change the password. The app-specific password has a scope attached to it, and can thus be used only to do what the app needs to do, without any possibility to take your entire account over.
It's a password that allows access to email, but not to the "change my Google password" page, or to push app installation to the Play Store, or to invite other people into Google Meet links. These passwords are contained to very specific APIs surrounding email and Caldav and such.
That means you're not completely screwed when your Outlook password database gets stolen by malware.
As a user, it also allows you to revoke an application remotely without having to change your password and log in to every device again. One click of a button and new emails won't appear on a lost laptop or phone, even if they manage to bypass the screen lock. It's all about risk management.
It's a long, random password, that you generate anew for each application that needs it: one compromised app can be revoke quickly without affecting other.
But more importantly, app password can only be used for email, not other Google's service, so even if it gets leaked, the impact is severely reduced.
Fully agree. Also paying for my gmail account and hate every moment of it but nobody seems to be able to get remotely close to gmail for spam handling.
After two years of using Fastmail as my primary account, in my effort to de-Google in 2022, spam recognition at Fastmail seems to me to be on a par with Gmail, if not better. I still use both.
I use Fastmail for 5+ years now. Initially I feared that the experience would be worse than Gmail (with regards to the Web UI, to spam filtering, etc). It is not. It really is much better!
Which plan are you on?
I use the standard plan.
Agreed, Fastmail is pretty good at spam filtering. My Gmail account is pretty much full of spam nowdays which seems to suggest Gmail's spam filtering isn't that great.
What makes me really mad is that I mark a sender as 'not spam' over and over again in Gmail and where does it keep going? Spam. I have a bunch of system emails and I can't convince Google to just give me my damned mail.
Interesting, might have to give it another shot!
I love it. I can sync my Gmail to it seamlessly as I slowly transition all my accounts to my new email address.
I really have no qualms about Fastmail spam handling either. It's fine; don't let that stop anyone from switching away from Google.
Strangely O365 handles most spam pretty well. I don't know why they can't do the same for outlook/hotmail/live accounts.
Hotmail is truly mind-blowing to me.
In my case ALL spam goes to inbox (a LOT) and ALL uselfull real emails go to the junk folder (very few).
I truly wonder how they do it. I can't get my head around it.
I've been gradually shifting over to protonmail over the past years and haven't seen any spam at all.
No this is about getting users off fucking Outlook 2007 or worse.
Outlook 2007 users can use app passwords to maintain access. This is about users running Outlook 2007 with their main app password stored to their account database, rather than a randomly generated, email-specific password.
Any casual computer user won't be able to get this working.
If they can't get it working, they're probably not aware of the risks and should move to newer mail solutions anyway.
This only affects Workspace accounts, so I'm sure the users stuck with Outlook 2007 can call IT to get it working again.
They should get on it and adopt jmap already.
It’s a good, standard protocol with unreasonably low adoption because of the chicken and egg problem between mail providers and mail applications. If Gmail supported jmap it would encourage implementers everywhere to support it. And jmap supports notifications and all the rest.
I agree, but why would Google adopt it when they have their own proprietary protocol with similar functionality? Companies love anything that makes them more "sticky", whether it's good for the user or not.
IMAP does too.
Does any service use it beside fastmail on a large scale?
App specific passwords will continue to work, and will work fine if your native app does not support the usual OAuth flow.
This is good to know, because I think I already use those everywhere (except on my latest machine; I should fix that).
Even so, I will also be using this as a reminder to move my stuff away from Google.
"will continue" can't really be said about anything Google with any degree of confidence.
I appreciate that we all have different bugbears, but realtime mail notification isn't going to get me off Thunderbird. Email is asynchronous, and therefore finding out 10 minutes later about a message coming in shouldn't be a problem. If I'm expecting the message then I'll be mashing refresh until it arrives, anyway.
If you need me more urgently, text me. Don't call. I don't like calls.
Same, native iOS Mail app in my case. I get Gmail notifications only when connected to power and Wi-Fi (can be set to a time interval too but I’d rather conserve my battery). When I expect a mail, I open the app and it auto refreshes until the mail comes.
Yes, it's pretty obvious this is what's going on. The solution to these "less secure apps" was to simply generate stronger passwords for them instead of making the user jump through hoops by using oauth2 proxies, especially for older hardware/software.
Which is actually supported already with App specific Passwords...
Yeah, I am sad. I still use the Microsoft Exchange option to access my Gmail account on my iPhone in Mail.app so that I get push notifications.
Their realtime mail notifications are specified at https://developers.google.com/gmail/api/guides/push
You can also get realtime notifications using IMAP+IDLE+app passwords, although IIRC that'll lag by a couple of seconds.