robn_fastmail

So far the majority of devices haven't had a problem. We've got one confirmed case of it not working automatically on iOS 9 beta, and a couple of other reports that we haven't been able to identify yet. We'll keep testing.

> Our main servers

"main" servers. Most services are mastered at NYI, with replicas at other sites (currently Amsterdam, soon LA as well). Soon some services will have the option of being mastered elsewhere. Maybe I should reword that help doc a little bit.

Our security is about as good as is practicable. It might not be the absolute best but I'd wager its better than most, especially when balanced with the usability and reliability guarantees we make. Obviously encasing your server in concrete and dropping it into the ocean is more secure, but that doesn't give you much of a service.

I don't think I can say NYI do better than every other datacentre, because I haven't used ever other datacentre, but they certainly seem to be far above most other players. It also helps that we've worked with them for years and know most of the key staff personally.

We don't currently encrypt traffic between our servers within the same datacentre. We own all our servers and network equipment, so there's no inter-server traffic leaving our own equipment. Of course its possible for some kind of network tap device to be installed but at that point the attacker already has physical access to our servers so we've already lost. This point was addressed in the first blog post alfiedotwtf linked to.

We do encrypt between datacentres, of course.

So to your final question, what differentiates us from other services, its hard to say exactly because I don't know which other services you're talking about. Our general approach is to use the best tools and techniques available, and to understand everything we use so we know what compromises we're making at what our attack surface looks like. Our ops staff know this stuff well, respond quickly (eg we patched Heartbleed before start-of-business in the US, when most of the mainstream media hadn't picked it up yet), we talk very openly about what we do and how we do it, and we offer a generous security bounty to anyone that finds an exploit.

If you think we could be doing more, let me know! I'm happy to be contacted directly (robn@fastmail.com or @robn on twitter) or you can open a support ticket or ping @fastmailfm.

Give me a ticket number and I'll have a look.

Tbh, I wouldn't be surprised to find the ticket was assigned to me and I never got to it. I have a few CardDAV tickets still lying around. That's part of the "beta" guarantee - support is .. spotty :P

We've made a lot of improvements since then. Did you ever report the problems you had?

As an Australian company, we fall under applicable Australian law. The new data retention regime is not applicable to us (we believe) because if the reasons outlined in the blog post, that is, we don't meet the criteria necessary for the new rules to apply to us.

Basically, its business as usual. With an appropriate Australian warrant, we will hand over user data (content and metadata). It's been like this for years. See our privacy policy for details.

https://www.fastmail.com/about/privacy.html

The apps use OS/platform push for notifications, because the webapp component is asleep at the time. When the app is active, its just the regular webapp, which uses eventsource.

The JMAP spec provides for eventsource and webhooks, but obviously an individual provider can offer more than that via an extension. When we do switch over to JMAP, we'll continue to use our custom method to register platform notifications.

FYI, our CalDAV support has been in full production for almost a year now.

We talked about this in the office a few weeks ago. The conclusion that we came to is that we're pretty happy with our current situation so any buyout would have to have a fairly enormous amount of cash attached :)

So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?

Right. I'm a little rusty on the details. My point stands - key distribution is not a solved problem for the average user.

We're working on a proxy that will work with any IMAP server that of course will work with Cyrus. I think its likely that we'll look into building support directly into Cyrus at some point but we don't have any concrete plans yet.

If you read the spec closely, you'll note that it provides support for arbitrary challenge/response auth mechanisms. Its conceptually the same as SASL in that respect.

Yes, we're assuming a secure transport. Most of the internet currently does. Most of the passwords you send over encrypted channels right now are plaintext. This is not something we're trying to solve with JMAP (if it even needs solving, which is debatable).

We're fully owned by the staff, with no external funding. We've been nicely profitable since the beginning. Not huge profits but enough to pay for a nice office, decent salaries and few gadgets.

So yes, if your goal is to attract massive amounts of venture capital and then get bought out, don't copy us. If you want to have some fun doing something you love without having to worry about anything else then this is definitely the way to do it :)

And how do you trust those? And if I'm a brand new user, how do I get my key in there?

All the moving parts probably exist, but so far no one has pulled it together into something that a random person off the street can use.

Its not the problem JMAP is trying to solve.

Android, iOS, (Windows Phone, Blackberry, etc) have services where a server application can push a small data packet to a specific device. That device wakes an application in response which can then do things.

We use this right now in our mobile apps. The apps respond by calling back to FastMail to check for updates.

More info:

http://blog.fastmail.com/2014/12/02/dec-3-push-it-real-good/

https://developer.android.com/google/gcm/index.html

https://developer.apple.com/library/ios/documentation/Networ...

> "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP

Not actually true; the protocol does not require HTTP. Any bi-directional stream transport will work just as well.

> "M" is misleading because this protocol is designed for a lot more than mail.

Maybe "Messaging" would have been better. I don't know.

Part of the JMAP name is to make it look like IMAP so its easy to see the relationship. J is after I. And so on.

But lets not quibble about names. Perhaps its not a great name. It doesn't really matter because products get different, better names.

