Checking Detected Locations in Security Sensitive Applications

A new paper, PrivacyShield: Relaying BLE Beacons to Counter Unsolicited Tracking, proposes a way to make hidden Bluetooth trackers less useful to stalkers by causing them to appear in other locations. It presents a working research prototype, tested mainly against Apple’s AirTags and Find My network.



The underlying problem is that these tracking networks enlist nearby phones to report a tag’s location, potentially including the victim’s own phone. The authors argue that existing anti-stalking measures offer insufficient protection. Alerts take time to appear, speakers can be disabled, and modified trackers can evade detection by changing their identifiers or pretending to be another type of device.

PrivacyShield captures nearby tags’ Bluetooth broadcasts and sends them over the internet to relay stations elsewhere. Those stations rebroadcast the signals, prompting nearby phones to report the tag at the relay’s location. This exploits the network’s inability to distinguish an original broadcast from a relayed copy. The prototype uses a modified Android app, a server and inexpensive ESP32 hardware, without requiring Apple’s cooperation or physical access to the hidden tracker.

In experiments with locations roughly four kilometres apart, the researchers made Apple’s Find My app display an AirTag at the relay location. With one reporting phone at each location, rebroadcasting twice per second reliably produced the false location; slower rebroadcasting caused the displayed position to alternate or stop updating. Effectiveness depended on both broadcast frequency and the number of phones reporting each location.

The crucial limitation is that confusing the displayed location does not necessarily erase the real one and genuine location reports can remain available. A sophisticated attacker analysing all reports, or using prior knowledge of the victim’s movements, might distinguish real locations from decoys. The experiments are relatively small, and protection across other tracking networks is proposed rather than demonstrated to the same extent. The system also cannot protect against GPS trackers, can disrupt legitimate lost-item tracking and could be misused to conceal stolen belongings.

The authors therefore present PrivacyShield as a temporary defence while providers improve their systems. They recommend faster alerts, alerts covering all device types and stronger protocol-level protections. The paper’s main contribution is demonstrating that relaying tracker signals can give potential victims a practical means of disrupting surveillance, although it does not establish guaranteed protection against determined stalkers.

The same principle could apply to ordinary, non-proprietary Bluetooth Low Energy beacons where a receiving system treats a broadcast identifier as evidence of location or proximity. Capturing and rebroadcasting that signal elsewhere could create misleading detections, although the effect would depend on how the receiving system validates and processes them. The broader lesson for users and system designers is that detecting a beacon’s signal does not always, by itself, prove that the original device is physically nearby. More security sensitive applications need to do more checks.

Can an iBeacon Send Users to a Website?

The short answer is no, iBeacons cannot directly send users to a website. iBeacons do not have the capability to push content or URLs to devices automatically.

Instead, they rely on apps to detect their presence and take appropriate actions which can include sending the user to a web site. The app has to already be on the smartphone.

There used to be a mechanism in Android that used the Eddystone-URL advertising format but this has since been discontinued by Google.

Bluetooth Beacon-Based Child Boarding and Alighting Detection

A new study develops a safety system that uses Bluetooth Low Energy (BLE) beacons to detect when a child boards or leaves a school transport vehicle. Each child carries a small BLE beacon, while the teacher’s smartphone or tablet continuously scans for its signal. The system uses the beacon’s unique address to identify the child and then sends the boarding or alighting status to the parent’s phone through a push notification.


The beacon is used mainly as a proximity sensor rather than for precise positioning. The system measures RSSI, which represents the strength of the Bluetooth signal received by the teacher’s device. A stronger signal generally means the beacon is closer, while a weaker signal suggests it is further away. Because RSSI can fluctuate due to distance, vehicle layout, obstacles and orientation, the researchers do not rely on a single signal-strength threshold. Instead, they analyse ten recent RSSI readings and calculate the average, trend and variance. A lightweight logistic-regression model then decides whether the child has boarded or left the vehicle.

The system was tested in three vehicle sizes. A conventional fixed RSSI threshold worked well within about four metres, but accuracy declined at longer distances. The machine-learning approach improved accuracy from 88% to 94% at 4–5 metres and from 76% to 87% beyond five metres.

Overall, the research shows how simple, low-cost BLE beacons can be used for automatic boarding and alighting detection without modifying the vehicle or requiring the child or teacher to scan or press anything. The main limitation is that Bluetooth signal strength becomes less reliable over longer distances, so vehicle-specific calibration is still required.

