ubuntu-push-devs team mailing list archive

[John Lenton <john.lenton@xxxxxxxxxxxxx>]

On Tue, Aug 6, 2013 at 7:10 PM, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> wrote:
>
>> 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!

just in case: this is at the transport level, not at the message level.

> 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.

yes. The app server needs to auth to the push server using a per-app
token, and each message needs to be signed with a per-bucket token
(per-user-per-app), and the app needs to auth to it too (via the
client-side daemon) using a per-user-per-app token. I'll be adding
something overly simplistic today; would be interested in knowing what
things we could do in that space. (note none of this is done yet)
(note also i seem to have lost half of today already, doing nothing of
use).

The app needs to get the per-bucket token to the app server; currently
the plan is that we let the app do it directly (they'd need network
access, but I'm struggling to think of a scenario for an app that will
want notifications that will not also want full network access). I'd
appreciate your input on this too.

> 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.

well. I'm not sure if there's a way to avoid app Foo from popping up
notifications with app Bar's icon, right now. Is that what you mean?

At the notifications level, the app receiving the notification would
be dictated by the token the app server used to shove it in.

> 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.

no email addresses. The app server, however, has me nervous.