I think around I year ago I contacted some Jive people privately regarding a “feature” in the commercial version of Wildfire. I told them this was an evil “feature”, and that they better remove it. They don’‘t wanted to do that which I can understand for marketing reasons. I also said they better not add this to the open-source version of Wildfire. As they didn’'t did, I did not took any action…so far. I just discovered there is an open-source plugin called FileTransferDisabler which says to implement “Automatically rejects FileTransfer requests”. So, that is what I send this message.
Why such a feature is evil?
It gives the customer a false sense of security; it is security through obscurity. You just have to send unstandard XML requests to bypass the feature.
It only is a marketing feature as it is very easy to bypass the restriction.
The WORSTS issue with such “features”: it will create friction in the XMPP protocol community as it promotes clients that use XML that is not compliant with any file transfer XEP.
This friction will also increase the entry barrier for new Jabber clients as it will become harder to compete with existing clients that implement unstandard XML like this (compare it with the current state of the browser world where you have to do much more than just implementing the W3C specs to compete with Internet Explorer/Firefox/Konqueror/Opera)
It will result in the long run in LESS Jabber clients and thus a worse Jabber community
So, what can be done by Jive?
Withdraw the FileTransferDisabler plugin
Do not publish similar evil plugins in the future
What will be done by my?
I will contact Jabber client developers to implement a random file transfer initiating requests to make this plugin even more useless (so that it will not be a marketing-only feature anymore). Actually, I already contacted one client project. So, a fast reply to this message is advisable.
I will make bad publicity about Jive, especially related to how it abuses the XMPP community.
PS: please don’'t censure this message, I know this message is harse, but I warned I would be harse when I contacted you privately regarding the feature in the commercial version of Wildfire, and you already know I keep my promises. If you do, however, it only will result in me working harder in persuading clients to bypass the evil misfeature and in spreading the evilness about Jive.
How does your opinion that security through obscurity is a bad thing relate to your request to censor free and open source plugins?
If you had a look at the plugin you would have noticed that it’‘s not even provided by Jive Software but by a community member. I think it’‘s great that Jive Software provides us with an open community and even lists plugins that are otherwise part of Jive’'s commercial offerings.
So if you don’‘t like it, don’‘t use it but don’'t cry for censorship.
How does your opinion that security through obscurity is a bad thing relate to your request to censor free and open source plugins?
It’‘s not only about the security by obscurity issue, in fact this is something I don’'t care about personally. My main concern is that this plugin (and other similar plugins) will hurt the XMPP community. (And as Jive says it cares about the community, promoting this plugin by listing it is IMO very hypocritical)
If you had a look at the plugin you would have noticed that it’‘s not even provided by Jive Software but by a community member. I think it’‘s great that Jive Software provides us with an open community and even lists plugins that are otherwise part of Jive’'s commercial offerings.
So if you don’‘t like it, don’‘t use it but don’'t cry for censorship.
People still can host it elsewere. What I ask is that Jive does not promote plugins that can cause protocol pollution by listing them on their website. This is not about censorship; this is about vision in the sense of “we care about the XMPP protocols, so we will do everything to protect them”.
do you really think that this plugin is an ugly misfeature?
I think it will only be used by some small companies to try to enforce a “no (private) filetransfer via IM” policy - as far as I can tell this will work fine as there are enough other ways to share files. There were a lot of users/admins who did ask for one and so one did write and release it. I think it’'s still version 0.0.1 and not 1.0.0.
Every public server may have a privacy policy and if it disallows file transfers there should be no problem running this plugin. A server which is used for (warez) file transfers and not for chats may benefit a lot by this plugin.
The problem is that this plugin is not able to prevent file transfers. It intercepts the file transfer requests which are sent over the server. The problem of doing this, is that it invites people to invent unstandard (or even randomly generated!) requests to initiate a P2P file transfer. This plugin will not be able to handle this at all, instead it will result in support for unstandard file transfer behaviour in Jabber clients.
Your argument was and still is really silly. Users don’‘t “invent non-standard file transfer mechanisms”. Perhaps a very small percentage of engineers could/would, but I think they probably have better file transfer options than that anyway. In any case, we’'re not going to censor legit plugin contributions from the community and I really really doubt that an optional plugin for Openfire is going to screw up any standards efforts.
matt wrote:
Users don’'t “invent non-standard file transfer mechanisms”. Perhaps a very small percentage of engineers could/would, but I think they probably have better file transfer options than that anyway.
Well, and I will do my best to promote this exploit as much as I can when it become available.
In any case, we’'re not going to censor legit plugin contributions from the community and I really really doubt that an optional plugin for Openfire is going to screw up any standards efforts.
As I said, this is NOT about censorship! This is about corporate responsibility for the community that wrote the protocols and the various Jabber software that makes JIVE’‘s software more valuable. If you don’‘t like to withdraw that module from the listing, ad if you don’‘t like to answer feature requests for this feature, you SHOULD add a big and visible disclaimer that warns about the uselessness of this module. If you do not do this you are exploiting the community that gives you the competitive advantage that makes you rich. Hence, I will do everything to show people this community unfriendly behaviour of Jive software. In this way they are aware of this, and so they can decides themselves if they want to do business with Jive, if they want to contribute to Jive’‘s projects, if they should fork one of Jive’'s projects,…
My goal is to sustain a HEALTHY community, now and in the future. Therefore, I want to prevent things like EEE ( Embrace, extend, and extinguish - Wikipedia ) like we saw happening with the Web…the Web is still not healed for 100% yet. HTH to understand my fierce resistance.
It’‘s honestly really hard for me to follow your logic. By allowing someone to publish a Open Source plugin, we’'re exploiting the community?
We (Jive) and the entire ignite community invest a huge amount of time, energy, and money into promoting XMPP, Open Source, and open standards in general. Isn’‘t there a better way you can be spending your time? Anyway, I’‘m locking this thread because it’‘s pointless. If you really feel passionate about this issue, you’'re welcome to keep working on it, but please do so somewhere else.