<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Lots of things I was going to answer as already be done Matthias ;)</div><div>But first of all thanks Bruno for this detailed answer. </div><div>All your concerns make totally sense and it's by tackling them in the SDKs and the server that will make it a valuable piece of software that people would like to use.</div><div>Some extra answers inline<br><br>Envoyé de mon iPhone</div><div><br>Le 15 déc. 2014 à 21:37, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><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"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></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't want to hard-wire geo to the push server</div></div></div></div></div></blockquote>Yes, for instance all mobile apps would not need Push but would like use geo stuff.<br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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'd assume that a Geo SDK would be based on-top of the mobile OS'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></div></div></div></blockquote>Yes adding this kind of security would really make the difference than a simple "send-my-location" library.<div>Could keycloak for instance help to authenticate the SDK call ? Or token based stuff ?<br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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'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></div></div></div></blockquote>We could also add extra warnings in the documentation like Cordova does <a href="https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/index.md">https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/index.md</a><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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'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's position? </blockquote><div><br></div><div>I think that'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't admin<br>
specify a range and check how many devices are active on that region?<br>
Into this way you don't need to store their positions. I'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'm very concerned about privacy here, I'm not against the<br>
solution, but Geo location is like to open a Pandora box.<br></blockquote><div><br></div><div>yeah, it'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'm not exaggerating).<br></blockquote><div><br></div><div>+1 I'd argue that the "Geo server" would be, initially, a 'simple' 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 'collected' 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></div></div></div></blockquote>+1 as I said in the beginning of my message.<br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>
> Hi all,<br>
><br>
> I have been working on a POC around geolocation. Like we discussed in<br>
> another thread, we decided not to have a "deep" integration with the Push<br>
> server but instead a separate component / microservice. Well the POC is<br>
> more a miniservice ;)<br>
><br>
> So, the idea is to have a server to which devices can register by providing<br>
> their positions. On the other side, the server provide an endpoint to make<br>
> spatial queries, like give me all the installations within a radius of 10<br>
> km around this lat/ltg.<br>
><br>
> Thanks to Forge, I created/scaffolded a really simple server providing the<br>
> registration endpoint and the search endpoint.<br>
><br>
> I tried to make a decent readme that will give you more details :<br>
><br>
> <a href="https://github.com/sebastienblanc/unified-geo-server" target="_blank">https://github.com/sebastienblanc/unified-geo-server</a><br>
><br>
> And as usual, I made a little screencast showing all that in action ;)<br>
><br>
> <a href="https://www.youtube.com/watch?v=R-qdLJh4EWQ" target="_blank">https://www.youtube.com/watch?v=R-qdLJh4EWQ</a><br>
><br>
> Please remember this is a POC, so the security is almost inexistant, the<br>
> console is awful ;)<br>
><br>
> What about the Client SDKs ?<br>
><br>
> If we reach some kind of consensus arounf the concept of Unfied Geo Server<br>
> we can start building the Client SDKs / POCs , they will be quite simple :<br>
> retrieve geolocation and register to the geo endpoint.<br>
><br>
> Sebi<br>
<br>
</div></div><span class="">> _______________________________________________<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 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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>aerogear-dev mailing list</span><br><span><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></span></div></blockquote></div></body></html>