[aerogear-dev] [POC] Unified Geo Server

[Matthias Wessendorf]

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



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



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


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



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