Hacker News Reader

Comment by kylehotchkiss | Hacker News Reader

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.

View on HN

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.

Does any service use it beside fastmail on a large scale?

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.

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.

> It requires a WebView as part of the setup process

Why does it require a WebView, btw? Is there a good technical reason for that, or is it just what they happened to do?

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.

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.

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.

Don't passkey's just use the hardware key as the only factor (or at least that's how I've seen it implemented)?

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.

Or am I missing something here?

Passkey's don't strictly require 2FA sources.

Some hardware keys like yubikey's generally only prove physical presence of the key. And software implementations exist too.

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.

> Why does it require a WebView, btw?

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.

App passwords still work. There's no need to be hyperbolic.

... for how long?

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.

What's the point of an app password?

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.

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.

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.

My use case is OTP. Either through email or via SMS/google voice. Real time really helps with those, especially if you use Safari's OTP prefill.

I'd really rather use 1password for OTP but so few non-tech services support that.

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 really have no qualms about Fastmail spam handling either. It's fine; don't let that stop anyone from switching away from Google.

Interesting, might have to give it another shot!

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.

I love it. I can sync my Gmail to it seamlessly as I slowly transition all my accounts to my new email address.

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.

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.

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...

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.

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.

Push requires a Pub/Sub client, which doesn't have a free tier (last time I checked).

I'm sure I misunderstand something then, so please correct me: doesn't Gmail pub to a server you choose, and you sub from it?

Are there no servers with free tiers, is it impossible to run your own, does Gmail refuse to pub to a server outside Google, or what's the problem?

I'm talking about the "Cloud Pub/Sub API", linked from the doc you posted. The pricing is described here: https://cloud.google.com/pubsub/pricing

Reply on news.ycombinator.com