API Key request

[Jan-Tarek Butt]

Hi together,

my name is Tarek I am studding computer silences in Emden, Germany.
I got a google summer of code scholarship this year and I plan to write
a software defined gps Module for Linux as a kernel module.

This kernel module which should communicate with the API and provided
a device driver under /dev as a tty driver. The Linux kernel provides GPS
hardware as tty devices. This software defined tty device should print GPS
format e.g. NMEA 0183. The goal of this kernel module is that programs like
gpsd and other can easily use this standard tty device as a normal GPS hardware.
The position detection continues over Wifi. The advantaged of this module is
that devices like laptops or routers can have simulated GPS hardware. After
that a library should convert the NMEA 0183 format to long-/latitude and
print that.

The API backend should replace the old openwifi.su backend and also communicate
with MLS.

Locking forward to hear from you :)
Tarek

--
# Home ta...@ring0.de
# Freifunk Nordwest <ta...@ffnw.de>
# GnuPG:
# Ich nehme verschlüsselte Mails entgegen.
# Fingerprint: 57C0 5D95 DBB0 8A60 159D D114 D41F 2089 1E7A 91C2
# Download Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x1E7A91C2
# Anleitung zur Mailverschlüsselung: http://bit.ly/1e3g2yF

[Zeeshan Ali (Khattak)]

Hi Jan-Tarek,

Good project. Have you heard of Geoclue? It is the default geolocation
framework on freedesktop environments:

https://geoclue.freedesktop.org

I am the author and maintainer of Geoclue2, which has already very
tight integration with GNOME (which will be the default on future
Ubuntu) and already makes use of Mozilla Location Services.

Moreover, it already supports making use of NMEA-over-network and we
have an android application that let's you easily use your phone's GPS
on geoclue-enabled machines on your local network:

https://github.com/ankitstarski/GeoclueShare

One thing that is missing in Geoclue is support for standalone (we
already support GPS on modems) GPS devices. Since GPSD was supposed to
die a long time ago (https://gypsy.freedesktop.org/why-not-gpsd.html)
and I didn't feel like reviving Gypsy (we can get into reasons later),
I decided to go another way:

https://github.com/zeenix/gps-share

This will be not only a replacement for GPSD but also be able to share
your GPS device on the local network (the same way as our android app
works). I'm writing it in Rust language so it's very reliable and I
have aims of porting Geoclue to Rust as well in the future.

So while you're free to do as you wish, I'd strongly recommend you
modify your GSoC project a bit to join forces with me to enable GPS
support in Geoclue instead. You won't need a new MLS key either. :)

> _______________________________________________
> dev-geolocation mailing list
> dev-geo...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-geolocation
>



--
Regards,

Zeeshan Ali

[Zeeshan Ali (Khattak)]

Oh and could you please put your mentor on the CC to your reply? Thanks.

--
Regards,

Zeeshan Ali

[Jan-Tarek Butt]

Hi Zeeshan,

Johannes is my mentor I put him in CC.

> Good project. Have you heard of Geoclue? It is the default geolocation
> framework on freedesktop environments:

Yes, I have heard something about Geoclue.
I am already on the geo...@lists.freedesktop.org list some years.

> https://geoclue.freedesktop.org

I am writing this mail currently offline so I cant check the links ;P

> I am the author and maintainer of Geoclue2, which has already very
> tight integration with GNOME (which will be the default on future
> Ubuntu) and already makes use of Mozilla Location Services.
>
> Moreover, it already supports making use of NMEA-over-network and we
> have an android application that let's you easily use your phone's GPS
> on geoclue-enabled machines on your local network:

Right, I tested that last year. Nice feature :)

> https://github.com/ankitstarski/GeoclueShare
>
> One thing that is missing in Geoclue is support for standalone (we
> already support GPS on modems) GPS devices. Since GPSD was supposed to
> die a long time ago (https://gypsy.freedesktop.org/why-not-gpsd.html)
> and I didn't feel like reviving Gypsy (we can get into reasons later),
> I decided to go another way:
>
> https://github.com/zeenix/gps-share
>
> This will be not only a replacement for GPSD but also be able to share
> your GPS device on the local network (the same way as our android app
> works). I'm writing it in Rust language so it's very reliable and I
> have aims of porting Geoclue to Rust as well in the future.
>
> So while you're free to do as you wish, I'd strongly recommend you
> modify your GSoC project a bit to join forces with me to enable GPS
> support in Geoclue instead. You won't need a new MLS key either. :)

Ok, I don't understand what exactly is missing? You mean standalone as
only receiving coordinates base on surrounded WiFis? Could you explain
what do you mean?

My use case is a bit special. I am maintaining a firmware for few
thousand routers. This is an open source and open wireless network, working
with distributed network protocols like BATMAN-adv (Freifunk
ffnw.de <-- is in german). The problem is that many routers have only 4MB
Flash. So I need a very small application which gave me lat/long by
surrounded WiFi networks. Actually we use libwlocate and lwtrace. It doesn't
need an API key or any authentication for receiving a position anonymously
like real GPS.

So if Geoclue already supports communicating with real GPS hardware over
/dev/tty devices, Geoclue should also able to work with sgps or not?
The pro is that we have a very modular structured modules.

In my last mail I told that I would like to write a new backed for
openwifi.su. Maybe I can realise that all wifi informations can also
integrated into MLS. So MLS will get more datas. :)

