Sleep and monitoring files: unknown messages

Thank you for getting back on this Ben, at least this is clear now.

Would be interested to know what you have discovered, and maybe how !

All I know is what's in the FIT SDK. The only thing I worked out for myself is roughly interpreting sleep patterns based on activity_type and intensity in the Monitoring files. I can compare sleep data from today with 5 years ago because I always use the same method, but if it is actually sleep quality.. don't think so, it's more about how little I move. So I don't advice doing that.

This answer feels incredibly unsatisfying, incomplete, and unhelpful. 

How is it that when looking at FIT files from 2018, there are still unknown fields?  Looking at the latest FIT SDK documentation (21.40) doesn't answer any of my questions.

How can Garmin make a credible claim that they are complying with CCPA requirements?  Aren't we supposed to know what data is being collected about us?  How can we know if Garmin won't tell us?

I agree with some reservations.

If Garmin themselves introduce new fields at the core level (non-dev data), I fully agree that Garmin should take responsibility and document these. Especially since many users upload their data for analysis in an unknown online environment (the developers of these apps/environments may also have been able to reverse engineer unknown fields without my knowledge). Today, even outside of fitness and biometrics, I as a user often have to give consent for a third-party to analyse data that is in part effectively unknown to me. It would indeed be nice if Garmin was on the forefront in terms of "data openness".

While I wouldn't share data I know to be sensitive, it's often difficult to judge exactly what I am sharing, due to the complexity and numerous tiny pointers sprinkled all over that "connect the dots" in today's telemetry formats. A photo taken on a modern mobile phone usually contains both location and time. GoPro embeds all telemetry within the MP4 (including gps data) whereas VIRB at least has a separate FIT-file etc. At work we've been using a lot of FIT-files lately, and I get a bit frustrated with how easily some throw around "open data" considering the challenges with preserving privacy and the need to protect identities when I may not even know exactly what the data contains.

As for other hardware manufacturers using FIT, I guess it's a bit more difficult to control? Unless it's possible to demand that all new data types, "core" types and developer data types, are openly documented somewhere. (of course, as you mention, there may exist other regulations to comply with). Ironically dev data is already in a better position since it mostly comes with a description embedded within the FIT-file.

One thing is clear and obvious from the threads in this forum, however: quite a lot of us deal with data with undocumented fields.

Good points. I consider all fitness data potentially sensitive - even if it would not be considered as such today, who knows what it could be used for, or combined with, or where it could go to, in the future.

There is good software to locally process activity files, but nothing for monitoring files, so I wrote some to get the stepcount, active calories etc out of the monitoring files back in 2016 - no unknown fields in the files from back then. Stress level was added and it's clear what it is. 

All in all it's sure nice that my 2016 software still works on today's files, so I can understand that Garmin doesn't share newly developed messages when they are not sure they will keep them, but why not put a date on an experimental feature: if it has been used for 6 months, document it?