Voice Codecs, NDAs and Open Source

[Craig Watson 1344682]

Firstly, there has been a lot of discussion over on VATUK's forums over the last week or two about the much-maligned voice codec, and how the situation could be improved. Link here. Some very good points have been raised, and I'd like to pick up a few of those points here for the wider VATSIM community.

 

I've read several forum threads that have descended into flame-wars on open source, and I am not looking to start another one, so can everyone please respect this, and think before posting inflammatory responses.

 

---

 

In the nature of full disclosure, I will say the following: I am a technologist at heart, and a vocal proponent of open source software and ideals. I am a professional Linux systems administrator with many years of experience and somewhat of a specialism in DevOps and Agile practices and automation, and generally tend to work in a management-less environment with the emphasis very much on "Get The Stuff Done" - less time having endless committee meetings, more time actually doing stuff that matters.

 

I have designed, implemented and maintained high-traffic, UK-wide, scalable systems using the latest technologies including AWS and Puppet, have written numerous Puppet modules on GitHub, and presented at Puppetlabs' PuppetCamp Stockholm event in November 2015, as well as open source projects for several other communities. More info is on my GitHub.

 

---

 

I understand that the vast majority of the underlying code and protocols behind VATSIM are locked down and only handed to developers under an NDA. I'm not necessarily opposed to the concept of an NDA (though it does irk me on a personal level). What I am opposed to however, is an NDA that is imposed due to selfish, impractical reasons.

 

I am not a lawyer, but having worked with, written and released open source software, the issue of copyright and legality is absolutely moot. If you have a problem with the virus-like GP, use the ASL - as I do with all of my projects. That way, copyright, ownership and credit is maintained, but the code remains open for use and improvement. There other licenses besides the GPL and MIT/BSD - use them.

 

The issue of control can be nicely dealt with too - with Git (and specifically GitHub), you have one single authoritative branch of your code. Others can fork it, modify it, and then submit a pull request back to the original. If the author isn't happy with either the quality, direction or any other aspect of the request, they can deny it. Committing to "master" is actively discouraged, and outright impossible with the correct permissions setup - I have worked in this way for many years, and never ever had a problem.

 

Then there's the danger of forks of the codebase being used to start up new networks. This is just childish and based on insecurity of a problem that does not exist. If the code that VATSIM puts out there is good enough, what possible reason would anyone have for starting up a new network? Surely the amount of leg-work necessary is a significant barrier to entry. How many people would be bothered enough to do it? And even then, how many people could then be dragged away from VATSIM, after investing a significant amount of time and effort in attaining ratings?

 

Now, I've just spent a lot of words slamming the NDA. I'll now spend a few stating how open-sourcing components will actually help the network.

 

For a start, it will lift the bottleneck on VATSIM's under-strain developers, and open up the code-base to a legion of potential maintainers. Old clients would no longer be left to rot, and the "core" developers can actually concentrate on furthering the network and fixing real problems, as opposed to patching and supporting an already-creaky system.

 