cheers
Tarek

[Zeeshan Ali (Khattak)]

Hi Jan-Tarek,

So sorry for late reply.

On 14 May 2017 at 19:47, Jan-Tarek Butt <ta...@ring0.de> wrote:
> Hi Zeeshan,
>
> Johannes is my mentor I put him in CC.

Aweosome, thanks. Just out of curiosity, which org this is under?

>> Good project. Have you heard of Geoclue? It is the default geolocation
>> framework on freedesktop environments:
>
> Yes, I have heard something about Geoclue.
> I am already on the geo...@lists.freedesktop.org list some years.

Cool!

>> https://geoclue.freedesktop.org
>
> I am writing this mail currently offline so I cant check the links ;P

Ah ok, if you know geoclue, that link isn't important but the
following ones were important for you to get a good idea of what I'm
talking about. :)

>> I am the author and maintainer of Geoclue2, which has already very
>> tight integration with GNOME (which will be the default on future
>> Ubuntu) and already makes use of Mozilla Location Services.
>>
>> Moreover, it already supports making use of NMEA-over-network and we
>> have an android application that let's you easily use your phone's GPS
>> on geoclue-enabled machines on your local network:
>
> Right, I tested that last year. Nice feature :)

Great! Thanks.

>> https://github.com/ankitstarski/GeoclueShare
>>
>> One thing that is missing in Geoclue is support for standalone (we
>> already support GPS on modems) GPS devices. Since GPSD was supposed to
>> die a long time ago (https://gypsy.freedesktop.org/why-not-gpsd.html)
>> and I didn't feel like reviving Gypsy (we can get into reasons later),
>> I decided to go another way:
>>
>> https://github.com/zeenix/gps-share
>>
>> This will be not only a replacement for GPSD but also be able to share
>> your GPS device on the local network (the same way as our android app
>> works). I'm writing it in Rust language so it's very reliable and I
>> have aims of porting Geoclue to Rust as well in the future.
>>
>> So while you're free to do as you wish, I'd strongly recommend you
>> modify your GSoC project a bit to join forces with me to enable GPS
>> support in Geoclue instead. You won't need a new MLS key either. :)
>
> Ok, I don't understand what exactly is missing? You mean standalone as
> only receiving coordinates base on surrounded WiFis?

Standalone GPS are the ones that are not part of a 3G modem but are
just GPS devices (USB and bluetooth). This has nothing to do with
WiFi-part really. The WiFi-geolocation is already in place and geoclue
even uploads Wifi information to MLS if submit-data=true is set in
/etc/geoclue/geoclue.conf file.

Applications on Linux system are expected to use Geoclue (and many do,
even if some still use the old geoclue) for geolocation and I feel
that your current plan will create unnecessary redundancy: Geoclue
will be using MLS for WiFi-geolocation and then your module will be
doing exactly the same.

Unless I misunderstood your project or your project is meant to be
never used on a typical Linux system?

> My use case is a bit special. I am maintaining a firmware for few
> thousand routers. This is an open source and open wireless network, working
> with distributed network protocols like BATMAN-adv (Freifunk
> ffnw.de <-- is in german). The problem is that many routers have only 4MB
> Flash. So I need a very small application which gave me lat/long by
> surrounded WiFi networks. Actually we use libwlocate and lwtrace. It doesn't
> need an API key or any authentication for receiving a position anonymously
> like real GPS.

Ah ok. Geoclue with it's deps chain[1] on a typical desktop Linux
machine (Fedora in my case) is 13MB but these deps have not been
configured/built for a limited-resources case like yours. I won't be
surprised at all if you can strip quite a lot if you build the deps
(e.g glib) with most features disabled and make everything fit within
a few MBs.

> So if Geoclue already supports communicating with real GPS hardware over
> /dev/tty devices, Geoclue should also able to work with sgps or not?

That's what is missing. It does not. It only has support for
modem-based GPS devices.

> The pro is that we have a very modular structured modules.
>
> In my last mail I told that I would like to write a new backed for
> openwifi.su. Maybe I can realise that all wifi informations can also
> integrated into MLS. So MLS will get more datas. :)

I recall that I did have a look at this openwifi before MLS existed
but once MLS came to being, I didn't see any point of project. I felt
it was very Germany-focused project (the webpage still speaks to you
in German by default).

Anyway, if you project has to be about openwifi, sure I understand but
I still don't understand the point of putting anything in the kernel
if everything can be very efficiently implemented in the user-space.


--
Regards,

Zeeshan Ali

[1] with geoclue built without support for ModemManager and NMEA source.

[Jan-Tarek Butt]

Hi,

> So sorry for late reply.

Is ok :)

> On 14 May 2017 at 19:47, Jan-Tarek Butt <ta...@ring0.de> wrote:
>> Hi Zeeshan,
>>
>> Johannes is my mentor I put him in CC.
>
> Aweosome, thanks. Just out of curiosity, which org this is under?

The org is Freifunk
https://summerofcode.withgoogle.com/projects/#6078953772023808

>>> https://github.com/zeenix/gps-share
>>>
>>> This will be not only a replacement for GPSD but also be able to share
>>> your GPS device on the local network (the same way as our android app
>>> works). I'm writing it in Rust language so it's very reliable and I
>>> have aims of porting Geoclue to Rust as well in the future.
>>>
>>> So while you're free to do as you wish, I'd strongly recommend you
>>> modify your GSoC project a bit to join forces with me to enable GPS
>>> support in Geoclue instead. You won't need a new MLS key either. :)
>>
>> Ok, I don't understand what exactly is missing? You mean standalone as
>> only receiving coordinates base on surrounded WiFis?
>
> Standalone GPS are the ones that are not part of a 3G modem but are
> just GPS devices (USB and bluetooth). This has nothing to do with
> WiFi-part really. The WiFi-geolocation is already in place and geoclue
> even uploads Wifi information to MLS if submit-data=true is set in
> /etc/geoclue/geoclue.conf file.
>
> Applications on Linux system are expected to use Geoclue (and many do,
> even if some still use the old geoclue) for geolocation and I feel
> that your current plan will create unnecessary redundancy: Geoclue
> will be using MLS for WiFi-geolocation and then your module will be
> doing exactly the same.

The difference is, that MLS needs SSL and an authentication via API key,
openwifi.su not. On our Routers we don't have SSL and a requires of an API
key for each router. It is also not really a good way for both sides.

> Unless I misunderstood your project or your project is meant to be
> never used on a typical Linux system?

You can use it as well on typical Linux systems. Even in geoclue if
geoclue got the support of working with Standalone GPS hardware.

>> My use case is a bit special. I am maintaining a firmware for few
>> thousand routers. This is an open source and open wireless network, working
>> with distributed network protocols like BATMAN-adv (Freifunk
>> ffnw.de <-- is in german). The problem is that many routers have only 4MB
>> Flash. So I need a very small application which gave me lat/long by
>> surrounded WiFi networks. Actually we use libwlocate and lwtrace. It doesn't
>> need an API key or any authentication for receiving a position anonymously
>> like real GPS.
>
> Ah ok. Geoclue with it's deps chain[1] on a typical desktop Linux
> machine (Fedora in my case) is 13MB but these deps have not been
> configured/built for a limited-resources case like yours. I won't be
> surprised at all if you can strip quite a lot if you build the deps
> (e.g glib) with most features disabled and make everything fit within
> a few MBs.

Right, there is the problems with SSL and authentication... I tried this last
year.

>> So if Geoclue already supports communicating with real GPS hardware over
>> /dev/tty devices, Geoclue should also able to work with sgps or not?
>
> That's what is missing. It does not. It only has support for
> modem-based GPS devices.

So if we implemented communicating over device drivers, geoclue should also
work with sgps. The main point on my side is the required authentication
and ssl for embedded devs. I see GPS as an authenticationless service.
But I will take a deeper look into geoclue maybe we can also integrate
communicating with openwifi.su. Maybe we can merge the openwifi.su datas
into MLS as well.

>> The pro is that we have a very modular structured modules.
>>
>> In my last mail I told that I would like to write a new backed for
>> openwifi.su. Maybe I can realise that all wifi informations can also
>> integrated into MLS. So MLS will get more datas. :)
>
> I recall that I did have a look at this openwifi before MLS existed
> but once MLS came to being, I didn't see any point of project. I felt
> it was very Germany-focused project (the webpage still speaks to you
> in German by default).

Yes, sure I know what you mean. But it is the only service which works
without authentication and SSL.

> Anyway, if you project has to be about openwifi, sure I understand but
> I still don't understand the point of putting anything in the kernel
> if everything can be very efficiently implemented in the user-space.

The main idea wars to create a software application which should work with
all other applications they are communicating with gps hardware over tty devices.
That is the reason why the project is called software defined GPS.

cheers
Tarek

[Zeeshan Ali (Khattak)]

Hi,

On 18 May 2017 at 18:53, Jan-Tarek Butt <ta...@ring0.de> wrote:
> Hi,
>
>> So sorry for late reply.
>
> Is ok :)
>
>> On 14 May 2017 at 19:47, Jan-Tarek Butt <ta...@ring0.de> wrote:
>>> Hi Zeeshan,
>>>
>>> Johannes is my mentor I put him in CC.
>>
>> Aweosome, thanks. Just out of curiosity, which org this is under?
>
> The org is Freifunk
> https://summerofcode.withgoogle.com/projects/#6078953772023808

Ah OK, thanks.

>>>> https://github.com/zeenix/gps-share
>>>>
>>>> This will be not only a replacement for GPSD but also be able to share
>>>> your GPS device on the local network (the same way as our android app
>>>> works). I'm writing it in Rust language so it's very reliable and I
>>>> have aims of porting Geoclue to Rust as well in the future.
>>>>
>>>> So while you're free to do as you wish, I'd strongly recommend you
>>>> modify your GSoC project a bit to join forces with me to enable GPS
>>>> support in Geoclue instead. You won't need a new MLS key either. :)
>>>
>>> Ok, I don't understand what exactly is missing? You mean standalone as
>>> only receiving coordinates base on surrounded WiFis?
>>
>> Standalone GPS are the ones that are not part of a 3G modem but are
>> just GPS devices (USB and bluetooth). This has nothing to do with
>> WiFi-part really. The WiFi-geolocation is already in place and geoclue
>> even uploads Wifi information to MLS if submit-data=true is set in
>> /etc/geoclue/geoclue.conf file.
>>
>> Applications on Linux system are expected to use Geoclue (and many do,
>> even if some still use the old geoclue) for geolocation and I feel
>> that your current plan will create unnecessary redundancy: Geoclue
>> will be using MLS for WiFi-geolocation and then your module will be
>> doing exactly the same.
>
> The difference is, that MLS needs SSL and an authentication via API key,
> openwifi.su not. On our Routers we don't have SSL and a requires of an API
> key for each router. It is also not really a good way for both sides.

OK but then I'm confused as to why you want to use MLS still?

>> Unless I misunderstood your project or your project is meant to be
>> never used on a typical Linux system?
>
> You can use it as well on typical Linux systems.

That's why I think this may be a very bad idea. It only adds
duplication in typical Linux systems.

> Even in geoclue if
> geoclue got the support of working with Standalone GPS hardware.

Well, if you expose MLS as a normal standalone GPS device as you plan
to do, Geoclue will use it through gps-share in the near future and
we'll end-up with using MLS at the same time, for no reason.

Even without gps-share, we'll at least have duplication of code.

>>> So if Geoclue already supports communicating with real GPS hardware over
>>> /dev/tty devices, Geoclue should also able to work with sgps or not?
>>
>> That's what is missing. It does not. It only has support for
>> modem-based GPS devices.
>
> So if we implemented communicating over device drivers, geoclue should also
> work with sgps.

Yup and it certainly will end up doing that if sgps is installed on a
machine and for reasons mentioned before, we really don't want this.

>The main point on my side is the required authentication
> and ssl for embedded devs. I see GPS as an authenticationless service.
> But I will take a deeper look into geoclue maybe we can also integrate
> communicating with openwifi.su. Maybe we can merge the openwifi.su datas
> into MLS as well.

The last part would make the most sense but I'm pretty sure:

* this has been already considered and not acted on (don't recall the reasons).
* MLS has a *lot* more data, with a lot of duplication in Germany so
not very sure it's very useful.

>>> The pro is that we have a very modular structured modules.
>>>
>>> In my last mail I told that I would like to write a new backed for
>>> openwifi.su. Maybe I can realise that all wifi informations can also
>>> integrated into MLS. So MLS will get more datas. :)
>>
>> I recall that I did have a look at this openwifi before MLS existed
>> but once MLS came to being, I didn't see any point of project. I felt
>> it was very Germany-focused project (the webpage still speaks to you
>> in German by default).
>
> Yes, sure I know what you mean. But it is the only service which works
> without authentication and SSL.

I guess then you have to make a choice:

* Enable SSL somehow and use MLS.
* Use openwifi and forget about MLS completely.

But of course, it's your project and your decision on what you do. :)

>> Anyway, if you project has to be about openwifi, sure I understand but
>> I still don't understand the point of putting anything in the kernel
>> if everything can be very efficiently implemented in the user-space.
>
> The main idea wars to create a software application which should work with
> all other applications they are communicating with gps hardware over tty devices.
> That is the reason why the project is called software defined GPS.

Sure but most apps are not supposed to use GPS directly. They just
want to get the location and Geoclue already provides an API for that.
The apps that do use GPS device directly are GPS device management
type and they'd expect a real GPS device behind the tty node.

--
Regards,

Zeeshan Ali

[Hanno Schlichting]

On 19. May 2017, at 14:01, Zeeshan Ali (Khattak) <zees...@gnome.org> wrote:
> On 18 May 2017 at 18:53, Jan-Tarek Butt <ta...@ring0.de> wrote:
>> But I will take a deeper look into geoclue maybe we can also integrate
>> communicating with openwifi.su. Maybe we can merge the openwifi.su datas
>> into MLS as well.
>
> The last part would make the most sense but I'm pretty sure:
>
> * this has been already considered and not acted on (don't recall the reasons).

The problem is openwifi.su uses the ODbL license for its dataset, which has a share-alike requirement in it.

Our legal understanding is that it violates European privacy laws to release a dataset, which contains the combination of a BSSID and a lat/lon position. This combination is considered personally identifiable information.

If we were to integrate the openwifi.su dataset into our own, we'd be required to also release our derivative combined dataset under the Odbl. That in turn would mean we'd violate privacy laws.

This is not legal advice to anyone else and if you only operate in a single country, the situation might be different. If you are small project the chance of you being sued is also a lot smaller. But given that Google was sued and lost over this, we need to be careful.

>> Yes, sure I know what you mean. But it is the only service which works
>> without authentication and SSL.

Regarding SSL, at Mozilla we very much consider location data to be privacy sensitive. Sharing such privacy sensitive data over a non-encrypted channel is not an option for us.

As for authentication, geoclue as a library ships with a built-in API key, so not every user has to get a key. These keys merely help us to attribute traffic to the various clients and act a lot more like an extended user-agent header. Since we are providing this service for free, they also give us a way to shut down access from one client library, without affecting everyone else. We never had to do so, but if someone where to abuse our service, we'd have a way to single out one client, rather than shut down the service for everyone. We specifically don't want to have an API key for a single device or user, as that would allow us to track an individual. Something we really don't want to be able to do.

Hanno

[Jan-Tarek Butt]

On 05/19/17 14:01, Zeeshan Ali (Khattak) wrote:
> Hi,

>>>>> https://github.com/zeenix/gps-share
>>>>>
>>>>> This will be not only a replacement for GPSD but also be able to share
>>>>> your GPS device on the local network (the same way as our android app
>>>>> works). I'm writing it in Rust language so it's very reliable and I
>>>>> have aims of porting Geoclue to Rust as well in the future.
>>>>>
>>>>> So while you're free to do as you wish, I'd strongly recommend you
>>>>> modify your GSoC project a bit to join forces with me to enable GPS
>>>>> support in Geoclue instead. You won't need a new MLS key either. :)
>>>>
>>>> Ok, I don't understand what exactly is missing? You mean standalone as
>>>> only receiving coordinates base on surrounded WiFis?
>>>
>>> Standalone GPS are the ones that are not part of a 3G modem but are
>>> just GPS devices (USB and bluetooth). This has nothing to do with
>>> WiFi-part really. The WiFi-geolocation is already in place and geoclue
>>> even uploads Wifi information to MLS if submit-data=true is set in
>>> /etc/geoclue/geoclue.conf file.
>>>
>>> Applications on Linux system are expected to use Geoclue (and many do,
>>> even if some still use the old geoclue) for geolocation and I feel
>>> that your current plan will create unnecessary redundancy: Geoclue
>>> will be using MLS for WiFi-geolocation and then your module will be
>>> doing exactly the same.
>>
>> The difference is, that MLS needs SSL and an authentication via API key,
>> openwifi.su not. On our Routers we don't have SSL and a requires of an API
>> key for each router. It is also not really a good way for both sides.
>
> OK but then I'm confused as to why you want to use MLS still?

Ah, I see the miss understanding. MLS is for the openwifi.su backend.
If it not possible for openwifi.su to determinate a position, use MLS
as fallback.

>>> Unless I misunderstood your project or your project is meant to be
>>> never used on a typical Linux system?
>>
>> You can use it as well on typical Linux systems.
>
> That's why I think this may be a very bad idea. It only adds
> duplication in typical Linux systems.

I see. The answer is below.

>> Even in geoclue if
>> geoclue got the support of working with Standalone GPS hardware.
>
> Well, if you expose MLS as a normal standalone GPS device as you plan
> to do, Geoclue will use it through gps-share in the near future and
> we'll end-up with using MLS at the same time, for no reason.
>
> Even without gps-share, we'll at least have duplication of code.

Right, I agree with you. Explanation below.

>>>> So if Geoclue already supports communicating with real GPS hardware over
>>>> /dev/tty devices, Geoclue should also able to work with sgps or not?
>>>
>>> That's what is missing. It does not. It only has support for
>>> modem-based GPS devices.
>>
>> So if we implemented communicating over device drivers, geoclue should also
>> work with sgps.
>
> Yup and it certainly will end up doing that if sgps is installed on a

> machine and for reasons mentioned before, we really don't want this.

I see. Sorry I wars a bit confused.

>> The main point on my side is the required authentication
>> and ssl for embedded devs. I see GPS as an authenticationless service.

>> But I will take a deeper look into geoclue maybe we can also integrate
>> communicating with openwifi.su. Maybe we can merge the openwifi.su datas
>> into MLS as well.
>
> The last part would make the most sense but I'm pretty sure:
>
> * this has been already considered and not acted on (don't recall the reasons).

> * MLS has a *lot* more data, with a lot of duplication in Germany so
> not very sure it's very useful.

Yes, I change the plan see below.

>>>> The pro is that we have a very modular structured modules.
>>>>
>>>> In my last mail I told that I would like to write a new backed for
>>>> openwifi.su. Maybe I can realise that all wifi informations can also
>>>> integrated into MLS. So MLS will get more datas. :)
>>>
>>> I recall that I did have a look at this openwifi before MLS existed
>>> but once MLS came to being, I didn't see any point of project. I felt
>>> it was very Germany-focused project (the webpage still speaks to you
>>> in German by default).
>>

>> Yes, sure I know what you mean. But it is the only service which works
>> without authentication and SSL.
>

> I guess then you have to make a choice:
>
> * Enable SSL somehow and use MLS.
> * Use openwifi and forget about MLS completely.
>
> But of course, it's your project and your decision on what you do. :)
>
>>> Anyway, if you project has to be about openwifi, sure I understand but
>>> I still don't understand the point of putting anything in the kernel
>>> if everything can be very efficiently implemented in the user-space.
>>
>> The main idea wars to create a software application which should work with
>> all other applications they are communicating with gps hardware over tty devices.
>> That is the reason why the project is called software defined GPS.
>
> Sure but most apps are not supposed to use GPS directly. They just
> want to get the location and Geoclue already provides an API for that.
> The apps that do use GPS device directly are GPS device management
> type and they'd expect a real GPS device behind the tty node.

Ok I´ll change the plan, thank you for giving me the hint of redundancy project.

The old plan was:

In the weak project over view I plan to divide this Project into 3 or 4 sub-projects.

The first one is a restful API backend whit should include a backwards compatibly to
the old openwifi web backend. May written in Go. The New API should use MLS as fallback
if it not passible to determinate a position based on the own db entrys. As well received
WiFi information's can also redirect to MLS (if they want that).

The next is a kernel module which should communicate with the restful API and provided

a device driver under /dev as a tty driver. The Linux kernel provides GPS hardware as
tty devices. This software defined tty device should print GPS format e.g. NMEA 0183.
The goal of this kernel module is that programs like gpsd and other can easily use
this standard tty device as a normal GPS hardware. The position detection continues
over Wifi. The advantaged of this module is that devices like laptops or routers can
have simulated GPS hardware.

The last one a library should convert the NMEA 0183 format

to long-/latitude and print that.

Here is my new plan:

The first one is a restful API backend whit should include a backwards compatibly to
the old openwifi web backend. May written in Go. The New API should use MLS as fallback
if it not possible to determinate a position based on the own db entrys. As well received
WiFi information's can also redirect to MLS (if they want that).

The Kernel module will be dropt because of new infromations from geoclue.
We don't wanna do redundancy project. ;)

geoclue: I discuss with Zeeshan, the maintainer of geoclue, to build support in geoclue for
standalone GPS.

Hopefully the new plan is OK with you or do you have so other ideas? :)

cheers
Tarek

[Zeeshan Ali (Khattak)]

Hi,

On 19 May 2017 at 15:17, Jan-Tarek Butt <ta...@ring0.de> wrote:
> On 05/19/17 14:01, Zeeshan Ali (Khattak) wrote:

..snip

> Ok I´ll change the plan, thank you for giving me the hint of redundancy project.

Thanks for being so extremely flexible and cooperative. :) I rarely
see people being so rational so I wasn't expecting so much.

> The old plan was:
>
> In the weak project over view I plan to divide this Project into 3 or 4 sub-projects.
>
> The first one is a restful API backend whit should include a backwards compatibly to
> the old openwifi web backend. May written in Go. The New API should use MLS as fallback
> if it not passible to determinate a position based on the own db entrys. As well received
> WiFi information's can also redirect to MLS (if they want that).
>
> The next is a kernel module which should communicate with the restful API and provided
> a device driver under /dev as a tty driver. The Linux kernel provides GPS hardware as
> tty devices. This software defined tty device should print GPS format e.g. NMEA 0183.
> The goal of this kernel module is that programs like gpsd and other can easily use
> this standard tty device as a normal GPS hardware. The position detection continues
> over Wifi. The advantaged of this module is that devices like laptops or routers can
> have simulated GPS hardware.
>
> The last one a library should convert the NMEA 0183 format
> to long-/latitude and print that.
>
> Here is my new plan:
>
> The first one is a restful API backend whit should include a backwards compatibly to
> the old openwifi web backend. May written in Go. The New API should use MLS as fallback
> if it not possible to determinate a position based on the own db entrys. As well received
> WiFi information's can also redirect to MLS (if they want that).

Sounds fine to me. Is this supposed to be run on a remote server?

> The Kernel module will be dropt because of new infromations from geoclue.
> We don't wanna do redundancy project. ;)

Cool. Thanks.

> geoclue: I discuss with Zeeshan, the maintainer of geoclue, to build support in geoclue for
> standalone GPS.

Great! Sorry I wasn't very clear about this I think. I'm already
slowly adding this support through an external means:
https://github.com/zeenix/gps-share . Geoclue itself won't need any
modification since it already support network NMEA sources. So if you
would want to help me with this goal, gps-share is what we should
collaboratively work on. I'm attaching my vague TODO for gps-share.

Just to remind, gps-share is written in Rust for ensuring reliability.

> Hopefully the new plan is OK with you or do you have so other ideas? :)

Sure, looking forward to working with you. :)

--
Regards,

Zeeshan Ali

[Zeeshan Ali (Khattak)]

Oh and if you need more direct interaction, IRC channel #gnome-maps on
irc.gnome.org would probably be the best place.


--
Regards,

Zeeshan Ali

[Jan-Tarek Butt]

Hi,

On 05/19/17 14:34, Hanno Schlichting wrote:
> On 19. May 2017, at 14:01, Zeeshan Ali (Khattak) <zees...@gnome.org> wrote:
>> On 18 May 2017 at 18:53, Jan-Tarek Butt <ta...@ring0.de> wrote:

>>> But I will take a deeper look into geoclue maybe we can also integrate
>>> communicating with openwifi.su. Maybe we can merge the openwifi.su datas
>>> into MLS as well.
>>
>> The last part would make the most sense but I'm pretty sure:
>>
>> * this has been already considered and not acted on (don't recall the reasons).
>

> The problem is openwifi.su uses the ODbL license for its dataset, which has a share-alike requirement in it.

Right, merge is maybe not possible, But I can build the new API
like also forwarding all new incoming data as well to MLS.
This should be done without licences problems. I prefer working
together between both services. It will be very nice for openwifi.su.

> Our legal understanding is that it violates European privacy laws to release a dataset, which contains the combination of a BSSID and a lat/lon position. This combination is considered personally identifiable information.

please could you show me the privacy laws or any references?
I didn't find much while googling. :)

> If we were to integrate the openwifi.su dataset into our own, we'd be required to also release our derivative combined dataset under the Odbl. That in turn would mean we'd violate privacy laws.

right, we don't want to bring you changing your licence concept.
We just would like work close with MLS because of same concept and idea.

> This is not legal advice to anyone else and if you only operate in a single country, the situation might be different. If you are small project the chance of you being sued is also a lot smaller. But given that Google was sued and lost over this, we need to be careful.

All right, I see the most problems are in licences and laws.. that is not
really my part. But maybe we can find a good solution together :)

>>> Yes, sure I know what you mean. But it is the only service which works
>>> without authentication and SSL.
>
>

> Regarding SSL, at Mozilla we very much consider location data to be privacy sensitive. Sharing such privacy sensitive data over a non-encrypted channel is not an option for us.
>
> As for authentication, geoclue as a library ships with a built-in API key, so not every user has to get a key. These keys merely help us to attribute traffic to the various clients and act a lot more like an extended user-agent header. Since we are providing this service for free, they also give us a way to shut down access from one client library, without affecting everyone else. We never had to do so, but if someone where to abuse our service, we'd have a way to single out one client, rather than shut down the service for everyone. We specifically don't want to have an API key for a single device or user, as that would allow us to track an individual. Something we really don't want to be able to do.

I see, I fully agree with you, but about the SSL part I it is not possible to
get SSL on our routers between batman-adv mesh networks protocols and other
stuff 4MB flash is not really SSL friendly...

If wee find a good solution to build a communication between the openwifi.su
backend and MLS we definitely can use SSL because the backend will run on a
server were ssl is not a problem. To give a better view how it should worke:
the routers will comunicate with the openwifi.su server to solve SSL problems
and don't spamming your APIs. The openwifi.su backend will send the data to MLS
(if we find a way :P ). The idea on the end of the GSoC project is to integrate
the locating service in an open wireless framework from the Freifunk organisation
in Germany. Than around ~30K routers will use that services in hole Germany.
https://www.freifunk-karte.de/

cheers
Tarek

[Jan-Tarek Butt]

Hi,

On 05/19/17 17:49, Zeeshan Ali (Khattak) wrote:
> Hi,
>
>
> On 19 May 2017 at 15:17, Jan-Tarek Butt <ta...@ring0.de> wrote:

>> On 05/19/17 14:01, Zeeshan Ali (Khattak) wrote:

...

>> Here is my new plan:
>>
>> The first one is a restful API backend whit should include a backwards compatibly to
>> the old openwifi web backend. May written in Go. The New API should use MLS as fallback
>> if it not possible to determinate a position based on the own db entrys. As well received
>> WiFi information's can also redirect to MLS (if they want that).
>
> Sounds fine to me. Is this supposed to be run on a remote server?

Right, on the openwifi.su server or on the ffnw.de server infra,
we have enough capacity.

>> The Kernel module will be dropt because of new infromations from geoclue.
>> We don't wanna do redundancy project. ;)
>
> Cool. Thanks.
>
>> geoclue: I discuss with Zeeshan, the maintainer of geoclue, to build support in geoclue for
>> standalone GPS.
>
> Great! Sorry I wasn't very clear about this I think. I'm already
> slowly adding this support through an external means:
> https://github.com/zeenix/gps-share . Geoclue itself won't need any
> modification since it already support network NMEA sources. So if you
> would want to help me with this goal, gps-share is what we should
> collaboratively work on. I'm attaching my vague TODO for gps-share.
>
> Just to remind, gps-share is written in Rust for ensuring reliability.

Nice, a good friend of me started learning rust last year and I would
like to take a look as well on that language. So now I have a good
project for that, to learn it as well ;)

>> Hopefully the new plan is OK with you or do you have so other ideas? :)
>
> Sure, looking forward to working with you. :)

nice :)

cheers
Tarek

[Jan-Tarek Butt]

