Privacy Policy

What do you do for this? I may want to grab User Weight from UserProfile for a W/kg type metric. This says I need to host a page that explains what I intend to do with the data. Nothing except display to the user a calculation that is informed by their weight... If you've run into this, do you just point to a Google Doc you've created and then can change without notice. GDBR implications too I assume.

  • What do they mean by "collect"? What if I get the birthyear from the userprofile to calculate age to calculate max heart rate? Is that "collection"?

  • I am not a lawyer or an expert on the GDPR, but I assume "collect user data" in this context means that the app sends user data over the network to a server that stores the data.

    I would assume that the use of user data as described above does not count (especially as there's already an app permission for that kind of thing - the ability for the app to access user profile data.)

  • I'll assume you are correct and click NO for my data field. Thanks! 

  • I know you didn't ask, but just a suggestion... if you use Max HR for calculating metrics that are useful, consider a User Setting. I'm 62 y/o and my max HR is about 178. The 220-age = 158. Way wrong.

  • But max HR setting is already part of the Garmin ecosystem and CIQ apps can read it. You can even get to the max HR per activity type (run/cycle/swim/other) so you don't need to add it as a setting to your app

  • While what you send matters, I suspect where you send it also comes into play. 

    Say you have a location and use that to get weather or maps from a site.  A site that has it's own privacy policy.  And the intent is pretty clear.

    But if you send it to your own site, that's where this privacy policy comes into play.  Like "Why do you collect that data and how do you use it?"

  • I need the max HR so I can multiply it by the target heart rate percentage of max (which is an app setting) to get the target rate. Since this is for a watch face specific activities don't apply in this case. And I'm working on the premise that since I'm not saving this value anywhere and garbage collection will dispose of the temporary value when the function exits that it's not collecting data.

  • What if I get the birthyear from the userprofile to calculate age to calculate max heart rate?
    I know you didn't ask, but just a suggestion... if you use Max HR for calculating metrics that are useful, consider a User Setting. I'm 62 y/o and my max HR is about 178. The 220-age = 158. Way wrong.
    But max HR setting is already part of the Garmin ecosystem and CIQ apps can read it. You can even get to the max HR per activity type (run/cycle/swim/other) so you don't need to add it as a setting to your app
    I need the max HR so I can multiply it by the target heart rate percentage of max (which is an app setting) to get the target rate. Since this is for a watch face specific activities don't apply in this case. And I'm working on the premise that since I'm not saving this value anywhere and garbage collection will dispose of the temporary value when the function exits that it's not collecting data.

    I think the point that's being missed here is that, as flocsy said, max HR from the user profile is already available via the CIQ API, so there's no reason to estimate max HR using the user's birth year, and no reason to have an app setting for max HR.

    It may not be obvious, since there's no function or class member that explicitly mentions "maximum heart rate". You get the max HR indirectly by asking for the user's heart rate zones.

    [https://developer.garmin.com/connect-iq/api-docs/Toybox/UserProfile.html#getHeartRateZones-instance_function]

    getHeartRateZones(sport as UserProfile.SportHrZone) as Lang.Array<Lang.Number>

    Retrieve an Array of the current heart rate zone threshold values in beats per minute (bpm)

    The returned Array contains zone values as follows:

    • min zone 1 - The minimum heart rate threshold for zone 1

    • max zone 1 - The maximum heart rate threshold for zone 1

    • max zone 2 - The maximum heart rate threshold for zone 2

    • max zone 3 - The maximum heart rate threshold for zone 3

    • max zone 4 - The maximum heart rate threshold for zone 4

    • max zone 5 - The maximum heart rate threshold for zone 5

    To be clear, element 5 of the returned array will have the user's max HR. (By definition, zone 5 maxes out at 100% max HR.) As flocsy alluded to, you can either request generic or sport-specific HR zones:

    [https://developer.garmin.com/connect-iq/api-docs/Toybox/UserProfile.html#SportHrZone-module]

    e.g.

    var maxHeartRate = UserProfile.getHeartRateZones(UserProfile.HR_ZONE_SPORT_GENERIC)[5];

    Having said that, both birth year and max HR are part of the user profile, and there's already a CIQ permission which gates access to the user profile, so your app would be unable to use either of those things without enabling the permission (which the user has to agree with in order to install the app). Then again, I'm guessing most people consider their birth year to be a lot more sensitive than their max HR. Regardless, as far as CIQ goes, there's just one monolithic permission for all user profile data (which is understandable). Again, my point here is that the app *already* has to request permission to access the user profile - not only is this permission listed in the app's store page, the user also has to explicitly agree to the permission to install the app. With that in mind, it doesn't seem necessary to mention a 2nd time (in the privacy policy) that the app needs to access the user profile, especially when said usage doesn't have any privacy implications (bc private data is not being stored or shared).

    Ofc if you wanted to store either birth year or max HR on your own server (or send it to a 3rd party site for some reason), you would probably have to mention that in your privacy policy.

    I think (*) it's probably understood that any local (on-device) usage of this kind of personal data:

    - does not constitute "data collection" (as far the privacy policy goes)

    - is already covered by the standard CIQ app permissions

    For example, say your app reasd information from the user profile and uses that to calculate some value (like estimated calories burned) which is recorded to an activity FIT file? That kind of thing would already be covered by the "access user profile" permission and the "record to activity FIT file" permission.

    (* I am not a lawyer)

  • Say you have a location and use that to get weather or maps from a site.  A site that has it's own privacy policy.  And the intent is pretty clear.

    But if you send it to your own site, that's where this privacy policy comes into play.  Like "Why do you collect that data and how do you use it?"

    It seems to me that if your app sends user information to a 3rd party site as you described, that should be mentioned in your own privacy policy. Otherwise how would the user know? inb4 "it's in the app description" - my point is it seems that anything that's relevant to your app's handling of private user data should be mentioned in your own app's privacy policy, regardless of whether it's your server or a 3rd party service.

    Like: "This app sends your device location to totally-legit-dark-sky-alternative.com to obtain weather information. Here's a link to their privacy policy: ..."

    It's not like the act of sending people's data to *someone else* absolves you of any of the normal responsibilities regarding private data. Otherwise anyone could get away with not having a privacy policy by simply having 2 separate companies: one company which makes apps and another completely unrelated company which provides network APIs and stores data.

    From a practical pov, just because you trust the 3rd party providers that you use, it doesn't mean that your users automatically trust those 3rd parties, even if they trust you.