[aerogear-dev] [POC] Unified Geo Server

Tue Dec 16 00:13:59 EST 2014

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 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141216/4a03ce13/attachment-0001.html 