OpenPush
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47514 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Android (robot)Software frameworkFreewareOpen sourceSoftware developerCore dumpSoftware maintenanceContent (media)Server (computing)Client (computing)OvalFood energyLibrary (computing)GoogolPoint cloudComputing platformService-oriented architectureMessage passingMobile appArmAbsolute valueCartesian coordinate systemDifferent (Kate Ryan album)Fiber bundleLibrary (computing)FreewareConnected spaceClient (computing)Message passingWeb serviceMobile appSoftware developerMatrix (mathematics)Service-oriented architectureSystem callInformationNumberWriting1 (number)GoogolMereologyServer (computing)Multiplication signWordData conversionView (database)Online chatPoint (geometry)Goodness of fitMultiplicationSoftwarePoint cloudSoftware maintenanceCollisionState observerContent (media)Condition numberOpen setAndroid (robot)Instance (computer science)MultilaterationKey (cryptography)Mobile WebInternettelefonieWeb 2.0Online helpInstant MessagingCore dumpComputer animation
05:32
System programmingMessage passingSoftware developerService-oriented architectureInstance (computer science)Distribution (mathematics)Computing platformCommunications protocolMusical ensembleTask (computing)Client (computing)MereologyLibrary (computing)Server (computing)Open sourceControl flowMobile appGoogolService-oriented architectureKey (cryptography)PressureUltraviolet photoelectron spectroscopyOnline helpTraffic reportingInstance (computer science)Mobile appClient (computing)Musical ensembleCommunications protocolGoogolExterior algebraPhysical systemSoftware developerConnected spaceArmSmartphoneCASE <Informatik>Bit rateServer (computing)Game controllerComputer architectureSoftwarePoint cloudTask (computing)MetadataMessage passingComputer animation
08:25
Computer architectureMobile appServer (computing)Client (computing)Image registrationToken ringMessage passingToken ringWeb serviceOpen setMobile appService-oriented architectureMereologyWeb 2.0Server (computing)Client (computing)Computer architectureAuthenticationMatching (graph theory)Endliche ModelltheorieImage registrationLatent heatProjective planeConnected spaceData storage deviceArmDependent and independent variablesInstance (computer science)State observerSelf-organizationAndroid (robot)Computer animation
10:37
Computer architectureServer (computing)Connected spaceServer (computing)Token ringClient (computing)Latent heatCopyright infringementMathematicsState observerPhysical systemMereologyMobile appOpen setProgram flowchart
12:09
Server (computing)ImplementationAndroid (robot)Client (computing)Library (computing)DisintegrationSystem programmingEvent horizonCommunications protocolPhysical systemMechanism designInterprozesskommunikationService-oriented architectureCorrespondence (mathematics)Android (robot)Open setServer (computing)Arithmetic progressionOpen sourceFreewareImplementationMobile appClient (computing)InterprozesskommunikationSoftwareConnected spaceMereologyExterior algebraAxiom of choicePhysical systemCommunications protocolPrototypeLatent heatMathematicsNP-hardMessage passingDifferent (Kate Ryan album)Library (computing)Formal languageInformation privacyBroadcasting (networking)Event horizonComputer configurationBit rateArmForcing (mathematics)Computer programmingQuicksortSineHTTP cookieWebsiteGoogolMultiplication signPoint (geometry)Video gameComputing platformRight angleComputer animation
16:27
DisintegrationClient (computing)Server (computing)Matrix (mathematics)System programmingMobile appClient (computing)Operator (mathematics)Transportation theory (mathematics)Physical systemSoftwareIdentity managementMatrix (mathematics)Condition numberServer (computing)Connected spaceDifferent (Kate Ryan album)Library (computing)CASE <Informatik>Web serviceMessage passingContent (media)Mobile appService-oriented architectureWordEncryptionInternet service providerPlug-in (computing)ArmFerry CorstenMachine visionEvent horizonMultiplication signInverter (logic gate)GoogolRow (database)Moment (mathematics)Online chatEngineering physicsComputer animation
19:16
PrototypeInformationGraphic designPublic key certificatePhysical systemMultiplication signMusical ensembleService-oriented architectureDesign by contractConnected spaceGoogolAndroid (robot)NumberAverageRight angleTask (computing)ArmMeasurementBenchmarkMobile appRevision controlLevel (video gaming)Internet service providerProcess (computing)CASE <Informatik>Presentation of a groupBlogData storage deviceVideo gameProjective planePrototypeArithmetic meanCentralizer and normalizerImplementationInformationDomain nameComputer configurationoutputPlastikkarteDifferent (Kate Ryan album)In-System-ProgrammierungBlock (periodic table)RobotDistribution (mathematics)Web 2.0Server (computing)Client (computing)Computer animation
25:59
FacebookPoint cloudOpen source
Transcript: English(auto-generated)
00:14
Hi. Thanks for coming to my talk. Who of you is only here for the matrix talk afterwards?
00:24
Don't worry, I'll be talking about matrix a bit as well. So hi, I'm Markus. I'm a free software developer from Berlin. I've been working on the free Android ecosystem for the last two or three years. What does it mean? It means I'm using an Android phone but without
00:43
any Google services or Google Play Store. And I want to make that a more pleasant experience. So I'm an Android core contributor and app maintainer for a while. So who of you here is using an Android phone? Oh, wow. And who of you is using the Google Play Store or apps
01:07
from the Google Play Store? About half or something like that. Yeah, so that's what I'm trying to improve. So push notifications. They turn out to be one of the key missing
01:25
pieces for free Android apps, apps that want to be published on Android. Because currently there's, if you Google how to do push notifications to Android, you get that, yeah, use
01:41
those Google servers. Get into that later. So push notifications are when a server, a web app, web service sends unsolicited content to an app on your phone. That is without the app specifically asking for, give me this update. It's also used for marketing purposes
02:03
by proprietary apps a lot. So all of those newspaper, CNN, whatever app they send to, not really helpful push notifications a lot of the time. But it's also like a requirement for doing instant messaging or voice over IP apps on your phone because it's really no use
02:26
if somebody calls you and your phone tells you half an hour later, oh, you got a call. So we need push notifications. So how do you send information from a server to a client
02:42
without the client asking for it? Well, we cheat. We ask beforehand, give me new information at some point later so we keep an open connection, which the server then can use to send those updates to the client. The problem is keeping a connection open does
03:03
require maintenance of those connections. And that means battery power on mobile. Even more so under varying network conditions, flaky Wi-Fi, flaky GSM network.
03:20
So that means in turn that keeping it one connection open for every app on your phone that wants to receive push notifications to every one of their different web services. Well, that works, but it's going to drain your battery really, really fast. That's why Google introduced, well, Google Cloud Messaging and later Firebase Cloud Messaging,
03:45
which bundles all those push notifications into one connection, which goes to Google service. So your phone is connecting to the Firebase service, which is just for receiving push notifications and all those web services send their push notifications to Google service,
04:06
which then forwards it to your device. That has a number of drawbacks. For once, it requires Google Play services being present on the device, which is the non-free part of Android. It also requires every app that wants to register for push notifications to include
04:27
a proprietary library distributed by Google. So that actually means when you get free or apps you thought you were free on the Google Play service, which do Google Cloud Messaging,
04:44
they're not actually free software because they include a proprietary library or multiple ones. Well, that means all your push messages are sent through Google service. Your FOSS apps aren't actually FOSS anymore. That includes Riot, Conversations, Firefox,
05:07
Jami, Next Cloud, Rocket Chat, if you get them from the Google Play service, from the Google Play Store. And there's also one other key drawback because, well,
05:22
Matrix and XMPP and Rocket Chat and Next Cloud are decentralized by design, so you can host your own instance or you can use instances of other people. But when the developers of the app build the APK of that app, they register for the Google Cloud Messaging service,
05:44
and they get a key from Google to send those push notifications through those Google service to your device. And that key is tied to the APK. And you can't make it public because otherwise Google will just block it. So now you have to send your push, receive
06:01
your push messages through two hops. From your own Next Cloud instance, you send a push notification to a server hosted by the Next Cloud app developers who forwards it to Google Cloud Messaging, who forwards it to your device. So now for an actually decentralized systems, you introduce two centralized hops, which is not good. Or the alternative to that
06:28
would be if you host the Next Cloud instance, you have to distribute your own APKs of the Next Cloud apps, which works but is a real hassle. So what are the alternatives if you
06:42
don't want to use Firebase Cloud Messaging? Well, everybody builds their own more or less reliable solutions. Some protocols can do it better than others, like XMPP. They can do in-band push notifications because they have a persistent connection anyway that works reasonably well. But Android makes it quite hard to run background tasks. So it's a struggle,
07:09
and the battery life is still horrible if you have all the different apps with all their persistent connections. So what do we want to do differently? Well, first of all, it's going to
07:27
be decentralized, because we want people to run their own instances. And then we want users to be in control, which means the user of a smartphone can choose the push server instance they want to register with. They trust to handle their data and metadata.
07:48
And this push server instance is then communicated to all the different servers for corresponding to all the different apps on their phones. And we can also do away with this developer key requirement because it's actually only used
08:08
for accounting by Google. And as we want to be accountable to the user, not to app developers, we don't actually need APK to push account pairing, so you don't need this intermediary hub.
08:27
So how does the architecture of this look like? Well, we have Android apps on your phone installed by user. They want to receive push notifications, and they talk to some web service which notifies
08:42
them or which they want to receive notifications from. The web service, it receives, well, when the app registers for push notifications, it gets a token. It's called push token. It sends this to the web service, and the web service saves this push token.
09:05
And whenever it wants to send a push notification to one specific app instance, it uses that push token as authentication. The web services sends this push notification through the push server,
09:21
which is part of the Open Push project. So the push server has an API for the push client, which we'll come to in a second, to register for push notifications. It generates those push tokens
09:40
and stores the matching of a phone or a push client to the push token. And then it provides the API to the server, to the web services for receiving incoming pushes, and then it forwards them to the push client. The push client in this model is an app running on
10:05
your Android phone. It handles the registrations for pushes by other apps. It registers with the push service. It's the part where you can choose which push server to use,
10:23
and it's responsible for keeping the open connection to the push server. And whenever it receives a push notification, it distributes it to the other apps which have previously registered with it. So how does it look on a picture? So the green parts are the things
10:45
from the Open Push project, and the red parts are basically the users of this system. So this is your phone. These are the apps on your phone, and these, every app talks to one server. So when you install an app, it registers to the push client on your phone,
11:11
asks it for a push token. The push client registers with the push server. The server generates a token, sends it to the client, sends it to the app, which then sends to
11:24
the app server. And when the app server then generates a push notification, it sends it the other way around to the push server, which sends it to the push client on your
11:43
phone, which forwards it to the app on your phone. This connection here from the push client of the push server is the one that is kept alive by your phone. And so when you receive a push notification from it, it wakes up the app, and the app then
12:02
can then talk to the app server again and get more information or whatever. So that's the current status. There is the open API specification of the server part. That's
12:20
roughly done, probably pending a few changes as we go along. There's this corresponding server implementation in Python, which is kind of meant as a prototype for seeing if this whole thing is viable. It's relatively thin, so implementing the same API in a different
12:42
language would not be that hard. Then there's an Android client implementation, which is still a work in progress. Android is not, or especially Android IPC talking, different apps talking to each other is not the easiest to work with my phone, so
13:01
this is still ongoing. And then there's the corresponding client library, which other apps would use to register for push notifications on your phone. This is developed alongside the Android push client. It's also still a work in progress. And then when we have the
13:21
system, we need to, of course, integrate it in other communication platforms, systems. And well, this is to do for after the client implementation are finished. So how does it work in more detail? The connection between the push client and the push server
13:46
is currently using server sent events, which has been tried out for custom built push notifications on Android. Server sent events are part of HTTP following a very simple text-based protocol, which you can send on JSON blobs over. It's really simple. It works reasonably
14:07
well in first tests, but the choice of the protocol is deliberately transparent to all users of the system. So we can experiment with having a different transport protocol
14:21
later on without impacting any third-party implementations. The push client is currently a standalone Android app. It's possible to integrate it maybe in MicroG later on. If people don't know what MicroG is, MicroG is an open source implementation of the
14:42
Google Play services on your phone, which does allow you to use Google Cloud Messaging without using Google Play services on your phone. But it's still using Google servers and still requiring the proprietary app library, so it's not a very good solution for after from a privacy standpoint, or from a free software standpoint. But MicroG is already integrated
15:07
in some Android ROM builds, so having this integrated in MicroG would maybe make sense in the future. And I said earlier that it's getting pretty tricky, hard to keep background
15:23
connections alive or doing any kind of background work on Android. So for this, I choose the easy option, which is running a foreground service, which has a persistent notification for the user, which you can hide, but this is, I think, this is okay for when
15:47
it's one app that does it, and it gets annoying when 20 different apps do it. The alternative would be running it as a system service like MicroG does currently, then you have the same permissions as running as a foreground service without needing the notification.
16:06
And the client library communicates with the push client via Android IPC that's using a bound service, and then for incoming push it sends targeted broadcast events. This is basically modeled after what Google does for their own push messaging. So where do
16:30
we go from here? Well, we need to integrate it in, for example, Matrix clients and servers RocketChat, Next Cloud, and see how it performs in practice under interesting network conditions.
16:47
It's going to be interesting. One thing I've thought about is adding end-to-end encryption. End-to-end encryption in this case would mean from the web service to your phone, the message being encrypted, so operators of push services are not, so for them it's
17:07
possible to read the content of the messages. They'd still get all the metadata, but that's what Google gets at the moment as well. But actually we already have less metadata
17:20
than Google because apps register with Google Cloud Messaging with their identity as an app, and OpenPush doesn't do that, so you would just, the operator of the push server would just see there's a message, then it would also be encrypted in the future. So there's
17:42
less metadata. And I don't think it would be that hard to add famous last words because we're only sending unidirectional messages and we don't want to keep any history, so it's just encrypt one with a key the client can use to decrypt it. I also want to experiment with different transports and service end events, just that goes hand-in-hand to seeing
18:05
how it works in practice with actual networks. And one other interesting thing that came up is having existing systems be the push provider for your phone. So if you're already
18:22
running an XMPP client on your phone, you already have this persistent connection to your XMPP server because that's how XMPP works. So why couldn't we use this connection and just implement the push server API on your XMPP server as a plugin and include
18:41
a library in your XMPP client that would allow other apps to register for push notifications using the same APIs? And then, well, you have one less connection and hopefully a longer battery life. The interesting thing about that is then how to figure out if the user
19:02
has multiple apps installed that could act as a push provider, which one gets selected and secure, tricky user experience to figure out. I think that's it. This project, I've
19:25
been working on it since, but there's a series of prototypes. And you can find more information on this website. Thank you. Thank you for your talk. We have time for, we have
19:44
about five minutes for questions. Hi, thanks for the talk. I would think the number one worry that I would have is that you won't get away forever with the four service you said another option would be being I mean the the thing you
20:01
technically would want to be is a system system app right so you wouldn't have that problem I'm not sure whether are you worried as well there's no way to become a system app right so what can you yeah I don't didn't get the exact question ah the yeah I'd be I know right now the solution for you
20:25
service and and you get the annoying notification if you don't configure it away but but I but I'd be worried as Android is becoming more and more restrictive with background tasks that you know two versions of Android from here you might this might might no longer be the solution so if I would
20:44
have thought that's the main worry that you will one day fail at keeping alive in the background and providing a push service yes so I think the only solution to that is being integrated on a system level which either means custom ROMs and people figuring out how to pseudo move some APK surround but more
21:06
ideally it would mean that actually phone when this would distribute non Google Android phones which we are severely lacking right now I wanted to
21:25
ask it's by the way it's great presentation and thank you thank you I wonder how easy it would be for Google to make your solution possible to use on Android again yeah how how easy would it be for Google to make your solution impossible to use on Android well we if say block foreground
21:52
services running forever that's Ben makes it somewhat impossible if you depend on the stock Android from a bot in the store they can still be
22:08
workarounds for doing smart things with checking in every 15 minutes however often you allowed but they they only can do things through the
22:23
normal Android distribution if you're not using any Google Play services and you're not getting your apps from the Google Play Store they they can't really enforce any anyone not using this system through other means there's the web API for push notifications have you thought about using the same
22:43
API for the push server connection I haven't really looked into web push which I think is partly because it's a different problem domain because on
23:02
desktop you can get away with a lot less battery saving solutions so what this is modeled after is Google's solution for push measures only decentralized and free because well they have thought about this probably a long
23:23
time I once heard that that mobile ISPs have special contracts with push service providers like like Google Apple that via TCP connections are not terminated relatively quickly like all the others so have you done any any
23:45
measurements any benchmarks on how yeah on how efficient your services how often do do connections get terminated and is this different from the Google implementation I've not yet done any measurements at least not was this I've
24:05
heard this quite often as well I have never seen or heard anyone actually providing any data to back this up so I consider this a rumor to now it might
24:22
be different in the US I don't think it's the case it's yep let's do I'd be happy to hear input for that so how does the push client here so how
24:42
does the push client check for broken connections because I tried to do something similar a few months ago using Autobahn and crossbar and all that as well running as a foreground service in Android and ultimately I had to send these pings after every few minutes just to make sure the
25:01
connection was alive and the Android would complain that it's killing the battery so the user would end up uninstalling that so that was my biggest fear so have you found a solution for that no well the solution is check every X minutes where you can be a bit smart about how big X is I
25:23
don't think Android would complain more than well this notification you get with foreground service as well it's a bit well on Android you can hide notifications by long pressing on them if you do that with a foreground service that is still running you get another notification by the system which actually tells you this app is killing your battery user education is the
25:45
solution for this right now this is how we we can work okay thank you very much we are running out of time