It's not a client, when gmail changed it's TOS to use your messages, I wrote gpgmda. Found sup!? alot? notmuch.
I've spent the last two years building a new email client
201–210 of 608 posts
Re: I've spent the last two years building a new email client
#202Earlier quoted context omitted.
Outlook is trustworthy for the most part at least as far as security goes MSFT isn’t fooling around and it’s an enterprise product. And yes choose your email provider based on your threat model but there is nothing wrong with Google or even MSFT for most people security wise privacy is a different concern but these are different threat models. An email client won’t prevent my email provider from snooping on me (E2E m…
You're already trusting hundreds of individual developers by running their software on your computer. There is nothing wrong with running an email client made by an individual developer unless you have a particular reason to distrust that person. > as far as security goes MSFT isn’t fooling around They have a proven track-record of security bugs for the past 20 years and longer. > there is nothing wrong with Google o…
The threat and trust models are completely different.
It's not just about using a piece of software it's about using a piece of software that can lock or unlock your life because essentially every service you use today is tied to an email address.
>There is nothing wrong with running an email client made by an individual developer unless you have a particular reason to distrust that person.
It's not that i distrust that person but it's that I know how unlikely it is for a single person to be able to validate the security of their product especially when it comes to something as complex as a product with a DOM parser and a layout engine, nor do I think they would be able to maintain it up to date when new attacks and vulnerabilities are discovered even they do use something like electron since electron isn't simplicity safe and plenty of electron based software even fairly well maintained one lags well behind it's update cycle including when security patches are concerned.
>They have a proven track-record of security bugs for the past 20 years and longer. They also have a proven track record of finding and fixing those bugs.
>I wouldn't use them as my main email provider security-wise and trust my current email provider way more than those companies. (Not because I think they are less secure, but because I think they are attacked more often.) But of course your mileage may differ, nothing to object to that.
There are potentially more secure providers but being attacked more often isn't a really good sole metric threat model unless you can effectively estimate resilience responsiveness and compare it to other options.
I used Hushmail as my primary email (still somewhat do) because it was fairly secure and had integrated PGP, I switched to Proton Mail now.
Re: I've spent the last two years building a new email client
#203Earlier quoted context omitted.
Every recent new app I can remember installing in the last year is Electron. Native UI is dead. It's more work and all it really buys you is the privilege of being tied forever to one platform or having to code your UI multiple times. The effort of writing your UI three times to use three different proprietary UIs would be better spent optimizing Electron for less resource use. In the long term web will totally repla…
Or you use qt. Which is cross plateform, native, fast and open source.
Ask yourself why more people don't use Qt:
(1) With web technologies you can write once and run everywhere including mobile to some extent. Writing a UI multiple times is monumentally expensive. Even huge companies don't like to do this, let alone indie efforts and startups. If Slack with its billion dollars doesn't do it what does that say?
(2) The ecosystem is far more active. The web is the largest open source ecosystem in history. There is code to do literally everything and an embarrassment of riches when it comes to libraries, frameworks, connectors, etc.
(3) Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic.
(4) Long build times mean that I have to wait a lot longer between dev/test. UI development tends to be a whole lot of iterative hack-test-hack-test. With web tech it's literally edit-refresh, which is much faster than edit-make-wait-launch.
(5) To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode. At that point I'm halfway to browser rendering.
(6) If you code UIs with web tech you also get the web, meaning your app could be run remotely in a browser as well as locally. This is the networked app promise of X11, Citrix, etc., and you get it for free.
Electron is popular because it delivers a ton of value in terms of cross-platform compatibility, reduced effort, rapid development, consistency, and ecosystem. Performance and memory use problems can be fixed.
I have been watching this project:
https://github.com/andlabs/libui
It's a genuinely lightweight wrapper that looks really promising. Trouble is everyone I show it to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs and that takes you down a path that looks increasingly like CSS whether you like it or not. I also have this strong feeling that if I wrote with it I'd be rewriting in 5 years after desktop UIs are abandoned in favor of 100% web technology everywhere. Of course web UIs shift a lot too. Maybe the fate with UIs is to rewrite every 5 years no matter what.
Re: I've spent the last two years building a new email client
#204Earlier quoted context omitted.
That's almost never the choice though is it? Who offers an Electron app and a native app? So the choice becomes use an Electron app or something else entirely.
Nobody, but many offer an Electron app for things where equally good native apps exist.
Not true. Look at the various Skype clients, e.g. for Linux. Memory usage ballooned after they wrote their Electron based client. It uses 4 to 5 times the amount of memory of the old Qt based client and idle CPU usage is through the roof, too. And it can't even handle long conversations smoothly.
Re: I've spent the last two years building a new email client
#205No offense but unless it’s a 1st party client email clients are something that is very hard to trust. Who controls your client has access to your inbox with most services even the few that have separate IMAP/POP3 passwords like Hushmail can be compromised through it. If your client also integrates with encryption or worse takes charge of it my encryption key is also now at risk. Lastly since email today is pure HTML…
Tust is everything. What does it change if you have an c53 audit of Version 1.0.0 and 1.0.1 has malicious code?
That is correct but it's a slightly different threat model that I don't want to tackle here.
I'm not going to make claims that a developer would maliciously embed code into their own product but I do care about the quality of their code and their security practices at large (specifically how secure is their code promotion and binary distribution supply chain).
Re: I've spent the last two years building a new email client
#206Earlier quoted context omitted.
For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB. I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does). Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though i…
That's it? My Gmail tabs used to take 2GB (the last time I checked, years ago).
Actually, that was just from just loading Gmail and letting it idle, a couple of weeks back, not actually using it. A year and a half ago, I recall it being more like 125MB, up towards 150MB as it was used. Gmail hasn’t really changed since then, but the Hangouts widget (which is pretty heavy!) might have, and the browser definitely has (I blame it for most of the increase). I haven’t actually used Gmail since around that time.
For reference, I’m using the explicit/window-objects/top(…) figure from about:memory. This is not an accurate representation of the full footprint, but is close enough.
Re: I've spent the last two years building a new email client
#207Earlier quoted context omitted.
Electron apps are web apps "sold" with Chrome. Like buy one, get two for free.
The OP clearly means not hosted remotely / not requiring a server to set up, but somehow everyone thinks this is a great opportunity to mention that since it uses the same underlying front-end technology, there's no distinction, and it's actually worse.
Good thing this is hacker news, or I might have missed out on a barely-relevant pile-on of commenters letting me know how terrible Electron is!
Re: I've spent the last two years building a new email client
#208Earlier quoted context omitted.
Electron apps are web apps though.
Not sure if there is a common agreement about terminology, but my distinction is - web app: loads from a server and connects to a backend to perform its activities. Business logic is on the server. If at all, very limited offline capabilities - desktop app: is installed on the local machine, doesn't need any connection to a backend to work, works offline. I don't mind at all which technology the dev used to implement…
And a web app runs on a local server, so where is the problem?
On my linux "Apps" run on (X) server too.
Re: I've spent the last two years building a new email client
#209Earlier quoted context omitted.
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.
Nonsens. Every traffic can be monitored, web app or native app, that is not important.
Re: I've spent the last two years building a new email client
#210Why do you spent 2 year of your live to build a new email client? Aren't there quite software per this scope?