Dear Friends,

I hope this post finds you all in good health and spirits.

Recently re-discovered VoxCommando 2.2.2.6 and started to explore its many features and capabilities.

I noticed two network related activities that I wanted to get clarification on. I include my thoughts on each bullet point to show research effort or guesswork.

1. During each startup of the VoxCommando application, a connection on TCP port 80 from my computer to VoxCommando.com (destination IP address 192.185.45.219) - I could not find any specific information on this activity in the VoxCommando wiki or forum. The only exception was the installation instructions on the VoxCommando wiki (see here) that advise the user to create exceptions in the Windows Firewall for VoxCommando. May I kindly inquire on what VoxCommando is doing with this specific network connection? License check? Version update check? Telemetry upload?

2. After I issue the first voice command (voice command can be anything) once the VoxCommando application has started, a network broadcast on UDP port 32080 from my computer (see bullet point #3 for an oddity during this network activity) to IP address 255.255.255.255 is performed - I could not find any specific information on this activity in the VoxCommando wiki or forum. Both UPD and TCP 32080 ports are unassigned on the IANA Service Name and Transport Protocol Port Number Registry (see here) so that makes getting more information on this network activity more difficult. Considering VoxCommando is engineered to work with Home Automation technology, I could venture a guess that it is broadcasting to any network-aware equipment that can listen to network traffic from my computer. May I kindly inquire on what VoxCommando is doing with this specific network activity?

3. In addition to the behavior observed in bullet point #2, I notice when the VoxCommando application initiates the network broadcast on UDP port 32080, it is using the source IP address of my VirtualBox Host-Only network adapter and not the source IP address of the wireless network adapter I use to connect to my wireless router (which is what the VoxCommando application should be using) - For those that are not familiar with VirtualBox, it is an application that allows the creation and use of virtual PCs (see here). One of its functions is that it has the ability to create a closed network so that only virtual PCs can communicate with each other. In order to do this, VirtualBox creates its own unique wired virtual network adapter and assigns it an IP address in the private IP address range of 192.168.X.X. The purpose(s) of this closed network function can be various (e.g. for testing, etc.). I would like to clarify that I am running the VoxCommando application on my actual hardware installed instance of Windows 7 and not in a virtual PC within VirtualBox. My best guess here is that there may be logic in the VoxCommando application that makes it prefer the use of a wired connection and not a wireless connection when performing this specific network activity. My 3rd party firewall doesn't log any similar network activity to what I documented in bullet point #2 and #3 for my wireless network adapter so I am inclined to believe the aforementioned network activity is only occurring on the wired virtual network adapter of VirtualBox. So, if the network activity documented in bullet point #2 is of any importance, and I am correct in my assumption, it won't be going anywhere on computers that have similar scenarios such as my own. Just wanted to call that out.

Thank you for taking time to read my somewhat lengthy post. I hope I have provided enough information for a good start. This is my first post and will improve as I learn the lay of the land of this forum and its citizens.

I appreciate any feedback that can be provided.

Sincerely,
MetaCode

Hi MetaCode.  Welcome (back) to VoxCommando.

1 - Yes this is an activation check.

2 - This sends out information about recognized voice commands or alternates via UDP broadcast to any Android devices running the VoxWav app.

3 - I'm not sure. It could be that the virtual box is confusing VC and the broadcast is being made on the wrong NIC.  It is just guessing what the first obvious LAN is where other devices might be listening and sending on that.  If you don't run VoxWav then it doesn't matter.  I'm not aware of anyone having an issue with this at the moment but I guess most people only have one active NIC on their system, or are not using VoxWav so didn't notice any problem.

By the way the main reason that we advise you to make a firewall exception is actually because VC communicates (sending and/or receiving) with so many different programs and devices through various network connections via various features and plugins.  Whether or not you actually need to use network communication will depend on how you set things up but the majority of users will need it for at least one application.

Quote from: jitterjames on October 15, 2016, 11:32:10 AM
Hi MetaCode.  Welcome (back) to VoxCommando.

1 - Yes this is an activation check.

2 - This sends out information about recognized voice commands or alternates via UDP broadcast to any Android devices running the VoxWav app.

3 - I'm not sure. It could be that the virtual box is confusing VC and the broadcast is being made on the wrong NIC.  It is just guessing what the first obvious LAN is where other devices might be listening and sending on that.  If you don't run VoxWav then it doesn't matter.  I'm not aware of anyone having an issue with this at the moment but I guess most people only have one active NIC on their system, or are not using VoxWav so didn't notice any problem.

JitterJames,

Thank you. After delving deeper into what VoxCommando can do, I am very glad I came back.

1. Thank you very much for the information.

2. Interesting. I take it this is done to provide feedback to the user if they are sending the voice command via VoxWav. The information that is sent back to VoxWav, does it contain the text of the voice command or its alternate(s) (e.g. I say "Execute Order 66" and VoxCommando literally sends the text of "Execute Order 66" to any and all devices via broadcast?) The reason I ask is, due to my security-minded nature, if I am using VoxCommando on a PC, I would not want what I am saying to be broadcast in cleartext to anyone sniffing packets on the network.

3. My thoughts exactly. I am not a programmer but I have seen behavior where LAN traffic is prioritized over WLAN traffic in other applications so I thought I would mention it in case it becomes a problem for other users.

Thank you very much for taking time out of your Saturday to reply to my post. 

Sincerely,

MetaCode

Quote from: jitterjames on October 15, 2016, 11:35:38 AM
By the way the main reason that we advise you to make a firewall exception is actually because VC communicates (sending and/or receiving) with so many different programs and devices through various network connections via various features and plugins.  Whether or not you actually need to use network communication will depend on how you set things up but the majority of users will need it for at least one application.

JitterJames,

Thank you for that information. It makes perfect sense.

Sincerely,

MetaCode

Quote from: MetaCode on October 15, 2016, 11:53:00 AM


2. Interesting. I take it this is done to provide feedback to the user if they are sending the voice command via VoxWav. The information that is sent back to VoxWav, does it contain the text of the voice command or its alternate(s) (e.g. I say "Execute Order 66" and VoxCommando literally sends the text of "Execute Order 66" to any and all devices via broadcast?) The reason I ask is, due to my security-minded nature, if I am using VoxCommando on a PC, I would not want what I am saying to be broadcast in cleartext to anyone sniffing packets on the network.

I think if someone is able to sniff packets on your LAN you've already got a big problem. UDP broadcasts do not traverse the LAN / WAN barrier so they would need to have breached your security already to do that, no?  Still, I would not recommend you include voice commands where you say critical passwords etc.

The messages sent to Voxwav include recognized speech, alternates (if any), confidence level, OSD messages, confirmation prompts, and TTS messages. No other info is transmitted.

JitterJames,

Thank you for the information and guidance.

My concerns about the verbose nature of the UDP broadcast are not based on the scenario of a home LAN being compromised or undesirable network traffic traversing the LAN/WAN barrier. In a post you made indicating the diverse usage of VoxCommando by others and yourself (see here), one could argue that VoxCommando could be used in, for example, a corporate LAN where the audience of such broadcasts cannot always be controlled. In such a scenario, even if one doesn't include critical passwords, certain private information could be conveyed within the command (depending on how the user constructs the commands) that the user may desire to have remain private. Keep in mind that you have created quite a powerful and robust productivity tool and your licensing allows for business use (with permission from your company, of course), so it is bound to be used by power users outside the realm of home automation (e.g. IT administrators automating repetitive server maintenance tasks). As an IT technologist myself, I would be foolish not to use the VoxCommando to make my job more efficient if it checks all the boxes of my needs.

In this scenario, mitigation steps do exist. If VoxWav use is not needed or desired by the user, he/she could configure their firewall to restrict this specific UDP broadcast as long as it doesn't negatively impact VoxCommando.

Please know that I understand that to some I am presenting an edge case since VoxCommando has its roots in home automation. Nonetheless, computing is evolving and the user experience is changing towards less keyboard/mouse-centric interaction. We will see more speech recognition software become the norm as personal assistants transform how users interact with technology and how that technology uses information. As a concerned citizen for the welfare of VoxCommando, I felt it appropriate to speak as if I was evaluating VoxCommando from the viewpoint of a security analyst.

Thank you for entertaining this conversation. Just sharing some food for thought and desire nothing more than to see VoxCommando succeed. 

Sincerely,

MetaCode

Well it's never been an issue so far but it is probably something that could be ameliorated without too much bloodshed. I send those messages by default just to make it as easy as possible for anyone who wants to use Voxwav or develop their own OSD app.

Of course it can be made optional but every option added increases the complexity for new users by just a little bit. Not much but it adds up.

So is this just a hypothetical concern for you or is it a real issue?

JitterJames,

Thank you for elaborating on your thought process behind the design of this UDP broadcast and for your question.

I can certainly see the consideration you put in with having the information being sent to VoxWav or user-created apps. Keeping VoxCommando as bloat-free as possible is safer, more stable, and easier on the developer. No argument there.

TL;DR - To answer your question, I prefer to err on the side of caution. Personally, I don't wish everything I say to VoxCommando be broadcast like that. Especially if I am performing dictation. At home, it isn't much of an issue for now since I can block it with my local firewall. But if I used VoxCommando at work for a productivity enhancer in IT administration, I would have concerns knowing what I know. Considering how some businesses hardcode firewall configuration with policies that prevent user tinkering, my mitigation step wouldn't be applicable. If you want to know more about my motivations or are really bored and want to kill a few more minutes reading this post, please proceed to the paragraphs below.

Before I go any further, I feel like I should put forth a disclaimer. I am a newbie to this forum, a complete stranger, and respectful of people and their efforts. Even though my intentions are benevolent in providing my feedback to any and all who desire it, I always try to tread carefully. The last thing I want is to insult or injure the recipient of said feedback. It is evident that a lot of work has gone into making VoxCommando, its documentation, and the continued support your company offers. I highly respect that and would never want to be perceived as someone who doesn't see the effort you put in or as someone whose expectations can never be fulfilled or as judgmental. Please take what I say as polite, constructive feedback.

The best way that I can answer your question is to present you with an experience I have gone through quite a few times. It will help you understand my thought process. When I was on-boarding a new software platform in a previous corporate position I held, the IT security team of said company was very good about scrutinizing the ins and outs of the software platform to ensure the due diligence was performed by the developer(s) and implementers so that security was not sacrificed for the sake of fancy features or convenience. Now, the IT security team did not go through the source code line by line looking for adherence to secure coding practices but they did examine the obvious behavior of the software platform from the perspective of application security, network security, data security, etc. Being security conscious by nature and leveraging experience from previous positions I have held in my IT career, I had my bases covered and made sure I remediated/mitigated any gaps/issues I could find before the IT security team had a reason to worry. This made the on-boarding of the software platform less painful for all parties involved. You would think what I did was nothing special but I can't tell you how many times I get surprised looks from people when they see me actually working towards my goals with security in mind.

I don't know how many of your customers utilize VoxCommando in a business environment or how important security is to them, so I don't want to speak out of turn here.  But, if my past experiences (such as the one described above) have taught me anything is, like the old adage says, an ounce of prevention is worth a pound of cure. Security analysts (the good ones at least) are quite picky about how an application behaves. Today's "oh what harm will that little feature do?" or "it was easier to set it up this way," is tomorrow's hacker/social engineering attack vector. In the setting of a home environment, security may not be at the forefront of the user's mind, but in a corporate environment, it is a different story. With the popularity of home automation and Internet of Things technology, homes will start to become appealing targets to wrong-doers as well.

In the scenario of this specific function of VoxCommando where the user prioritizes security, one could solve it a couple of ways (shown in order of ease).

1. If user is not utilizing VoxWav or another 3rd party application that depends on this UDP broadcast, then the user can configure their local firewall to block the broadcast - I presume that is safe to do.

2. Your suggestion of adding the option to enable/disable that function.

3. The developer could implement secure transmission of the information to prevent eavesdropping.

My intention in this thread is not to challenge the design of VoxCommando. I just ask that you always keep security in mind when designing and implementing functions within VoxCommando.

Thank you for reading this lengthy post.

Sincerely,

MetaCode

I will make some adjustments for the next release.

JitterJames,

Thank you for considering this security enhancement to VoxCommando and for allowing me to dialog with you on this matter to this extent.

I hope I was able to help in some way to make things better.

Sincerely,

MetaCode

As of today's beta release of VC version 2.2.3.0 this concern has been addressed.

VC no longer broadcasts UDP message to VoxWav. A client running VoxWav must first connect to VoxCommando via the TcpMic plugin and then all messages will be sent to that client only. If another client connects to VoxCommando, subsequent messages will be directed to that new client.

Change log: http://voxcommando.com/mediawiki/index.php?title=ChangeLog#Version_2.2.3.0

The beta can be downloaded as usual from the Downloads page: http://voxcommando.com/home/downloads/

VoxCommando Team,

Thank you all very much for the work that was performed in this new version of VoxCommando to address this concern. Remember...every time a security hole is closed, a security analyst gets his/her wings 

Also, I greatly appreciate Nime5ster's time in posting back to this thread with the information of this upcoming update.

Sincerely,

MetaCode

I don't want to nitpick but just so there is no confusion, it's not an upcoming update... It is available for download now.

JitterJames,

Thank you for the clarification.

My apologies for my poor choice of words.

Sincerely,

MetaCode