Menu

  • About
    • Our Team
  • Who We Work With
    • Councils
    • BIDS
    • Town Teams
    • Bespoke Projects
    • Case Studies
  • ElephantWiFi
  • GEO-Sense
  • Vehicle Sense
  • Reports
  • News
  • Contact
  • Skip to primary navigation
  • Skip to main content
  • Skip to footer

Proximity Futures

Decisions through Data

  • About
    • Our Team
  • Who We Work With
    • Councils
    • BIDS
    • Town Teams
    • Bespoke Projects
    • Case Studies
  • ElephantWiFi
  • GEO-Sense
  • Vehicle Sense
  • Reports
  • News
  • Contact

GEO-Sense MAC Hashing

July 27, 2021 by Rod Rayner

This blog has been written to provide an explanation on how GEO-Sense adheres to GDPR requirements on data privacy by utalising software hashing against the MAC address of a device..

What is a MAC Address

A MAC address is a 12 character hexadecimal unique identifier associated to every network device. The MAC address is associated to a device and not a person, it does not contain any personal information about an individual however GDPR does regard the MAC address as Personally Identifiable Information ( PII ) as it can be used to track the location of a device.

System Overview

GEO-Sense servers are hosted by Amazon Web Services (AWS) in London, UK.

Local sensors installed at the venue collect signals emitted from WiFi devices when in range which are referred to as probe requests. When a probe request is captured, all information other than the MAC Address is discarded at which point we also append the date, time and sensor ID to the data. The data is transferred to our cloud based servers at AWS where it is securely stored into our databases. Transmission of data takes place immediately when connected to the Internet or is stored locally until such time there is a connection to our cloud servers. All sensors are secured by username and 8 digit alphanumeric password.

As soon as the data is data within the database the MAC Address is immediately hashed.

What is a Hashed Address

In simple terms hashing is passing data through a formula that produces a different result to the original data provided, this is called a hash. That hash is a string of characters and the hashes generated by a formula are always the same length, regardless of how much data you feed into it. For example, the MD5 formula used by GEO-Sense always produce a 32 alphanumeric character long hash. E.g the hashed result of GEO-Sense is 54e5a86b210bf915efe9dee6bfe4ba8. Its worth noting that any change in the original data, even the character case will change the hash.

Finally and probably the most important note, hashing works in one direction only for a given piece of data, e.g. if the same data is used you will always get the same hash you CAN NOT turn a hash back into its original data.

Hashing Detail

GEO-Sense does not store any MAC Addresses. As soon as the probe request is received by our servers the MAC address is hashed using an MD5 hash function. We apply two levels of hashing with GEO-Sense, when the data is initially received we regard this as the level one which immediatley encrypts the data ensuring it is anonymised.

The first level hash is created using the MAC Address and another unique data block known only to key personnel at Proximity Futures. This additional data block is different for every venue we manage.

Level one hashed data is stored in the database until midnight. Every day after midnight an automated scheduled task runs which summarises all the probe request data moving it into new tables within our database meaning the end result is just numbers, i.e. 9654 visitors. It is this data that is used to populate the customer web portal. The original hashed MAC Addresses are not stored in these summary tables.

All but one ( please see retained hashed data section ) database table stores summarised data.

Level Two Hashing

In addition to the original hashed MAC Address all summary tables ( apart from Repeat visitors ) undergo a further step which hashes the original hashed address ensuring completely anonymisation. We refer to this as level 2 hashing.

Level 2 uses a random number which has a float value of up to 15 decimal places between the range zero and one (e.g 0.264232316207357). Such a long randomised number would take approximately 44593678502 ( 4.45 Billion ) years to correctly guess and therefore it is considered to be impossible. This can be checked by entering the above number into the following website – https://random-ize.com/how-long-to-hack-pass

If by chance the correct number was guessed ( every guess would involve testing to see if it’s was correct ) you would still need the original MAC address AND then attempt to crack the level one hashed address at which point you will then need the additional data block added to the level one hashed address. Forgetting the requirements needed to obtain the unique data block code the only way to obtain the MAC address is through consent as only the person with control over the device can obtain the MAC address. More information on consent is detailed below.

Finally if everything above is not enough to put someone off, the random number used for level two hashing changes every day so if it were possible to hack the only data obtained would be for that single day and then another 4.45 Billion years would be needed to get the next days data and so on.

Retained level one hashed data

As mentioned above there is one table that does not undergo the level 2 hashing.

In order to calculate if a visitor has been to the venue before GEO-Sense uses a dedicated table which is used to determine whether the new probe request already exists in our database for any given venue. These records are stored as a level one hashed address with a first seen and last seen timestamp associated to it. We do not store any other data within this table.

