Google Locator Tag guidelines

Hi,

There are two 'should' (as opposed to 'must') statements in the Fast Pair implementation guidelines for Locator Tags:

1. The Provider should reject normal Bluetooth pairing attempts and accept only Fast Pair pairing
2. The Provider shouldn't expose any identifying information information in an unauthenticated manner (e.g. names or identifiers).

However, I want to include the locator tag functionality into an existing custom BLE application in development that has an associated mobile app.

What's the opinions/thoughts on not following the guidelines?  (e.g. my device ModelId gets banned from the FMDN network?)

I appreciate that I may have answered my question and the authoritative source to the answer of my question is Google so as well as your thoughts I wondered if anyone in Nordic (or elsewhere) can point me to contact in Google that might be able to clarify/confirm that ignoring those 2 guidelines is perhaps a path to tears.

Thanks,

Wayne

Parents
  • Hi Wayne,

    If you have another Bluetooth application use case apart from the locator tag, you may not need to declare their device as a "locator tag". In this case, you wouldn't be required to follow the locator tag guidelines.

    You can consider creating another Bluetooth identity to serve you second application use case and use it for pairing/bonding. However, you still need to follow the privacy requirements, as any vulnerability in the second Bluetooth use case can be leveraged to track the Bluetooth device that combines both features.

    As a side note, the Bluetooth bonding is omitted for FMDN locator tags, as there is an issue on Android that causes connection delays/failure when connecting to bonded targets.

    Best regards,

    Charlie

Reply
  • Hi Wayne,

    If you have another Bluetooth application use case apart from the locator tag, you may not need to declare their device as a "locator tag". In this case, you wouldn't be required to follow the locator tag guidelines.

    You can consider creating another Bluetooth identity to serve you second application use case and use it for pairing/bonding. However, you still need to follow the privacy requirements, as any vulnerability in the second Bluetooth use case can be leveraged to track the Bluetooth device that combines both features.

    As a side note, the Bluetooth bonding is omitted for FMDN locator tags, as there is an issue on Android that causes connection delays/failure when connecting to bonded targets.

    Best regards,

    Charlie

Children
No Data
Related