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

Thu Feb 5 14:44:59 EST 2015

On Thu, Feb 5, 2015 at 8:24 PM, Matthias Wessendorf <matzew at apache.org>
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) :-)
>
> 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).
>
Yeah but as you said just above, privacy will be protected by EU Laws and
in many cases by national laws, like in France with have the CNIL (
http://www.cnil.fr/english/) which is very powerful on this area (Google
has even lost a trial against them  :) )

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

>
> 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 list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150205/e9422ac1/attachment.html 