For example, if VATSIM were to agree on adopting the new Opus system, old clients could be patched by knowledgeable community members (while at the same time being QA'd by core developers), and abandoned clients could be patched and updated to use new codecs and network improvements - completely removing the extremely sticky subject of how to handle out-of-date clients. Want your client to work? Just update the client. No need to buy a new simulator.

 

There's also the fact that open source is the de facto standard for hobby communities in the 21st century. Almost every developer I've seen hired in the last 4 or 5 years have had a GitHub. There's so, so much untapped talent out there that can be harnessed to drive the network forward.

 

I'd be very, very interested in hearing why an NDA is in place, and even more interested in reasons why an NDA is still relevant in 2016.

 

Also - if any of the developers of Swift are reading this: you say your client is open source. Where's the source? Your project website makes lots of references to repositories, but doesn't actually link to them.

Edited January 27, 2016 at 05:28 PM by Guest

[Mike Evans]

For example, if VATSIM were to agree on adopting the new Opus system, old clients could be patched by knowledgeable community members (while at the same time being QA'd by core developers), and abandoned clients could be patched and updated to use new codecs and network improvements - completely removing the extremely sticky subject of how to handle out-of-date clients. Want your client to work? Just update the client. No need to buy a new simulator.

 

You're misunderstanding how the client process works.. VATSIM doesn't own any of the clients, they have a license to use them. This license does not include the right to the source code, etc.. the NDA protects the protocol docomeents & VATSIM specific libraries, it doesn't give any rights to the clients to VATSIM unless the authors specifically grant them.

[Craig Watson 1344682]

You're misunderstanding how the client process works.. VATSIM doesn't own any of the clients, they have a license to use them. This license does not include the right to the source code, etc.. the NDA protects the protocol docomeents & VATSIM specific libraries, it doesn't give any rights to the clients to VATSIM unless the authors specifically grant them.

 

I'm not necessarily querying how it works - I understand that core libraries are provided under NDA to developers under license, However, I am asking outright why the NDA even exists at all, and if the time has now come for the VATSIM core development team to embrace being more open and to lead from the front.

 

Why bother open-sourcing a client when you have a locked-down, licensed binary in the middle that provides core functionality? If the entire ecosystem was more open, then clients would be more likely to adopt open development, and in turn if individual developers lost interest, gave up their clients, or just "fell out" of the community, development could be forked and improvements to the software would at least be able to continue.

[Colin Schoen]

I agree with you for the most part and have had this conversation quite a few times.

 

Progress is being made and VATSIM truly has been making great strides in becoming more "open". One example includes the publicly available SSO. Open sourcing the protocol and server code is ultimately at the discretion of the founders.

 

With that said there are some real benefits of keeping access to the protocols restricted. There are some things that help keep troublemakers and abusers away very efficiently that wouldn't be so effective if the source was public.

 

It is a trade off. If you are interested in helping develop, the BoG has been making a serious effort to make the NDA process more painless and happen within 30 days. Perhaps you should consider signing it.

[Craig Watson 1344682]

Progress is being made and VATSIM has really been making great strides in becoming more "open". Some examples include the publicly available SSO. Open sourcing the protocol and server code is ultimately at the discretion of the founders.

 

That last sentence says it all, really.

 

There are some things that help keep troublemakers and abusers away very efficiently that wouldn't be so effective if the source was public.

 

Can you give some examples here? Are we talking security holes, copyright infringement, or people starting up their own networks and stealing VATSIM members?

 

If you are interested in helping develop, the BoG has been making a serious effort to make the NDA process more painless and happen within 30 days. Perhaps you should consider signing it.

 

I would never in a million years sign any kind of NDA docomeent that is not related to my occupation and employer (and even then it would be through gritted teeth), so I'll have to decline here.

 

Development on any platform should be because people actively want to help - this is a community, after all. What the BoG don't realise is that any kind of imposed NDA really creates more problems than it solves - and only serves the established status quo, not the community they are supposedly there to serve.

[Ernesto Alvarez 818262]

Can you give some examples here? Are we talking security holes, copyright infringement, or people starting up their own networks and stealing VATSIM members?

 

 

network has been around for over 20 years (previously under SATCO). in that time it has seen its fair share of attacks, trolls, hackings, etc...

 

call it fear or what have you, but i do believe they have a pretty darn good idea of what could happen if they dont protect that key part, until the day comes when the way you connect to the network and the security protocols change.

 

FSD is open source, anyone and their grandma can start their own network, thats not what they are worried about

[Don Desfosse]

Open sourcing the protocol and server code is ultimately at the discretion of the founders.

That last sentence says it all, really.

Maybe I'm reading you incorrectly, but that looks to me like a bash of the founders. Before you do that, you may want to understand what proposals have been presented to the EC and/or BoG, and what plans, if any were taken to the Founders. I'm not aware of any. So please don't bash people for not making a decision that they haven't been even approached about making.....

 

As for your sentiments about the need to make progress so we don't decline, I completely agree. We need to make the hard decisions about the tradeoffs involved with losing an infinitely small percentage of our membership who cannot keep pace with advancing technology vs. losing the ability to keep pace with at least semi-current technology and risk losing a much larger percentage as a result. If you're not moving forward, you're moving backward. That said, there are surely some security protections involved that may still be needed. I'm not smart enough to know what can move forward (e.g. codecs and cutting the tie to backwards compatibility with abandoned clients) and what absolutely has to remain. I trust that some of the latter exists, but it would be really good to have a visionary project leader attempt to segregate the two.

[Colin Schoen]

There are some things that help keep troublemakers and abusers away very efficiently that wouldn't be so effective if the source was public.

 

Can you give some examples here? Are we talking security holes, copyright infringement, or people starting up their own networks and stealing VATSIM members?

 

 

I cannot.

 

What the BoG don't realise is that any kind of imposed NDA really creates more problems than it solves - and only serves the established status quo, not the community they are supposedly there to serve.

 

Based on your CID I gather you are rather new to the network. I suggest that you really take a close look at what has and hasn't been discussed on this topic before making blanket accusations like above. The BoG is well aware of the issues with the NDA. They have a different perspective than you and some issues become more prominent when you are tasked with protecting the network and its membership rather than just developing software. Just because you don't agree with them doesn't mean they aren't informed about the situation.

Edited January 27, 2016 at 07:14 PM by Guest

[Ross Carlson]

I am asking outright why the NDA even exists at all

 

I've been a VATSIM developer for 10 years, I served on the BoG, and I still don't know the answer to that question. I know it has been answered for me before, but right now I cannot recall the specific reasons for the NDA's existence.

 

I don't think you'll find the correct answer in the forums. My suggestion would be for you to contact the BoG directly and ask the question.

 

And if you decide to do so, I politely suggest that you leave edgy, subjective statements such as this out of the discussion:

 

Then there's the danger of forks of the codebase being used to start up new networks. This is just childish and based on insecurity of a problem that does not exist.

 

Note that I agree that the danger of other networks supplanting VATSIM just because we made our tech open source is not a real danger. I just think you will have a more productive discussion without calling the founders/BoG childish.

 

As for my own opinions on the matter, I'm totally fine with making my clients open source if VATSIM decides as a whole to open everything up.

 

One thing I'm unsure about, though, is how we would deal with new clients that don't follow the established protocols for how things are done in terms of client-to-client interaction, especially between ATC clients. For example, there is a fairly strict set of packets that need to flow back and forth when things like a handoff occurs. If we open everything up, and someone develops a new client that doesn't follow the sequence correctly, it could cause issues for other controllers. I'd love to hear ideas from Craig or others on how we would manage that sort of thing. Maybe we'd have to make the server more intelligent about validating packets?

 

In other words, how do we ensure the integrity (for lack of a better term) of the network in the wild west of open source?

[Craig Watson 1344682]

network has been around for over 20 years (previously under SATCO). in that time it has seen its fair share of attacks, trolls, hackings, etc...

 

I'm not sure I see this as a reason to keep the network closed-source. Every platform, whether it is open or closed, has its share of hacks. Just look at the Apache webserver, OpenSSH, Firefox, Google Chrome, Android and the Linux kernel. In fact, open source projects could be argued to be more secure, as there are far, far more eyes available to pour over the codebase than any software company can muster.

 

i do believe they have a pretty darn good idea of what could happen if they dont protect that key part

 

Change?

 

Maybe I'm reading you incorrectly, but that looks to me like a bash of the founders.

 

Not bashing, necessarily. I'm getting at the fact that it feels as if the NDA which - IMO - is at the crux of holding the community back, is there to protect the interests of the status quo.

 

Based on your CID I gather you are rather new to the network.

 

This is true.

 

... some issues become more prominent when you are tasked with protecting the network and its membership rather than just developing software.

 

As above, I'm not sure how open source is automatically putting the security of the network at risk. This kind of (supposed) viewpoint is what feeds the view that the BoG are out of touch with 21st century technology.

 

Just because you don't agree with them doesn't mean they aren't informed about the situation.

 

Also true, however it's difficult to know if people are "informed about the situation" unless there is actual progress - which it seems is glacially slow, and is in fact so slow that users are gradually getting more and more frustrated, and will end up leaving the network.

 

I've been a VATSIM developer for 10 years, I served on the BoG, and I still don't know the answer to that question. I know it has been answered for me before, but right now I cannot recall the specific reasons for the NDA's existence.

 

This. Simply this. If nobody can recall a concrete reason why beauocracy exists, it should not exist.

 

And if you decide to do so, I politely suggest that you leave edgy, subjective statements such as this out of the discussion:

 

I'm purely voicing concern that has been raised elsewhere - the edge is entirely intentional, and very real.

 

how do we ensure the integrity (for lack of a better term) of the network in the wild west of open source?

 

By establishing and publishing standards, and not allowing code to be merged without prior QA. The open source world really isn't the "wild west" where literally anyone can contribute - if you do it properly.

Edited January 27, 2016 at 08:06 PM by Guest

[Ross Carlson]

I'm purely voicing concern that has been raised elsewhere - the edge is entirely intentional, and very real.

 

That's your choice of course, I'm simply suggesting that you leave the insults out of it. I know that I for one am less likely to have any desire to engage in discussion with someone that calls me childish. In other words, your (IMO valid) opinion can be expressed without the insults, and doing so will usually help make the other party more receptive to the argument.

 

how do we ensure the integrity (for lack of a better term) of the network in the wild west of open source?

 

By establishing and publishing standards, and not allowing code to be merged without prior QA. The open source world really isn't the "wild west" where literally anyone can contribute - if you do it properly.

 

Maybe I'm misunderstanding just how open you're suggesting that the VATSIM tech should become. What you're saying here works for existing clients and the server, where someone can take the lead on code review and merging pull requests, but what about new clients? Say I'm a developer who wants to write a new pilot client and post it up on my web site for any VATSIM user to download and run. How do we ensure that such clients are written correctly? There's no core dev team that controls the code or the distribution of built executables in that case ... that's what I mean by wild west.

[Craig Watson 1344682]

That's your choice of course, I'm simply suggesting that you leave the insults out of it. I know that I for one am less likely to have any desire to engage in discussion with someone that calls me childish. In other words, your (IMO valid) opinion can be expressed without the insults, and doing so will usually help make the other party more receptive to the argument.

 

Point taken, but the ire that has perhaps boiled over is extremely real, and it has to be said, is not just mine alone. I originally wrote the post with the intention of asking how it can be that a "community" can be so closed, but the more I wrote, the more frustration came out.

 

The original catalyst to this discussion was the voice problems that have plagued a vast number of people for a long time (and have consequently been put aside as PEBKAC issues). I then looked into why those problems exist, and eventually found an organisation that seems to be effectively ruled by committee, software that is crying out for modernisation but is being held back by a set of outdated protocols that were decided by the aforementioned committee - all with very little (or glacially slow) progress or shows of intent to change.

 

Personally, VATSIM has the potential to become an awesome open community, where any talented developer can write any tool they choose that makes more people join VATSIM and actually enjoy the experience. I'm specifically thinking of an HTML5 cross-platform voice client, or a Linux/Mac port of Euroscope - the Windows-centric side to VATSIM is something that I sincerely hope will change, given enough involvement and encouragement. I actually don't own a Windows machine, so I'm running Euroscope within a dedicated Windows 10 VM on my MacBook - but hey, hacky hacks are hacky.

 

Maybe I'm misunderstanding just how open you're suggesting that the VATSIM tech should become. What you're saying here works for existing clients and the server, where someone can take the lead on code review and merging pull requests, but what about new clients? Say I'm a developer who wants to write a new pilot client and post it up on my web site for any VATSIM user to download and run. How do we ensure that such clients are written correctly? There's no core dev team that controls the code or the distribution of built executables in that case ... that's what I mean by wild west.

 

This can be covered very, very easily - by docomeentation, and also trust. The HTTP protocol has a defining RFC docomeent, as does SMTP, as does TLS, as does TCP and even the Opus codec.

 

Basically, VATSIM writes the RFC, which then determines if a client is suitable for the network. To be "VATSIM Compliant", for example, a client needs to communicate with servers on TCP port 3471, and needs to use version 1.x of the Opus codec and transmit mono sound at 64kbps CBR , using the 44.1KHz sample rate.

 

Even if in reality, the vast majority of development is done by VATSIM Core developers, at least the specification of what constitutes a "compliant" client is out there and public, and can be built upon by any developer. Take a look at Bitcoin as an example of what I'm talking about. The entire technology stack is open source, and there's an insane community surrounding it.

 

Using that example, I had an itch to scratch. I run a few full-nodes and wanted a way to show them off to the world. The Bitcoin daemon provides an RPC interface, and someone else had very kindly written a PHP library that interfaced very nicely with it, and open sourced it under the MIT license. I used - and fully credited - the library to create my own status page application (which has since had contributions from numerous third-parties adding functionality and fixing bugs). My application is distributed under the Apache Software License, which maintains my rights as the owner of the software, but is less "viral" than the GPL and doesn't require derivative works to explicitly use the ASL - or even distribute the source.

 

If you want to get really fancy, you could use a certificate authority (either real or self-signed) and only accept connections from clients presenting a signed certificate - to be a "certified" client, a developer would need to provide a CSR which is then signed by the VATSIM CA. Puppet uses a similar mechanism to authenticate nodes.

Edited January 27, 2016 at 09:17 PM by Guest

[Ross Carlson]

This can be covered very, very easily - by docomeentation, and also trust. The HTTP protocol has a defining RFC docomeent, as does SMTP, as does TLS, as does TCP and even the Opus codec.

 

Basically, VATSIM writes the RFC, which then determines if a client is suitable for the network. To be "VATSIM Compliant", for example, a client needs to communicate with servers on TCP port 3471, and needs to use version 1.x of the Opus codec and transmit mono sound at 64kbps CBR , using the 44.1KHz sample rate.

 

It goes without saying that we would provide docomeentation on how to write a compliant client. We already do that. The question is what do we do about non-compliant clients? We can publish compliance guidelines all day long, but how do we enforce them?

 

If you want to get really fancy, you could use a certificate authority (either real or self-signed) and only accept connections from clients presenting a signed certificate - to be a "certified" client, a developer would need to provide a CSR which is then signed by the VATSIM CA. Puppet uses a similar mechanism to authenticate nodes.

 

Now you're getting to the heart of the matter. We do something like this now, but the current mechanism is not compatible with open source. I don't think I can go into details without violating my NDA. I'm wondering if using certificates would have the same problem: how does the server know if the certificate is actually being presented by the client it was issued for?

 

This is where we bump into the limit of my knowledge about how certificate systems really work, so I'm probably missing something obvious and this may be a really stupid question, but if VATSIM issues a client certificate to Client A, what's to stop someone from using that certificate with a new client that they build, Client B, since presumably that certificate would need to be distributed with Client A's executable?

[Craig Watson 1344682]

We can publish compliance guidelines all day long, but how do we enforce them?

 

Possibly by using a variant on the HTTP 400 "Malformed Request" response header. If you write a server application so permissive that any client can connect and send garbage, then yes - you will have problems.

 

If, however, the server software is intelligent enough to reject non-compliant requests, you are than indirectly enforcing the standard in software.

 

I don't think I can go into details without violating my NDA.

 

Now this sentence is every single thing that is wrong with the current NDA. Solutions are being discussed to a known problem in an open, public forum, and those discussions are being hampered by a piece of (IMO) pointless bureaucracy. BoG - please, please take note of this. It's insane.

 

I'm wondering if using certificates would have the same problem: how does the server know if the certificate is actually being presented by the client it was issued for?

 

Not a foolproof system, granted - certificates was used as an example of what might be possible rather than a serious suggestion.

 

That said, I don't necessarily see the need to validate clients of the server is able to determine what is and is not a valid request - anything that can talk HTTP is able to contact a webserver for example - and there is no central authority defining or certifying web browsers or CLI clients.

 

Obviously HTTP is a text-based protocol instead of media-based, but the basic guiding principle is the same. Ultimately the VATSIM network shouldn't care what clients are being used - having an open standard means literally anything is possible. Surely that can only be a good thing.

 

More clients = wider target audience = more diverse user base = more loyal users = better reputation = even more users = better experience = more realistic traffic levels = happier pilots and controllers ... rinse and repeat?

[Colin Schoen]

What if someone writes a client that makes it easy to disrupt others by deliberately hovering over aircraft and spamming text frequencies or someone implements the VVL protocol creating a client which facilitates the use of sound cards to play music over frequency.

 

Yes if we had an infinite amount of man power we could build in more advanced spam/disruption checks, but it would always be possible to get around them with enough work.

 

It is nearly impossible to 100% enforce connections are coming from nonmalicous clients if the protocol is open sourced.

 

These are nontrivial problems that have serious and irreversible consequences. It isn't as simple as just "open sourcing" the protocols.

[Craig Watson 1344682]

What if someone writes a client that makes it easy to disrupt others by deliberately hovering over aircraft and spamming text frequencies or someone implements the VVL protocol creating a client which facilitates the use of sound cards to play music over frequency.

 

What's stopping me plugging my iPhone into my microphone or line-in port and holding down my PTT key - with the current protocol and client software?

 

Yes if we had an infinite amount of man power we could build in more advanced spam/disruption checks, but it would always be possible to get around them with enough work.

 

I don't see the link between "closed source" and "less bugs" or "more secure". That way of working is as out-dated as the dot matrix printer, and is no longer true - it's security by obscurity at best, which is as near as makes no difference to no security at all.

 

It is nearly impossible to 100% enforce connections are coming from nonmalicous clients if the protocol is open sourced.

 

No, it's very very possible - you just move the authentication layer to the server architecture, where it belongs, and if you're seriously paranoid, you can either GPG the client binaries or ask client developers to opt-in to having their code signed by a VATSIM certificate.

 

These are nontrivial problems that have serious and irreversible consequences.

 

I'm not disputing this. Ignoring them altogether is even more serious and will end up with users getting fed up and either defecting or leaving the hobby altogether - both of which have actually happened already.

 

I'm attempting to table a way for that to happen.

 

It isn't as simple as just "open sourcing" the protocols.

 

Of course it's not - I never suggested that it was "just" that simple. However, the open source way does have a ton of advantages that can actually help drive the network forward and can enable more contributions from more people, which in turn will allow the network to adopt new technologies faster.

[Ross Carlson]

We can publish compliance guidelines all day long, but how do we enforce them?

 

Possibly by using a variant on the HTTP 400 "Malformed Request" response header. If you write a server application so permissive that any client can connect and send garbage, then yes - you will have problems.

 

If, however, the server software is intelligent enough to reject non-compliant requests, you are than indirectly enforcing the standard in software.

 

Right, so we're back to my original thought which was to build intelligence into the server. I don't really see a way around that. However, we should be careful not to trivialize the amount of effort that would be required there. The HTTP analogy has come up in these discussions numerous times in the past, and on the surface, it seems like a valid comparison, but it's not. HTTP is a simple stateless request/response protocol. Each request can be validated in isolation. Not so with VATSIM, where the question of the validity of any given packet sent to the server is *sometimes* more complicated.

 

I'll see if I can articulate an example of an easy validation problem and a complex one.

 

For the easy problem, let's say we want the server to enforce the rule that a pilot client should be sending position updates at a rate of 1 every 5 seconds. That's very simple ... you just measure the interval between updates and if it falls outside an acceptable range, allowing for network lag, you disconnect the client.

 

For a more complex problem, let's say we want the server to enforce the rule that an ATC client, when responding to a query from another ATC client as to who has track control over an aircraft, must respond with the aircraft's current [Mod - Happy Thoughts]igned beacon code, temporary altitude, and voice capabilities. You can see how that becomes more complex to enforce that rule on the server. (In fact, I would advocate for changing the protocol completely so that the client doesn't propagate that aircraft state info, and the server does it instead.)

 

Maybe at the end of the day it doesn't matter ... maybe if someone writes a client that doesn't follow the spec, then nobody will use it. That feels like a naive attitude to me though.

 

I'm wondering if using certificates would have the same problem: how does the server know if the certificate is actually being presented by the client it was issued for?

 

Not a foolproof system, granted - certificates was used as an example of what might be possible rather than a serious suggestion.

 

Damn ... I was hoping you knew of a way we could use certificates and actually be able to reliably validate the client software that was connecting to the server, and still be compatible with open source development. That would certainly alleviate the last of my concerns.

 

That said, I don't necessarily see the need to validate clients of the server is able to determine what is and is not a valid request - anything that can talk HTTP is able to contact a webserver for example - and there is no central authority defining or certifying web browsers or CLI clients.

 

Obviously HTTP is a text-based protocol instead of media-based, but the basic guiding principle is the same. Ultimately the VATSIM network shouldn't care what clients are being used - having an open standard means literally anything is possible. Surely that can only be a good thing.

 

Agreed ... and this is the same conclusion that we came to in the past when I've had this very same discussion with other developers. If the network can protect itself from poorly-written clients, then there's no reason not to open the protocol up. I'm just not sure that's as easy as some may think it is. It certainly seems to be a more complex problem than the web browser/web server problem which is often brought out as an analogy. I've been trying to think of another open source system that could serve as a better analogy, but so far I'm striking out. Maybe IRC?

 

What if someone writes a client that makes it easy to disrupt others by deliberately hovering over aircraft and spamming text frequencies or someone implements the VVL protocol creating a client which facilitates the use of sound cards to play music over frequency.

 

We're protected from maliciousness by virtue of the fact that every connection is authenticated. What we're discussing here is poorly-written *clients*, not poorly-behaved *users*.

[Colin Schoen]

What if someone writes a client that makes it easy to disrupt others by deliberately hovering over aircraft and spamming text frequencies or someone implements the VVL protocol creating a client which facilitates the use of sound cards to play music over frequency.

 

We're protected from maliciousness by virtue of the fact that every connection is authenticated. What we're discussing here is poorly-written *clients*, not poorly-behaved *users*.

 

Sure on the FSD side of things, but certainly not VVL.

[Ross Carlson]

Sure on the FSD side of things, but certainly not VVL.

 

That's actually a problem that we have now. Going open source wouldn't really change much in that regard. If anything, one could argue that going open source might actually improve things because it would theoretically increase the chances of someone volunteering to rewrite the voice architecture so that it has user authentication on the connection.

 

Anyway, my point is that malicious users isn't the concern ... that can be dealt with via authentication. My concern is more nebulous and harder to define ... that is, how to deal with clients that aren't written well and don't play nice with other clients. I feel like we need to be able to control which clients connect to the network, and I'm not sure how best to accomplish that in an open source developer ecosystem. I'd love to see us come up with a solution, though.

 

Maybe it's not even a problem ... maybe if a client is found to be poorly written, the issue will be identified and the author will be motivated to fix it, and it'll get fixed before it causes too much disruption on the live network.

[Bradley Grafelman]

Maybe it's not even a problem ... maybe if a client is found to be poorly written, the issue will be identified and the author will be motivated to fix it, and it'll get fixed before it causes too much disruption on the live network.

Similar to what has already happened on the ATC side of things with the Euroscope ModeS plugin?

[Craig Watson 1344682]

An email that I have just sent to [email protected], [email protected] and [email protected]:

 

Dear all,

 

Despite being only a recent addition to the VATSIM membership, I have been an admirer of the VATSIM network for many years.

 

I would like to draw your attention to recent discussions in the VATSIM.net message forums [1] and VATUK’s forums [2], regarding the much-maligned voice codec and the largely negative effect it is having both on VATSIM’s pilots and controllers. A lot has been said about the more practical parts of the equation (i.e. user setup), but there is no denying the fact that VATSIM’s network (and debatably the leadership style) is in dire need of modernisation.

 

As well as this, I personally feel that there is no real need to continue the use of an NDA - and in actual fact the use of such a docomeent does more to harm the community than it does to protect it. I would be extremely interested in hearing reasons why this is in place, with practical examples of areas where the NDA would actually be useful - I have not heard one yet.

 

To this end, I genuinely and truthfully believe that the best way forward for the network would be to start the process of open-sourcing the core VATSIM codebase, with a view to VATSIM becoming fully open source in the future. The reasons for this belief are detailed at length in the VATSIM.net forum post [1].

 

There will of course be many challenges in this approach - both technical and legal - and I would like to offer my [Mod - Happy Thoughts]istance to you officially. Unfortunately I’m unable to offer practical [Mod - Happy Thoughts]istance and programming ability due to time constraints and the fact that my professional occupation is a systems administrator rather than developer, however I’m more than happy to offer advice and guidance on any open-source related queries you may have, as I have been a member of the open source community for many years and have written, maintained and distributed a fair number of projects, with a couple having full community involvement - all of which are available via my GitHub.

 

My computer science bachelors degree (which I p[Mod - Happy Thoughts]ed with a 2:1 in 2010) also contained a module on open source technologies, including the licensing arrangements and potential pitfalls. I am, however, not a lawyer and so wouldn’t be able to give full legal advice, but would happily give guidance on open source matters.

 

Please do not hesitate to get in touch if I could be of any help to the VATSIM community. That said, my offer of [Mod - Happy Thoughts]istance does not mean that I would consider signing the NDA, and if doing so is necessary for my [Mod - Happy Thoughts]istance to be useful, I will withdraw my offer.

 

In the interests of openness, this email will also be posted in full to the VATIM.net forum.

 

Kind regards,

Craig Watson

 

VID: 1344682

GitHub: https://github.com/craigwatson

Personal Blog: https://cwatson.org/

 

[1] viewtopic.php?f=6&t=70380

[2] http://community.vatsim-uk.co.uk/topic/32637-vatsim-isnt-fun-anymore-why-read-on

[Don Desfosse]

A question: Wouldn't you need to sign the NDA to understand it's contents and reasons behind them to understand how to provide effective rationale as to what parts of it, including potentially all, aren't needed and a preliminary design concept to move forward? It's like me stating there are processes and procedures that are inefficient and wasteful at an Airbus [Mod - Happy Thoughts]embly plant, never having stepping in that plant nor having read/seen their processes and procedures in action, even though I understand how aircraft are built and am a subject matter expert on manufacturing process optimization, saying I am more than willing to help you fix the problem, but refuse to sign an NDA required to read your current competition-sensitive processes. Ultimately, because I refuse to sign an NDA, I won't be allowed access to the processes, and therefore cannot provide an educated opinion about what can be optimized. In other words, you didn't really offer any help. I'd think that to truly be helpful, you'd need to be trusted enough based on your professional credentials and abilities to be used as a consultant, sign the NDA, understand all the whats and whys, and then make an educated proposal on how to move forward.

[Craig Watson 1344682]

There is an important distinction to be made here: I am more than happy to see the NDA docomeent, but I will not sign or be governed by it.

 

A question: Wouldn't you need to sign the NDA to understand it's contents and reasons behind them to understand how to provide effective rationale as to what parts of it, including potentially all, aren't needed and a preliminary design concept to move forward?

 

Because the basic nature of a Non-Disclosure Agreement is to state that I am not able to discuss the NDA'd details in an open and transparent public arena - and it's something which I feel extremely strongly that should be possible in the 21st century.

 

While I'm happy to offer my [Mod - Happy Thoughts]istance to the BoG in dealing with open source matters, I'm not willing to be governed by any legally-binding agreement that would end up hampering my ability to provide the [Mod - Happy Thoughts]istance in the first place.

 

This illustates my point when I say that the NDA does not serve the community at large, only the vested interests of a small minority - I have not found a single individual case where me having signed an NDA would be even remotely useful to either VATSIM or the wider community.

 

In fact, the use of an NDA actually discourages involvement from the community. I work with developers on a daily basis, and have done for years - developers who actively contribute to a whole host of open source projects, who have a great amount of skill and p[Mod - Happy Thoughts]ion for what they do. They could be an incredible [Mod - Happy Thoughts]et to an organisation like VATSIM, but like me, they are not prepared to sign any restrictive or (IMO) pointless docomeents and would rather spend their time on projects they they feel appreciate their efforts.

 

It's like me stating there are processes and procedures that are inefficient and wasteful at an Airbus [Mod - Happy Thoughts]embly plant, never having stepping in that plant nor having read/seen their processes and procedures in action, even though I understand how aircraft are built and am a subject matter expert on manufacturing process optimization.

 

VATSIM is not a manufacturer with commercial obligations, or trade secrets. We are a hobbyist community that is made up of community members that have little-to-no commercial activities. Nobody will lose their life-supporting jobs/pensions/income if VATSIM goes down the chute, or if any "insider" secrets are leaked into the public domain.

 

I've been a member of (and created, in the days before Facebook) several online communities, and not a single one of them has asked me to sign anything other than an EULA to contribute.

 

I've written code for a number of Puppet modules, and even chatted to Puppetlabs developers on the in-depth workings of the Puppet DSL, binaries and protocols. An NDA was never even mentioned - and Puppetlabs is a commercial organisation that delivers both a paid-for and open-source version of its software, and does an amazing job doing it. They even have a Communities Manager - a paid job - that has responsibility for listening to and nurturing the people who write modules for their software.

[Luke Kolin]

This brings up some fun memories. For background, I have signed the NDA and looked through whatever protocol docs I can find. I've also written my own pilot and controller clients, voice library and multi-player servers, albeit not for VATSIM, that handle several hundred thousand flights a year. Finally, for a number of years my day job was writing back-end data services - if you got weather on an iOS or Android device between 2008 and 2014 from the dudes who wear blue jackets and jump up and down at thundersnow, there's a good chance it p[Mod - Happy Thoughts]ed through one (or several) of my ssytems.

 

This illustates my point when I say that the NDA does not serve the community at large, only the vested interests of a small minority - I have not found a single individual case where me having signed an NDA would be even remotely useful to either VATSIM or the wider community.

 

In fact, the use of an NDA actually discourages involvement from the community. I work with developers on a daily basis, and have done for years - developers who actively contribute to a whole host of open source projects, who have a great amount of skill and p[Mod - Happy Thoughts]ion for what they do. They could be an incredible [Mod - Happy Thoughts]et to an organisation like VATSIM, but like me, they are not prepared to sign any restrictive or (IMO) pointless docomeents and would rather spend their time on projects they they feel appreciate their efforts.

 

Having read the NDA and looked through the architecture of a lot of the systems, I can tell you that there is only one legitimate purpose for it - security. But it's not the security that people (especially the 99% of the people here who don't write software) think.

 

The security mechanisms within the VATSIM protocols do not protect the servers. It's pretty trivial (and actually far easier) to construct an attack against FSD that does not engage any of the security mechanisms. Given its architecture, it won't efficiently scale and or be able to shed these attacks, eventually degrading service for people already on the network. (As an aside, FSD is something that seemed cool in 1999 but now wouldn't get a p[Mod - Happy Thoughts]ing grade in CS201 - it can't do I/O, it's synchronous but single-threaded, and relies on ASCII in the protocol with no escaping.)

 

No, the security mechanisms there are to secure against something more likely and dangerous than a cyber attack - a fork. While they do prevent against unauthorized clients, they work in multiple directions - they ensure that VATSIM clients can choose not to operate on other servers or the open-source FSD instances. It ensures that the VATSIM/IVAO split can never happen again. It ensures that there's very significant costs to switch networks - you need to download, install and learn brand new pilot and controller clients.

 

I joined the SB3 alpha team late in the process over a decade ago. One of the most interesting and fascinating aspects of the SB3 alphas was that networks were completely abstracted away - you had a plugin that handled the implementation details of a particular network. You could, at the login screen, select VATSIM or IVAO from a dropdown, it would fetch the server lists and pre-populate your credentials, and off you go! That was an amazing piece of functionality for the community. Not so for VATSIM or IVAO - and when you think that the protocols are still 95% the same, a universal pilot client would make perfect sense for the community.

 

VATSIM is not a manufacturer with commercial obligations, or trade secrets. We are a hobbyist community that is made up of community members that have little-to-no commercial activities. Nobody will lose their life-supporting jobs/pensions/income if VATSIM goes down the chute, or if any "insider" secrets are leaked into the public domain.

 

You sound like a younger version of me, over a decade ago. I was having this vigorous argument in late 2004. At the time, I predicted that VATSIM's greatest danger was not security threats (or even a fork) - it's that software development for this ecosystem would gradually wither away and die. It's too hard to get involved, and every year we get more software authors who find the antiquated VATSIM methodologies impossible to work with.

 

I think history has proven me right.

 

On the server side, look at FSD. It hasn't fundamentally changed since it was written. You can't put colons in flight plans or remarks (escaping characters? encoding? crazy talk!) and credentials still take HOURS to propagate throughout the network. You can have FREE data stores separated by multiple time zones replicate with single-digit seconds of latency. Not for VATSIM.

 

The Servinfo feed is equally pitiful. It's again that same unecoded colon-delimited data delivery. The data update interval hasn't changed and at 2-3 minutes it's so slow to be almost useless. It shouldn't be hard to crank the update interval down to seconds and put a network of caching proxies in front of the generator. Don't even get me started on the server list - it boggles the mind that we still have people typing in IP addresses in 2016.

 

In the real-world, we use DNS. We use DNS that's intelligent and can use geolocation to automatically determine the closest server to a particular user. (Gasp! Heresy! Witchcraft!) For 99% of the population you should select fsd.vatsim.net as your server and the back-end services do the rest. My DNS provider (which charges me the outrageous sum of 50c a domain/month) gives me that for free, along with worldwide redundancy and ability to edit my zones from a browser and an API.

 

On the client side, how many clients are under active development, and by how many people? How many strategically placed meteorites would it take to stop VATSIM development? On the FSX/P3D side, you went several years without any updates. SB4 went into a black hole, and FSINN was buggy and complicated with a completely broken installer. Go read through Ernesto's posts and figure out which components need to be installed as Admin, which should NEVER be installed as Admin and the like. Then stay below FL240. Don't get me started on the approachability of any of their authors.

 

I suspect (and we are blessed with Ross's presence and interaction here to correct me) that Ross only wrote VPilot out of desperation or necessity; a new simulator (P3D) was coming out and there was NO client support. Crazy.

 

(I'm not going to refer to the open-source pilot client called Swift that is neither open source nor is its development rapid. In fairness, they've taken on a very (over) ambitious task and I hope they release something, but as time goes on the risk of people moving on increases.)

 

The problem here isn't just the NDA. Getting rid of the NDA and open-sourcing all the code is a start, but there's a gigantic institutional problem that VATSIM faces. To see what it is, reach out to Kyle and get a copy of the NDA. (This isn't the NSA; merely reading the NDA doesn't prevent you from talking about it.) You should even consider signing it - I have, and it hasn't impacted my ability to work or comment on things.

 

When you become an official developer, start looking around for code samples and libraries. Look for docomeentation. Go into the development forum. There aren't very many threads there. What's even more disturbing is that a lot of the threads seem to tail off, but they refer to other discussions that are going on in private. So I imagine that there's a fair bit more going on, but completely in private somewhere. Why? Is there a "double-secret NDA" you need to sign? It's the quietest development forum I've ever seen.

 

I don't know if things have gotten better (I think Ross was doing some work making C# libraries) but when you start writing code for VATSIM you'll discover that there are all sorts of impediments beyond the NDA. You'll end up writing a lot of boiler plate code to handle the basics of the protocol and unless you are one of the special breed of masochists who insist on writing C++, you have a ton of P/Invoke in your future dealing with VVL.

 

The most dangerous time in any hobby software engineering effort is the early part, when you're building your framework and learning a new platform. Until you get to the point where you're adding the features you really care about, there's always the risk you get blocked, delayed or frustrated and walk away saying "I'll grab a beer and watch the game, and try again tomorrow." And one day, you realize it's been three years.

 

That's the biggest problem VATSIM has. It's a small, closed development ecosystem with almost all of the major players as incomebents. There hasn't been a client released by someone new since Ross wrote VRC. (Or was Euroscope later?) It's not designed for turnover or refreshing itself, which is critical in a community. It's why development slows or stalls, and what you're left with are tweaks for ATC (don't let anyone fool you, this is an ATC network and Pilots are second-cl[Mod - Happy Thoughts] citizens, especially with software) and a server and data formats that are straight out of 1995. (Have you read an SCT2 file? Ick.)

 

How many years has it been since Wade resigned as VATGOV5? Think about it - VATSIM is a technology organization. It's lifeblood is software and technology, and yet we haven't had a VP of Software Development in years. Think of any other technology organization - imagine if Google had no CTO or SVP of Engineering? Apple? The only "tech" orgs without technology leaders are those who don't take technology seriously. I guess VATSIM doesn't. (To be fair to Kieran, he's done pretty well on the server side - but there's a huge backlog still to do.)

 

I once asked a VATSIM President (I cannot remember which one) why they announced all sorts of BoG positions and opened things up to the membership, but never the technology positions. The answer I received at the time was that they were "too important" and too hard to fill for such a process. When I have a hard time finding the right person, I tend to cast the net wider, not narrower, but that's just me. I think the real reason is that the pool of people willing and able to perform such a role and tolerate the NDA and VATSIM's existing technology dysfunction is almost, if not, zero. And I still believe that the Founders will not accept any changes to this.

 

(The Founders are a real cause of dysfunction - a veto is destructive, not constructive. If you look at how long ATOs took to launch after the "Founder's Letter" you will learn, as they did, that you can forcibly prevent change, but not forcibly enact it. Having a group of technology-ignorant individuals in the stage of their lives where they are most averse to change hold a veto over technology change is staggering.)

 

It's interesting to compare VATSIM and IVAO. Both are closed-source, yet IVAO has combined closed source development with a structure that facilitates it over the long-run - a centralized, unified technology org that owns all the code and has continuity of development. VATSIM has managed to combine a closed-source model with a distributed authorship and ownership model that only works in open source when you can easily fork, copy and continue a project. To combine the weaknesses of both closed- and open- source in a development model while gaining none of their advantages is a pretty special achievement.

 

And things aren't likely to change until that gets resolved. I gave up waiting for that. I suspect neither of us has enough time or patience for it, but you're welcome to tilt at that particular windmill. I've consumed too much of VATSIM's precious bandwidth and too much of my time. Good luck!

 

Cheers!

 

Luke

[Karl Mathias Moberg]

Holy smokes, that has to be one of the most on-point, and most perfect posts on how backwards things are in reality on VATSIM I've read in ages...

 

Like Craig have said. Making software opensource does not mean it's prone to more attacks and vulnerabilities. Look at Google Chrome, Firefox as an example. They have BILLIONS of users combined and are both opensource...