[aerogear-dev] Storing the payload of the push notification

[Matthias Wessendorf]

I have created AGPUSH-1257 and AGPUSH-1258

On Fri, Jan 30, 2015 at 3:22 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> earlier this week there was some discussion about storing the payload of
> the push notifications ([1]).
>
> Right now, we store some metrics (e.g. client that send the push, number
> of devices, deliveryStatus etc) *and* the entire content of push
> notification. This includes custom key/value pairs, the name of the sound
> file or even the size of the badge.
>
> Is all of that, storing the entire push notification payload really
> needed? *No!*
>
> What do we need, and why?
>
> For counting the number of sent pushes (over time), the metrics are good
> enough. We do *NOT* need any of the push content for that, that's correct!
>
> But we want to do more on the 1.1.0 release. We want to introduce some
> analytic features, to give our app developers (our users) a better
> understanding of their push usage (see [2]).
>
> In order to see details on how successful a push was (or not), we need to
> only store the value of the alert key:
> https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png
>
> Ok, let's change that (see [3])!
>
> For our app developers, using the UPS to reach out to their mobile app
> users ("user engagement"), it's important to understand which push was more
> successful:
>
>    - "Get 10% discount today" (sent on a Monday)
>    - "Our shop got new site, check it out and get 5% discount" (sent on a
>    Friday)
>
> With the upcoming analytics we can help them to improve usage of their
> app. User interaction is very important to a successful mobile application
> and push is a key driver here! Our app developers want an app that is
> actively used by their users (Nobody wants his app sitting on the last page
> of the device or, even worse, in a folder together with Apple-Maps).
> Therefore it's critical for our app developers to understand the relevance
> of their push messages sent and how it impacts the usage of their app.
> That's why we do the analytics described in [2]. And, yes - only the alert,
> not the entire payload is needed for that.
> <https://gist.github.com/matzew/b6459083f39394a892c5#privacy>Privacy
>
> On the mentioned PR there was also some discussion about privacy
> violations and stuff, when we store the content of the notification. An
> example where *sensitive* data was sent over push was given. Something
> like: "Dear Mr. Joe, your blood donation appointment was scheduled for 3
> p.m"
>
>    1. This is not how push notifications are used for mobile apps. Push
>    is to signal, not carry actual (sensitive) data around.
>    2. In a lot of countries, at least almost all European countries, you
>    are not even allowed, by EU law, to give "data" to 3rd party providers
>    (like the push-networks of Microsoft, Apple or Google).
>
> How does the actual (sensitive) data come to an app?
>
> As said above a push is used to signal/ping an app, to indicate that there
> is real data for the mobile app user. In the background the mobile app
> tries to connect to the backend of the company, running/maintaining the
> mobile app. After the real data was fetched, "local notifcations" are used
> to give the user a visible notification, like "Dear Mr. Joe, your blood
> donation appointment was scheduled for 3 p.m", or simply "New appointment
> scheduled".
>
> If the app was a chat system (and not a blood donation app from the Red
> Cross), it would be the same: After a signal, the app connects to "chat
> server" and receives the actual chat message from there. A reply would go
> over the same "chat server" connection. None of this would go over a 3rd
> party push network provider like Google, Microsoft or Apple.
>
> What would we store from these silent notifications?
>
> Nothing, since there is no alert, we would just store the metrics (e.g.
> client that send the push, number of devices, deliveryStatus etc). If the
> signaling is actually done with an alert (e.g. alert:"you got a new Chat
> text" or "New appointment scheduled"), we would store that.
>
> I hope this helps a bit to understand what is stored and also why we do
> need a little bit of information.
>
> BTW. our documentation already says that push is used for signaling, not
> carrying actual data around, but based on this email I will update it to
> have explicit information on best practices. Also, the documentation will
> be clear about what (the alert only) is stored by the UPS, and why. (see
> [4])
>
> Greetings,
>
> Matthias
>
>    - [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/478
>    - [2] https://issues.jboss.org/browse/AGPUSH-971
>    - [3] JIRA TO CREATE: to only store ALERT and not the full payload
>    - [4] JIRA TO CREATE: update doc regarding push message storage and
>    best practices
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150204/b440fe37/attachment-0001.html