Hacker News Reader

Comment by jonathanstrange | Hacker News Reader

I will do everything in my power to pressure my university to migrate their email accounts to another service.

This is anti-competitive behavior designed to make it as hard as possible to use email client software. For example, check the procedures needed to set up oauth2 in my preferred client claws-mail.[1] That's insane.

[1] https://www.claws-mail.org/faq/index.php/Oauth2

View on HN

> This is anti-competitive behavior designed to make it as hard as possible to use email client software

Use App password. They are not blocking any 3rd party clients. Are you advocating using real password in every random client that may or may not transmit it in full text elsewhere?

I do assume you know security essentials.

I will do that if our university decides to switch on 2-factor authentication (which would be total chaos), but my trust in Google's ability to make this effortless and easy in third-party email clients is zero. See my other post why.

Regarding security: Google had physical fiber optics connections to the NSA and claimed they didn't know about them. It's not a very credible claim but if if was true, then it would be proof that Google has no competence in security at all.

Any decent 3rd party client does this already. Take for example, thunderbird or k9-mail - major open source ones. Even Mail (from Apple, macOS) does this. What else you need? Sure if you use mutt or ALPINE read the related forums for help.

while anyone can criticise any large company one should do it for the correct reasons.

Your frankly-speaking somewhat condescending reply fails to address the issue. This has nothing to do with the client software, which is claws-mail in this case. My organization does not enable 2-factor authentication. Once they do, claws-mail can be configured to use "App passwords."

But if you look at my other post, quotes of Google's own documentation of "App passwords" and various testimony in this thread do not inspire much confidence that this will work as an acceptable long-term solution. As I said elsewhere, the rationale behind all of this seems to be anti-competitive behavior. It's not new idea to disguise anti-competitive behavior as security issues (cf. e.g. Apple's code signing and Gatekeeper). This also explains the misleading and incorrect term "Less Secure Apps" Google uses.

Happy to help onboard your university!

We currently serve UMD, Tufts, Swarthmore, and more.

https://forwardemail.net

I read through your website and I don't understand what your service is. You sorta seem like an email host but seem to very intentionally and carefully not advertise as an email host.

It's shameful how far we've gone down this path. My university is using Microsoft Exchange and they refuse to allow IMAP access even with Oauth2, only allowing you to use proprietary protocols. So far I've only seen Evolution and Thunderbird working (with a paid plugin for the latter). I think it's a means to exert control on your email usage. For example, most sane clients do not show images by default, which prevents various types of tracking pixels from working, whereas Outlook doesn't do this afaik.

Here's updated info on Outlook:

"Microsoft Outlook is configured by default to block automatic picture downloads from the Internet. You can, however, unblock pictures that you think are safe to download."

From https://support.microsoft.com/en-us/office/block-or-unblock-...

Perhaps the headline is a bit hard to parse, but OAuth will NOT be required for email, IMAP and POP will continue to work with App Passwords

From Google's own official documentation:

"Tip: App passwords aren’t recommended and are unnecessary in most cases."

"Tip: Don’t create an app password unless the app or device you want to connect to your account doesn’t have 'Sign in with Google.'"

"To help protect your account, we revoke your app passwords when you change your Google Account password."

"Tip: If the app offers 'Sign in with Google,' we recommend you use that feature to connect the app to your Google Account."

"If you use a non-Google app and can't sign in, the app's sign-in process might not be secure. Try to update to the latest version of the app and use 'Sign in with Google,' if it’s an option."

Yeah, no problem at all. I'm sure it's going to work flawlessly and effortlessly.

My SO uses GMail and anything but Thunderbird it's a hellish nightmare to setup. On the HN comments about "but my secUrity"... who cares. Get a good and long password and use TLS everywhere. This is enshittification and pure EEE tactics against public standards and free sofware email clients and yet these careless users applaud it.

The nice thing with public standards is that you do not have to patronize providers who do not comply with the standards.

For now. They've been threatening to remove App passwords for a long time.

Thank you, where have they mentioned a possible removal of App passwords?

We use gmail at work and they warned our IT department that App passwords were deprecated and would be removed at some point (there was a previous deadline but it has been extended to a non-specific point in the future).

We had the same communications with Google that encouraged us not to use App Passwords, and hinting at a future removal. Plus the fact that App Passwords expire when the Google Account password changed, means you can’t count on the App Password working.

We are a large enough organization with that we have 25 years of use cases beyond “People Reading in their Inbox”. Printers and scanners have been mentioned. But we also have email used to automatically move data between systems.

Sometimes this is due to limitations of third party systems, sometimes we have to decide does it make sense to invest the time to rewrite a well tested tool that uses POP.

So we have decided to a standards based POP, IMAP, SMTP email service for these automated systems. It takes much less time to configure and test swapping POP server info than migrating to OAUTH

The end user email stays with Gmail.

I see, thanks.

Why is there AFAIK no tutorial on how to steal the "app token" (sorry, I don't know the proper term) from Thunderbird or other mail clients?

Reply on news.ycombinator.com