<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 9:57 PM, Summers Pittman <span dir="ltr">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 02/05/2015 02:24 PM, Matthias
      Wessendorf wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">While working on the doc for AGPUSH-1258, I found
        this in Apple&#39;s &quot;iOS Developer Program License Agreement&quot;:
        <div><br>
        </div>
        <div>...</div>
        <div>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.<br>
        </div>
        <div>...</div>
        <div><br>
        </div>
        <div>That means, if an app-developer sends something like &quot;Your
          blood donation appointment is tomorrow&quot; 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) :-) <br>
        </div>
      </div>
    </blockquote></span>
    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&#39;t help since it is
    only the data in context which becomes personally identifying or
    protected.  <br>
    <br>
    I don&#39;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&#39;s) backs out of the gate by storing all of the
    messages by default.</div></blockquote><div><br></div><div>Let&#39;s make storing the &#39;alert&#39; an option, which needs to be enabled, and is turned off by default.</div><div><br></div><div>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</div><div><br></div><div>proper=&gt; make it explicit that the UPS stores data, and link to privacy policy etc. the entire thing :-) </div><div><br></div><div> </div><div>Thoughts? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <div><div class="h5"><blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>BTW. for Google I don&#39;t seem to find a similar paragraph,
          but IMO they are not that thoughtful on privacy terms
          (compared to Apple). </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>Regarding a &quot;Privacy Policy&quot;, I will also make clear what
          data of the push we store, for analytic reasons.</div>
        <div><br>
        </div>
        <div>You&#39;ll see a PR during my Friday.</div>
      </div>
    </blockquote>
    <br>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Greetings,</div>
        <div>Matthias</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Feb 4, 2015 at 2:53 PM,
          Matthias Wessendorf <span dir="ltr">&lt;<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>&gt;</span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">I have created AGPUSH-1257 and AGPUSH-1258</div>
            <div>
              <div>
                <div class="gmail_extra"><br>
                  <div class="gmail_quote">On Fri, Jan 30, 2015 at 3:22
                    PM, Matthias Wessendorf <span dir="ltr">&lt;<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>&gt;</span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div dir="ltr">
                        <p>Hi,</p>
                        <p>earlier
                          this week there was some discussion about
                          storing the payload of the push notifications
                          ([1]).</p>
                        <p>Right
                          now, we store some metrics (e.g. client that
                          send the push, number of devices,
                          deliveryStatus etc) <em>and</em> 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.</p>
                        <p>Is
                          all of that, storing the entire push
                          notification payload really needed? <em>No!</em></p>
                        <p>What
                          do we need, and why?</p>
                        <p>For
                          counting the number of sent pushes (over
                          time), the metrics are good enough. We do <em>NOT</em> need
                          any of the push content for that, that&#39;s
                          correct!</p>
                        <p>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]).</p>
                        <p>In
                          order to see details on how successful a push
                          was (or not), we need to only store the value
                          of the alert key: <a href="https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png" rel="noreferrer" style="color:rgb(65,131,196);text-decoration:none" target="_blank">https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png</a></p>
                        <p>Ok,
                          let&#39;s change that (see [3])!</p>
                        <p>For
                          our app developers, using the UPS to reach out
                          to their mobile app users (&quot;user engagement&quot;),
                          it&#39;s important to understand which push was
                          more successful:</p>
                        <ul>
                          <li>&quot;Get 10% discount today&quot; (sent on a
                            Monday)</li>
                          <li>&quot;Our shop got new site, check it out and
                            get 5% discount&quot; (sent on a Friday)</li>
                        </ul>
                        <p>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&#39;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&#39;s why we do the
                          analytics described in [2]. And, yes - only
                          the alert, not the entire payload is needed
                          for that.</p>
                        <h3><a name="14b5b8a6ff4e0f01_14b54ddbb375879a_14b3b38c7b34ae00_user-content-privacy" href="https://gist.github.com/matzew/b6459083f39394a892c5#privacy" rel="noreferrer" style="color:rgb(65,131,196);text-decoration:none;display:block;padding-right:6px;padding-left:30px" target="_blank"></a>Privacy</h3>
                        <p>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 <em>sensitive</em> data was
                          sent over push was given. Something like:
                          &quot;Dear Mr. Joe, your blood donation appointment
                          was scheduled for 3 p.m&quot;</p>
                        <ol>
                          <li>This is not how push notifications are
                            used for mobile apps. Push is to signal, not
                            carry actual (sensitive) data around.</li>
                          <li>In a lot of countries, at least almost all
                            European countries, you are not even
                            allowed, by EU law, to give &quot;data&quot; to 3rd
                            party providers (like the push-networks of
                            Microsoft, Apple or Google).</li>
                        </ol>
                        <p>How
                          does the actual (sensitive) data come to an
                          app?</p>
                        <p>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, &quot;local
                          notifcations&quot; are used to give the user a
                          visible notification, like &quot;Dear Mr. Joe, your
                          blood donation appointment was scheduled for 3
                          p.m&quot;, or simply &quot;New appointment scheduled&quot;.</p>
                        <p>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
                          &quot;chat server&quot; and receives the actual chat
                          message from there. A reply would go over the
                          same &quot;chat server&quot; connection. None of this
                          would go over a 3rd party push network
                          provider like Google, Microsoft or Apple.</p>
                        <p>What
                          would we store from these silent
                          notifications?</p>
                        <p>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:&quot;you got a new Chat text&quot; or &quot;New
                          appointment scheduled&quot;), we would store that.</p>
                        <p>I
                          hope this helps a bit to understand what is
                          stored and also why we do need a little bit of
                          information.</p>
                        <p>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])</p>
                        <p>Greetings,</p>
                        <p>Matthias</p>
                        <ul>
                          <li>[1] <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/478" rel="noreferrer" style="color:rgb(65,131,196);text-decoration:none" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/478</a></li>
                          <li>[2] <a href="https://issues.jboss.org/browse/AGPUSH-971" rel="noreferrer" style="color:rgb(65,131,196);text-decoration:none" target="_blank">https://issues.jboss.org/browse/AGPUSH-971</a></li>
                          <li>[3] JIRA TO CREATE: to only store ALERT
                            and not the full payload</li>
                          <li>[4] JIRA TO CREATE: update doc regarding
                            push message storage and best practices</li>
                        </ul>
                        <span><font color="#888888">
                            <div><br>
                            </div>
                            -- <br>
                            <div>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>
                          </font></span></div>
                    </blockquote>
                  </div>
                  <br>
                  <br clear="all">
                  <div><br>
                  </div>
                  -- <br>
                  <div>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>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div>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>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class=""><pre>_______________________________________________
aerogear-dev mailing list
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
    </span></blockquote><span class="HOEnZb"><font color="#888888">
    <br>
    <br>
    <pre cols="72">-- 
Summers Pittman
&gt;&gt;Phone:404 941 4698
&gt;&gt;Java is my crack.
</pre>
  </font></span></div>

<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></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>