On 2015-02-05, Matthias Wessendorf wrote:

> On Thu, Feb 5, 2015 at 9:57 PM, Summers Pittman <supittma@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.
> >
> > 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.
> >
>
> Let's make storing the 'alert' an option, which needs to be enabled, and is
> turned off by default.
>
> This allows those that want to use the UPS for marekting reasons, to
> explicitly enable it. The enabling should be done with a proper*
> dialog/step inside of the setup-wizard that is planed for 1.1.x
>
> proper=> make it explicit that the UPS stores data, and link to privacy
> policy etc. the entire thing :-)

+1 on privacy policy

-1 on let people enable/disable for marketing reasons.

>
>
> Thoughts?
>
>
> >  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@apache.org>
> > wrote:
> >
> >> I have created AGPUSH-1257 and AGPUSH-1258
> >>
> >> On Fri, Jan 30, 2015 at 3:22 PM, Matthias Wessendorf <matzew@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@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev