<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good morning, first nice screencast Sebi and even knowing this is just a<br>
PoC I have some considerations:<br>
<br>
1. What would be the use case scenario to justify a separated server<br>
instead of just a module on AGPUSH?<br></blockquote><div><br></div><div>I think main discussion around this at F2F meeting was, it might be useful for other scenarios as well,</div><div>and we don&#39;t want to hard-wire geo to the push server</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. How do you plan to prevent people from faking their location?<br></blockquote><div><br></div><div>I&#39;d assume that a Geo SDK would be based on-top of the mobile OS&#39;s facility, to receive the long/lat values.</div><div>I think in the future we can have some sort of checks, like validating the users IP address, if it somewhat matches the submitted geo data.<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">
<br>
3. Do we have a privacy policy to make the developer real aware about<br>
what&#39;s being collected?<br></blockquote><div><br></div><div>I think that the level of collected geo data is up to the developer of the app, using the Geo SDK.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4. Will collecting geo location be opt in or default?<br></blockquote><div><br></div><div>If the Geo-data SDK is used w/in an app, I think it will still ask, up-front, if location based services are OK to use (at least apple). And I&#39;d argue that users can still disable the geo usage, per app (at least apple)</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">
<br>
5. Why is necessary to store current user&#39;s position? </blockquote><div><br></div><div>I think that&#39;s up to the use case, and its usage of the Geo SDK.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Couldn&#39;t admin<br>
specify a range and check how many devices are active on that region?<br>
Into this way you don&#39;t need to store their positions. I&#39;m not the Geo<br>
specialist here but the idea is:<br>
<br>
1. Admin specify the range when a push message must be sent. For<br>
example: Whole Florida<br>
2. Client opt in and sent her its position to the server<br>
3. Server compares and sent the push message<br>
<br>
I&#39;m very concerned about privacy here, I&#39;m not against the<br>
solution, but Geo location is like to open a Pandora box.<br></blockquote><div><br></div><div>yeah, it&#39;s also creepy :) I have not much services that I give my geo data</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We might be careful about unintentional disclosure of geolocation information,<br>
because it carries physical risks to the client (theft, to stalking, kidnapping<br>
and domestic violence — I&#39;m not exaggerating).<br></blockquote><div><br></div><div>+1 I&#39;d argue that the &quot;Geo server&quot; would be, initially, a &#39;simple&#39; back end, that is able to store n pairs of long/lat values (grouped by a user/device).</div><div>The mobile SDK for it basically store the &#39;collected&#39; data to this backend (somewhat similar to the push registration SDK) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Again, I know this is a proof of concept, but sooner we have it in mind, the<br>
better.<br></blockquote><div><br></div><div>+1 fully agree. Replied to your questions with my POV on this</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
<br>
<br>
<br>
On 2014-12-10, Sebastien Blanc wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I have been working on a POC around geolocation. Like we discussed in<br>
&gt; another thread, we decided not to have a &quot;deep&quot; integration with the Push<br>
&gt; server but instead a separate component / microservice. Well the POC is<br>
&gt; more a miniservice ;)<br>
&gt;<br>
&gt; So, the idea is to have a server to which devices can register by providing<br>
&gt; their positions. On the other side, the server provide an endpoint to make<br>
&gt; spatial queries, like give me all the installations within a radius of 10<br>
&gt; km around this lat/ltg.<br>
&gt;<br>
&gt; Thanks to Forge, I created/scaffolded a really simple server providing the<br>
&gt; registration endpoint and the search endpoint.<br>
&gt;<br>
&gt; I tried to make a decent readme that will give you more details :<br>
&gt;<br>
&gt; <a href="https://github.com/sebastienblanc/unified-geo-server" target="_blank">https://github.com/sebastienblanc/unified-geo-server</a><br>
&gt;<br>
&gt; And as usual, I made a little screencast showing all that in action ;)<br>
&gt;<br>
&gt; <a href="https://www.youtube.com/watch?v=R-qdLJh4EWQ" target="_blank">https://www.youtube.com/watch?v=R-qdLJh4EWQ</a><br>
&gt;<br>
&gt; Please remember this is a POC, so the security is almost inexistant, the<br>
&gt; console is awful ;)<br>
&gt;<br>
&gt; What about the Client SDKs ?<br>
&gt;<br>
&gt; If we reach some kind of consensus arounf the concept of Unfied Geo Server<br>
&gt; we can start building the Client SDKs / POCs , they will be quite simple :<br>
&gt; retrieve geolocation and register to the geo endpoint.<br>
&gt;<br>
&gt; Sebi<br>
<br>
</div></div><span class="">&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>
<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 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>