<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 11:54 AM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2015-02-05, Matthias Wessendorf wrote:<br>
> On Thu, Feb 5, 2015 at 10:51 PM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>><br>
> wrote:<br>
><br>
> ><br>
> ><br>
> > On Thu, Feb 5, 2015 at 9:57 PM, Summers Pittman <<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>><br>
> > wrote:<br>
> ><br>
> >> On 02/05/2015 02:24 PM, Matthias Wessendorf wrote:<br>
> >><br>
> >> While working on the doc for AGPUSH-1258, I found this in Apple's "iOS<br>
> >> Developer Program License Agreement":<br>
> >><br>
> >> ...<br>
> >> Further, as a condition to using the APN, You agree not to transmit<br>
> >> sensitive personal or confidential information belonging to an individual<br>
> >> (e.g. a social security number, financial account or transactional<br>
> >> information, or any information where the individual may have a reasonable<br>
> >> expectation of secure transmission) as part of any Push Notification, and<br>
> >> You agree to comply with any applicable notice or consent requirements with<br>
> >> respect to any collection, transmission, maintenance, processing or use of<br>
> >> an end user’s personal information.<br>
> >> ...<br>
> >><br>
> >> That means, if an app-developer sends something like "Your blood<br>
> >> donation appointment is tomorrow" to a user of his mobile app, the<br>
> >> app-developer is breaking the Apple terms _and_ the law in a lot of<br>
> >> countries (at least in all EU countries) :-)<br>
> >><br>
> >> What we have to remember is that large amounts of information in<br>
> >> aggregate can become personally identifying even if any individual message<br>
> >> is not. So the law in this case doesn't help since it is only the data in<br>
> >> context which becomes personally identifying or protected.<br>
> >><br>
> > Good point.<br>
> ><br>
> >><br>
> >> I don't think anyone is advocating for sending sensitive information via<br>
> >> push, but what we are advocating is not putting a big target on our (or our<br>
> >> user's) backs out of the gate by storing all of the messages by default.<br>
> >><br>
> > Only the alert is stored (PR has been merged) . But, and this is just an<br>
> > idea that just popped out, couldn't we encrypt the value of the alert that<br>
> > is stored? It could be by default or a config thingy ...<br>
> ><br>
><br>
> yes, I am totally fine it making this a configurable option, which needs to<br>
> be enabled, for safety reasons. Those that want it, need to enabled it.<br>
><br>
> I will work on the JIRA tickets for this, if we are all cool with this.<br>
<br>
</div></div>So the decision of storing messages is up to the admin?<br></blockquote><div><br></div><div><br></div><div>Good point, let's have that option to store the alert or not on the "Create Application screen" (default would be disabled).</div><div>That way the app-developer company can decided per Push App if that is needed or not.</div><div><br></div><div>- 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.</div><div>(Does not make sense to have analytics for a gazillion pushes that are all "New appointment", or similar)</div><div>- 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.</div><div>- 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).</div><div><br></div><div>These are the classic examples why we do nee the analytics from the often given JIRA.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
> Greetings,<br>
> Matthias<br>
><br>
><br>
><br>
> ><br>
> >><br>
> ><br>
> >> BTW. for Google I don't seem to find a similar paragraph, but IMO they<br>
> >> are not that thoughtful on privacy terms (compared to Apple).<br>
> >><br>
> >><br>
> >> Now, for our UPS guide (or documentation), I will add a few sentences<br>
> >> to make it clear that our app-developers should NEVER submit sensitive<br>
> >> personal or confidential information with a push.<br>
> >><br>
> >> Regarding a "Privacy Policy", I will also make clear what data of the<br>
> >> push we store, for analytic reasons.<br>
> >><br>
> >> You'll see a PR during my Friday.<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> Greetings,<br>
> >> Matthias<br>
> >><br>
> >><br>
> >><br>
> >> On Wed, Feb 4, 2015 at 2:53 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
> >> wrote:<br>
> >><br>
> >>> I have created AGPUSH-1257 and AGPUSH-1258<br>
> >>><br>
> >>> On Fri, Jan 30, 2015 at 3:22 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
> >>> wrote:<br>
> >>><br>
> >>>> Hi,<br>
> >>>><br>
> >>>> earlier this week there was some discussion about storing the payload<br>
> >>>> of the push notifications ([1]).<br>
> >>>><br>
> >>>> Right now, we store some metrics (e.g. client that send the push,<br>
</span>> >>>> number of devices, deliveryStatus etc) *and* the entire content of<br>
<span class="">> >>>> push notification. This includes custom key/value pairs, the name of the<br>
> >>>> sound file or even the size of the badge.<br>
> >>>><br>
> >>>> Is all of that, storing the entire push notification payload really<br>
</span>> >>>> needed? *No!*<br>
<span class="">> >>>><br>
> >>>> What do we need, and why?<br>
> >>>><br>
> >>>> For counting the number of sent pushes (over time), the metrics are<br>
</span>> >>>> good enough. We do *NOT* need any of the push content for that, that's<br>
<span class="">> >>>> correct!<br>
> >>>><br>
> >>>> But we want to do more on the 1.1.0 release. We want to introduce some<br>
> >>>> analytic features, to give our app developers (our users) a better<br>
> >>>> understanding of their push usage (see [2]).<br>
> >>>><br>
> >>>> In order to see details on how successful a push was (or not), we need<br>
> >>>> to only store the value of the alert key:<br>
> >>>> <a href="https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png" target="_blank">https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png</a><br>
> >>>><br>
> >>>> Ok, let's change that (see [3])!<br>
> >>>><br>
> >>>> For our app developers, using the UPS to reach out to their mobile app<br>
> >>>> users ("user engagement"), it's important to understand which push was more<br>
> >>>> successful:<br>
> >>>><br>
</span>> >>>> - "Get 10% discount today" (sent on a Monday)<br>
> >>>> - "Our shop got new site, check it out and get 5% discount" (sent<br>
<span class="">> >>>> on a Friday)<br>
> >>>><br>
> >>>> With the upcoming analytics we can help them to improve usage of their<br>
> >>>> app. User interaction is very important to a successful mobile application<br>
> >>>> and push is a key driver here! Our app developers want an app that is<br>
> >>>> actively used by their users (Nobody wants his app sitting on the last page<br>
> >>>> of the device or, even worse, in a folder together with Apple-Maps).<br>
> >>>> Therefore it's critical for our app developers to understand the relevance<br>
> >>>> of their push messages sent and how it impacts the usage of their app.<br>
> >>>> That's why we do the analytics described in [2]. And, yes - only the alert,<br>
> >>>> not the entire payload is needed for that.<br>
</span>> >>>> <<a href="https://gist.github.com/matzew/b6459083f39394a892c5#privacy" target="_blank">https://gist.github.com/matzew/b6459083f39394a892c5#privacy</a>>Privacy<br>
<span class="">> >>>><br>
> >>>> On the mentioned PR there was also some discussion about privacy<br>
> >>>> violations and stuff, when we store the content of the notification. An<br>
</span>> >>>> example where *sensitive* data was sent over push was given. Something<br>
<span class="">> >>>> like: "Dear Mr. Joe, your blood donation appointment was scheduled for 3<br>
> >>>> p.m"<br>
> >>>><br>
</span>> >>>> 1. This is not how push notifications are used for mobile apps.<br>
<span class="">> >>>> Push is to signal, not carry actual (sensitive) data around.<br>
</span>> >>>> 2. In a lot of countries, at least almost all European countries,<br>
<div><div class="h5">> >>>> you are not even allowed, by EU law, to give "data" to 3rd party providers<br>
> >>>> (like the push-networks of Microsoft, Apple or Google).<br>
> >>>><br>
> >>>> How does the actual (sensitive) data come to an app?<br>
> >>>><br>
> >>>> As said above a push is used to signal/ping an app, to indicate that<br>
> >>>> there is real data for the mobile app user. In the background the mobile<br>
> >>>> app tries to connect to the backend of the company, running/maintaining the<br>
> >>>> mobile app. After the real data was fetched, "local notifcations" are used<br>
> >>>> to give the user a visible notification, like "Dear Mr. Joe, your blood<br>
> >>>> donation appointment was scheduled for 3 p.m", or simply "New appointment<br>
> >>>> scheduled".<br>
> >>>><br>
> >>>> If the app was a chat system (and not a blood donation app from the Red<br>
> >>>> Cross), it would be the same: After a signal, the app connects to "chat<br>
> >>>> server" and receives the actual chat message from there. A reply would go<br>
> >>>> over the same "chat server" connection. None of this would go over a 3rd<br>
> >>>> party push network provider like Google, Microsoft or Apple.<br>
> >>>><br>
> >>>> What would we store from these silent notifications?<br>
> >>>><br>
> >>>> Nothing, since there is no alert, we would just store the metrics (e.g.<br>
> >>>> client that send the push, number of devices, deliveryStatus etc). If the<br>
> >>>> signaling is actually done with an alert (e.g. alert:"you got a new Chat<br>
> >>>> text" or "New appointment scheduled"), we would store that.<br>
> >>>><br>
> >>>> I hope this helps a bit to understand what is stored and also why we do<br>
> >>>> need a little bit of information.<br>
> >>>><br>
> >>>> BTW. our documentation already says that push is used for signaling,<br>
> >>>> not carrying actual data around, but based on this email I will update it<br>
> >>>> to have explicit information on best practices. Also, the documentation<br>
> >>>> will be clear about what (the alert only) is stored by the UPS, and why.<br>
> >>>> (see [4])<br>
> >>>><br>
> >>>> Greetings,<br>
> >>>><br>
> >>>> Matthias<br>
> >>>><br>
</div></div><span class="">> >>>> - [1]<br>
> >>>> <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/478" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/478</a><br>
> >>>> - [2] <a href="https://issues.jboss.org/browse/AGPUSH-971" target="_blank">https://issues.jboss.org/browse/AGPUSH-971</a><br>
</span>> >>>> - [3] JIRA TO CREATE: to only store ALERT and not the full payload<br>
> >>>> - [4] JIRA TO CREATE: update doc regarding push message storage and<br>
<span class="">> >>>> best practices<br>
> >>>><br>
> >>>><br>
> >>>> --<br>
> >>>> Matthias Wessendorf<br>
> >>>><br>
> >>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >>>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>> Matthias Wessendorf<br>
> >>><br>
> >>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >>><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Matthias Wessendorf<br>
> >><br>
> >> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
</span>> >> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<span class="">> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Summers Pittman<br>
> >> >>Phone:404 941 4698<br>
> >> >>Java is my crack.<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
--<br>
<br>
</span>abstractj<br>
PGP: 0x84DC9914<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</div></div>