A common question that potential Handy buyers have is the safety of the device considering it requires a persistent Internet connection to synchronize with content and access features. When something as private as masturbation is concerned, it’s important to understand exactly what role this connection plays and what data is being transmitted back and forth.
As a general overview, we implement the following security measures when dealing with Handy connectivity:
End-to-end encryption between Handy and our servers through HTTPS
Your connections to a third-party service is only identifiable by your connection key — which you can change at any time
Connection key changes are done at the hardware level and third-parties will not be able to know your new connection key if you do not provide it to them
The Handy always starts in Offline Mode. There is no risk of anyone taking over your device because it is not communicating with the Internet unless you put it into Online Mode
Local Handy configuration is done over Bluetooth, which has a signal range of around 10 meters
Let’s take a look at some commonly asked questions he received over time
Is it really true that the content-synced movement requires an internet connection?
Is it really true that the content-synced movement requires an internet connection?
Perfect one-to-one timed syncing requires an Internet connection. You can sync videos through Bluetooth offline through community tools such as Buttplug.io, Intiface, and ScriptPlayer.
Bluetooth playback is not built by us — we just added one command and the amazing community have done the rest.
However, we generally don’t recommend these methods as the experience will not be as accurate as using online sync, this is due to the limited development that was done on the Bluetooth Interface.
Why does the perfect sync require an Internet connection? Can you not just make it offline and/or available through Bluetooth?
Why does the perfect sync require an Internet connection? Can you not just make it offline and/or available through Bluetooth?
We believe in simplicity and online interactive play.
Due to limited resources, we have to pick one direction and stick to that. The online solution allows us to integrate quickly with content providers. Most of these services are web-based, and controlling a local device requires much more effort from them than just adding our JavaScript SDK with four lines of code.
Other aspects of it are operational: we don’t have the capacity for technical support of three different synchronization methods. We need to focus on keeping what we have stable and bug-free. We still need more time to grow from the start-up small company to a fully stable company.
This task is much more complex than we imagined, and our biggest problem is that there are so many cool things that we can do! But doing everything at once is not sustainable, and we will need time to recruit good personnel and onboard them to take on more tasks like different sync methods.
Why not just open-source the server code and let the community do the work?
Why not just open-source the server code and let the community do the work?
Well, the honest answer to this is that it is our intellectual property, and we do not want this to be public. We have to run a business at the end of the day, but it is unfortunate because it collides with our ambition of building the product with the community.
Our server code and firmware will be closed source, but with as much transparency as possible. Everything else should be open. We aim to have our websites and product code in public Git repositories for transparency and community feedback as well.
What data exactly is uploaded to The Handy servers? Does it include the full script? The name of the script? Any metadata?
What data exactly is uploaded to The Handy servers? Does it include the full script? The name of the script? Any metadata?
If the user is synchronizing with a FunScript file, the whole script is uploaded to our servers, converted to a CSV file, then downloaded from our servers to the Handy. If you are hosting a CSV file on a server (local or remote), then your Handy downloads it directly.
If there is metadata in the FunScript, it is never read. Only the actions array of the FunScript is converted to CSV. When your Handy downloads the script, it is stored as the SHA256 value of the script contents in memory.
For example:
Script name: “Video 123”
Action array: Alternating between position 0 and 100 for 2 seconds
Resulting SHA256 value:
0767c52c7b5f8a996a57d742e6508ccf7fd1daa4266ade0a12e1b8d9b5fb25c5.
Currently, the Handy only holds one script at a time, but this might change in the future with updates to Firmware and the device.
How does this work for services that are not script-based, like games which can have unpredictable movement?
How does this work for services that are not script-based, like games which can have unpredictable movement?
This works by sending an API call through our servers. Example with starting the Alternating Motion mode (HAMP):
You press start on any Handy-connected app, including HandyFeeling
The service sends an API request to our servers. You can read more about the specific request here: https://www.handyfeeling.com/api/handy/v2/docs/#/HAMP/start
The command is transformed by our server to “Handy language” and sent to your device. The server knows which Handy to send it to based on the Connection Key you have entered in the app you are using.
Our server analytics adds an entry that a remote control session has been started. All data is scrambled, including the Connection Key.
Can the Handy be Hacked?
The risks with using the Handy are minimal. Here is an explanation for how The Handy works from CTO Alexander:
“General rule/advice: “If it's online, it can be hacked or manipulated”. With that being said let us describe Handy’s connection system.
The Handy key is generated inside your Handy using noise on the Wi-Fi antenna to generate a true random key. Generating a new key renders the old one useless. There are no historic records of keys. This makes tracking hard for 3-party applications that need to connect through our API to control your Handy. They do not get an IP of your Handy when connecting to our API. Our Handy-server connection system is fire and forget. When you send a command, the system checks if there is a machine with that key online, it does not check a database to verify if that key exists. If the machine is online the message is transformed and sent to the machine.
It's up to the machine to reply or not. This means that you would need to brute force and to check all keys possible to see if there is a machine that has the key you are testing online. The key length is variable from 5-32 characters, with lower case, upper case, and numbers. That gives 26+26+10=62 chars. For the shortest key length renders 625 = 916.132.832 combinations. The longest key length gives 6232 = 2.272.657.884.496.751.345.355.241.563.627.544.170.162.852.933.518.655.225.856 combinations to test out.
But let’s say the system is brute forced and your key is stolen. Then the attacker can control your machine while it is online. Not the biggest security issue, not optimal of course, but they do not have access to stuff like your browser history or payment info. Then, you could simply change your key and render the attacker’s future attacks useless.
Another thing we would say is that The Handy is offline by default. You must press a button to activate the Wi-Fi on a hardware level each time you power your Handy. It is your choice to bring it online.
One could say that it would be better to create a completely offline device, but by bringing your machine online you can get the latest firmware updates and the power of the API. We can spend our time on the hardware, the server connection, and the 3-party developers that can create apps for your device. With our Connection Key system, they will not have direct access to your device. If you want to revoke their access just change your key.
Privacy by default is very important for us. A good thing that it is very little money in the “data” compared to other services you might use. That will leave the pressure off the engineers to collect data in the future as well.”