Hacker News Reader

I've downvoted you for your sheer negativity.

This is a person who's worked 2 years on a project, in a neglected space where companies don't go because they can't make money.

He deserves praise for taking the time, creating something that's different, and thinking through the idea. Well done!

I built a webmail client from scratch many years ago and I agree with the security concerns. In my case the credentials were not a problem with displaying inline HTML securely was difficult to get right. Back then there was no CSP.

He isn't trying to take away from the achievement, just highlighting some legitimate security concerns.

IMHO this is justified since people often overlook how critical an attack vector this would be.

Imagine if a state-sponsored "hobbyist" posted a pet project like the OP to Reddit and started harvesting keys/password reset capabilities for huge amounts of users.

Hell, people flocked to use unroll.me and then it turned out they were (predictably) scraping your entire inbox and selling the data to advertisers.

I don't believe that worrying somebody's skepticism might hurt feelings is a legitimate reason to downvote (remember, downvotes aren't about whether you agree with somebody; it's about whether they add constructively to discussion).

Aside: Great work OP. Seems like an incredibly hard sector to make traction with though, so best of luck.

Yea, I kind of feel the same way about it. "Great work but not my cup of tea for reasons A, B, and C" should be valid feedback on a Show HN.

Absolutely. But the OP forgot the "Great work but...". Had they, I wouldn't have commented.

Security concerns are the one of the primary reasons why so many email clients died out mid to late 2000’s when every red team success story was “found XSS in email client pwned admin”.

No body is detracting anything from anyone but there is no way I’m trusting an application that can take contol of a large portion of my life without assurances.

If your email address gets compromised it’s game over for most people every service you’ve registered with is up for grabs which is also the reason why I don’t recommend anyone to use personal domains for email unless they are willing to pay for it till death do them part.

As time and time again after buying a domain that was used by someone else and setting up a catch all email address I got emails from Twitter, GitHub and the likes.

Just because someone works on something for two years doesn't mean they "deserve" anything. That's flawed reasoning.

For me, an additional concern is being tied to this client after using it. Every offline mail client has its own storage formats (mbox, maildir, SQLite, another database or a mix of these), and so moving across clients is not an easy exercise unless the clients support multiple formats for import. I would also like to see how the client behaves when one single mailbox is more than 20GB in size, with at least one of the folders being around 3-4GB by itself. Claims that searches happen in milliseconds need to state the size of the mailbox and the folders (and also include enough variability in the content for the index to be large enough).

I certainly like the idea of new email clients, especially those that integrate with Exchange calender (a weak point for Thunderbird even with extensions). But in my view, building a fast, robust and feature rich email client would take about an effort of 10-30 person years or even more, depending on the feature set. This one seems to stand at a mere two person years, and so my expectations would be quite low (though it's still in beta and states upfront some of the important features it's missing).

P.S.: I'm a supporter of Thunderbird and donate money to the project. https://donate.mozilla.org/en-US/thunderbird/

> Claims that searches happen in milliseconds need to state the size of the mailbox

I'd honestly outsource the indexing and searching to something like mairix which is designed purely for this purpose.

(On my 4.5GB Maildir, 57 folders, 111k emails, mairix takes 205s to index from scratch. Incremental updates are <5s. Worst search I've yet done took 0.5s to return 13k hits for 'bank'.)

Or "notmuch" which has integration with Mutt and similar mailboxes, and it has GMail-like tagging and boolean searches.

Interesting, thanks! Trying that now. Took twice as long (13m) to index my folders (and ignoring a whole bunch of fake-mbox files that seem to be coming from my gmail-to-local forwarding) but the searching is about the same kind of speed as `mairix`.

I had a very quick look at the mairix repo on GitHub, and I'm not sure what to make of at least one pull request (about large mailboxes) that has no comments on it for a few years. Though it's an old project, I just wanted to confirm that it's still good enough to use without too many issues and also check if you're using the main one [1] or any of the other forks. [2]

[1]: https://github.com/rc0/mairix/

[2]: https://github.com/rc0/mairix/network

Couldn't tell you offhand, sorry - I'm using the Arch Linux community package which doesn't explicitly state where it's coming from. Currently v0.24-1 if that helps figure it out.

I think the largest inbox ever tried in Ivelope so far is around 10GB and from what I heard from that user, there were no major problems - but I haven't made any measurements. A few people have requested mbox import and it is on the todolist.

Since you responded elsewhere that your client stores mails in a proprietary format, one very important product goal should be an export mechanism that can export to one, if not more, of the common formats (mbox, maildir, etc.). After all, if you’re confident on your client’s features as the USP to get customers, you should also easily allow those who want to move out to do so. I personally wouldn’t try our client for serious use otherwise.

Of course, I haven't put my focus on this yet, but it is on the todo list.

> Lastly since email today is pure HTML

Where did you get that idea? If your email is pure HTML all I'll see is your markup, if it makes it through the spam filter to begin with which assigns a pretty stiff penalty for sending me HTML mail.

On a related note, any email that’s “pure HTML” or mostly HTML is something I don’t even open, mainly because such emails tend to be of the marketing and tracking kind, where viewing it would send various signals to the sender. If anyone has something important for me to read, they better put it in plain text.

Exactly. HTML email is a privacy hell[0]. However, many email clients can work around this, e.g. in Mutt you can let Lynx do a plaintext dump of the HTML email.

Also, the whole issue of JavaScript in HTML emails at least deserves a mention[1]. Since Ivelope is an Electron app, I'd guess it would go ahead and just run everything it receives, right?

[0]: https://freedom-to-tinker.com/2017/09/28/i-never-signed-up-f...

[1]: https://stackoverflow.com/questions/3054315/is-javascript-su...

Are there still email clients that run Javascript? I though that idea had been properly murdered a while ago.

Unfortunately, I agree with you. I'm saying "unfortunately" because it's such a shame that this sector is so closed off to innovation from smaller players just because it has become too important in our lives.

I might try this client with a throwaway email account, but never with something important.

From the landing page:

> Privacy & Security

> Total privacy - we do not have access to your email account, Ivelope only sends your email data and password between your computer and your email server.

Without source code, that's nearly impossible to verify.

As with any other closed source app. What's your point?

If you're really paranoid but still want to try it out, you could run something like Little Snitch to verify the connections the program makes.

No offense, but if everyone thinks like this we better not use email at all.

Few webmail "clients" are open source and many native clients like e.g. Outlook are also not open source, yet these are very popular. Unless you use a highly trustworthy email provider, considerations about client programs are kind of moot anyway.

I'd personally be more picky about my mail provider and not use any offerings by Google or Microsoft, for instance, because they are stock market companies with interests that principally conflict with the interests of their users. In contrast to this, trusting individual developers and small companies makes much more sense. You check out their online presence and decide for yourself. I'd only be wary about individual developers who offer closed-source security applications (e.g. encryption) and have no prior history of working and posting in this field. But an email client? To be honest, I haven't even checked the vita of the maker of my preferred client, claws-mail, let alone those of any of the authors of the plugins I'm using.

On modern operating systems you basically have to trust every developer of any application anyway, since many installers require admin rights and even if they don't it wouldn't be hard for a malicious developer to exploit a security hole. Your kitchen timer application can get your email credentials almost as easily as your email client.

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 maybe), and no email provider could prevent my client from snooping on me either.

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 or even MSFT for most people security wise

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.

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.

The software runs completely on your desktop - your email & password is only sent between your computer and your email server. There are quite a few security measures in place that prevents HTML vulnerabilities, both built-in into Electron and others. I'd very much welcome an audit of the code from a respected firm!

No offense but unless it’s a 1st party client email clients are something that is very hard to trust.

This seems an odd position to me.

Online clients are well known to be scanning your emails, necessarily involve giving access and control to third parties, are impossible to use while retaining control of private encryption keys, and so on.

Local clients might have some of those problems. If they're open source then in theory you could audit them and find out, but in practice even that gives a false sense of security because no-one has the resources and willingness to undertake that work every time they install a new version.

Ultimately software security is still all about who you trust, the same as always.

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).

There's not a lot of attack surface when JavaScript is disabled. If there's a HTML/CSS vulnerability in Chromium, then your email client is the last thing you have to worry about.

Do you run any non-sandboxed software from any non-"first party" on your computer? If you do, that software also already has access to your entire email inbox.

So unless you have the source or show an audit from a respected firm (c53, isec etc.) its going to be quite hard to recommend to anyone to take the dive and try this out.

Please. How many times a day do you enter a password somewhere on your computer? Do you look at the source or ask for an audit for every one of those apps?

Not as many times as you'd think and again that us utterly irrelevant.

It's not how many time you put it in it's into what and then what that thing can do with it.

Not all passwords are equal and for most people their primary email is the domain admin/root credentials for of their life.

And it isn't relevant if I personally audit every application or not I can build a trust model based on my risk appetite and the threat models that are relevant to me and the situation and everyone does it even if they are not aware of it.

I can put my trust in a specific vendor based on their business model, their reputation, the resources they have available and my experience with them and the legal frameworks surrounding the service/product. I can put my trust in the community at large in the case of open source products because while individually neither myself nor most other user validate every line of code and every commit it is possible and the community at large does do that.

Let me ask you this I this wasn't and email client but say a thick client for your online banking would you still ask me the same question? bare in mind that having your email compromised today is considerably more damaging than someone logging into your online banking as it's much easier to sort the latter and there are also considerable mitigating security controls around it.

Pretty much everything you said is bullshit, fwiw. Nobody gives a shit about your name drop of firms, nor will not having an audit from any of them impact the target market for this app.