Live data from Hacker News

JMAP – a better way to email

blog.fastmail.com

61–70 of 116 posts

Re: JMAP – a better way to email

#61

Earlier quoted context omitted.

You're assuming SSL is implemented without any security bugs. We saw what happened with Heartbleed and when SSL implementations are not properly reviewed and updated by a full funded team.

So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…

No, I'm not assuming anything and didn't even say anything like that.

My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else.

It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it.

Also, a widely studied protocol spec means nothing. The bugs are from the humans coding the implementations, it doesn't matter what level it is, they will have some bugs. Nobody can code a perfect secure implementation but we can have some kind of redundancies in the system, where if one security level fails, the rest can still have some reasonable security left.

Relying on SSL alone is not enough. But I don't think JMAP is the right place to do this, we may need something else in addition to JMAP.

At least JMAP is extendable, so that's one good thing it has.

Re: JMAP – a better way to email

#62
post #14
post #12

JMAP is a rather misleading name. "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP, along with recently added HTTP features such as push. JSON is just the message packing scheme. HTTP is what does all the heavy lifting. "M" is misleading because this protocol is designed for a lot more than mail. It also handles contacts and calendars, and I wouldn't be surprised i…

It must be a generational thing: for me, anything starting with "J" must have something to do with Java. ... But to be honest, I don't really care. A lot of people don't know what IMAP and POP and SMTP actually stand for -- they don't care, and neither do I.

I thought that it'd be lowercase "j" that signifies Java, not a capital "J"...

Re: JMAP – a better way to email

#63

Earlier quoted context omitted.

So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…

No, I'm not assuming anything and didn't even say anything like that. My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else. It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it. Also, a widely studied protocol spec means nothing. The bugs are from the humans codin…

What would you recommend then?

Re: JMAP – a better way to email

#64
post #48
post #28

Great job guys! Things like this together with CalDAV and CardDAV are reasons why I pay you guys for service. I just tried the following experiments with my Gmail and FastMail account. There's a reason why FastMail just feels faster! Try this: 1) While having the Gmail iOS app open, mark an email as read on the web 2) See how long it takes for Gmail to reflect the change 3) Now try with FastMail iOS app, see that it'…

Thank you for this comment. I do wonder why they simply didn't say this at the beginning of the article. I understood what they were up to purely because I'm a technical guy, but still I didn't want to actually have to watch the video -- namely because I'm deaf, and far too often there's no captions to explain what's going on so I prefer to read (and so do people at work, school, no sound etc), and it takes a lot les…

The Youtube page has the full script on it.

Re: JMAP – a better way to email

#65

Earlier quoted context omitted.

No, I'm not assuming anything and didn't even say anything like that. My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else. It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it. Also, a widely studied protocol spec means nothing. The bugs are from the humans codin…

What would you recommend then?

No clue at the moment, this is still a big problem and something Fastmail already knows based on the comment here from robn_fastmail.

If we have a solution, everybody would be using it by now. PGP or SIME was going to be it back in 90s but it didn't take off well.

The content of the message itself should be encrypted at the very least but how do you deal with the keys then?

Re: JMAP – a better way to email

#66
post #53

For the well acquainted -- how does this relate to Inbox ( https://www.inboxapp.com/ )? I have not spent enough time with either to make a comparison

Michael from Inbox here— a few key differences, from the horse’s mouth. :) First of all— I want to say that we’re huge fans of Fastmail and really admire their team and focus. Rob and Neil actually came by for lunch this summer and hacked in our office for the day. We’ve discussed JMAP back and forth with them for a while, and specifically had a long thread when we added calendar endpoints to the Inbox platform. [1]…

Hi Michael,

Thanks for commenting! I agree that our APIs are orthagonal in some ways.

We definitely plan to ship open-source code for everything JMAP. I'm working on an IMAPJMAP proxy, which I'm hoping to have in time for FOSDEM in February. I'll be giving a lightning talk about JMAP there.

I tell you what - that writing it taking a lot of my time! Evenings, on the train to and from work. It's not a pace we can keep up forever.

You guys are doing awesome work. Hope to catch up with you again - and hey, it will be great if you add a JMAP backend when JMAP is a bit more mature.

Worst case for FastMail, we still have an awesome API for our own backend. Best case, we help everyone else too.

Re: JMAP – a better way to email

#67

Earlier quoted context omitted.

So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…

No, I'm not assuming anything and didn't even say anything like that. My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else. It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it. Also, a widely studied protocol spec means nothing. The bugs are from the humans codin…

If SSL is broken, you are - as many people have noticed, screwed. JMAP itself is entirely encryption layer agnostic. It's transport layer agnostic. JMAP over HTTPS is definitely going to be the first layer, but we're looking at websockets with interest as well.

If you were insane, you could do JMAP over XMPP, or JMAP over email. That would be neatly recursive...

Re: JMAP – a better way to email

#68
post #55
post #48

Earlier quoted context omitted.

Thank you for this comment. I do wonder why they simply didn't say this at the beginning of the article. I understood what they were up to purely because I'm a technical guy, but still I didn't want to actually have to watch the video -- namely because I'm deaf, and far too often there's no captions to explain what's going on so I prefer to read (and so do people at work, school, no sound etc), and it takes a lot les…

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

I know it is not the solution, but maybe it will work for some people. You can sign up for Google account with external e-mail. It gives you everything but mail.

Re: JMAP – a better way to email

#69

Earlier quoted context omitted.

No, I'm not assuming anything and didn't even say anything like that. My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else. It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it. Also, a widely studied protocol spec means nothing. The bugs are from the humans codin…

If SSL is broken, you are - as many people have noticed, screwed. JMAP itself is entirely encryption layer agnostic. It's transport layer agnostic. JMAP over HTTPS is definitely going to be the first layer, but we're looking at websockets with interest as well. If you were insane, you could do JMAP over XMPP, or JMAP over email. That would be neatly recursive...

Exactly what I was trying to say but likely did it wrong.

I rather have a secure modular system than a single protocol that does everything. We simply just can't leave it as JMAP+SSL because once SSL cannot be trusted, it should be easier to replace it with a better solution or an updated SSL protocol. I don't think it is reasonable to include this within JMAP and force all services to update jMAP overnight because the internal crypto library had a hole.

Re: JMAP – a better way to email

#70
I hate to be critical considering the considerable work they've put in, but I don't buy their "JMAP is actually more REST-like than most “RESTful” APIs" statement. But maybe I'm missing a whole lot.

REST doesn't preclude doing multiple things in one round trip. Well it does seem JMAP is a bit more flexible when it comes to multiplexing very different actions. But the error handling doesn't seem to tell you which command has failed. You still can't get away from certain ordering issues. And to be honest, I don't see how it's going to be that easy to cache.

This really is RPC – using it as a straight replacement for IMAP might work well, but I wouldn't want to use it as a platform to build something very different than an email client on it.

Post reply on HN