<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 11:32 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"><span class="">On 2014-12-15, Matthias Wessendorf wrote:<br>
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
> ><br>
> > 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>
> ><br>
><br>
> I think main discussion around this at F2F meeting was, it might be useful<br>
> for other scenarios as well,<br>
> and we don't want to hard-wire geo to the push server<br>
<br>
</span>Which scenarios?<br></blockquote><div><br></div><div>anything else that may require geo data. E.g. other systems may benefit from interacting with geo as well.</div><div>I really do not see a reason why geo is hard-wired to push.</div><div><br></div><div>the geo server should be a system to store any sorts of geo data (long/lat) + some APIs to query. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
><br>
> ><br>
> > 2. How do you plan to prevent people from faking their location?<br>
> ><br>
><br>
> I'd assume that a Geo SDK would be based on-top of the mobile OS's<br>
> facility, to receive the long/lat values.<br>
> I think in the future we can have some sort of checks, like validating the<br>
> users IP address, if it somewhat matches the submitted geo data.<br>
<br>
</span>I think Geo based on IPs are a bad idea. This is a very inaccurate method<br>
and should be our last resort, it's easy to spoof IPs.<br></blockquote><div><br></div><div>:-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android, which underneath</div><div>leverage the OS facilities for Geo-Data. Like CoreLocation on iOS.</div><div><br></div><div>Regarding the IP, I had this in mind (not sure if that is a good idea or not):</div><div>* if long/lat (can be faked with man-in-the-middle) says Germany, but IP says singapore,</div><div>our server could see: something is wrong.</div><div><br></div><div>or if we get weird long/lats from the same device (.e.g. 12:00 Germany, 12:30 UK, 14:00 USA, 14:30 China),</div><div>we might know something is wrong too. But that's perhaps not for the initial scope of the poc</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
><br>
> ><br>
> > 3. Do we have a privacy policy to make the developer real aware about<br>
> > what's being collected?<br>
> ><br>
><br>
> I think that the level of collected geo data is up to the developer of the<br>
> app, using the Geo SDK.<br>
<br>
</span>I'm sorry, but I have to disagree. If we don't provide a policy about the usage of the Geo<br>
server, we're pretty much accountable for it.<br>
<br>
Nothing huge, only a simple txt documenting what's being collected and<br>
why.<br></blockquote><div><br></div><div>I'd think that, if we provide an SDK (and the POC will get us there), we do not really track anything 'silently'.</div><div>I hope that the SDK would allow me to get the current position (e.g. using CoreLocation), and store it with a name (e.g. home, work, my fav. cinema) and some metadata (e.g. username).</div><div><br></div><div>But I'd not imagine our SDK constantly tracks all positions and silently sends them to the Geo Server.</div><div> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
> ><br>
> > 4. Will collecting geo location be opt in or default?<br>
> ><br>
><br>
> If the Geo-data SDK is used w/in an app, I think it will still ask,<br>
> up-front, if location based services are OK to use (at least apple). And<br>
> I'd argue that users can still disable the geo usage, per app (at least<br>
> apple)<br>
<br>
</span>Most of users have no idea that their data is being collected. I'm<br>
confused about your answer, is that an yes or no?<br></blockquote><div><br></div><div>I mean yes, see above. </div><div><br></div><div><br></div><div>-MAtthias</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
><br>
><br>
> ><br>
> > 5. Why is necessary to store current user's position?<br>
><br>
><br>
> I think that's up to the use case, and its usage of the Geo SDK.<br>
<br>
</span>Currently we store. I know this is just a proof of concept.<br>
But I insist to be the boring, and avoid it if possible.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
><br>
> > 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>
> ><br>
><br>
> yeah, it's also creepy :) I have not much services that I give my geo data<br>
><br>
><br>
> ><br>
> > We might be careful about unintentional disclosure of geolocation<br>
> > information,<br>
> > because it carries physical risks to the client (theft, to stalking,<br>
> > kidnapping<br>
> > and domestic violence — I'm not exaggerating).<br>
> ><br>
><br>
> +1 I'd argue that the "Geo server" would be, initially, a 'simple' back<br>
> end, that is able to store n pairs of long/lat values (grouped by a<br>
> user/device).<br>
> The mobile SDK for it basically store the 'collected' data to this backend<br>
> (somewhat similar to the push registration SDK)<br>
><br>
><br>
> ><br>
> > Again, I know this is a proof of concept, but sooner we have it in mind,<br>
> > the<br>
> > better.<br>
> ><br>
><br>
> +1 fully agree. Replied to your questions with my POV on this<br>
><br>
><br>
><br>
> ><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<br>
> > providing<br>
> > > their positions. On the other side, the server provide an endpoint to<br>
> > 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<br>
> > 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<br>
> > Server<br>
> > > we can start building the Client SDKs / POCs , they will be quite simple<br>
> > :<br>
> > > retrieve geolocation and register to the geo endpoint.<br>
> > ><br>
> > > Sebi<br>
> ><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>
> ><br>
> ><br>
> > --<br>
> ><br>
> > abstractj<br>
> > PGP: 0x84DC9914<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>
> ><br>
><br>
><br>
> --<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><br>
<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>
<br>
<br>
--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<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></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>