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

Fri Feb 6 06:39:41 EST 2015

On Fri, Feb 6, 2015 at 11:54 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2015-02-05, Matthias Wessendorf wrote:
> > 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.
>
> So the decision of storing messages is up to the admin?
>

Good point, let's have that option to store the alert or not on the "Create
Application screen" (default would be disabled).
That way the app-developer company can decided per Push App if that is
needed or not.

- Something like the "Blood donation" app does not need it, since  push is
used as signalling here to fetch the 'sensitive" data from the
app-developers own backend.
(Does not make sense to have analytics for a gazillion pushes that are all
"New appointment", or similar)
- Something like the mobile app for BBC may find it useful to see if a push
like "Breaking news: New iPhone presented" was well received, or not.
- Similar to an app of a shopping website, may find it also useful to see
if a push was successful or not (e.g. "10% discount", on a Monday - versus
- "5% discount", on a Friday).

These are the classic examples why we do nee the analytics from the often
given JIRA.

>
> >
> >
> > 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
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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/20150206/3ac66375/attachment-0001.html 