A privacy analysis of the Viwoods AiPaper
A look into the internals and network requests of the Viwoods AiPaper e-ink tablet.
I am not a professional security analyst. Some information may be inaccurate.
The following was done on system version 3.4.1, some parts of this article may not apply to future versions.
TL;DR: The AiPaper doesn’t perform dedicated telemetry calls to Viwoods. It can also be used without an internet connection or account, only missing AI features and ViTransfer. AI conversations are stored on-device. Overall, their claims about privacy seem to be trustworthy, although not everything can be proved entirely.
Background
Viwoods is a relatively recent player in the e-ink tablet market, having started their Kickstarter campaign in August of 2024. I found them while searching various forum posts and reviews and noticed that they seem to push a lot of pro-privacy rhetoric.
On the Amazon page they have an entire image dedicated to their privacy practices. It mentions “No data storage on our server” and “No cloud storage,” both meaning basically the same thing. This, along with other things, got me to purchase it so I could analyze what’s going on behind the scenes.
First Impressions
When I first turned on the tablet and went through the setup process, they didn’t require me to sign into an account or connect to Wi-Fi, that is a nice thing to have in the modern world where everything expects access to the internet.
Without creating an account, you can access all parts of the tablet except for the AI functions and ViTransfer.
Tooling Setup
Lockdowns
This is an Android tablet, which is mentioned throughout its marketing, so the first thing I did was connect it to my computer and ran ADB. Surprisingly, it was instantly picked up and authorized, unlike most other Android devices I’ve used ADB on.
However, I then noticed that nearly all of the main commands on ADB failed. Any call to adb shell returns a message saying error: not support command and adb push/pull return an internal error. The only functional command was adb install which is helpful, at least.
As of system update v3.5.5, running
adb install now causes the same error, adb: failed to install [APK NAME]: Error: not support command cmd, Viwoods did not mention this in any release notes that I saw. This may be a mistake or just a problem with my unit, it may not be, I am not sure. APKs can still be installed on-device via a web browser or file manager.Viwoods have confirmed that ADB’s functionality was intentionally disabled, but they may re-enable it in the future after their open-source SDK releases. I am hoping that they do end up following through and opening ADB for better third-party development.
I also saw that when I connected the tablet, Windows showed it as a drive. Looking inside it, however, only shows the folders Documents and e_book. While annoying, this does make more sense than locking down ADB as it makes it more understandable to the average user where things should go.
Since I couldn’t make any modifications externally, I poked at the built-in settings app and discovered it was also quite locked down. There isn’t much to change and it has no way to access “advanced” settings, so I had to get a bit more creative.
Workarounds
Being heavily limited by what I could do with the “proper” tools, I took to modifying another project of mine, the LemonLoader Installer, to instead list all apps on the device and launch them when clicked.
Somewhat surprisingly, this just worked and instantly revealed a few things. All Viwoods-built apps are packaged under the com.wisky group, why they’re labeled that way, I am not sure.
With that list, I was able to find that the official Android settings app was still available and would launch without issues. This allowed me to use the app PCAPdroid to perform a man-in-the-middle attack on a lot of outbound connections and read the data being sent.
If you want to access the Android settings app on your device, I made an app that redirects to it without all this effort. You can download it here.
Analysis
Viwoods API
Most API calls to Viwoods run through the same API, https://api.viwoods.com/api/. Alongside each (or at least, most) of these calls, the following information is sent.
- System version
- Machine model (my AiPaper non-mini was labeled as
SE03_wifi) - Machine number (the serial number)
- A signature (of what, I am not sure)
- Update 03/27/2025: I have done further research for a related project and have found that the signature is a hash of the data being sent to the API, alongside a “secret” value. I presume this is to prevent people from easily tampering with or sending their own requests.
AI Tools
Nearly all of the AI functionality in the device use the same “Wisky AI” app.
On launch, the app sends a request to https://api.viwoods.com/api/v2/openAi/modelList. As implied by the name, this returns the available models for their OpenAI API endpoints.
When a message is sent to the AI, a POST request is sent to https://api.viwoods.com/api/v2/openAi/completions with the message information and any attachments, usually an image of the current canvas. The API then returns the response from the AI.
For speech-to-text conversations, the MP3 data of the recording is first sent to the endpoint https://api.viwoods.com/api/v1/openAi/speechToText. This responds with the detected text, which is then sent to the standard completions API.
One claim I saw from Viwoods was that AI conversations were stored locally and were only stored on their servers for a day, so I wanted to verify that as much as I could.
When you access an existing chat conversation, there are no network requests being sent. Assuming that a request wasn’t missed, this tells me that they are storing them locally.
When a new message is sent in a conversation, the chat history is also sent alongside it. While this doesn’t verify that they aren’t storing everything, it does show that they are storing AI conversations locally and are sending them from the client which inclines me to believe them.
Paper + Other Writing Apps
None of these directly communicate with Viwoods. Using the AI tools and transferring files via ViTransfer are the only built-in ways for documents to be sent externally.
Accounts
When you sign in, and presumably when you create an account, the device sends your email and password in plain text to the API endpoint at https://api.viwoods.com/api/v1/user/login.
This is done over HTTPS, so the risks from just that are minimal. However, that means that I cannot confirm whether or not they store passwords in plaintext server-side.
ViTransfer
On the device, ViTransfer sends out a request every 20 seconds to https://api.viwoods.com/api/v2/file/receive to check if there is a new file available to receive. If one is found, a call to https://api.viwoods.com/api/v2/file/confirm is made before downloading the data from an Amazon S3 server.
I did notice that the app does this in the background, even when the app doesn’t appear in the task manager. It’s weird to do this so often for a tool that won’t be used 24/7.
When a file is uploaded, a call to https://api.viwoods.com/api/v2/upload/init is done, then https://api.viwoods.com/api/v2/upload/confirm and https://api.viwoods.com/api/v2/upload/complete. During that process, a PUT is sent to the Amazon S3 server to upload the file.
As far as I can tell, authorizations are handled properly and the Amazon files are set to expire in 24 hours, as expected.
Updates
Both in the background and when the Update section is accessed in the settings, a call to https://api.viwoods.com/api/v1/system/version is done to compare the current version to the latest. I updated my tablet before anything, so I can’t see the actual update process requests.
Similarly to ViTransfer, this call is done a lot more than I feel is necessary. While it seemed more sporadic, it still checked a surprising amount.
When you request release notes, a call to https://api.viwoods.com/api/v1/system/details is done, replying with the released notes formatted with HTML.
OCR
The OCR tools can be used without being connected to the internet, however, sometimes the app com.wisky.ocr sends out a call to firebaselogging.googleapis.com. I wasn’t able to read the data being sent, but from what I can tell in the source code, it seems to be due to their usage of Google’s Firebase ML Kit. This doesn’t happen very often and seems detached from actually using the OCR tools, so I wouldn’t be too worried about it.
App Store
The App Store for this device is odd, the declaration they put up when you first open it tells me that they just ripped/downloaded some APKs for apps they think people would want and slapped them into their database.
The most I could uncover with this was a call to https://api.viwoods.com/api/v1/apk/list to get the APKs and the Amazon S3 server for unknown information.
Mailbox
The Mailbox doesn’t communicate with Viwoods when signing in, loading emails, composing, etc. The only calls being performed are directed to the email host, as well as autoconfig.thunderbird.net which is used for mail configuration information. The only exception is the AI tools, which use the Wisky AI app and call back to the aforementioned completion API endpoints.
Google Play Services
Enabling Google Play Services on your devices opens it up to Google telemetry. While this is a negative for privacy, it is not up to Viwoods and they default to having the services disabled.
The AiPaper is not Play Protect certified, while this doesn’t instantly mean it’s insecure and bad to use, it does show that Viwoods haven’t had Google review their product and get official approval. I am inexperienced in this so I can’t speak for certain why they (seemingly) haven’t submitted it for approval.
Regardless, when you turn on Google Play Services in the device settings, it enables Google Play Store and Google Play services. This causes those apps to begin sending a large amount of network requests to Google, as part of this, I assume Google generates a GSF ID for the device, if it hasn’t already had one generated. With that ID available, you are supposed to manually register the tablet with Google as a non-verified device.
Throughout that process, there are no communications with Viwoods beyond the existing background calls like system version checking and Viwoods account refreshing. While I can’t say that the implementation of Google Play Services is entirely secure, I see no evidence of anything malicious going on with it. I also checked the APK signatures of both Google apps and compared them to official releases which verified that they have not been modified.
Other Oddities
When digging through the filesystem, I noticed that inside of /sdcard/Pictures/snapshots there’s a rotating buffer of screenshots, compressed versions of those screenshots, and proto files. From what I could tell through the source code, these snapshots seem to be used for the AI and Picking tools.
Potential Improvements
The only constant networking calls that I could see were the ones checking the system version and checking for received ViTransfer files. I feel that both of these could be improved and changed to occur a lot less while still retaining the same functionality.
Conclusion
From all that I could tell, Viwoods’ claims about their device are accurate. While I feel some improvements could be made, overall, I believe that Viwoods does care about privacy and I hope that they continue to improve as time goes on.
Comments, questions, concerns? Email me at [email protected].