The beacon sends out a signal which is a the same as the connection advertising format, but with the CONNECTABLE bit turned off. This gives 20-30 bytes or so of data you can stuff out there along with the UUID.
The app typically listens for UUIDs of beacons it cares about, and when it sees it, collects the one-way device to app beacon data. Then does something with that -
It's just that the "something" is usually reporting to a website that the beacon has been seen. This is entirely how TILE find-it tags work.
So the threat model here is that if you can get someone to go to your website, you could potentially see what BLE beacons are near that device and report them.
I am not sure if SCANNING requires user consent - or just connection event does.
The beacon sends out a signal which is a the same as the connection advertising format, but with the CONNECTABLE bit turned off. This gives 20-30 bytes or so of data you can stuff out there along with the UUID.
The app typically listens for UUIDs of beacons it cares about, and when it sees it, collects the one-way device to app beacon data. Then does something with that -
It's just that the "something" is usually reporting to a website that the beacon has been seen. This is entirely how TILE find-it tags work.
So the threat model here is that if you can get someone to go to your website, you could potentially see what BLE beacons are near that device and report them.
I am not sure if SCANNING requires user consent - or just connection event does.