Push Topics: Security
Posted by Dave
Note: This post is part of a series on the Deacon Blog that will address topics in implementing Push Notification systems. Naturally, this coverage is oriented toward the Deacon Project, but the topics and issues discussed are often widely applicable.
"Software security" - it's been a hot topic in the mobile phone world (or at least my feed reader) lately, what with multiple iPad and iPhone related security snafus at AT&T, and the release of the first major-label security software for Android phones by Norton/Symantec. With lots at stake in the mobile world - sensitive little things like GPS locations, contact lists and phone records - security should be a consideration in any mobile computing endeavor. Push notifications are certainly no exception.
Introduction
Bass, Clements and Kazman define a system's security as it's "ability to resist unauthorized usage while still providing its services to legitimate users." [1] We can decompose this requirement into two equally-important areas: determining which users are "legitimate", and restricting access to only those users. In push notification systems (and those based on Meteor in particular), there are also two types of users: push subscribers (those that receive notifications) and channel controllers (those that send notifications). Last in the rundown of areas to consider comes data transport: push notifications can traverse untrusted networks as they are generated, sent and received.
But before we dive into the security mechanisms that can be used with Deacon and Meteor, there's something important to keep in mind. For efficiency's sake, remember that push notifications should be as small as possible to minimize the load on the server. This is Google's advice when using Android's C2DM system; a notification's payload should only contain a "tickler" for the receiving app (such as an ID number or URL), which should then handle subsequent retrievals or processing after it receives the push. To enforce this behavior, Google limits C2DM payloads to 1024 Bytes - no such limit exists in Deacon, but it's still a good idea to follow the "tickler" approach.
So what can be done to secure push notification systems? It boils down to three relatively-simple practices: don't accept subscriptions from unauthorized users, use secure connections for channel controllers, and don't send data payloads that require secure transport. We'll take a look at all three after the jump...
Progress: Battery Life Testing
Posted by Dave
As a runner, I know a thing or two about milestones. Whether it's watching the mile-markers tick by during a race, or just topping that pesky hill climb on a weekday jog, there's something about crossing landmarks that's encouraging. It makes you want to run that much harder...
In the marathon of software development, Deacon has been passing some exciting milestones this past week. For one thing, we've got our own Meteor test server set up, complete with a customized configuration and message format. Thanks to that achievement, we've been able to start testing with feed sources that are a little more controlled than the Meteor Demo Server!
Setting up our own feed server enables something important from the Deacon Roadmap - battery life impact testing. While some preliminary tests by Deacon contributor Faisal Abid (using the high-bandwidth "shooting star" stream from Meteor) had us a little nervous, today offered some very promising results. We set up Deacon in a test app, running on a Motorola Droid, receiving one push notification per minute from the test server - and in three hours of continuous operation, the app didn't move the battery meter, or even appear on the handset's "Battery Use" screen. After almost seven hours of cumulative operation, Android reports that the Deacon test consumed about 2% of the battery's capacity power used since the handset was unplugged - not bad for a message a minute, with hardly any use and no telephone activity!
While our initial battery testing is about as scientific as it is precise (which is "not very"), it at least gives us a rough idea of how much energy Deacon consumes - and we still have plenty of room for optimization. For now, we'll keep working toward Deacon's alpha release having put to rest any concerns that long-held TCP connections will drain too many precious milliamp-hours!
(Both of the screenshots above were taken from the Droid that ran the test, just after it was plugged back into the system in debug mode. The test started at 11:30AM and ran [almost] continuously.)
Push on Android: A Rundown
Posted by Dave
While we at the Deacon Project like to think we're breaking some new Android ground in releasing our push client, we're definitely not the first folks to attempt such a feat. There has been lots of talk and lots of action elsewhere, and this post is an endeavor to pull together what we know of so far. In the future, I'll likely put up a page that sums up the different methods and tools for providing push notifications to Android devices...