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

Thu Feb 5 17:33:37 EST 2015

On Thu, Feb 5, 2015 at 10:51 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

>
>
> On Thu, Feb 5, 2015 at 9:57 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>  On 02/05/2015 02:24 PM, Matthias Wessendorf wrote:
>>
>> While working on the doc for AGPUSH-1258, I found this in Apple's "iOS
>> Developer Program License Agreement":
>>
>>  ...
>> Further, as a condition to using the APN, You agree not to transmit
>> sensitive personal or confidential information belonging to an individual
>> (e.g. a social security number, financial account or transactional
>> information, or any information where the individual may have a reasonable
>> expectation of secure transmission) as part of any Push Notification, and
>> You agree to comply with any applicable notice or consent requirements with
>> respect to any collection, transmission, maintenance, processing or use of
>> an end user’s personal information.
>>  ...
>>
>>  That means, if an app-developer sends something like "Your blood
>> donation appointment is tomorrow" to a user of his mobile app, the
>> app-developer is breaking the Apple terms _and_ the law in a lot of
>> countries (at least in all EU countries) :-)
>>
>> What we have to remember is that large amounts of information in
>> aggregate can become personally identifying even if any individual message
>> is not.  So the law in this case doesn't help since it is only the data in
>> context which becomes personally identifying or protected.
>>
> Good point.
>
>>
>> I don't think anyone is advocating for sending sensitive information via
>> push, but what we are advocating is not putting a big target on our (or our
>> user's) backs out of the gate by storing all of the messages by default.
>>
> Only the alert is stored (PR has been merged) . But, and this is just an
> idea that just popped  out, couldn't we encrypt the value of the alert that
> is stored? It could be by default or a config thingy ...
>

yes, I am totally fine it making this a configurable option, which needs to
be enabled, for safety reasons. Those that want it, need to enabled it.

I will work on the JIRA tickets for this, if we are all cool with this.

Greetings,
Matthias

>
>>
>
>>  BTW. for Google I don't seem to find a similar paragraph, but IMO they
>> are not that thoughtful on privacy terms (compared to Apple).
>>
>>
>>  Now, for our UPS guide (or documentation), I will add a few sentences
>> to make it clear that our app-developers should NEVER submit sensitive
>> personal or confidential information with a push.
>>
>>  Regarding a "Privacy Policy", I will also make clear what data of the
>> push we store, for analytic reasons.
>>
>>  You'll see a PR during my Friday.
>>
>>
>>
>>
>>  Greetings,
>> Matthias
>>
>>
>>
>> On Wed, Feb 4, 2015 at 2:53 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> 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
>>>
>>
>>
>>
>>  --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>> _______________________________________________
>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Summers Pittman
>> >>Phone:404 941 4698
>> >>Java is my crack.
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
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/20150205/8804d5bf/attachment-0001.html 