Automatically translate this page?
29 June, 2018

Private data switch: GDPR compliance and personal location data protection

A ready-made solution to hide personal location data and make your business GDPR compliant.

There's a lot of buzz about personal location data protection these days and it has further intensified with the introduction of the GDPR regulations. Businesses relying on location data are heavily concerned about the issue since failing to comply incurs fines and hits the reputation. Employees using corporate transport should feel safe and secure when running their private errands. This is exactly what the business-private switch intends to do — stop sending your location data when not at work.

Task at hand

Say, we have a channel that receives data from tracking devices. The tracking device has a switch connected to a certain digital input. If the switch is turned on, the tracking device position info must NOT come to a Business Application. For example, this typical telemetry message:


must be transformed to:


Note that I also excluded GSM data (as one can define tracker’s location by GSM cell id) and speed-direction data (as one can estimate tracker’s position by building its track using secondary positioning data). Is it worth mentioning that if the private data switch is on, a driver must look at the rearview mirror more often to detect and avoid surveillance and pursuit? :)

The solution provided in this article relies on the MQTT pipeline:

  1. MQTT client subscribes to a special topic to receive new messages from the tracking devices

  2. Simple algorithm cuts off position data from messages received on subscription (or not, if private data switch is off)

  3. MQTT client publishes a processed message to another special topic

  4. The business application receives the processed messages

Looks simple, doesn’t it? Let’s see how it works.


To emulate this case I decided to do the following:

  • I’ve got Wiatag app on my smartphone. This is my GPS tracker. In WiaTag I can create custom statuses — customized parameters to send with telemetry data from my phone. I created 2 statuses with the name custom.din (din stands for Digital INput like I have physical private data switch on my phone): public and private. So if my Private Data Switch is turned on, I will receive the special parameter “custom.din_index” = 1. (NOTE! In most GPS tracking devices the name of switch parameter will be most likely just "din")

  • I’ve got a Wiatag channel and set up my Wiatag app to send data to the channel’s IP:port.

wiatag setup

  • I’ve got the MQTT channel that will subscribe to a special topic and receive processed messages. Below is the screenshot of the MQTT channel configuration:

mqtt channel setup

  • And last, but not least. The power that will analyze the content of messages in the Wiatag channel, excide the private data, and push the result to the MQTT channel — meet flespi_pipeline.


flespi_pipeline is based on gmqtt library and is 80% the example from gmqtt’s Readme. Everything I added was:

  1. Configuration. You must write the channel_id to read messages from, Authorization Token, and Private Data Switch parameter name and value (I've used the name "custom.din_index" to test it with Wiatag but on most tracking devices it would be just "din"). You can modify some secondary stuff but basically, this is it.

  2. Function to process received messages:

def on_message(client, topic, payload, qos, properties):
        message_json = json.loads(payload.decode("utf-8"))
    except ValueError:
        print('invalid JSON received: ' + payload.decode("utf-8"))

    # define if pipline message processing required
    if pds_parameter_name in message_json and message_json[pds_parameter_name] == pds_turn_on_value:
        processed_msg = {}
        # iterate over message parameters and exclude position info
        for parameter in message_json:
            # if parameter starts from "position" or "gsm" — exclude it from message
            if not (parameter.startswith('position') or parameter.startswith('gsm')):
                processed_msg[parameter] = message_json[parameter]
        payload = json.dumps(processed_msg)

    # publish processed(or not) message
    client.publish(publish_topic, payload)

The above ten lines of code analyze the Private Data Switch parameter and eliminate the position info from messages.


What do we have as a result? flespi channel with messages stored according to the Private data switch position. 

What can we do with this channel? Send processed messages to the target business platform. 

What is the right way to do this? Create a special ACL token that will be authorized to get data only from the channel with processed messages. This is an important remark since the usual all-allowed token will allow your Business Application to see all messages (including private data!). In my case it looks like this:

acl token setup

Yes, this is not a magic button embedded into your application, and you have to host the script somewhere. But flespi plus 15 lines of code give you a fully functional solution to the task that occupied your head for quite a while. Not a huge time investment to show appreciation to your employees and stay in sync with the latest GDPR regulations, isn't it?

Get the latest updates and monthly newsletters from flespi in your inbox

When The Clouds Close Down: Feeding GPS Data to Microsoft Azure IoT

How to get messages from GPS trackers in MS Azure IoT via flespi telematics hub.

12 July, 2018 | about flespi | Jan Bartnitsky

MQTT scores again: flespi REST API over MQTT

How to use flespi HTTP REST API over MQTT and when not to do that.