[aerogear-dev] [POC] Unified Geo Server

Mon Dec 15 17:36:31 EST 2014

On 2014-12-15, Sébastien Blanc wrote:
> Lots of things I was going to answer as already be done Matthias ;)
> But first of all thanks Bruno for this detailed answer.
> 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.
> Some extra answers inline
>
> Envoyé de mon iPhone
>
> > Le 15 déc. 2014 à 21:37, Matthias Wessendorf <matzew at apache.org> a écrit :
> >
> >
> >
> >> 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
> Yes, for instance all mobile apps would not need Push but would like use geo stuff.
> >
> >
> >>
> >> 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.
> Yes adding this kind of security would really make the difference than a simple "send-my-location" library.
> Could keycloak for instance help to authenticate the SDK call ? Or token based stuff ?

Yes, it's possible to have some sorta of integration with Keycloak, but
must be evaluated.

> >
> >
> >>
> >> 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.
> We could also add extra warnings in the documentation like Cordova does  https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/index.md

That makes sense, or https://www.google.com/privacy/lsf.html.

> >
> >>
> >> 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)
> >
> >
> >
> >>
> >> 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.
> >
> >> 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
> +1 as I said in the beginning of my message.
> >
> >
> >>
> >>
> >>
> >>
> >> 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

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

abstractj
PGP: 0x84DC9914