> reinvented HTTP > yet another bloated protocol

This is kind of "citation needed" stuff. I'm not saying JMAP is perfect, in concept or in implementation, but we've have a shipping product running on it for a couple of years. Its got runs on the board already, and we're inviting everyone to pick it apart and make it better.

> IMAP+SMTP using a stateless protocol would be cool

Both IMAP and SMTP are inherently stateful, and that's not the worst of their problems. Why not fix it all properly?

Its expected that you'll run JMAP over HTTPS which takes care of the wire encryption. For end-to-end encryption, there's a heap of problems that still aren't solved (key distribution, need for content analysis). There's no reason JMAP couldn't be extended in the future to support these via additional properties, attached encrypted payloads, etc but mandating it from the outset would quickly see the whole protocol dead before it began.

That doesn't match our experience. Do you have benchmarks to support this? I'd be interested to take a look.

The other side is that it does take a not-insignificant amount of time and effort to prepare a fifteen-year-old codebase for the public. There's got to be some benefit to the business to make it worth that.

The old web framework that we use is good for what it is, and we understand it, but its not state-of-the-art by any stretch, it does some weird things that aren't good practice in "modern" Perl, its still fairly heavily tied to Apache2/mod_perl and other parts of our internal libs, and so on. We don't use it for new code ourselves and we're actively migrating everything written in it onto Overture-based UI.

So given that even we don't want to use it and the off-the-shelf Perl web frameworks are generally better, it really doesn't help anyone to make it open source.

That's not to say there's nothing in our system not worth open-sourcing. For example, we've deliberately written our CalDAV/CardDAV libs in a nice clean modular way because we've planned to release them from the very beginning. Its just some things, like the web framework, that have no particular value.

Please report this in this issue tracker: https://github.com/fastmail/overture/issues

Nah. If they want your stuff, they'd work through the appropriate Mutual Assistance Treaty to get an Australian court to issue a warrant, and then we'd comply with it and hand over your mail because we follow the law.

Making a phone call is way easier and cheaper than giving RobM a free Mediterranean holiday :)

Our current advice is that we are bound by the provisions of the Privacy Act 1988 and the Telecommunications (Interception and Access) Act 1979. Neither of these contain provisions that would allow indiscriminate capture of communications. You can read more about how we understand and apply this in our privacy policy:

  https://www.fastmail.com/help/legal/privacy.html

If you're talking to the proposed amendments to the TIA Act that are currently before Parliament then I can't really offer you much since the bills have not been passed and if they are passed, what's before Parliament might not be the final text.

So given that there is no legal means by which we can be asked to participate in blanket surveillance, it is entirely accurate to say that we do not.

If the legal situation changes then naturally we will make any necessary changes to our privacy policy and inform our customers of this.

If you're looking for us to commit to never ever doing something even if the law changes in the future to make that thing a requirement, then I'm afraid you're out of luck. But I hope you also see that that would be a rather silly commitment to make given its entirely hypothetical nature.

I said governments and other third-party actors are not under our control. I never ever said that FastMail was not under our control.

We do not participate in blanket surveillance.

I am not sure how to make it any clearer than that. Perhaps you could tell me what you'd like us to say, and then I can tell you whether or not that's something we agree with?

You've completely misunderstood the line you quote. FastMail as a company do not participate in blanket surveillance. We can't control the actions of any one else, governments or otherwise.

Not sure what's about either. Like many rich-text editors, it can handle embedded images, but the attachment stuff proper is handled in the surrounding application.

> Even though Squire isn't meant as a drop-in replacement for web page editing, it still suffers from the same endemic issue that plagues all editors: browser inconsistency.

Squire's purpose is to make things look on-screen and in email the way the user expects it to look. The actual HTML generated is secondary to that. While its nice if it can produce the same HTML every time on every browser, its not especially important.

In terms of UI consistency, its intention is to provide a simple, pleasant editing environment that the user is mostly familiar with it (keyboard controls etc). Again, it doesn't have to be identical everywhere, as long as it does what the user expects.

(Note: I'm a FastMail employee, but not directly involved with Squire).

Sorry Alfie, your memory fails. We started with Sphinx.

We use Elasticsearch elsewhere (ELK stack), but not for mail search.

Xapian is to Cyrus what Lucene is to Elasticsearch - the search engine embedded into the larger server.

> it's fairly well connected (on top of multiple transatlantic cables)

Not as well as you'd think. We see substantial packet loss to Iceland for long periods at least once a week, and very occasionally the entire country disappears from the internet (maybe every couple of months).

Also so far we haven't found a datacentre that we feel we can trust to care about reliability as much as we do. I've just spent the last four hours dealing with our entire Iceland presence being taken off the internet because someone at the datacentre misinterpreted our normal replication load as a denial of service and blocked the entire thing.

We're trying, but so far we do not have the confidence that we could reliably provide user-facing services from Iceland, or at least not to the standard that we do from New York.

Yeah, I've answered that questions a few times in the last couple of days. It was also asked a bit when first release the mobile web app a while back. It's on my list to bring it up with the UI team soon :)