Xiaomi MiBand3 and privacy… not much

MiBand is a wearable activity tracker produced by Xiaomi. The 3rd generation has a reasonable feature set and it is 2-3 times cheaper than its competitors. It’s a great entry-level band if you want to begin tracking your fitness levels.

I bought a Xiaomi MiBand3 because I was hoping to make sense of my erratic sleeping patterns. I was also eager to discover how much movement I was getting through the day. Additionally, I was hoping to connect with some faraway friends via the MiFit phone app.

“But what about privacy?” a nagging voice in my head kept asking. The data that a fitness tracker generates feels personal and Xiaomi is a Chinese company. I don’t want the Chinese government to have information about me. It’s bad enough that Chinese citizens have no privacy. To make an informed purchase, I searched for articles about “Xiaomi privacy”. I found two articles (1 and 2) reviewing the InfoSec aspects of a couple of fitness trackers. Yet, nothing that answered my question about Xiaomi. In the end, I decided to buy the band, but I felt uneasy every time the MiFit app “synchronized” with the band. Uneasy, but not concerned enough to look deeper into the matter.

Susana Sanz, from BalkonTactics, renewed my interest in privacy and InfoSec. After our talk, my unease changed into serious concern about the data generated by my shiny, new fitness tracker. The ethical/moral/philosophical aspect of privacy did not interest me, that’s something that others have talked in more detail (Glenn Greenwald and Edward Snowden come to mind).

I was interested to know what exactly does Xiaomi know about me. Making a Subject Access Request (SAR), a right recognized by the GDPR, is one way to go about it. For the sake of learning how SAR work, I submitted one to privacy@xiaomi.com. But this process would take a long time and I don’t like to wait. While waiting for an official response, why not use a “hacky”, DIY approach to get an answer?

Nowadays, almost all phone apps communicate with a server on the internet. It is possible to intercept that communication, while it’s happening (see the technical method section at the bottom of the post). Thirty minutes later, my concern was confirmed: Xiaomi collects all the data that MiBand generates. To be more specific, all the data that is shown in the MiFit app (e.g. sleep data, training data, heart rate, etc.) gets uploaded to the Xiaomi servers. There is no way to disable the upload in the configuration of the application. The band keeps a backlog of all the recorded data and everything gets uploaded to Xiaomi when you use the mobile app. If you don’t use the MiFit app, you’ll end up with a band that only knows how to count your steps and how to measure your heart rate.

The only good news here is that, at this moment, the geo-location data is not collected passively (outside training sessions). But there is no guarantee that it will stay like this in the future.

This is a lot to take in. In the end, I’m left with a feeling of disappointment that Xiaomi has unrestricted access to sensitive information about my lifestyle:

  • what would happen if someone infiltrates their systems? I’m sure that there are ways in which this data could be exploited to my disadvantage.
  • what’s up with this shady user agreement? Not clear to me what Xiaomi and its partners do with the data. I understand that the moment it gets uploaded I “waive any and all ownership, legal and moral rights” to my data. But how does Xiaomi use it? Who are the third parties or Xiaomi affiliates that have access to it? Is it sold or monetized in any way? Lots of questions and no clear answers.

If you’ve been on the internet long enough, you’re familiar with the phrase “If you’re not paying for the product, you are the product”. Fun fact, in 2016, the average worth of a Facebook user was $3.73 per quarter. I’m not ok with that, but let’s leave it there for now. Thinking logically, the phrase should not stand once I start paying for the product. Right? Well, it seems that this is not the case with Xiaomi MiBand.

I’m dissatisfied that, despite paying for the MiBand, I “waive any and all” rights over the data that I generate. In this new light, what seemed to be a good deal (best cheapest fitness tracker on the market) became a lousy deal when reading the fine print and doing a bit of research.

In the end, there are two big questions left in my mind about this way of collecting personal data:

  • is this a general practice of the fitness band industry or is Xiaomi an exception?
  • are other Xiaomi products collecting data in the same way?

If you own a fitness tracker or another Xiaomi product, can you do a bit of digging around and let me know? Or get in touch with me and we can do the research together. 😉


The technical method of finding out what MiBand3 data gets uploaded to Xiaomi’s servers was simple. Had I known it would be so simple, I wouldn’t have postponed it so much.

The hardware setup: I had to install mitmproxy on my laptop.

  • connect both my phone (with the Xiaomi MiFit app) and my laptop to the same WiFi network
  • install and run mitmproxy on my laptop
  • install the mitmproxy root certificate on my phone
  • on my phone, set the proxy server for the Wifi to point to my laptop
  • open the Xiaomi MiFit app and look at the requests going into the proxy running on my laptop

Out of all the requests made by the Xiaomi MiFit app, only one sends a lot of data:

POST https://api-mifit-de.huami.com/v1/data/band_data.json?r=50AB6198-7007-47BF-86AC-53F606CDD4F6&t=1565977799279

In the payload of this request is a key called data_json that contains all the recent band data (as the name of the endpoint suggests). I took a look at the data in the JSON object and saw all the data points that are shown on all the graphs (in the app), including all the geo-coordinates of my running sessions. To my surprise, the MiFit app didn’t seem to send to Xiaomi information about my current location. Yet, this is not a guarantee that this information will remain on my phone in the future.

From a technical perspective, I enjoyed doing this little research. Using mitmproxy was straightforward and I recommend it if you want to see what communication goes on between the apps on your phone and the internet.

Database integration tests

Did you ever struggle while trying to write integration tests without mocking the third party? I know I did.

I’ve known about Martin Fowler since I was a junior developer. He is one of my favorite technology thought-leaders and I enjoy reading the thought-provoking articles that he publishes on his blog. In this post, I want to expand on his article about the test pyramid, in which he explains the difference between unit tests, integration tests and, UI tests. I’ll expand on the part about integration tests.

I want to show you an easy way to run integration tests against a database. With this goal in mind, I’ve created this java demo project. It illustrates the concept and is useful as a starting point for more complicated applications.

In the past, I would delay writing the integration tests. I dislike the idea of not having any integration tests. Fixing errors at runtime is not something that I want to do in Java. Meanwhile, I didn’t want to invest time on setting up a separate test infrastructure. And tests running against a mocked database, are not testing anything. The options seemed limited:

  • mocking the database interaction layer
  • connecting to an in-memory database
  • connecting to a local/remote test database

Regardless of the option I picked, I always had the feeling that the solution could be more elegant. My hesitation would turn into frustration as the application grew and the tests would become harder to maintain. Recently, I discovered a better option: connecting the tests to a database running in a Docker container.

In my last project, Vlad and Max showed me that using docker containers simplifies running integration tests against a database. No mocking, no complicated infrastructure, no tinkering with configuration files. As long as you can run Docker on the build machine, you can run the tests.

This is the elegant solution that I was looking for:

  • install and configure Docker on the build servers and the developer machines that will run the tests
  • use docker-maven-plugin to build a docker image of the database and start/stop a container based on the image
  • populate the database with the necessary data (use ‘/docker-entrypoint-initdb.d/’ or a database migration tool like flyway)
  • finally, use maven-failsafe-plugin to run the integration tests

I like this approach because the integration tests are portable and easy to debug. If the tests run on my laptop, they will run also on the build machine. If the tests fail on the build machine, the problem will also appear on my laptop.

I also like that the tests are repeatable: the plugin builds the Docker image from scratch before the tests start and removes it after the tests finish.

Finally, I like that this approach is transferable to other types of integration tests. It’s easy to replace the database container with a dockerized REST API (in a move towards contract testing) or with a message queue container.

The demo project is more than a typical “hello world” application. The integration test starts a docker MySQL container and makes a simple SQL query. You will notice that the docker-maven-plugin configuration is more complicated than necessary, given such a simple test. The reason: the code samples that I found online seemed trivial. I wanted to have a “bootstrap” project that I could reuse in real-life projects without the hassle of gluing everything from scratch.

This approach to writing integration tests has opened my eyes to the possibilities that exist today in the QA automation domain. The tools built on top of Docker seem varied enough to accommodate all test types. The number of plausible excuses for not having a proper CI pipeline is getting too low…