Devgeeks

I know this blog has been a ghost town, but my work on the PhoneGap team at Adobe has keep me plenty busy.

However, I am working on something cool that I am hoping to blog about on here soon. It's basically a replacement for Crypton (the lib used in Encryptr for private app storage). It should be a great deal faster and simpler to use / set up.

Anyway, with SpiderOak giving up on Crypton, it seemed like a good time to implement some ideas David Dahl and I had at the time Encryptr was being developed.

I am happy to announce that SpiderOak has acquired Encryptr. They were already providing all of the hosting of the Crypton server back-end, but they are now taking over ownership, marketing, support, etc.

I am still the primary developer for now (Encryptr is open source, after all), but SpiderOak will be in control of the day to day direction of the app such as features and releases.

We will soon be releasing v2.0.0 — a near total rebranding of the visual side of the app led by SpiderOak's Lead Designer @helveticade. Soon after we will be releasing the long-awaited iOS version.

From there, it's going to be all about the features people have been asking for... like import/export, sharing, and more.

The new location for the source is https://github.com/SpiderOak/Encryptr

(Belatedly) Introducing: Encryptr (and Development With Crypton)

"A free, open source password manager and e-wallet. Zero-Knowledge. Cloud-based. Private."

If you would like to see it in action, my colleague David Dahl has made a video of it on Linux.

First, An Origin Story

In December 2013, I took two weeks off (for certain values of "off") to travel with my wife and children up to Brisbane to have Christmas with my parents. I used that break (among other things) to spend some time away from my day to day dev tasks by exploring the new Crypton privacy framework being built at SpiderOak. I decided the best way to really learn it was to actually write a small example app. When I had been talking about Crypton at meetups, I had thought that a simple password manager would be a great use-case for the framework.

TL;DR: Using Crypton, I was able to write the greater part of a privacy-focussed, zero-knowledge password manager in two weeks... while also spending time with my family.

Encryptr was the result. It is open source, and available on GitHub.

Admittedly, the TL;DR above glosses over quite a bit. Between other priorities, waiting for Crypton to reach a point where it had at least been externally audited, refactoring the Backbone integration, and having to learn how to package and sign desktop apps, I did not release Encryptr as an actual "product" for another eight months. But those are topics for other posts.

Authentication

One of the "hard parts" of app development is authentication. With all of the breaches lately, no one wants to be storing passwords anymore, much less storing the master password for a password manager. Crypton solves that by using the zero-knowledge "Secure Remote Password" protocol (SRP).

Registering a new user account is very straightforward:

crypton.generateAccount('username', 'passphrase', function(error, account) { if (error) { // Handle the error } else { // Use the account } });

Then, authenticating an existing user is as simple as:

crypton.authorize('username', 'passphrase', function(error, session) { if (error) { // Handle the error } else { // Use the session } });

It was amazing how freeing that was. I didn't have to decide how I was going to handle auth tokens, or worry if I was storing the user's password with sufficient encryption. Just crypton.authorize(), and on to the next part of the app.

Backbone integration

Crypton stores data objects in "Containers". Containers are named and contain an object called "keys" (not crypto keys... keys in the key/value sense) where the actual data is stored. Encryptr is a Backbone app, and although my first integration between Crypton and Backbone was not to my liking, the actual mapping was not that hard. In my first attempt I made some architectural decisions that turned out to be sub-optimal. Originally I had a single Container for the entire app. This original Container was mapped to a single Collection in Backbone, with each Model stored in the Container's keys object. Although this kept the mapping between Backbone and Crypton very very clean, it meant I would be missing out on some neat features of Crypton like Container sharing. If the user's entire list was one Container like it was originally, it would be impossible to share an individual password entry with someone else. It would have been all (of their entries) or nothing. It needed to be refactored.

The refactor changed it so that there is a single Container that acts as an index of the password entries (and yes, still maps to a Backbone Collection), but then that index points at the individual entries that are each in their own container. These Containers are mapped to Models. It's not perfect. Not everything available in Backbone is mapped to Crypton, but so far it has worked quite well. I may not have added password sharing to Encryptr yet, but at least now it's possible.

At it's heart is Crypton's session.load() that loads the container with a name that matches the model's id, then returns its keys:

session.load(model.id, function(err, container) { if (err) { return errorHandler(err, options); } return successHandler(container.keys); });

This Backbone adapter means that I no longer even really think in terms of Crypton, now I am just writing a Backbone app and everything "just works".

Cordova for Mobile, and Node-Webkit for the Desktop

Encryptr is currently available for Android, Mac OS X, Linux and Windows. As I am primarily a mobile developer, the app started as just another Cordova/PhoneGap app. However, a useful cloud-backed password manager would also have to work on a user's desktop. This is where Node-Webkit came in.

Once I had decided on node-webkit for the desktop versions, the bulk of the work was done by the grunt-node-webkit-builder Grunt plugin. Aside from configuring the plugin, it mostly just required adding another package.json file to the app's www folder.

Obviously, there is a bit more to it before it's ready to actually release, such as fixing the icon on windows, creating the various installers and signing them. But again, those are really stories in themselves (worthy of their own posts). The node-webkit wiki has many helpful resources about some of those extra steps. I was just pleased that I was able to add desktop platforms outside of Cordova from the same codebase with very few changes.

The Bad News: iOS

This is where crypto with JavaScript falls down a bit. It eats CPU power for breakfast. Many Cordova/PhoneGap developers think they need the new WKWebView in iOS 8 so they can have access to the JIT and have faster JS performance. The WKWebView certainly does boost performance of JavaScript. It is about four times faster than the JIT-less UIWebView normally used by hybrid apps. The actual truth, however, is that most apps (games excepted) are not bottlenecked by the speed of their JavaScript. There are many other factors that play a much greater role in the speed of Cordova/PhoneGap apps.

Unfortunately, speed is the greatest bottleneck in an app that performs crypto with JavaScript in a mobile device. As an example, Encryptr takes almost two whole minutes just to log in on my iPhone 5, much less display any entries. This means that until the WKWebView is available to Cordova apps, there will be no version for iOS. My only option is to either wait for Apple to finally fix that bug and release it in a version of iOS 8, wait for the Cordova team to come up with a workaround, or to implement the crypto in Onjective-C (ick).

The Future

Hopefully, the near future will bring an iOS version in some shape or form. Until then, I have a great many other feature requests both obvious and surprising. Some I knew before I even launched, and some I hadn't even considered. That's the joy of an MVP. Get it out, get it being used, and get feedback on what it's missing.

Here are some of the features coming in the next few releases:

Changing your master passphrase. This is a Crypton limitation that is currently being resolved

Obscuring the display of passwords. In the app to prevent them being seen "over your shoulder", etc

Import / export of entries. This is important for users switching to or from Encryptr

Offline access. At the moment, it's cloud only. I would like it to be offline by default and just use the cloud to sync

Internationalisation. Almost 45% of the downloads from the Android Play store alone are from devices with a primary language other than English

Sharing of entries. Securely share passwords or other data with your wife, business partner, etc

Today in the #phonegap IRC channel, a frustrated developer showed me the cartoon below:

Sourced from: http://www.commitstrip.com/en/2014/08/18/the-dilemna-of-mobile-apps-development/

It's funny, of course, and closer to the truth in some cases than some of us would like... but it's still a massive over-simplification. It reminds me of my lightning talk: "PhoneGap doesn't suck, YOU suck" and the great blog post by Brock Whitten (@sintaxi) that inspired it - "You half assed it. That is why your PhoneGap application sucks".

I can't draw cool cartoons, so I can't make a pretty rebuttal. However, I would posit that developing a PhoneGap app properly is more like following Google maps to a beautiful suburban home. Is it Neuschwanstein? Maybe not, though it depends greatly on what kind of app, and the developer(s) making it. There are certainly areas where hybrid app development shines, and some where it struggles. But, I would further suggest that a quick perusal of the various app stores would clearly show that merely being "native" does not instantly bestow taste in design, lightning speed, or the ability to make a useful and useable app that users actually enjoy. The castle on the left is probably as much of a fairy tale as it looks.

As the wise Eion Robb said in response to my wanting to write this post:

"the real argument is time [leads to] quality, regardless of language, platform, [or] technology. There are no shortcuts"

One thing I can say, is that the rickety shack attributed to hybrid development in the cartoon above is too often the result of not knowing how to get the best out of a great platform. Slapping a Bootstrap or jQuery Mobile app into a Cordova wrapper is not going to get you the same app that learning Objective-C, and Java, and making use of the tools Android and iOS provide are going to get you. Having said that, I personally believe that with a solid understanding of HTML, CSS, and JavaScript, you can get pretty damn close (or better) and not have to freeze to death in the maze from the Shining, to get there.

Resources:

Apache Cordova Tutorial by Christophe Coenraets

Tips for Creating Real PhoneGap Apps That Look As Good As They Perform by Mike Wolf at Adobe Max

Performance & UX Considerations For Successful PhoneGap Apps by Andrew Trice

Today I made a thing. The Privacy Screen Plugin.

Some backstory: both iOS (as of iOS 7) and Android have app switchers that display a screenshot of your app. This is a lovely feature for most apps, but if your app displays sensitive information, this is a possible privacy risk.

My apps using the "Zero-knowledge" JavaScript library Crypton, as well as those for my primary day-job at SpiderOak, are privacy focussed. This means that we treat data displayed in these apps as sensitive and... well... private. Therefore, I had tried many times, quite unsuccessfully, to "black out" my apps when displayed in these "app switchers" on iOS and Android.

The problem was that I was trying to do this using variations on the pause and resume events available in Cordova / PhoneGap. These events can be very handy, and I already use them for other purposes, but for this use case they don't fire fast or early enough. The screenshots of my apps were getting taken before any DOM changes I might make in the pause event occured. I had basically given up on this thinking that a cross-platform plugin to do this would be way too big of a pain.

It came up again in conversation with SpiderOak's "security guy" Tomâs Touceda, and I decided to take the plunge and see how hard it would be. I had grand plans of covering the screen with an all black native view or something. I knew how to do that in iOS, assuming I could hook into the native applicationWillResignActive or similar. The issue was Android, of course. My native Android dev skills are way weaker than my Objective-C and iOS, particularly in the area of LayoutManagers and other view stuff.

Luckily, after about 15 minutes of ye olde Googling, I found FLAG_SECURE!

Well, between that and a recent Cordova dev email thread mentioning method swizzling (omg, that term... pfah!), I had a real idea for how to get started. I also found a great StackOverflow post that suggested just hiding the window.

I don't like having to use plugins, but I really enjoy writing them, strangely. So a couple of hours later, I had a real working plugin on two platforms.

Warning: this is a pretty log post.

A few months ago, I bought a ZTE Open Firefox OS device on eBay. It was the original Open, not the apparently much nicer Open C that is available now. I wanted to have a play with Firefox OS as not only was it entirely HTML5 based, but Apache Cordova was beginning to implement support for the fledgling OS. I was pretty interested in seeing how well it worked, and the phone itself was pretty cheap for an outright phone - less than $90AUD.

Now, first up, let's make it clear that Mozilla is not targeting iOS or Android with Firefox OS. It is not intended to go head to head with those much more established mobile OS's. Mozilla is instead interested in the market the other two have almost entirely ignored. Low priced and developing countries. A Firefox OS device is not intended to replace an iPhone or the latest Samsung Galaxy device. A Firefox OS phone is much more likely to replace a "feature phone" – a dumbphone, as it were. They seem to be looking to get smartphones into the hands of people that otherwise might not be able to afford them. This is another reason I was very interested in the platform.

I mention all that as the nicest possible way of saying that my ZTE Open was not a very high end or powerful device. In some ways, it's even more low powered than my HTC Wildfire S – my slowest Android 2.3 test phone. In fact, in a lot of ways the two phones are very similar. Small screen, low powered CPU, etc.

So what did I think?

As I kinda have a soft spot for the aforementioned HTC Wildfire S, I actually liked it quite a bit. After playing with it casually for a couple days I came to the conclusion that they were doing a pretty good job at what they were trying to do. The "apps" worked nicely, and the seamless integration with "hosted" apps - i.e.: actual served web apps like Facebook Mobile and Twitter Mobile - was a real joy. Only iOS really comes this close to making a web app feel like a "real" app - removing the location bar, etc. I resolved kinda halfheartedly to try and think of an app to make for it. I didn't think I could port my current apps to it, but thought it would be fun to try to think of something more suitable.

This was all a while back when I first got the device. I came away basically feeling that I really thought Mozilla was onto something, and that if I ever found the time and an idea that might suit the power of the device I would try and make an app for it. I also kinda thought that if there ever was such a thing as a high-end Firefox OS device, that it might almost be possible to use it as a daily driver. I don't actually use as many apps as you might think an app developer would. Email, Facebook, Twitter, SpiderOak and Encryptr - gotta eat your own dogfood, after all - and that's about it. Of course there are plenty of other things I use rarely, but those main ones are my desert island needs from a smartphone. I thought that if I had a Firefox OS phone as powerful as my Nexus 4 - my main phone at the time - that I would certainly be willing to give it a go, just out of HTML5 solidarity if nothing else.

Getting serious

So fast forward to this week. I started thinking about my little orange phone again and even updated my Firefox OS simulator. Now that the Cordova CLI supports Firefox OS, I thought I'd see how hard it was to get a simple Hello World app up and running, at least on the simulator. Turns out it was so easy that it only took a couple seconds. I wanted more. Out of morbid curiosity I made a copy of my Encryptr app to really see how far I could push it. To my complete surprise, I ran the app up on the simulator and it actually mostly worked. All the primary functionality.. it worked. Wow.

So that's all well and good, but this app uses on-device JavaScript encryption. It worked in the simulator, but all that means is that the browser powering the apps was advanced enough to handle all the APIs in use by the app. Encryptr needs some power. It works great on high end Android phones, but it brings my iPhone 4 to its knees. It's something the Crypton team are working on, but I had no realistic expectation that the ZTE Open would even be able to log in before I got bored and fell asleep.

My next problem was that the ZTE Open came with Firefox OS 1.0. My version of the Firefox OS simulator and App Manager needed at least version 1.2. This left me unable to even see how bad it was without upgrading. I couldn't even run up a Hello World app. I needed to upgrade the ZTE Open. It didn't go as smoothly as I would have hoped - at one point I even had it in an endless reboot loop - but I managed to get it updated to 1.2 with instructions on Mozilla's site. Yay!

I think all this preamble is a dead giveaway for what happened next. I ran Encryptr on my little ZTE Open. It not only ran on the low end hardware, it actually ran better than it does on my iPhone 4. A lot better. It was actually useable. Could it be faster? Of course. but was my mind blown? Absolutely. No matter what else, I was impressed with Firefox OS at that point. I will also be fixing the last few issues, and around the same time as the Android release, I will be releasing Encryptr for Firefox OS.

What happened next?

At this point I am pretty fired up about Firefox OS. I remembered how I felt that if only it was on decent hardware, it would be even more amazing. I remembered that at one time it was possible to run Firefox OS on a Samsung Galaxy S2. Since I had an S2 lying around, I thought I would see if it had gotten any easier to do. It hadn't, really.. but wait... what's this? Instructions on how to install Firefox OS on a Google Nexus 4? O_o

My Nexus 4 is no longer my main phone, so it was a ripe target for being flashed with a new OS. After a little trepidation I went ahead and did it, and let me tell you, Firefox OS 1.4 on a Quad-core 1.5 GHz CPU with 2GB of RAM is a sight to behold. It's pretty much everything I had thought it would be. I am not trying to switch to it as my daily driver yet or anything, but it's only been flashed since this morning. Just going to have to keep playing with it and see, but either way, it's still pretty damn cool.

Note: don't flash a Nexus 4 with Firefox OS then use it as your test phone for development. It's as bad or worse than only ever using the simulator. Actual Firefox OS devices in the wild will not have that much grunt. Use a device like the new ZTE Open C or one of the Geeksphone developer devices. Mozilla is pretty keen to get devices to developers that are serious about porting their apps, so have a look at see if maybe you can get in on the Phones for Apps program. However, if you want to use Firefox OS as a serious replacement for an iOS or Android device, a Nexus 4 makes a fantastic Firefox OS phone. I am looking forward to seeing where it takes me. This could be the start of a beautiful new friendship.

Update: 04/2014

Another set of slides, still no decent blog posts. *sigh*

Just started seriously trying to get Appium (http://appium.io) running and functionally testing Cordova apps like Encryptr here.

I see a lot of confusion still about the difference and relationship between Cordova and PhoneGap.

TL;DR: If you don't need to use the cloud build service at PhoneGap Build, just use the Cordova CLI tools, not the PhoneGap ones.

Lemme see if I can start with the penny tour.

In the beginning, there was PhoneGap. It was an amazing project by a little company called Nitobi in Canada. It was open source, and it was good.

Then the little company and the name PhoneGap was bought by Adobe. Adobe did not buy the actual PhoneGap codebase, just the people that worked on it, and the name. The actual open source project was donated to the Apache Software Foundation.

So now the open source project needed a new name. After a couple of false starts, eventually they came up with "Cordova" – the name of the street the Nitobi offices had originally been on in Vancouver.

For a bit over a year, "PhoneGap" was just the Adobe binary distribution of the Apache open source project "Cordova" – you could think of PhoneGap as Safari to Cordova's WebKit.

Now, all of this has been better documented in a couple of other posts by smarter people. The problem lies in what's happened since then.

In version 3.x of Cordova – and therefore PhoneGap – a shift was made towards heavy use of a Node-based command line interface (CLI). It handles everything from creation of the project, installing plugins, and finally building and even running the app. It's awesome, by the way, and if you haven't made the switch away from the shackles of IDEs like Xcode and Eclipse, I heartily encourage you to give it a try.

Anyway... at the PhoneGap Day US conference, back in July of 2013 in Portland, we released the 3.0.0 version of Cordova. At the same conference, a variation of the Cordova CLI was launched called the PhoneGap CLI. The first split in actual functionality between the two had finally arrived.

The PhoneGap CLI is a similar-but-different variation on the Cordova CLI. It does much of the same things and even uses the Cordova CLI under the hood. The biggest difference lies in its connection to Adobe's cloud build service called PhoneGap Build. The PhoneGap CLI allows you to – from the command line – create and build apps using that service. You don't need the SDKs for the various platforms installed on your machine.

However, aside from some small syntax differences – and a couple missing features, if I am to be honest – the use of PhoneGap Build is the only difference at the time of this article. So as I said in the TL;DR above, my advice is that if you don't need to use the cloud build service at PhoneGap Build, just use the Cordova CLI tools, not the PhoneGap ones.

More importantly, whatever you do, do not "mix and match" in a single project. This will only make a big mess.

I know I said no more slides till I actually post a real, well... post... but I spoke at the always awesome MelbJS tonight about Crypton and thought I'd better put these slides up with the others.

Slides from my talk at the Melbourne Mobile meet up - August 20th, 2013.

We did a JavaScript UI Framework Smackdown, hehe. We had representatives from Sencha and KendoUI, and one of the other organisers took on jQuery Mobile (poor guy).

Slides from my talk at the Melbourne Mobile meet up - May 21st 2013.