SDK 8.2 announcement: "On System 8 devices, ANT or BLE sensors that search for sensors outside of the native pairing flow will be shown a security warning."

Any dev or user who's been testing beta firmware has probably noticed that if they edit an activity data page and simply scroll to a CIQ data field which searches for sensors, it will *immediately* show a security warning prompt along the lines of "This connection is insecure. Proceed? [Yes/No]". It's not even possible to scroll fast enough to avoid this warning.

I wrote a bug report about this because:

- I felt the prompt is very vague

- It's triggered just by scrolling to a CIQ data field (not even selecting it). I understand why this happens, because the app is started in order to show content for the preview, but I don't think this is very user friendly

- If you select Yes, then the data field is added. (This seems like a bug to me. I pressed to START to select Yes for the prompt, I didn't press START to add the data field. I've seen similar bugs with the Map settings which were fixed, and hopefully this will be fixed too)

- If you select No, then the prompt comes back almost immediately, unless you very quickly scroll to another field. (Also very user-unfriendly.)

I also tested adding a data field that searches for sensors using the Connect IQ mobile app "real-time settings", while the watch was outside of an activity (e.g. on the watchface). In this case, the warning is displayed on the watch anyway.

Anyway, based on the announcement, it looks like the way to get around this problem is to use the native pairing flow.

In other words, this answers the months-old question about whether it's mandatory for CIQ data fields use the native sensor pairing flow. It kind of is, unless you want your users to get an annoying and user-unfriendly security warning.

This is clearly Garmin's way of "nudging" devs to use the native sensor pairing flow, and I kind of get it - it's all tied into the changes they are making to be compliant with EU RED [*], which is why ANT is "dead" [**] now.

[*] it specifies wireless communications have to be authenticated/encrypted or users have to be notified when this isn't the case

[**] not really dead but maybe dying. current ANT+ products will be supported, and new ANT+ products are still released, but there won't be any new development (like adding new ANT+ profiles)

flocsy🤠 27 days ago

My DataField can't work when the HRM is paired and connected from the watch system menu, because then the watch uses the ANT sensor instead of the optical HR sensor, and there whole point of the ANT+ HRM DF is to compare the HR readings from the optical sensor vs the chest strap, or that you SEE the HR of your training partner, but of course you want the watch to use your HR for all the usual calculations and not your partner's HR.

flocsy🤠 27 days ago

Where is the bug report?

FlowState 27 days ago in reply to flocsy🤠

flocsy🤠 said:
My DataField can't work when the HRM is paired and connected from the watch system menu, because then the watch uses the ANT sensor instead of the optical HR sensor, and there whole point of the ANT+ HRM DF is to compare the HR readings from the optical sensor vs the chest strap, or that you SEE the HR of your training partner, but of course you want the watch to use your HR for all the usual calculations and not your partner's HR.

I don't think you understand.

"Native pairing flow" in this context does not mean that you pair the sensor in the sensor menu with no involvement from the CIQ app, it means using the new CIQ feature where a CIQ app can use the built-in sensor UI to pair its own sensors. I think you should know better as this came up months ago and you were part of the discussions.

In other words, your app should still be able to make a direct connection to the sensor as before (using the Ant module), it's just that instead of scanning for sensors when the app starts up:

- when the user opens the native sensor menu, your app can take part in the built-in process of scanning for sensors

- if the user selects a sensor associated with your app, your app can do *whatever it needs to do to pair with the sensor*. Crucially, the *system* doesn't pair with your sensor, the app does.

e.g. As per the docs:

At this point, your app should do the necessary steps to pair the device. On ANT, this could be as simple as capturing the device id and persisting it

- when your app is installed, users will be prompted to pair with your app's sensor (if they answer yes, the native sensor UI will be brought up)

In other words, the sensor UI "drives" the pairing process in your app (and vice-versa).

Again, the system does not directly pair with the sensor. If that was the case, why would any of this be necessary? The user already has a way to make the system directly pair with a sensor without any involvement from a CIQ app.

At least that's my understanding of it - I haven't tried it myself. Someone else mentioned that there is now a separate Connect IQ category under the built-in Sensors menu. Here's a related bug report with a screenshot:

forums.garmin.com/.../native-sensors-appearing-under-sensors-connect-iq-menu-ciq-system-8

All of this obviously seems a lot more user-friendly than what CIQ data fields have to do today:

- blindly scan for devices on startup

and/or

- allow the user to manually enter ANT+ ID in settings

If you were to implement the "native pairing flow", users of your data field would actually be able directly select the HRM they want to use with your app from the built-in sensors menu, as opposed to using the clunky workaround of determining the ANT+ ID and manually typing it into app settings.

All of it is described here:

[https://developer.garmin.com/connect-iq/core-topics/pairing-wireless-devices/]

FlowState 27 days ago in reply to flocsy🤠

flocsy🤠 said:
Where is the bug report?

You have already seen the report and commented on it:

forums.garmin.com/.../fr955-23-20-when-changing-data-field-if-you-scroll-to-a-ciq-field-that-makes-an-ant-connection-a-full-screen-prompt-warns-you-that-an-open-connection-will-be-used-if-you-dismiss-prompt-with-start-the-field-is-also-selected

To be clear I think the bug report is mostly superfluous now, except for the part where answering Yes to the "insecure connection" prompt *also* selects the data field, when you edit a data page and scroll to a CIQ data field that scans for sensors.

Clearly Garmin wants app devs to use the native sensor pairing flow, so they're not going to get rid of that prompt or make any significant change to it (except maybe fixing that one bug). The way for devs to avoid the prompt is to use the native pairing flow.

FlowState 27 days ago in reply to FlowState

So I think 2 things are happening here with the native sensor pairing flow in CIQ:

1) Use of this feature makes apps which connect to sensors more user-friendly (in theory)

2) Use of this feature also allows the system to seamlessly display their new "insecure connection" warnings in a fairly user-friendly way (same as it's done for the native sensors, in the info menu for a given sensor.)

We can already see that Garmin intentionally displays a user-unfriendly "insecure connection" prompt when apps *don't* use this feature, but instead scan for sensors on their own. And it's hard to see how Garmin could make that prompt user-friendly, since it has no control over how apps scan for sensors on their own. This is why Garmin will immediately display the "insecure connection" prompt when you edit a data page and scroll to a data field which scans for ANT+ sensors. Garmin has no choice, because they have to start the data field app in order to show a preview of the field contents, and when the app starts, it tries to scan for sensors (bc it doesn't know it's "just" displaying a preview). Ofc we could imagine that Garmin could add a new feature where an app can provide a "preview" view, but that's a lot of work, and apps would have to opt-in anyway. (I guess they also have to opt-in to the native sensor pairing flow, but that's a lot more crucial as Garmin wants apps to use that flow anyway.)

So it's a way for making things easier for the user and also a way for Garmin to have some control over the process (e.g. to display the warnings they want to display, without being too obtrusive).