Hacker News Reader

Comment by emersion | Hacker News Reader

Unfortunately this requires users to setup their own OAuth client, which is a pretty manual/cumbersome process.

There's no good way around that unfortunately. The proxy could build in an OAuth client for the major providers, but it's unlikely that this would be trusted by default without significant effort being put into review processes.

As the readme explains, there's nothing to stop you using the existing OAuth client details from another source (such as the many already trusted open source email clients that exist).

Yes. I'd argue the problem is not on the project's side, it's on the Google side (they have ridiculously high requirements for registering OAuth clients for IMAP/SMTP use, especially for a small open-source project).

Any good guide on this (registering oauth clients) for people who want to make the move?

https://support.google.com/cloud/answer/6158849?hl=en#zippy=

There is likely a package/library for your language of choice to do a basic oauth client.

Same if you're building any OAuth-enabled client from source.

(Remind me, what's stopping me from extracting the client secrets from the compiled binary, and re-using them elsewhere?)

The provider might notice that their key is being used in an unauthorized way and terminate your account, prosecute you for computer fraud and abuse, etc.

I think this is the only assured way to interop, as I expect Google may try to kill other competing apps (specially in mobile) that does not capture user data or generate data points for its ads.

I wonder if any intentional limitation here should not trigger some of the EU Digital Services Act provisions for interoperability ... in this list [1] I see Google Play, Maps, and Shopping but not GMail!

[1] https://en.wikipedia.org/wiki/Digital_Services_Act#Very_larg...

I ended up ripping the app ID out of Thunderbird and using that for my OAuth process to Gmail.

Reply on news.ycombinator.com