How Many Connections Can an iBeacon Support?

We sometimes get asked how many connections an iBeacon can support? The answer is ‘1’ but it’s often the right answer to the wrong intended question! The intended question is usually “How many receivers can see a beacon?”

Beacons don’t usually connect. They just advertise and can be seen by a very large number of receivers that include phones, gateways or single board computers such as the Raspberry Pi. The beacon doesn’t even know the receivers are there.

The receivers only usually connect once, during setup via an app, to set the initial beacon parameters. When connected, the beacon doesn’t advertise which prevents extra receivers from connecting. Once set up, the app disconnects and the beacon starts advertising again.

In some extreme situations, radio congestion can affect how many receivers can see a beacon.

Which Beacons are Compatible with iOS and Android?

We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether iBeacon, Eddystone or sensor beacons can be used with iOS and Android. The compatibility is achieved through the implementation of common Bluetooth standards on these mobile platforms.

However, there are some caveats:

  • Android only supported Bluetooth LE as of Android 4.3. Older devices can’t see Bluetooth beacons. Over 99% of users are on Android 4.3 or later so most people can see beacons.
  • Apple iOS doesn’t have background OS support for Eddystone triggering. While iOS apps can scan for, see and act on Eddystone beacons, the iOS operating system won’t create a notification to start up your app when there’s an Eddystone beacon in the vicinity.
  • Apple can’t see beacon’s or other Bluetooth devices’ MAC address or iBeacon ids due to over zealous privacy concerns. It can see iBeacons but you have to pre-declare, already know, their ids.

Rather than beacons being compatible with iOS/Android, we find that there are more problems with particular Android devices not seeing beacons, when in background, due to some manufacturers killing background services.

Also see Which Beacon’s Are the Most Compatible?

View iBeacons

Improving BLE Indoor Positioning Through Stochastic RSSI Modelling

A new paper, Stochastic and functional modeling of RSSI measurements for accurate distance estimation in Bluetooth Low Energy–based indoor positioning, proposes a more statistically rigorous way of using Bluetooth Low Energy (BLE) signal strength to estimate distance. Its main argument is that Received Signal Strength Indicator (RSSI) measurements should not be treated as independent, random observations. Instead, RSSI errors are temporally correlated, or “coloured noise”, and this correlation needs to be modelled if reliable distances and uncertainty estimates are required.


The authors combine two types of modelling. First, they perform stochastic modelling to describe the behaviour of RSSI noise. Outliers are removed using a median filter, then the autocorrelation function (ACF) and partial autocorrelation function (PACF) are used to examine how successive RSSI observations depend on one another. These analyses indicate that an AR(2), or second-order autoregressive, process provides an appropriate model. The resulting covariance structure is then incorporated into Least Squares Variance Component Estimation (LS-VCE), which estimates realistic variances and measurement weights. Secondly, a functional RSSI–distance model is fitted using Best Linear Unbiased Estimation (BLUE), estimating both the environmental path-loss factor and beacon transmission-power parameter along with their uncertainties.

The experiment used two Tatwah BLE beacons, the IT002 and IT008, with a Samsung Galaxy S22+ as the receiver. RSSI measurements were collected for 20 minutes at 0.5 Hz at fixed separations of 1, 3, 5 and 10 metres. Importantly, the tests were carried out in a controlled outdoor environment rather than a normal indoor environment so that interference and multipath effects could be minimised and the intrinsic RSSI behaviour studied more cleanly.

The results strongly support the authors’ claim that RSSI noise is not white noise. Also, more distant measurements should receive less weight during model calibration.

The paper’s main contribution is not a new positioning algorithm itself, but a better statistical foundation for RSSI-based ranging. Instead of simply smoothing RSSI and fitting a distance equation, it explicitly models temporal correlation, calculates realistic measurement weights and uncertainty, and then estimates the RSSI–distance relationship. The authors conclude that this produces more statistically consistent calibration and more reliable BLE distance estimates.

Three-Dimensional Beacon Placement

The paper, Advanced Algorithms for the Three-Dimensional Beacon Placement Problem Based on Constraint Programming, Large Neighborhood Search, and Evolutionary Methods, investigates how Bluetooth Low Energy (BLE) beacons can be positioned efficiently throughout large, multi-storey buildings. The aim is to minimise the number of beacons, and therefore installation and maintenance costs, while ensuring that every relevant indoor position is covered by at least three beacons so that trilateration can be used reliably.

