<div dir="ltr">ok,<div><br></div><div style> I will write something, so that we have concrete things to talk about</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 11:25 AM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m fine on have a hangout anytime, but at least to me (abstractj) will be useless, until I get some working code for Pushee to validate ideas.<br>

<div class="im"><br>
Matthias Wessendorf wrote:<br>
&gt; Let&#39;s have hangout to talk about the proposed ideas and the related<br>
&gt; discussion, instead of getting lost in countless emails.<br>
&gt;<br>
&gt; I am happy to summarise the out come here, on this ML thread<br>
&gt;<br>
&gt;<br>
&gt; On Wed, May 22, 2013 at 7:03 AM, Matthias Wessendorf<br>
</div><div class="im">&gt; &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira<br>
</div><div class="im">&gt;     &lt;<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a> &lt;mailto:<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;         Is it a priority? If yes, please file a jira.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     Nah, not a priority at all.<br>
&gt;<br>
&gt;<br>
&gt;         Matthias Wessendorf wrote:<br>
&gt;         &gt; 1a)<br>
&gt;         &gt; would perhaps,... add some &quot;monitoring&quot; if an unreasonalble<br>
&gt;         about of<br>
&gt;         &gt; &quot;new devices&quot; is registered, but that means we need some sort<br>
&gt;         &gt; of analysis component (not for the first iteration) :)<br>
&gt;         &gt;<br>
&gt;         &gt; whoops, typos ===&gt;<br>
&gt;         &gt; we could perhaps,... add some &quot;monitoring&quot; if an<br>
&gt;         unreasonable amount of<br>
&gt;         &gt; &quot;new devices&quot; is registered, but that means we need some sort<br>
&gt;         &gt; of analysis component (not for the first iteration) :)<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt; On Sun, May 19, 2013 at 11:08 AM, Matthias Wessendorf<br>
&gt;         &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
</div><div><div class="h5">&gt;         &gt; &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;&gt;&gt; wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;     Concerns with both approaches<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     1)<br>
&gt;         &gt;     It would be possible to register new devices, if the<br>
&gt;         pub/private key<br>
&gt;         &gt;     (or the accessKey:secret combination) would be hacked.<br>
&gt;         &gt;<br>
&gt;         &gt;     HOWEVER, the &quot;hacker&quot; has to know how to generate VALID<br>
&gt;         tokens for<br>
&gt;         &gt;     the different push-networks. Apple and Google will NOT<br>
&gt;         accept<br>
&gt;         &gt;     incorrect tokens, and IMO this as a minimal risk.<br>
&gt;         &gt;     Similar for SimplePush. The SimplePush Network/Server,<br>
&gt;         generates<br>
&gt;         &gt;     UUIDv4 key, for every channel, so IMO.... it&#39;s hard to<br>
&gt;         &quot;hijack&quot; that<br>
&gt;         &gt;     as well.<br>
&gt;         &gt;     =&gt; But I may be just naive.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     1a)<br>
&gt;         &gt;     would perhaps,... add some &quot;monitoring&quot; if an<br>
&gt;         unreasonalble about of<br>
&gt;         &gt; &quot;new devices&quot; is registered, but that means we need some sort<br>
&gt;         &gt;     of analysis component (not for the first iteration) :)<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     2) hacker can update device info<br>
&gt;         &gt;     If the pub/private key (or the accessKey:secret<br>
&gt;         combination) are<br>
&gt;         &gt;     being compromised. it is possible to update informations<br>
&gt;         for a<br>
&gt;         &gt;     certain device. IF... he know the &quot;token&quot;.<br>
&gt;         &gt;     So... it&#39;s than very simple that the hacker can update<br>
&gt;         informations<br>
&gt;         &gt;     for his phone (since that token is VERY easy to read,<br>
&gt;         via the<br>
&gt;         &gt;     platform APIs).<br>
&gt;         &gt;     IMO not a big deal. If he updates his iPhone metadata<br>
&gt;         (e.g. changing<br>
&gt;         &gt; &quot;iOS&quot; to &quot;Android&quot;). If he changes his token, he looks<br>
&gt;         himself out<br>
&gt;         &gt;     -&gt; No longer receives &quot;push notification messages&quot;<br>
&gt;         &gt;<br>
&gt;         &gt;     2a)<br>
&gt;         &gt;     A hacker could update device infomations for other<br>
&gt;         devices. BUT !!!!<br>
&gt;         &gt;     he has to know the token of other devices, registered<br>
&gt;         with our<br>
&gt;         &gt;     server. This means, he needs access to those devices.<br>
&gt;         &gt;     =&gt; IMO as well not a big risk..<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     Summary:<br>
&gt;         &gt;     I think, if we really have a &quot;extra&quot;  pub/private key<br>
&gt;         (or the<br>
&gt;         &gt;     accessKey:secret combination) for &quot;device<br>
&gt;         (un)registration&quot;, and not<br>
&gt;         &gt;     allowing this  pub/private key (or the accessKey:secret<br>
&gt;         combination)<br>
&gt;         &gt;     on other HTTP calls (e.g. register Push Application,<br>
&gt;         register mobile<br>
&gt;         &gt;     Varian, sending): The risk is IMO minimal.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;       Thoughts ?<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     On Sun, May 19, 2013 at 10:58 AM, Matthias Wessendorf<br>
&gt;         &gt; &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
</div></div><div class="im">&gt;         &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;&gt;&gt; wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;         Another idea....<br>
&gt;         &gt;<br>
&gt;         &gt;         We generate, for EACH variant, an &quot;access-key&quot; with<br>
&gt;         a generated<br>
&gt;         &gt;         secret(password). This accessKey:secret combination<br>
&gt;         would be,<br>
&gt;         &gt;         similar to the previous email, ONLY be able to<br>
&gt;         perform updates<br>
&gt;         &gt;         for &quot;device (un)registration&quot;.<br>
&gt;         &gt;<br>
&gt;         &gt;         It would be NOT possible to use this combination for<br>
&gt;         sending<br>
&gt;         &gt;         messages to a device, (read: our HTTP send interface<br>
&gt;         would not<br>
&gt;         &gt;         allow this accessKey:secret combination).<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;         Not, sure, but this is (I guess) a bit simpler,<br>
&gt;         initially,<br>
&gt;         &gt;         instead of using private/public key approach.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;         On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf<br>
&gt;         &gt; &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
</div><div><div class="h5">&gt;         &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a> &lt;mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;&gt;&gt; wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;             Hi,<br>
&gt;         &gt;<br>
&gt;         &gt;             once the app is installed on the phone (or<br>
&gt;         launched in a<br>
&gt;         &gt;             browser),<br>
&gt;         &gt;             we (as discussed in the spec/mailing list) need<br>
&gt;         to upload<br>
&gt;         &gt;             the &quot;device token&quot; (or channelID) from the actual<br>
&gt;         &gt;             device/channel to the Unified Push Server.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;             My questions:<br>
&gt;         &gt;             Is it safe, if every &quot;Mobile Variant&quot; has a<br>
&gt;         Private/Public<br>
&gt;         &gt;             Key ???<br>
&gt;         &gt;<br>
&gt;         &gt;             The UP server keeps the private one.<br>
&gt;         &gt;             Once we register a new mobile variant (e.g. HR<br>
&gt;         for Android,<br>
&gt;         &gt;             HR for iPad, HR for iPhone, ...) EACH variant<br>
&gt;         has ONE<br>
&gt;         &gt;             Private/Public key<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;             The Public Key of this combo would be &quot;coded&quot;<br>
&gt;         into the<br>
&gt;         &gt;             actual mobiel application...<br>
&gt;         &gt;<br>
&gt;         &gt;             On EVERY iOS app, it would use the PubKey from<br>
&gt;         the iOS<br>
&gt;         &gt;             Variant, on EVERY JS-app, it would use the<br>
&gt;         PubKey from the<br>
&gt;         &gt;             SimplePush Variant, etc<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;             So, that means EVERY installation (on the<br>
&gt;         devices) would<br>
&gt;         &gt;             have that pbulci key...<br>
&gt;         &gt;<br>
&gt;         &gt;             Would that be (extremely) odd, if &quot;1 Mio Russian<br>
&gt;         hacker&quot;<br>
&gt;         &gt;             would have that public key, used on the device,<br>
&gt;         to perform<br>
&gt;         &gt;             some sort of &quot;auth&quot; (e.g. via HTTP BASIC (just<br>
&gt;         saying.....))<br>
&gt;         &gt;             against the server, in order to upload the<br>
&gt;         &quot;device token&quot; ??<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;             Note: This Private/Public key would/should be<br>
&gt;         EXCLUSIVE for<br>
&gt;         &gt; &quot;device registration&quot;. And really ONLY.. :-)<br>
&gt;         &gt;<br>
&gt;         &gt;             So that this &quot;Private/Public key&quot; pair can NOT<br>
&gt;         be used<br>
&gt;         &gt;             (==invalid) for sending messages to the<br>
&gt;         installations, or<br>
&gt;         &gt;             creating the Push-Applications / Mobile Variant<br>
&gt;         Constructs.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;             Greetings,<br>
&gt;         &gt;             Matthias<br>
&gt;         &gt;<br>
&gt;         &gt;             --<br>
&gt;         &gt;             Matthias Wessendorf<br>
&gt;         &gt;<br>
&gt;         &gt;             blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt;         &gt;             sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt;         &gt;             twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;         --<br>
&gt;         &gt;         Matthias Wessendorf<br>
&gt;         &gt;<br>
&gt;         &gt;         blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt;         &gt;         sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt;         &gt;         twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     --<br>
&gt;         &gt;     Matthias Wessendorf<br>
&gt;         &gt;<br>
&gt;         &gt;     blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt;         &gt;     sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt;         &gt;     twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt; --<br>
&gt;         &gt; Matthias Wessendorf<br>
&gt;         &gt;<br>
&gt;         &gt; blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt;         &gt; sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt;         &gt; twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;         &gt;<br>
&gt;         &gt; _______________________________________________<br>
&gt;         &gt; aerogear-dev mailing list<br>
&gt;         &gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
</div></div>&gt;         &lt;mailto:<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>&gt;<br>
<div class="im">&gt;         &gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt;         _______________________________________________<br>
&gt;         aerogear-dev mailing list<br>
</div>&gt;         <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>&gt;<br>
<div class="HOEnZb"><div class="h5">&gt;         <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     --<br>
&gt;     Matthias Wessendorf<br>
&gt;<br>
&gt;     blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt;     sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt;     twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Matthias Wessendorf<br>
&gt;<br>
&gt; blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <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>
</div>