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

On 2015-02-05, Matthias Wessendorf wrote: > On Thu, Feb 5, 2015 at 10:51 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > > > > > > > On Thu, Feb 5, 2015 at 9:57 PM, Summers Pittman <supittma(a)redhat.com&gt; > > 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?

> > > 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(a)apache.org&gt; > >> wrote: > >> > >>> I have created AGPUSH-1257 and AGPUSH-1258 > >>> > >>> On Fri, Jan 30, 2015 at 3:22 PM, Matthias Wessendorf < matzew(a)apache.org&gt; > >>> 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@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(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev