Archive for December 22, 2014

Monday, December 22, 2014

Introducing JMAP

FastMail:

JMAP is FastMail’s protocol with the warts removed. We leverage existing standards like HTTP, JSON, and native push channels on platforms which have them – making it easy for developers to work with.

JMAP is friendly to mobile devices. By batching multiple commands in a single HTTP request, and having an efficient update mechanism, the radio works less, and battery life is increased. By using the platform push channels, JMAP avoids having to hold its own connection open.

JMAP is friendly to servers. A stateless protocol, there’s no need for the server to maintain a version of the mailbox view that’s out of sync with the current state, as IMAP does, just so that clients can use integer offsets to refer to messages.

[…]

JMAP is friendly to multiple clients. In IMAP, if you rename a folder or move messages, then the client which initiated the action can update their local cache, but every other client has to re-fetch everything – there is no unique message ID which follows the message. JMAP uses globally unique IDs for messages, so immutable data can be cached forever.

[…]

FastMail commits to provide a reference server and reference client, as well as maintaining the specification document in collaboration with others and keeping an up-to-date test suite to allow verification of implementations.

Finally, we know IMAP, SMTP and the DAVs aren’t going away any time soon. No protocol will succeed unless it provides an upgrade path from where we are now, and a compelling reason to switch. We will provide a proxy which can talk to existing servers and present them over JMAP. If the proxy is run somewhere close (in network terms) to the legacy servers, then JMAP will be a better experience than speaking to the servers natively, particularly if you’re on a slow network or the other side of the world.

This sounds great. They will provide a reference server, a reference client, and a proxy for existing servers. jmap.io contains the protocol specification and documentation for writing clients and servers.

Schwab Password Policies and Two Factor Authentication

Jeremy Tunnell (via Rosyna Keller):

Like probably millions of people I have a Schwab brokerage account, and that account holds a good portion of my savings for retirement. I care very much about protecting my savings, and one would expect that Schwab would care a great deal about protecting a reputation for protecting me.

This is why, during a recent tech support call and subsequent investigation, I have become appalled at what appears to be a Rube-Goldberg, duct-tape-and-bailing-wire approach to implementing their much bragged about two factor authentication. Below is my list of several poor design decisions that, while taken in isolation might just be embarrassing, come together to fool perhaps tens of thousands of people into thinking that their account is secure when it is not.

Update (2014-12-23): Here are the comments on Hacker News and an older post mentioning some of the same issues.

Update (2015-09-03): Rosyna Keller:

I am glad @CharlesSchwab finally fixed their password issues!

Apple, Is USB Allowed Now?

Matt Ronge:

In the wake of the success of the Duet Display app, is using the USB connection in iOS allowed?

[…]

We knew that using USB instead of Wifi was a decision we had to make early on, as it would completely change our direction of development. USB offers a reliable, low latency connection which is 100x better than any wireless technology (especially with Yosemite experiencing serious Wifi reliability issues).

We were also very hesitant to build a business around a decision Apple may change on a whim. So we submitted an app to test the waters, would Apple allow an app that requires USB? An Apple representative called us and informed us USB connectivity was not allowed.