Add new event type for Bluetooth/Wifi proximity signal detection?

[dazcode]

Can an event be logged for wireless signals Haven detects that pass a certain signal strength threshold? For example, if someone has a bluetooth device on and walks near the Haven device, then that event could be logged.

[dustedrob]

I've got some level of expertise with the Android Bluetooth and WiFi API's and would love to collaborate on this one if it's requested. The problem is that starting with API 23, the Location permission needs to be granted and Location services need to be enabled for Bluetooth and Wifi scanning to work. This could compromise the privacy of the user:

https://developer.android.com/guide/topics/connectivity/bluetooth.html#Permissions
https://developer.android.com/reference/android/net/wifi/WifiManager.html#getScanResults()

[n8fr8]

We could leave it up to the user where they want to allow it or not, at least on Android 6+ devices.
Regardless, we need to consider more what we could actually achieve by monitor BT and Wifi... would it really be that meaningful?

[dazcode]

Would it be possible to initially gather as a (WIRELESS SIGNAL) event:

WIRELESS SIGNAL EVENT - (BLUETOOTH)

1. MAC address (00:00:00:00:00:00 / SAMSUNG S7)
2. Device Name ("Joes' phone")
3. RSSI (".85db" / PROXIMITY: VERY CLOSE)

And possibly in the future:

1. Device capability scan (hotspot,audio sink, filetransfer etc)

Possible issues:

1. This wireless data can be manipulated/spoofed or may not be broadcasted at all.
2. Active vs Passive scan modes. Some active wireless scanning can reveal the presence of a Haven device.

I really think that this wireless event intelligence would really be quite valuable for Haven, even if you're dealing with someone who is spoofing their MAC for a device, knowing that you are dealing with an advanced threat is useful.

Another benefit of this feature working is that Haven can be out of sight (in a bag for example) and still tell you when someone has entered your monitored area. Basically extending Haven with a wireless detection fence perimeter. I really think this would give Haven a huge advantage over other similar camera/sound security systems.

I know there are some limitations with regards to wireless scanning/detection on Android systems (such as monitor mode requiring root?), but I think there is a baseline (which doesn't require root) of very useful wireless information that can be gathered as an event. I hope that dustedrob or someone else who is an expert in this area can jump in and give some feedback on all this!

[E3V3A]

Great idea and also a good start for #106.

[dustedrob]

This wireless data can be manipulated/spoofed or may not be broadcasted at all.

@dazcode Yes, this data can be spoofed or altered by the source, especially if the source is another smartphone/computer so it's not 100% reliable

I know there are some limitations with regards to wireless scanning/detection on Android systems (such as monitor mode requiring root?

Root isn't really necessary. You can have Bluetooth, Bluetooth LE and Wi-Fi scans without having root.

[dazcode]

We could leave it up to the user where they want to allow it or not, at least on Android 6+ devices. Regardless, we need to consider more what we could actually achieve by monitor BT and Wifi... would it really be that meaningful?

@n8fr8 , Are you concerned about too many wireless events being logged or were there other concerns? I think with the right user onboarding calibration for this feature, that can definitely be addressed.

[ghost]

Clearly logs of bluetooth scans would be useful to have for identifying intruders who are not diligent about their bluetooth signalling.

It could also be used to detect approaching friendlies, and deactivate Haven before the logs get polluted with false positives, and reactivate when they're gone. A bluetooth whitelist could be an alternative to the timer.

Note also that detecting friendlies could to some extent lessen the need for this controversial feature request in some scenarios: #167. It could also solve @toxynoid's problem (#286).