On 2014-12-15, Matthias Wessendorf wrote:
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno@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?

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

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

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

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


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev