Hacker News Reader

Comment by robenkleene | Hacker News Reader

This is a great point: "There are no intermediary servers with access to your account or copies of your messages." A number of popular email clients use intermediary servers and that's a complete deal breaker for me. I'd argue that should be a deal breaker for almost anyone. I'm not a security expert, but as far as I can tell, for most people the single biggest security vulnerability is an attacker gaining access to their email. Using a mail client with an intermediary mail server essentially doubles the surface area attackers can exploit.

View on HN

I never quite understood what the value add was for email-client developers to use intermediary servers. Is it to gather usage telemetry or something else?

Usage telemetry can be gathered pretty easily from the client itself. Having an intermediate service is usually for stuff like push notifications, search, autocomplete, recommendations and really any other feature that goes beyond the email spec and would be difficult or cpu intensive to implement on all the clients.

Pessimistically for telemetry, but I suspect some of them are Javascript apps in a lightweight shell that have actual technical difficulties making a TCP IMAP connection.

Yeah, I think difficulty making an IMAP connection is one reason. I think the biggest reason has been to decorate more features on top of the backing email service, like adding Snooze support to an arbitrary IMAP account (so the server can un-snooze a message at the scheduled time).

That being said, there are security/privacy implications to that model, and I wouldn't personally use an app that works this way. That's why Mimestream was built as a traditional client.

Doing TCP from a "native" JS app should be pretty easy[1] (caveat: I haven't tried.) I'd think the cost of running a proxy server would be enough motivation to figure this out, for any developer whose primary reason is as simple as technical difficulties with JS and TCP. I think it more likely the other responses such as doing heavy indexing that won't work as nicely on the clients.

[1] https://stackoverflow.com/questions/41674063/is-it-possible-...

On iOS (and some of the more aggressively power-saving OEM Android builds), it's the only way to implement push notifications

On the positive side, you could use them for some privacy features, like predownloading images (works with popular clients like Gmail which prefetch them, whether you read the email or not, to water down analytics)

It turns the app into a service which might require an ongoing fee, which is revenue.

Indexing and search can be sophisticated & available before downloading any messages; you can ensure completion of complex pop and imap operation (eg working with messages "tagged" by gmail); just a few benefits.

Note, this is in no way an endorsement of middle manning email management and facading as a client.

I was about to install it until i went through OAuth setup which grants the "Mimestream" application permissions do to a number of things including "Read, compose, send, and permanently delete all your email from Gmail"

One can blame it on Google OAuth UI or on Mimestream UI, but its not clear to me whether these privileges are granted to the locally installed application and can only be used by it

whether these privileges are Granted to "Mimestream" the Google OAuth App account which can then be used to do those actions outlined above by some service associated with "Mimestream" Google App.

Needless to say, i chickened out from using my main google account with it and instead will test drive it with a toy account

I don't see much difference in the distinction between the client software (written by Mimestream, probably with regular updates) having access to your account, which it obviously has to has, and Mimestream having direct access. But IANA security researcher, so salt liberally.

I mostly agree -- it takes a level of trust to provide your credentials to a third party app.

However, there are precautions that you can do to minimize the risk of your credentials used without your authorization with a local client software:

1) requiring multi-factor authentication when credentials are used from a new location/device/ip... 2) A local firewall(like little snitch for osx) that surfaces any unexpected outbound requests.

These obviously wont be much help if you grant some other server permission to access your email.

Tokens are granted to the app running on your Mac, not a service. There's definitely no Mimestream-run service component with access tokens to your account.

One tip - on the Google OAuth sign-in page, you can inspect the URL's query component to see the redirectURL parameter, and you'll see where Google will send the token. In Mimestream's case, it is <long-custom-scheme>:/oauthredirect, which is a custom scheme registered with macOS by the app, so macOS shows you the "Do you want to allow this page to open Mimestream" prompt.

This being said, you are totally correct, when you use any closed-source app like this that you did not build yourself, you are placing trust in the developer, and you are wise to be cautious.

In my opinion, there are still several practical security/privacy downsides to apps that run intermediary services with access to (or copies of) your email: - A larger attack surface (the intermediary service) for an adversary to take advantage of, and one that is probably less hardened than Gmail - A larger bug surface, as the service could potentially accidentally expose your data to another user (and this sort of bug _has_ happened in the past to others). - Google probably has serious policies/systems in place for preventing a curious (or disgruntled) employee from reading your unencrypted email. Hopefully. That level of sophistication seems less guaranteed from a small company, and it's completely invisible to you as a user.

Reply on news.ycombinator.com