The problem is challenging because beacon signals are affected by the three-dimensional structure of a building, including walls, ceilings, their thicknesses and their materials. The authors therefore use an RSSI-based signal model that represents different levels of signal resistance for open space, drywall, solid walls and glass. Building layouts are discretised into spatial cells, with the model calculating which areas each possible beacon position can cover. The optimisation must achieve triple coverage while also maintaining sufficient separation between beacons and minimising the total number deployed.


The paper compares three main families of optimisation techniques. Constraint Programming formulates beacon placement as a Constraint Optimisation Problem and can theoretically identify globally optimal solutions, but the search space becomes extremely large in three dimensions. Large Neighborhood Search (LNS) instead starts with a feasible placement and repeatedly removes and replaces groups of beacons, attempting to improve the solution. Evolutionary Algorithms maintain populations of placements and use selection, crossover and mutation to progressively favour solutions that require fewer beacons. The authors also develop hybrid approaches in which Constraint Programming and LNS are combined on a floor-by-floor basis.

The paper shows that the best way to solve large three-dimensional BLE beacon placement problems is not to pursue a single globally optimal search. A hybrid approach combining constraint-based optimisation with faster heuristic search can produce near-minimal, fully covering beacon layouts much more reliably and at a scale that is realistic for complex buildings.

What’s the Best iBeacon?

We often get asked what’s the best iBeacon? Unfortunately, there is no one best beacon for all scenarios. It depends on your particular project and business requirements. Having said this we have some favourites based on specific characteristics:

Best for Price: KKM K11 – Inexpensive beacon that transmits iBeacon, Eddystone UID, Eddystone URL, Eddystone TLM and battery level:


Best for Features: M52-SA Plus – Large easy replaceable battery, long range, temperature, humidity, accelerometer:

iBeacon


Best for Battery Life: MBM01 – Replaceable lithium (included) battery for a very long battery life of up to 10 years (depends on settings):


Best for Setup App: Minew range – Minew’s latest BeaconPlus range (those supporting both iBeacon and Eddystone) provides the best in class app.


View our complete range.

Detecting When a Child Enters, Remains in or Leaves a Playground

A new paper presents a low-cost system that uses Bluetooth Low Energy beacons to detect when a child enters, remains in or leaves a playground. Each child carries a Bluetooth beacon, while a single smartphone installed at the playground scans the beacon’s signal strength. Entry and exit events are then sent to a server, which issues push notifications to caregivers and creates daily, weekly and monthly activity records.


Because BLE signal strength can fluctuate due to obstacles, reflections and movement, the system applies Kalman filtering and time-based thresholds rather than reacting to every change in RSSI. This reduces false alerts near the playground boundary, although it introduces a delay of several seconds and can miss very brief exits followed by rapid re-entry.


Field tests across five playgrounds reported an average detection accuracy of about 99.2% and an average response time of roughly 6.5 seconds. A separate test with ten beacons detected 39 of 40 events, giving 97.5% accuracy. The results suggest that BLE beacons are effective for simple presence and entry/exit monitoring, but not for precise positioning. Performance may also vary with weather, site layout, crowds and beacon placement.

Understanding Beacon Accelerometer Behaviour

Many sensor beacons contain accelerometers that measure movement along the x, y and z axes. These values can be included in the beacon’s advertising data and received by a smartphone, gateway or another Bluetooth-enabled device, such as a single-board computer.

Beacons transmit advertising packets at a predefined interval. Depending on the device and its configuration, this interval is typically between 100 milliseconds and 10 seconds. An important question is what happens to the accelerometer data between these advertising events. Is the data averaged, stored or simply lost?

A key characteristic of battery-powered beacons is that they transmit for only a very short period, typically one or two milliseconds, before returning to sleep to conserve power. They do not normally continue processing or storing accelerometer readings while asleep, as doing so would significantly reduce battery life.

As a result, the x, y and z values included in an advertising packet represent the acceleration measured at, or very close to, the time of transmission. Movement occurring between advertising events is not averaged or retained.

To reduce the likelihood of missing an important movement feature, the shortest available advertising interval should be used, which is often around 100 milliseconds. However, even at this rate, movement events lasting less than 100 milliseconds cannot be detected reliably because they may sometimes occur between two advertising transmissions.