Class-based, aggregated, anonymous device tracking / fingerprinting
- Langage dominant
- Python
- Étoiles
- 2k
- Forks
- 70
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
Allow some level of tracking of anonymized devices, even if we can't track them individually.
Some devices (such as Google FMDN (Find My Device Network) tags or other devices with randomized MAC addresses have no way of being individually tracked without some protocol-specific support.
Often that support doesn't exist yet or is impractical (I am hopeful that someone will create FMDN support in HA soon).
In other cases, support may exist (such as IRK resolution via the `Private Bluetooth Device` integration) but the operator of an HA install may not be able to implement it (eg to track a device they do not own, or one that has introduced to the home without their permission or knowledge).
It would be useful to be able to track those devices, even if only in a semi-anonymous form.
## Ethics?
Ethically, while this is a subversion of the deliberate anti-tracking efforts of using randomised MAC addresses, the tools that Bermuda offers don't *have* to be used, and there is an implied level of sovereignty over one's own home (in my admittedly male-centric culture, there is a common expression: "A man's home is his castle"). Making it easy to see the data that is being broadcast through the open air for all to see is not in its own right an invasion of privacy, IMO - if anything, its initial broadcast is the problem.
## How
So... the idea is that when a device with a random MAC is seen:
- If it can be uniquely identified via a protocol (such as via IRK), do that
- If it can be uniquely identified via the payload (such as an iBeacon), do that
- Otherwise, if it can be lumped into some sort of class (eg FMDN tag, AirTag etc), then this feature kicks in
The process then is to:
- If the option to do anything is turned off, don't do anything.
- Identify the class of the device (FMDN, AirTag, iOS Device etc)
- If there was a previous device of the same class that just stopped advertising, assume that this is the same device but now operating from its new address
- Otherwise, assign the next unused tracking-entry for the device class to this new device.
This means we'd have a collection of class-based devices in the system that come and go, with ones that "live" in the house being pretty stable in which entity they get assigned to, and the passing ones coming and going fairly randomly.
## How is this useful?
- If someone has slipped a tracker into your car, backpack etc, you are more likely to notice by the entity popping up, or you can create automations to advise you if this happens
- Bermuda can answer questions like "how many AirTags are in my house right now, and where are they?"
- If you have lost an item (say some headphones), Bermuda may not be able to tell you which one it is, but it can give you a short-list of places to look. This includes guest items that you may not otherwise choose to set up for tracking.
- If you only have one of a particular type of device, this might be all the features you need to track it.
- Bermuda can offer a second-class support for otherwise unsupported protocols.
## UI Elements
- options_flow boolean for "Enable class-based aggregated tracking of devices"
- perhaps one per "class"? (eg AirTags, FMDN, iOS, etc)
- Dynamically-generated devices for each class (eg: `Anonymous FMDN Tag #3` etc)
## When?
This is a lower-priority feature, likely to be taken on only after initial trilateration support is added.
Please vote via reacts if you wish to see this feature added, and comment if you feel there are improvements that would help your use-case. Please don't bother commenting if you won't use this feature, they're not *all* just for you :-)
## Related links
- #271 request for FMDN device support
Guide de contribution
Ouvrir le guide de contribution
Évaluation
Cette issue n'a pas encore été évaluée.