Client Authentication by means of a closed source plug-in

[FiringSquad]

What I'm suggesting might shock some of you, but please hear me out.

BZFlag is great fun to play, but some of the leagues are very competitive and there is a strong temptation, given the availability of the sources and the easy-to-follow instructions, to make advantageous alterations to your client and cheat.

What if we allowed the distribution of a closed-source binary plug-in (to be developed and distributed independently) that would communicate with a similar plug-in on the server. It would mean that BZFlag would have to contain code to interact with this plug-in (should one be loaded) and handle the authentication messages to/from the server, but after that BZFlag would not worry about what happens.

What I have in mind is a plug-in that gets to see each server communication (to & from) and then gets asked by the server at random intervals (low frequency) to answer an authentication question.

I know some of you will say "There's no point. It can be circumvented!", but we can discuss that another time.
Assume for the moment that such a plug-in could be built and that it would be extremely difficult to circumvent and yet introduce minimal strain on resources.

How would you developers feel about supporting such a plug-in in the code?

(Sorry if this is an inappropriate location for this topic. Please feel free to move it if necessary)

[blast]

You have the code. Go write it. However, I don't see it as something that will ever be part of the official BZFlag client/server. Adding such code would mean that some Linux distributions (such as Debian) would move us to the non-free section since we would have closed-source code in our application. This is not something that we would let happen.

[JeffM]

Yes this would be your own fork. I would recommend that you make it incompatible with existing games to ease confusion, but it is completely allowed by the license.

The bzflag project can not, and will not go down a closed source path, but you are more then welcome too. The project itself can not support you.

Our big reasons are these 3.
1) We'd loose distribution in many linux systems as blast said.
2) There are platforms that we support but do not build binary releases for. Building bins for every OS/runtime combo would not be trivial.
3) We would have to have multiple packages with different licenses and that also becomes more cumbersome. This would affect development as well as devs would have to have these plug-ins that allow for a modded client.

I know you are thinking about this for GU league, and that's fine. If you update it often enough it may be feasible for your needs, but it is not something that we can do to the baseline project.

[clarahobbs]

I am generally opposed to closed-source, proprietary software. If BZFlag came with closed-source plugins, it would be removed from the Fedora yum repositories. Also, I would likely stop playing BZFlag as a matter of principle.

[JeffM]

BZFlag will never ship like that. He is talking about his own fork. There is no need to comment about BZFlag doing this, as we never will.

Please keep the discussion constructive.

[FiringSquad]

Just to remove any confusion.
BZFlag would still be completely open. All source would still be available.
The difference would be that the built opensource app would have the capability to interact with a plug-in that is an optional download.

BZFlag would still run "out-of-the-box" on all supported OSes, but leagues could restrict membership to only those who have chosen to download the required plug-in.

All instances of BZFlag though, currently support and make use of closed binaries at some level. Even Linux eventually makes a hardware call that is essentially a call into a "black-box". I'm just asking if code, with an optional build flag, would be permitted in the source base so that such a plug-in could be supported.

Again, if the developer community was against it, then there's no point. I certainly would not wish to upset the apple-art. That's why, essentially, I started this topic. If the code to support such a plug-in was not included in the official sources, then it probably would not be worth pursuing.

[JeffM]

FiringSquad
At this time we would not really have any interest in accepting changes for this into the mainline tree, as it would be very specific to your setup. Client binary verification is not the way we want to solve the cheating problem, so there is no real reason for us to take on and maintain a set of API hooks to do that, even if we are not maintaing the closed source component. There are a lot of other issues with maintaining that code that would complicate our codebase ( and build system)

So to answer your question, "probably not".

That said, you don't need our approval to do it. It is perfectly acceptable for you to make and maintain these mods as a patch and then distribute binary versions for the major platforms (since you'll have to make bins for your component anyway). The developers and maintainers can't prevent you from doing it, nor do I think anyone would. Personally I think it would be interesting to see how such a system worked out from a practical standpoint.

If you did this, then it would be on your own. You would have a new fork. Your client would use a different protocol version so your version only showed servers that required your closed source component. This would prevent regular players from trying to join servers that need your module. This would be your own "completion" version of the game.

If you wish to discuss the mechanics of it, come on into the IRC channel and discuss.

[FiringSquad]

I wouldn't like to split from the current tree, for both philosophical and logistical reasons.
I'll forget about it for now.

Hmmm...Maybe I can come up with a set of APIs that provide some useful function along with a plug-in (complete with sources) that would be accepted.
Perhaps an AdvancedAutoPilot plug-in

It could be fun to watch auto-pilots compete. Nah! Forget about it. Move on.

Thank you all for your feedback. I think I can get a feel of where you're coming from.
I can see that adding any complication to the sourcebase without providing a direct advantage to the general release version would be resisted. And rightly so.

Thanks again.

- F.S.

[JeffM]

I honestly don't think you should give up on this, the stuff you'd have to do would not be that hard to apply to each version you released.

Now trying to slip in "secret" code with another patch would not be good. We review all patches before accepting them, and it's somewhat of an insult that you'd even suggest it, even jokingly.

As for robot wars, that's what BZRobots is for

The biggest problems I for see with it is making the system work for players that do and do not have the custom component. You don't want regular players to try to join servers where they need some "secret" module, and be kicked. The best way to do this is to just keep your client as a minor fork. Many projects have minor forks maintained by other development teams, it's quite common when all you want is a small variation.

Just because it is not something the proejct wants to do, doesn't mean that it isn't something other people can do. That's the beauty of open source, you can take it and mod it

[FiringSquad]

Now trying to slip in "secret" code with another patch would not be good. We review all patches before accepting them, and it's somewhat of an insult that you'd even suggest it, even jokingly.

I wasn't suggesting that. Rather I was suggesting that a useful feature that involved dynamically linking to an external plug-in, such as an autobot plug-in, could later be co-opted to link with a plug-in that performed the authentication, or whatever else was deemed useful/fun, without the need to rebuild the main client.
I'll definitely think about what you suggested. I would like to contribute to the development of BZFlag in some way.
As for the annoyance of not being able to spawn on the "special" servers. This is already the case anyway, even without such a plug-in. You already have to jump through a few hoops to be added to the spawn-list. One more hurdle isn't going to make that much of a difference.

[JeffM]

You want to minimize the number of hurdles in the first place. Not all servers have spawn lists. So yes the harder you make it, the worse it is for players.

Linking the client to an external lib isn't the hard part, it's getting the appropriate hooks into the system to allow the communication and checking you need. The hooks for a an autopilot plug-in would be VERY different from the hooks for authenticator. A robot would never need to use network traffic for instance, it would just need to drive the tank using the existing client code, where an authenticator would need to be able to access the networking system to be able to send and receive messages. Just linking a plug-in into an app doesn't automatically give it access to everything that app has, you have to export an API that gives you the features you need. In your case you'd need to have the ability to manage custom network messages in addition to whatever you need to "verify" the compiled client.

[FiringSquad]

Yes, but a powerful plug-in architecture that could do both (and more), could also be leveraged to make many useful enhancements without a need to alter the main source. It could equally provide something useful like showing the lagstats for a player in the Identify string or whatever other fancy plug-in one might dream up. Doing this would definitely be non-trivial though and it would require a lot of thought and planning if it is to be worth the effort.
Either way, it would increase the code's complexity and that should be avoided. And since I haven't actually written anything yet for BZFlag, and as such don't know what I'm talking about, perhaps I should just shut-up now.