The reason we check to see if the level one hashed address exists or not is so we can report on if the device has visited the venue or not in the past. We refer to this as New Vs Repeat data. The New Vs Repeat calculation is based on the first time a device is seen at a venue and also the last time, no other information is stored and its only available at a venue Level. i.e. has the device been seen by any sensors at a specific venue, it does not log which sensor has noted the device, it is simply a whole venue Yes or No calculation.

Can a hashed address be recreated?

Hashed addresses can ONLY be recreated if the original MAC address is provided and the additional data block is known. In order to obtain the original MAC address consent would be needed as the only way to obtain it is by physically checking it on the device itself.

What if you did recreate a hashed address?

Before we answer this there are two very important question that need to be considered.

  1. What data can be obtained if we did recreate the hashed address
  2. How did we recreate the hashed address.

In addition to the two questions above its important to note that we currently have no way to recreate a hashed address or use one to carry out a manual search within our databases. It would require a considerable amount of very specific software development to be undertaken which has no ongoing usefulness to us as a business and therefore the costs would be impossible to justify.

To answer question 1; If the software development was undertaken to be able to use a hashed address the ONLY information obtained would be to access the data generated from the device for the current day up to just after midnight when the 2nd level hashing is applied.

The answer to question 2 is probably the most important. , In order to recreate the hashed address consent has to be given as the MAC address has to be provided. Before consent is given the owner would be advised of all the data that can be obtained and presumably they would only provide consent if they are happy for that data to be used.

The definition of consent within the GDPR guidelines is

“Consent of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.”

Case Law

To date there have been two judgements on note concerning WiFi Location Analytics. One in the Netherlands and the other in the UK concerning Transport for London.

Netherlands case – Dutch Data Protection Authority (DPA) V’s the municipality of Enschede.

This legal case made the headlines as its resulted in a considerable potential fine which is being appealed. In summary the Dutch DPA ( UK equivalent to the ICO ) issued a fine against the municipality of Enschede for 600,000 EUR  at the end of April 2021. The fine is based on the incorrect use of data generated by WiFi Location sensors. The issue being the system did not mask the MAC address and instead appended additional data ( time stamp  / sensor ID etc ) to the MAC. This was believe to create a sudo address but as it contained the original MAC address it was not deemed that privacy had been upheld.

For information can be read here – https://edpb.europa.eu/news/national-news/2021/dutch-dpa-fines-municipality-wi-fi-tracking_en

Why is GEO-Sense different?

GEO-Sense maskes the Mac address where as the Dutch system appended data to it. A Masked address can not be recreated without being given the original data used to generate the hashed address which has to include the original MAC address. The ONLY way to obtain the original Mac address is through consent.

UK case – Transport for London

Although this is not a legal case it makes clear that the ICO are happy for WiFi Location Analytics to be used as long as the correct procedures are followed and privacy is upheld.

A recent question was put to the Mayor of London asking “Can you detail any advice you and/or TfL have sought or received (including but not limited to from the ICO) regarding the data protection implications of this tracking?”

The response was very clear which approved the use of WiFi to collect Location Analytics within the London underground system and showed that the ICO was involved in the decision to go ahead with the project and in fact he Information Commissioner, Elizabeth Denham, commended TfL’s approach to the pilot at a hearing of the Oversight Committee in September 2017.

More information can be read here – https://www.london.gov.uk/questions/2019/17450

Why is GEO-sense different?

GEO-Sense is no different to the system used by TFL which has been commended by the ICO.

In Summary

Unlike other applications that use traditional WiFi Access Points which haven’t been designed with footfall in mind and require the data to be manipulated to “try” and meet GDPR requirements, GEO-Sense is a dedicated solution designed in house by Proximity Futures from the ground up with privacy and footfall measuring at its core using proprietary hardware and bespoke software.

The two examples above highlight the difference between managing the data properly or making a very expensive mistake. It is very important that you chose your data solutions / suppliers based on a real understanding of the data laws and how to protect individual’s privacy.

We at Proximity Futures have been working with footfall data for several years and have a wealth of knowledge. Not just in collecting the data but also ensuring you get the best from it.  We are ranked very highly by our customers and continuously invest to make sure we stay ahead of the game.

Filed Under: Blog

Footer

  • About Proximity Futures
  • Our Team
  • Bespoke Projects
  • Working with Town Teams
  • Working with BIDS
  • Working with local authorities
  • Reports
  • News
  • ElephantWiFi
  • GEO-Sense
  • Enviro Sense
  • Vehicle Sense

Head Office

22 Greenfields Business Park
Wheatfield Way
Hinckley
LE10 1BB

0116 326 5389

Proximity Futures Ltd. Company Registered in England and Wales. No. 09307093
Copyright© 2025 · Privacy Policy · Site Map
Instilled Ltd