I can alter the contents of the “default.properties” file located in the tree structure of spark.jar such as… programs/spark/lib/spark.jar/org/jivesoftware/resource for the purpose of basic cumtomization of the spark client. In addition to the other restrictions that can be implemented to spark this way, I can also disable the users ability to enable OTR by just disallowing OTR in the Disallow Plugin List. However, it is obvious that a user can simply uninstall my modified Spark client and download a fresh install. This I do not seem to be able to control…if they have admin rights. Anybody know of a way thru the OPENFIRE console that encrypted chat by users can be restricted and/or disabled? thank you
You could try to use the Client Control plugin in OpenFire, only allowing Spark as client, and uploading your own Spark version with custom numbering so the server would nag every user that is not using your modified client to upgrade. I don’t know if you can force your own version to be the only allowed, but you can try.
Thanks for the response. I have essentially already done that in that I have customized the default.properties file in the Spark client which I install for each user. I enter OTR in the Plugins Blacklist and that takes care of that for the Spark client on that machine. However, it became readily apparent to me that a user could simply uninstall my modified Spark client, download a fresh copy of Spark, and thus my customized version of Spark would be “out the window”. And therefore, the client is again able to chat using encryption and therefore circumventing our chat history policy. I was hoping that someone knew of a way thru Openfire Server to prohibit the use of OTR 
But thank you for the prompt response.
I’m going to bump this. We need to be able to control this at the OpenFire level. The Monitoring plugin is useless if all users encrypt the communications at the client level. There is too much loss of control at having to change the client side.
Lucee, this our exact issue as well. Did you get a real solution?
My 5 ct about this issue:
Using a customized build of Spark to remove OTR is already a pretty strong option against encrypted chat. It requires however that a user can not install the clients he wants to have.
In addition to reduced rights or an (weak) alternative, you can add a customized resource name to Spark (like “MyCo Spark”) and use the Client Control plugin on OF to prevent any other client than “MyCo Spark” to connect to OF. This is not bullet proof, since user can rename their XMPP resource to “MyCo Spark”.
If you have given installation rights to “Joe average user” you are facing the fact that other XMPP clients are also offering OTR (http://www.binaryspa.de/jabber-off-the-record/). Hence you can not prevent OTR usage by moving away from Spark. A Openfire plugin to control Spark features would not help either, since the Openfire plugin can only control Spark and not Pidgin.
We are working against OTR usage, by reducing the installation rights for users and a customized Spark that is centrally distributed.
ZOODigital
The only solution I found was indeed temporary and not foolproof. I created a custom install for the Spark client. That install includes prohibiting OTR by editing the default.properties file in the Spark.jar But…if a user choose to do so, they could simply download a fresh copy of Spark. PLug in their username, password, the correct server address and off they go. We can control it in our corporate environment because if we see users listed in a chat session, yet no chats ever occur over many minutes, then we have a pretty good idea OTR would be in effect.
But…this is only a bandaid. the slutio is for the Openfire Server to prevent the use of OTR with a plug in…
Hey everyone. I have managed to disable OTR at the OpenFire-level, by utilizing the built-in content filter.
Go to Server -> Server Settings -> Content Filter. Set your pattern to “?OTR” and enable the filter.
Users attempting to enable OTR chat will see it trying to initialize and it will timeout after 10 seconds. My few users that used it think that an upgrade I performed “inadvertently broke it”.
1 Like