Privacy in this category is argued and almost never measured. Every maker says the reassuring thing, every buyer repeats a rumour, and nobody puts a number on it. You can settle it for your own device in an evening, with tools you already have. Here is the method, what the traffic means, and what is genuinely known versus genuinely unclear.
Policies are written to cover everything a company might ever do. They tell you what a company is allowed to collect. They do not tell you what your device did last Tuesday at 3am, which is the thing you actually want to know.
The gap is not small. A device can be entirely policy-compliant and still contact an update server, an analytics endpoint and a sync service while sitting closed on your desk. Another device with a scarier-sounding policy might sit silent. The only way to tell them apart is to watch.
Credit where it is due: eReadersForum is running a device-chatter benchmark that measures exactly this across e-ink note tablets. If you want someone else's numbers rather than your own, theirs is the work to read.
Pick any one of these vantage points. You do not need all three: your router's connection log (nothing to install), a DNS logger on your network such as Pi-hole, or a packet capture from a machine sharing the connection: tcpdump on macOS and Linux, Little Snitch if you prefer a window to a terminal.
Then put the device in these four states, in this order, and write down what you see. The order matters: it separates traffic the device makes on its own from traffic you asked for.
| State | What to do | What it tells you |
|---|---|---|
| 1 · Idle | Fresh boot, wifi on, screen off, do not touch it for an hour. | The baseline. Anything here is the device talking on its own initiative, which is the traffic people most want to know about and least expect. |
| 2 · Offline write | Wifi off. Write several pages. Turn wifi back on and watch what leaves. | Whether your writing itself is queued up and sent, and how much. This is the state that answers "do my notes leave the device". |
| 3 · Normal write | Wifi on. Write a page. | Whether anything is sent per stroke or per page, in real time. |
| 4 · Feature use | Use the smart features one at a time: search, handwriting conversion, summarise, any AI button. | Which specific features are cloud features. This is usually where the real answer lives, and it is often a different answer per feature. |
Record hostnames and rough volume, not packet contents. Almost everything is encrypted, so you will not read the payload, and you do not need to: who is being contacted, when, and how much answers the question on its own.
| What you see | Usually is | Worth worrying? |
|---|---|---|
| Small hit at boot, then nothing | Time sync, firmware check. | No. Every connected device does this. |
| Regular small beacons while idle | Analytics or telemetry. | Depends on you. It is not your notes, but it is a record of your habits, and it usually has an off switch worth finding. |
| Volume that tracks how much you wrote | Your pages syncing. | Expected if you turned sync on. Alarming if you thought you had not. |
| A burst only when you tap a smart feature | That feature is a cloud feature. | This is the useful finding. It means the device is fine and one button is not. |
| Traffic to a domain you cannot place | A third-party service the maker uses. | Worth ten minutes of searching. See the reMarkable example below. The recogniser is not always the company whose logo is on the device. |
reMarkable is the useful case because more has been documented about it than about any other device in the category, and because it shows why the last row of that table matters.
Known. Handwriting conversion and search for cloud users are processed in reMarkable's cloud rather than on the tablet, and community documentation of the cloud service reports that the recognition itself is performed by a third party, MyScript, not by reMarkable. Synced data is described as hosted on Google Cloud in Europe, encrypted in transit and at rest.
Not known, and we are not going to pretend otherwise. Who holds the encryption keys. The same community documentation says plainly that it is unclear whether reMarkable or Google holds them, and that distinction decides who could read a file if they wanted to. Anyone stating it confidently in either direction is guessing.
Sourced from community documentation of the reMarkable cloud service, not from reMarkable's own materials, and checked 2 Sep 2026. If reMarkable publishes something definitive, that beats this paragraph.
We would rather hand you the method than a promise. gemnotes reads handwriting on your own computer: the recognition call goes to 127.0.0.1, and state 4 above, the one where smart features usually light up a graph, should show nothing leaving the machine at all.
That is our claim, not a measurement someone else made, and the whole point of this page is that you should not take a claim. Run it. Security lists the four claims and how to check each one, and status lists what does not work yet, including the parts that scored badly.
If your capture disagrees with anything on this page, that is a bug we want more than you do. Say so on any page here and it goes to a person.
Some do, some do not, and most do it only for particular features rather than all the time. That is why the question is worth measuring rather than arguing. Run state 2 and state 4 above and you will have a specific answer about your specific device in an evening.
We are not going to answer that, because we make software in this category and the answer would be worth nothing coming from us. Measure the device you already own; if you want a cross-device comparison from someone with no product in the race, eReadersForum's device-chatter benchmark is the work to read.
Usually in transit, yes, and that protects you from someone on the same wifi. It does not tell you who can read the file once it has arrived, which depends on who holds the keys. Encryption in transit and custody of the data are different questions and get answered differently.
It defers it. Most devices queue and send when they reconnect, which is exactly what state 2 is designed to catch. An offline device that dumps a week of writing the moment it sees wifi was never really offline, it was just quiet.
Yes. Most home routers list connected devices and the domains they contacted, and that alone answers the idle-traffic question. You do not need a packet capture to see that a device phoned a hostname at 3am.
Because the alternative is asking people to trust a claim, and this is a category where the loudest objection at any product launch is a privacy objection. A test we could fail is the only kind worth publishing.