Re: [aerogear-dev] [POC] Unified Geo Server

This is great .

I missed the screencast is there a recording somewhere?

For my project i need geofencing features and if only this is well documented and there is a binary i would love to use it .

Regards Raj ------------------------------ *From:* Matthias Wessendorf <matzew(a)apache.org&gt; *To:* AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org&gt; *Sent:* Tuesday, December 16, 2014 12:13 AM *Subject:* Re: [aerogear-dev] [POC] Unified Geo Server On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: On 2014-12-15, Matthias Wessendorf wrote: > On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > > > Good morning, first nice screencast Sebi and even knowing this is just a > > PoC I have some considerations: > > > > 1. What would be the use case scenario to justify a separated server > > instead of just a module on AGPUSH? > > > > I think main discussion around this at F2F meeting was, it might be useful > for other scenarios as well, > and we don't want to hard-wire geo to the push server Which scenarios? anything else that may require geo data. E.g. other systems may benefit from interacting with geo as well. I really do not see a reason why geo is hard-wired to push. the geo server should be a system to store any sorts of geo data (long/lat) + some APIs to query. > > > > > > > 2. How do you plan to prevent people from faking their location? > > > > I'd assume that a Geo SDK would be based on-top of the mobile OS's > facility, to receive the long/lat values. > 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. I think Geo based on IPs are a bad idea. This is a very inaccurate method and should be our last resort, it's easy to spoof IPs. :-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android, which underneath leverage the OS facilities for Geo-Data. Like CoreLocation on iOS. Regarding the IP, I had this in mind (not sure if that is a good idea or not): * if long/lat (can be faked with man-in-the-middle) says Germany, but IP says singapore, our server could see: something is wrong. 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), we might know something is wrong too. But that's perhaps not for the initial scope of the poc > > > > > > > 3. Do we have a privacy policy to make the developer real aware about > > what's being collected? > > > > I think that the level of collected geo data is up to the developer of the > app, using the Geo SDK. I'm sorry, but I have to disagree. If we don't provide a policy about the usage of the Geo server, we're pretty much accountable for it. Nothing huge, only a simple txt documenting what's being collected and why. I'd think that, if we provide an SDK (and the POC will get us there), we do not really track anything 'silently'. 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). But I'd not imagine our SDK constantly tracks all positions and silently sends them to the Geo Server. > > > > > > 4. Will collecting geo location be opt in or default? > > > > 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) Most of users have no idea that their data is being collected. I'm confused about your answer, is that an yes or no? I mean yes, see above. -MAtthias > > > > > > > > 5. Why is necessary to store current user's position? > > > I think that's up to the use case, and its usage of the Geo SDK. Currently we store. I know this is just a proof of concept. But I insist to be the boring, and avoid it if possible. > > > > Couldn't admin > > specify a range and check how many devices are active on that region? > > Into this way you don't need to store their positions. I'm not the Geo > > specialist here but the idea is: > > > > 1. Admin specify the range when a push message must be sent. For > > example: Whole Florida > > 2. Client opt in and sent her its position to the server > > 3. Server compares and sent the push message > > > > I'm very concerned about privacy here, I'm not against the > > solution, but Geo location is like to open a Pandora box. > > > > yeah, it's also creepy :) I have not much services that I give my geo data > > > > > > We might be careful about unintentional disclosure of geolocation > > information, > > because it carries physical risks to the client (theft, to stalking, > > kidnapping > > and domestic violence — I'm not exaggerating). > > > > +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). > The mobile SDK for it basically store the 'collected' data to this backend > (somewhat similar to the push registration SDK) > > > > > > Again, I know this is a proof of concept, but sooner we have it in mind, > > the > > better. > > > > +1 fully agree. Replied to your questions with my POV on this > > > > > > > > > > > > > On 2014-12-10, Sebastien Blanc wrote: > > > Hi all, > > > > > > I have been working on a POC around geolocation. Like we discussed in > > > another thread, we decided not to have a "deep" integration with the Push > > > server but instead a separate component / microservice. Well the POC is > > > more a miniservice ;) > > > > > > So, the idea is to have a server to which devices can register by > > providing > > > their positions. On the other side, the server provide an endpoint to > > make > > > spatial queries, like give me all the installations within a radius of 10 > > > km around this lat/ltg. > > > > > > Thanks to Forge, I created/scaffolded a really simple server providing > > the > > > registration endpoint and the search endpoint. > > > > > > I tried to make a decent readme that will give you more details : > > > > > > https://github.com/sebastienblanc/unified-geo-server > > > > > > And as usual, I made a little screencast showing all that in action ;) > > > > > > https://www.youtube.com/watch?v=R-qdLJh4EWQ > > > > > > Please remember this is a POC, so the security is almost inexistant, the > > > console is awful ;) > > > > > > What about the Client SDKs ? > > > > > > If we reach some kind of consensus arounf the concept of Unfied Geo > > Server > > > we can start building the Client SDKs / POCs , they will be quite simple > > : > > > retrieve geolocation and register to the geo endpoint. > > > > > > Sebi > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev