Help us with this petition for security on anti-collision systems

On Thu, 28 May 2015 14:22:41 +0200, pcool wrote:

I fully agree with Bob, it is pointless to ask Flarm to open the
protocol. What we need is several other manufacturers selling their own
devices, based on the OGN open software for example. I have not signed
the petition for this reason.

IIRC the reason that FLARM encrypted the protocol was that the OGN crew
were refusing to honour the 'do not track' bit thus exposing the
whereabouts of people who didn't want to be tracked.

In view of that record, why should we trust OGN to do the right thing?

I won't sign the petition either. If DSX want to sell anti-collision kit,
let them drop their NIH attitude and join LX etc in using the de-facto
standard protocol. As long as FLARM sell licences to allow third parties
to use it they are no better or worse than, e.g. Oracle with their
proprietary attitude to Java or the companies who hold patents that
widely used wireless comms standards depend on: think WiFi.

BTW, has the DSX protocol been published? On a Creative Commons or GPL
license?


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

At 12:47 28 May 2015, Martin Gregorie wrote:
On Thu, 28 May 2015 14:22:41 +0200, pcool wrote:

I fully agree with Bob, it is pointless to ask Flarm to open the
protocol. What we need is several other manufacturers selling their own
devices, based on the OGN open software for example. I have not signed
the petition for this reason.

IIRC the reason that FLARM encrypted the protocol was that the OGN crew
were refusing to honour the 'do not track' bit thus exposing the
whereabouts of people who didn't want to be tracked.

In view of that record, why should we trust OGN to do the right thing?

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on reasonably
up-to-date Firmware.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never sent to
the Server.

I won't sign the petition either. If DSX want to sell anti-collision kit,

let them drop their NIH attitude and join LX etc in using the de-facto
standard protocol. As long as FLARM sell licences to allow third parties
to use it they are no better or worse than, e.g. Oracle with their
proprietary attitude to Java or the companies who hold patents that
widely used wireless comms standards depend on: think WiFi.

BTW, has the DSX protocol been published? On a Creative Commons or GPL
license?

On Thu, 28 May 2015 13:58:39 +0000, Tim Newport-Peace wrote:

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on reasonably
up-to-date Firmware.

By Easter Egg, do you mean the protocol expiry date? If so its not what I
was talking about and I don't have a problem with it: given that FLARM
was designed for small, low-powered hardware, syncing protocol version
that way makes a helluva lot more sense that having to maintain backward
compatibility over the last 'n' protocol versions just because some lazy
git can't be bothered to keep his software up to date.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never sent
to the Server.

Not necessarily: you can't guarantee anything like that if the receiver
is the result of a third party reverse engineering project, which is what
I've always heard about the RPi-hosted FLARM receiver units. If the
software author decides he wants to see everybody and ignores that bit
then pop goes your invisibility cloak.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

At 22:44 28 May 2015, Martin Gregorie wrote:
On Thu, 28 May 2015 13:58:39 +0000, Tim Newport-Peace wrote:

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on
reasonably
up-to-date Firmware.

By Easter Egg, do you mean the protocol expiry date? If so its not what I

was talking about and I don't have a problem with it: given that FLARM
was designed for small, low-powered hardware, syncing protocol version
that way makes a helluva lot more sense that having to maintain backward
compatibility over the last 'n' protocol versions just because some lazy
git can't be bothered to keep his software up to date.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never
sent
to the Server.

Not necessarily: you can't guarantee anything like that if the receiver
is the result of a third party reverse engineering project, which is what

I've always heard about the RPi-hosted FLARM receiver units. If the
software author decides he wants to see everybody and ignores that bit
then pop goes your invisibility cloak.

In which case it is not an OGN receiver any longer.

"Don’t believe anything you read on the net. Except this.
Well, including this, I suppose."

DOUGLAS ADAMS (1952-2001)

On Fri, 29 May 2015 08:04:52 +0000, Tim Newport-Peace wrote:

At 22:44 28 May 2015, Martin Gregorie wrote:
On Thu, 28 May 2015 13:58:39 +0000, Tim Newport-Peace wrote:

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on
reasonably
up-to-date Firmware.

By Easter Egg, do you mean the protocol expiry date? If so its not what
I

was talking about and I don't have a problem with it: given that FLARM
was designed for small, low-powered hardware, syncing protocol version
that way makes a helluva lot more sense that having to maintain backward
compatibility over the last 'n' protocol versions just because some lazy
git can't be bothered to keep his software up to date.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never
sent
to the Server.

Not necessarily: you can't guarantee anything like that if the receiver
is the result of a third party reverse engineering project, which is
what

I've always heard about the RPi-hosted FLARM receiver units. If the
software author decides he wants to see everybody and ignores that bit
then pop goes your invisibility cloak.

In which case it is not an OGN receiver any longer.

Indeed. Its just a bit sad that the authors of the original OGN received
got so dogmatic over their "all data must be displayed because I said so"
attitude that they forced the use of encryption to enforce the data
source's right to privacy.

IMO that makes them more akin to the most intrusive internet ad-slingers
than to normal glider pilots.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |