GDPR Privacy

Horror Stories in Compliance

GDPR went live in 2018, which would lead people to believe that companies are finally getting their compliance strategies and training right. Sadly, this past week alone I experienced 2 companies failing completely to maintain compliance and with little strategy to regain it.

The first case involved communications with a hardware supplier based out of Germany. I needed to confirm some details for an order and in the message, requested not to be added to any mailing list / newsletter. In a perfect world, the sales rep would have replied with the answers to my enquiry and a simple confirmation no unsollicited sales messages would be reaching me. As you can imagine, my writing about this exchange is due to the situation being ever so slightly different.

Indeed, the sales rep’s reply answered my inquiries and promptly let me know I could unsubscribe from the newsletter through the unsubscribe button at the end of any of the newsletter messages. Now, I have 2 concerns with this reply.

  1. This means that sales reps, who are likely to use a CRM have no control over the data, or lack the training necessary for it.
  2. The CRM is most likely from an external provider, which means any data is now in the hands of a third party without my conscent.

While the external provider generates the highest risk to compliance, it is the lack of control or training which most demonstrates a companies lack of interest to their data governance. Indeed, a company sharing all their data with a 3rd party with no control on what is transfered nor how it is transfered, will have a difficult time obtaining verification that records are deleted by the provider. Furthermore, when a client unsubscribes from the newsletter, the probability of the email adress being removed from the recepients list is minimal compared to that of the adress being placed in a different table, along with those emails generating bounce errors.

The second ocurred after ordering a delivery. The online ordering process was relatively clear, and marketing opt-in was well organised. The order confirmation came through, followed shortly by a receipt/bill for the ordered goods. So far so good, until the next day where… “Welcome to [delivery place]” and “Thank you for ordering with [delivery place]”. Quick scan of the emails showed domain was not spoofed and links were not hiding multiple redirections.

While unsubscribing from the mailing list took all of 2 seconds, the experience demonstrated that this company had completely lost control of their customers’ data, as the emails explicitely mentionned that data was shared with an external CRM and provided links to the CRM’s data privacy policy. All this while explicitely avoiding creating accounts for faster orders in the future and checking no marketting opt-ins were selected.

So, what strategies can users take to avoid these types of issues in the future? Well, for starters using dedicated emails for each service will mean once transactions with any business are finished, the dedicated email can be autoforwarded to trash should any marketting arise from the transactions. The second, is to make any small orders by telephone rather than online, as this is a piece of information requested for online orders anyways.

GDPR Privacy Tech

Protect Scotland & Privacy

Interconnectivity in the UK

Following my last post on privacy and the NHS apps in the UK, I was informed the different services in circulation in the UK were talking to each other. The main change for users was that they no longer needed to download different apps when moving accross the UK, being able to use their local app in Scotland, England, Wales, Northern Ireland or Gibraltar. While it certainly provides a better user experience, the backend implementation can be a nightmare for privacy conscious people.

The simplest implementation would be to move from local servers to a centralised location, and have all apps communicate with a single entity. Such a solution would provide the advantage of having an increased manpower which can focus on securing and protecting the infrastructure. On the other hand, with no geolocation data, such a system increases the amount of data devices need to check against drastically, specially with the rising number of cases in the UK at the moment.

Another possibility would be to let all apps communicate with all servers with distributed connection times. Given the data is distributed across devices there is little concern for data misuse, access to the data on the device would need to be as restricted as possible, given positive matches would allow for fingerprinting when an user was in which region.

Finally, a third solution would be a handshake protocol between devices. I remember a colleague who also worked IT in hospitality mentioning the physical access control system he used meant physical access only needed to be used on a single door, with the information being spread “like a virus” as employees and clients alike would load updated access control from locks and distribute it to any locks they opened. Now, imagine a handshake between 2 Bluetooth devices (A&B) before they start sending out their pings:

A: “I’m SCO” – PING
B: “I’m ENG” – PING
A: “Here are some cases from SCO” – PING
B: “Here are some cases from ENG” – PING

There are 2 possible implementations for this I can see, each with their drawbacks.
1. Non-local data is distributed only in a P2P fashion, with local devices sharing it locally. That is the local device would then share the new information with other local devices and update its own datapoints. This means the people most at risk from contact with folks travelling the country would be sharing this information with the people they expose (family, coworkers) without the need for a central repository. Additionaly, people with limited contact/exposure to travelers would not be checking oudated datapoints themselves.

2. Local devices update the local servers with the non-local positive cases daily, whereby all local residents can check their data. This of course leads to increased processing on the devices, and essentially the same situation as each app connecting to each server.

What concerns would a P2P infrastructure imply? Well, for starters, when a traveller is tested positive, the people they were in contact with while abroad would not be informed until at least 24 if not 48h after the infected person’s data is made public, at which point some or most of the data points may have been deleted from old age. In terms of privacy, a P2P protocol would be easier to reverse engineer and exfiltrate data / poison existing data due to the limited authentication required. However, a P2P infrastructure would make sharing data internationally far easier, for example by updating national systems from the data obtained from flight crews.

The debate between national & international health and privacy will not be going away overnight. However, regardless of which data sharing method was implemented, it is nice to see that Protect Scotland uses a clear and concise privacy policy, most notably specifying for how long data is retained. One can only hope private sector would follow suit accross the board, rather than only on a case-by-case basis.