Friday, February 12, 2016

Fastboot Mobile Announces The Future of Push Services

ownpushio

XDA’s official development partner, Fastboot Mobile, has announced a new open source push service as an alternative to Google Cloud Messaging (GCM). Their service offers improved control, security and substantially increased reach as a result of GCM being only compatible with devices featuring Google Mobile Services, leaving a billion users left out. The new service, dubbed OwnPush, forces end-to-end encryption for messages sent, and allows for increased privacy as your messages do not go through Google (unlike GCM) and uses seamless encryption straight through from the developer’s server to the end device. This means that Fastboot, and anyone else for that matter, can’t see or in any way access your push messages.

To aid in implementing OwnPush in your applications, Fastboot will be providing libraries for major backend platforms to help with handling the encryption and signing process. The service allows push messages to be delivered to any device running Android, and works on both WiFi and mobile data. As a result of their efforts they have developed one of the first steps towards creating a version of Android significantly less dependent on Google and as another added benefit has been shown to use significantly less battery life than GCM.
ownPush_High_Level 

The following is comparitive data from a Nexus 9, showing CPU usage over 20 hours when running OwnPush compared to Google Services.

AxPNJfzl sKxib3pl

CPU activity over the same 20 hour period while running OwnPush  uSfvhxll

The Fastboot mobile team recently took to Reddit to answer many of your questions.

Q: I want something that I can completely self-host on my own server. Is that what this is going to be?

A: Maybe. I’ll explain the challenge – the tl;dr is power consumption.

That was what I wanted when I designed the original specification. I’m a huge believer in self-hosting being an option (at the very least) – we don’t believe you should have to trust or rely anyone else. That’s why it’s designed so the push service provider doesn’t see messages or details. Unfortunately, power consumption is directly affected by the number of different connections held open at once. If you have 8 apps using OwnPush, that’s 8 separate connections to 8 servers, each needing managed.

The efficiency gains from push don’t scale so nicely doing that, from tests. Nonetheless, as an open source client library should let you do what you want. If there’s enough people interested, I’m sure it’s easy enough to allow a custom server in the design – obviously that only works with your own apps, since the developer server needs to know to send the messages to your server, and there will be higher power consumption.

Q: The second I can get my phones SMS’s pushed from and to my desktop clients on a self-hosted open source client/server I’m finally able to use push like apps, I don’t trust third party servers, I shouldn’t have to.

A: I’m like you :) I don’t use “push” or “cloud”. In fact I don’t use Google services. And this is the goal/vision. A future where you trust no third party. Right now we designed the current implementation to use our push server, but there will be some way to use your own for applications you make yourself. The specifics just need to be worked out (this approach will use more power). What we have shown here is the underlying technology platform for a fully Google-free platform to give push functionality to developers. With this, you can basically plug push into an app, in almost the same way you’d do it for Google push.

It’s straightforward, and means you don’t need to trust anyone else – your server (as the application developer) sends a message, and your app receives it. It’s secure and encrypted from before it leaves your server, until it reaches your app. Nobody in the middle can get at it. The next step for what you want is to adapt this, so your phone sends a push message your browser receives. And that’s mostly a few small tweaks, and development of the software on the browser.

The use-case you mentioned is one we are already considering to make. It’s just a case of finding out how many people want it, and working out how to make it happen. One of the big challenges is ensuring enough people will use it. We also need to work out a sustainable way to ensure development goes forward.

Q: I saw no releases so I assume it’s a WIP?

A: The intention isn’t to provide a finished app – we have an open source library you can “drop in” to get secure push capabilities in your app. What you describe above is something that would likely be done as an application of it. It’s one I’ve already started to evaluate.

Q: Either way, thank you for making it open source

A: It’s really the only way! Secure software isn’t trustworthy unless it’s open source. We want to make a viable, sustainable alternative to the current closed-off culture of today’s services frameworks. Making things open is our first step, and ensuring they’re developed long into the future is the second step

Q: It’s all very much clearer now, and I can see your head is on straight, you have thought about ensuring development

A: Thanks :) I like to bring together the commercial and technical aspects and ensure they all fit together. There’s so many unmaintained libraries out there, and everyone is fearful of a service being the next Google Reader or Parse, and disappearing. That’s why it’s incredibly important that independent solutions don’t die out from a lack of planning beforehand. Ideally a few small and medium businesses would want this, and that provides a stable way to keep development ongoing, and to improve it, and resolve issues. The only thing worse than no open source library is a buggy and unmaintained one.

Q: I personally wouldn’t mind paying as long as the price isn’t insane or a rolling cost, if I provide the hosting myself

A: Indeed – I feel this is the natural best starting point – I’m not a fan of rolling cost for anything that isn’t based upon some ongoing service provision, or something similar that’s directly costing you to provide each month. There’s also no point in insane pricing – it’s better to sell a million widgets for a dollar, rather than 500 widgets for $50. Advertising isn’t a sustainable development model, and nor is anything based on “making a price out of users” – it’s basically selling out on the whole principle of privacy and not requiring trust.

Q: Realizing that you need a bit of market penetration for it to work and finally your ideas on security, open source is the best way, by far!

A: Indeed. The best can happen when we have adoption. It finds bugs, improves stability, and actually will give more benefit. As a community we are hugely dependent upon a single entity providing almost all the services we use, and with a bit of adoption and interest, we can improve things.

And thanks – there simply is no other way. If it isn’t open to inspect and tweak, it’s not worth making. It’s also a good way to share secure design techniques with other developers, and let them see how we implemented things – if the future is zero trust, we have to start somewhere, and a lot of challenge is to prove to others it can be done, and that it doesn’t mean a life resigned to eating Ramen for eternity.

Q: I wish you best of luck and that I in the near, medium or distant future can push SMS:s between my desktops and my phone without any third party servers in a secure manner

A: Thanks! I am fairly confident this will happen. Not least because I want it, and I’m confident someone will do it anyway. A successful platform is what spurs on innovation and new apps, and I suspect this will be one of the first ones.

Q: If I had more/better words of encouragement for you I’d totally throw them in now, but I lack the words, so I can only wish you success!

A: And right now that’s what is needed the most, I believe. Informing people and spreading the word, and simply hoping we can make a difference to the sorry state of things today. Thanks

Q: I don’t understand the purpose of this app, can’t you just send an encrypted GCM?

A: Not only for people who don’t just want to rely on GCM forever, but also for those who at least would want better battery performance. In addition, there are plenty of people out there who are unable to use Google Services, so something that is more efficient than GCM and able to be used with/without Google Services is a huge selling point for developers.

Q: GCM is baked into android. They are able to get some great battery life that way. Wouldn’t my app now need a full time running service to receive a push? Instead of Androids already running GCM service?

A: You don’t need to directly run a service. We have a very small app that only needs installed once on the device, and your app talks to it. Our helper app runs the service and handles the messages to the server. That’s the one whose power consumption was highlighted in the post.

Of course you could do that, since it’s open source and everything, but you’d have to handle the sockets yourself, and any other apps also doing this would have to do the same.

We don’t need baked in, we can get the really low power consumption due to a very efficient push implementation without all the added bloat of GCM.We considered it essential the process of conversion would be easy, and something that will be documented and explained is the exact changes to make to the app. It’s really pretty straightforward to add :)

 

Visit the OwnPush thread



source: xdadevelopers

0 comments :