Hacker News Reader

Comment by geekuillaume | Hacker News Reader

What is the reason to build it as a native software instead of a webapp? Seems like a lot of email clients are now webapps and I can see the arguments why.

View on HN

Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users

Although, in reality, that doesn't make it more secure.

On a desktop app, you can see what kind of request the program makes and which servers it contacts. With a webapp, you'll never know what the app does.

You can do the same in your browser by opening the developer tools and in fact it comes built in to the browser whereas on a desktop you'd have to install another app like Wireshark/Fiddler to see those requests.

That only tells you what your browser sends to their server. It doesn't tell you what connections their server makes.

Nothing will. The vulnerability of what happens to your data after it is sent to a third party is the same for any app, web or native.

The biggest difference is that it's way easier to see where you're data is being sent in a browser, since it has built in tools. It's very hard to monitor native app traffic that is sent over SSL.

When the app is native there no requirement for a third party server.

You, Your mail (provider) server.

You, the server hosting the web app, your mail (provider) server.

How so? It's quite simple to tell what a web app does in my understanding. Chrome has many good monitoring tools.

The webapp can send your data wherever once it has the data, chrome won't log http requests if they were made server to server etc

A native application can do that too.

Isn't it the case for any app?

The logic is a native app can make a direct IMAP connection to the mail server and you can check it is doing so where as a web app has to send the login details to a server which does IMAP for the client and you can not see this last part.

> With a webapp, you'll never know what the app does.

Unless you run uMatrix or uBlock Origin (same code in both as far as this feature is concerned), of course.

Nonsens. Every traffic can be monitored, web app or native app, that is not important.

It's not possible to make a web-based email client that speaks to the IMAP/SMTP server directly. Only a "native" (electron can do this) client can use those protocols.

That depends on the user.

If it's proprietary it makes no difference at all. The app could be sending my password off to a remote server and I would have no way of knowing.

You can still see to which servers the software connects, ostensibly the only servers would be those for sending and receiving your emails. If you're feeling particularly paranoid you could enforce this behaviour using a firewall. For web based email anything could happen and you would have no way of knowing, even after the fact.

This doesn't make any sense as a motivation, let alone the primary motivation, to build a native app in the age of web apps. There's no real difference in security here and the user perception gain is marginal and ephemeral.

Would love to be able to self host this though and access it through the browser... That'd be awesome.

Why is that preferred for you, may I ask, over running it as a local desktop software?

Running it locally is fine, but a hassle if I need to access my mail on someone else's hardware (or my phone). I think this is one of the main reasons Gmail is so popular.

What's the reason not to, other than not knowing how to build it as native software?

Possibly only to render the HTML in some emails (and why not, then, just open them in the user's existing browser window,) but otherwise, there seems (to me) to be little about email that requires the overhead of a browser engine and associated Node dependencies and whatnot.

A native app could be smaller, faster, and use less RAM.

Most users have the mail client open all day and multi-task between reading/writing mails, reading websites, working in an office application, etc.

What would be the reason to cram the mail client into the browser instead of making it a first-class application on the same level?

Speed. Performance. Memory usage.

Reply on news.ycombinator.com