When we’re talking to companies about beacons, there’s one question that always comes up – ‘can’t they just be replicated?’
The answer is yes, they can. The signals that beacons emit are completely open, because they need to be. Beacons don’t make a direct connection with mobile devices, unless the owner has directly connected to them, using a password, to manage them. When a normal user passes a beacon, their device needs to be able to read the beacon ID to trigger the right action.
As beacons use the Bluetooth wavelength, they transmit on the unregulated 2.4Ghz band. Again, this is one of the good things about beacons, companies don’t need to pay to use the spectrum. So long as they own the space beacons are being deployed, they can be put anywhere.
Some companies are worried that with beacons, it will be possible for people to replicate the IDs to trigger the wrong action, in the wrong location. Here’s why some companies worry about this:
Triggering a competitors app: Whilst this could be possible for a competitor who truly wanted to, if they were to do this, it would be patently obvious what they have done. It would also require them to get the IDs, build the IDs into their app and release an update. Users would also then need to have the competitors app installed on their device. This is quite a lot of hassle to go to.
Trigger the wrong action or message at the wrong time: This is a concern when creating apps that utilise beacons for the blind or others with accessibility needs. If apps trigger the wrong action at the wrong time, it could be dangerous for the people using the apps.
Degrading the user experience: If too many of the wrong beacons were trying to trigger in the same place, it could cause apps to misbehave, which would then degrade or ruin the user experience.
Whilst these are all valid concerns, they don’t need to exist. To mitigate these types of concerns, we’ve developed some ways to intelligently protect beacons:
Wi-Fi management: network exists, companies can manage the beacons remotely to update the IDs on a rolling scale. By also updating the backend systems to trigger the right information, it removes the concern.
Device management: it’s possible to build into apps the ability to update beacon IDs to avoid spoofing. This wouldn’t need to be everyday but instead once a week. This type of implementation likely wouldn’t be used for retail apps or other apps directed at consumers, but instead for enterprise implementations where the entire experience can be controlled.
Hidden ID: It’s possible to build a hidden ID into beacons that can’t be read visibly and would need to be verified in the background by the app. As apps and beacons are designed to work together, this would make it simpler to manage.
Though there is the potential for people to mimick beacons, the same can also be said for other systems such as GPS where it’s possible to trick a device into thinking it’s somewhere else.
Due to the amount of effort required to have a tangible impact on the way in which these technologies work, we see it as being unlikely that companies or individuals would choose to try this. There wouldn’t be much that they can achieve by undertaking this type of activity.