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.
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.
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.
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.
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.
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.
but we're talking about google's implementation here, where fido keys are only a second factor. and in google's implementation, allowing passwords to be compromised means compromising your security, because their authentication flow is based around having more than just one factor.
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.
I would say that if you use your fingerprint to unlock the hardware key on your smartphone, then you have two factors: one needs to both steal your smartphone (for the hardware key) and copy your fingerprint.
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.
Sure you can, you just have to complete the OAuth2 login on a different device (e.g. phone) and then forward the token to the device which has no web browser.
On the phone itself the WebView limitation is worked around via deep linking (start Browser from App and once logged in start App from Browser with token).
There are tons of different ways how to do this actively being used.
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.
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.
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 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.
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.
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!
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.
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.
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.
