[aerogear-dev] [POC] Unified Geo Server

Sat Dec 20 12:42:13 EST 2014

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 .
RegardsRaj

      From: Matthias Wessendorf <matzew at apache.org>
 To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org> 
 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 at abstractj.org> wrote:
On 2014-12-15, Matthias Wessendorf wrote:
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno at abstractj.org> 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 underneathleverage 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141220/bcda800e/attachment-0001.html 