ubuntu-push-devs team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxx>]

On 2013-08-06 12:44:02, John Lenton wrote:
> Hello all!
> 
> So, push notifications.

Hello - thanks for summarizing your ideas for push notifications!

I've given it some thought since we spoke yesterday and had some
security-related notes that I wanted to mention. This stuff is all
somewhat obvious, but the architecture of push notifications has a very
large attack surface and single point of failure (the server) that could
be used to affect all users.

There are potentially malicious/infected app writers, potential attacks
on the server, and the client needs to be paranoid enough that it
*barely* trusts what it receives from the server in case any links in
the trust chain are broken. None of this should be too difficult to
protect against since you're still in the early design stages.

> We want to have a push notifications story that does a bunch of neat stuff:
> 
>  * very low power consumption on the client
>  * end-to-end encrypted

Oh, nice!

End-to-end authentication is also needed and there needs to be checks to
make sure that the authenticated notifications from the app writers
don't contain anything unexpected.

For example, one app writer shouldn't be able to spoof notifications of
another app writer. Maybe the app writer is malicious or maybe his web
server was compromised. Either way, a sound board app writer shouldn't
be able to spoof Facebook notifications.

Also, we don't want to let just anyone poke at the server. For example,
someone shouldn't be able to craft a notification from an app writer
that is targeted towards a specific user, send it to the server, and
then get *any* useful information back (even from error codes/messages)
about that user. We don't want our server to be used as a one-stop-shop
to query whether a given email address is registered for a bunch of
different services/websites.

>  * smart (locale-aware) client-side message handling to avoid waking
> apps up for notifications that don't need it
>  * have a preferences app (possibly synced to the server) to select
> which apps get notified and how
>  * have multiple "modes" (at-most-once, at-least-once,
> once-and-only-once, only-on-tuesdays*, etc)
>  * use operator-provided backend services when available and useful
> 
> After several ongoing discussions with different people,
> 
> Phase -1: exploratory work
> 
> I'm currently throwing together disposable code to get all the bits
> up, conceptually at least: a server-side daemon, a client-side daemon,
> an client app, and a app server. All python, exploratory code. This
> will let us quickly (before end-of-week, if all goes well) test the
> ideas behind v0 of the API with running code. It will also set the v0
> API in stone once we've decided it's done.
> 
> I expect that setting-in-stone to happen by end of next week, which
> would kick off the next phase.
> 
> Phase 0: version 0
> 
> Version zero of the API will only support a single message type
> (at-most-once), there'll be no preferences, and the app will be
> notified (i.e. woken or started up) for every message. It's the
> exploratory work, but done by actual engineers and with things like
> tests and QA.
> 
> The server side will be in Go (probably), the client-side daemon in
> C/C++, there'll be a QML component that app devs can use to get access
> to the functionality (maybe but not necessarily covering the basic
> "translate and show the message" use case already).
> 
> The expectation is that we will have very few apps actually using this
> version of the API, because people will only start using the API once
> v0 is out there, hence why waking the app every time isn't too much of
> a concern.

I'm glad to hear that you expect v0 to mainly be a way to publicize the
API.

Allowing someone to send me an email, tweet, facebook message, linkedin
message, etc., and almost instantaneously launch applications on my
phone at any given time could be bad. My battery life and/or whatever
I'm currently doing on my phone may be negatively impacted by that. 

But, I understand that we've got to start somewhere and, from what I
understand, v1 should fully solve this problem.

Tyler

Attachment: signature.asc
Description: Digital signature