On 05/19/17 17:52, Zeeshan Ali (Khattak) wrote:

> On 19 May 2017 at 17:49, Zeeshan Ali (Khattak) <zees...@gnome.org> wrote:
>> Hi,
>>
>>
>> On 19 May 2017 at 15:17, Jan-Tarek Butt <ta...@ring0.de> wrote:
>>> On 05/19/17 14:01, Zeeshan Ali (Khattak) wrote:
>>

>> ..snip
>>
>>> Ok I´ll change the plan, thank you for giving me the hint of redundancy project.
>>
>> Thanks for being so extremely flexible and cooperative. :) I rarely
>> see people being so rational so I wasn't expecting so much.
>>
>>> The old plan was:
>>>
>>> In the weak project over view I plan to divide this Project into 3 or 4 sub-projects.
>>>

>>> The first one is a restful API backend whit should include a backwards compatibly to
>>> the old openwifi web backend. May written in Go. The New API should use MLS as fallback

>>> if it not passible to determinate a position based on the own db entrys. As well received

>>> WiFi information's can also redirect to MLS (if they want that).
>>>

>>> The next is a kernel module which should communicate with the restful API and provided
>>> a device driver under /dev as a tty driver. The Linux kernel provides GPS hardware as
>>> tty devices. This software defined tty device should print GPS format e.g. NMEA 0183.
>>> The goal of this kernel module is that programs like gpsd and other can easily use
>>> this standard tty device as a normal GPS hardware. The position detection continues
>>> over Wifi. The advantaged of this module is that devices like laptops or routers can
>>> have simulated GPS hardware.
>>>
>>> The last one a library should convert the NMEA 0183 format
>>> to long-/latitude and print that.
>>>

>>> Here is my new plan:
>>>
>>> The first one is a restful API backend whit should include a backwards compatibly to
>>> the old openwifi web backend. May written in Go. The New API should use MLS as fallback
>>> if it not possible to determinate a position based on the own db entrys. As well received
>>> WiFi information's can also redirect to MLS (if they want that).
>>
>> Sounds fine to me. Is this supposed to be run on a remote server?
>>

>>> The Kernel module will be dropt because of new infromations from geoclue.
>>> We don't wanna do redundancy project. ;)
>>
>> Cool. Thanks.
>>
>>> geoclue: I discuss with Zeeshan, the maintainer of geoclue, to build support in geoclue for
>>> standalone GPS.
>>
>> Great! Sorry I wasn't very clear about this I think. I'm already
>> slowly adding this support through an external means:
>> https://github.com/zeenix/gps-share . Geoclue itself won't need any
>> modification since it already support network NMEA sources. So if you
>> would want to help me with this goal, gps-share is what we should
>> collaboratively work on. I'm attaching my vague TODO for gps-share.
>>
>> Just to remind, gps-share is written in Rust for ensuring reliability.
>>

>>> Hopefully the new plan is OK with you or do you have so other ideas? :)
>>
>> Sure, looking forward to working with you. :)
>

> Oh and if you need more direct interaction, IRC channel #gnome-maps on
> irc.gnome.org would probably be the best place.

Thanks, I will join there soon.

[Hanno Schlichting]

On 22. May 2017, at 22:39, Jan-Tarek Butt <ta...@ring0.de> wrote:
>> Our legal understanding is that it violates European privacy laws to release a dataset, which contains the combination of a BSSID and a lat/lon position. This combination is considered personally identifiable information.
>
> please could you show me the privacy laws or any references?
> I didn't find much while googling. :)

I have a fairly old blog post up at http://blog.hannosch.eu/2013/12/mozilla-location-service-what-why-and.html <http://blog.hannosch.eu/2013/12/mozilla-location-service-what-why-and.html>. Skip to the "Privacy" section for the interesting bits.

The best, but also very lengthy analysis is from the Dutch Data Protection Agency available at https://autoriteitpersoonsgegevens.nl/sites/default/files/downloads/mijn_privacy/en_pb_20110811_google_final_findings.pdf <https://autoriteitpersoonsgegevens.nl/sites/default/files/downloads/mijn_privacy/en_pb_20110811_google_final_findings.pdf>. Of particular note is section 4.3.

That report is hard to read, as Google was fined for both accidentally collecting the traffic of unencrypted WiFi networks, as well as doing metadata (BSSID, lat/lon) collection. Most of the report covers the former. In the US there were cases against Google for wiretapping charges, which covered the first offense. The metadata collection was to my knowledge not investigated or might not be illegal in the US. Several bills proposed to Congress/the Senate to regulate location privacy in the US never made it past the draft state.

As detailed in my blog post, there was a media hype around location privacy topics during those years. The industry standard of "you need to know two nearby" WiFi networks got established as a result, as well as the "_nomap" opt-out approach. The combination of those two satisfied the Dutch DPA, and it allowed geolocation services to continue to be operated. They have some more news articles on their site about this, search for "Google WiFi" on https://autoriteitpersoonsgegevens.nl/en <https://autoriteitpersoonsgegevens.nl/en>.

Cheers,
Hanno