Is it possible to retrieve the watch's unique device id or serial number on a VA-HR? I suspect there are interesting attributes in System.getDeviceSettings() but I can't find what they are :(
... but it's not as simple as providing the device ID because of security concerns. ...
I'm struggling with "security concerns".
We're presumably talking about security of the watch owners aren't we? I can't see how the security of any other stakeholders would be a consideration: the app developer, the equipment manufacturer, the general public? No, I don't think so.
And we're not talking security in any physical sense are we? Is it going to cause the watch to explode or harm the user in any way? No, I don't think so.
And how about security of possession? Is it going to make the watch any easier to steal? Again, I don't think so.
So is it something to do with privacy?
Could the owner's privacy be compromised by an app knowing the watch's device ID? I can't see how, after all, my app can already report details of the watch's activity back to my web service without having access to the device ID, so what's the difference? Since I don't know the identity of the owner either way, I can't see how their privacy is being affected.
Can anyone think of any way in which knowledge of the device ID might present a security concern?
Some users may not want the serial number, etc, of their devices available to 3rd party sites. It's really that simple. For an app in the store, you'd have to select "yes" for "Does your app collect user data?" if you did so, and also fill out a thing about how you use that data, etc, for users.
You may want to look at OAUTH to ID users on a specific device, or generating a key on your site a user must enter with settings for your app.
I would be quite happy to declare up front that the app will collect the watch's ID and why, so it would be up to you to chose whether or not to install the app. Also there are a number of ways to generate a specific id using OAUTH and other methods, but a reinstall of the app would regenerate a new one, defeating the objective of uniquely identifying a device.
Anyway, that was not my question.
My question was searching for ways in which my knowledge of your device ID could actually be used to harm or disadvantage you in any way. (And no, of course I'm not interested in doing that, but to protect myself from unscrupulous users double-dipping on introductory offers.)
I see no reason to refuse Unit ID usage. If customer warned about it with the special message and explanation in license from developer.
2.3.0 : Class: Toybox::AntPlus::ProductInfo has "serial" field. This means developers can share or at least collect private info about accessories (first idea - count bundled modern devices). It this something that regular customer knows, when agreed with Ant+ access?
Fit files store Unit ID.
FIT Decode Example Application Opening east_west.fit Decoding... OnMesgDef: Received Defn for local message #0, global num 0 It has 7 fields 0 developer fields and is 20 bytes long OnMesg: Received Mesg with global ID#0, its name is FileId Field0 Index0 ("SerialNumber" Field#3) Value: 3915777777 (raw value 3915777777) Field1 Index0 ("TimeCreated" Field#4) Value: 840985667 (raw value 840985667) Field2 Index0 ("Manufacturer" Field#1) Value: 1 (raw value 1) Field3 Index0 ("Product" Field#2) Value: 2431 (raw value 2431) Field4 Index0 ("Type" Field#0) Value: 4 (raw value 4) FileIdHandler: Received FileId Mesg with global ID#0 Type: Activity Manufacturer: 1 Product: 2431 SerialNumber 3915777777 Number TimeCreated Dynastream.Fit.DateTime
I read about App Trial feature and it is completely not clear how it works without Unit ID. If purchased one app, will it be for all devices in customers' account active? What if developer do not want to license app to all? Is it possible to delete device and add again into the one account and purchased apps will be restored? What if customer sold device and it was registered to another account, are any apps saved as purchased?
And finally, bad bad news. All of these makes no sense until Garmin allows to alter firmware and load it to device, or do not verify .GCD file signature before load, or allow to start bootblock and flash 0x0E region without signature... Modified patcher that can alter firmware for all possible watches that includes patch for the VM (i.e. always return in getTrialDaysRemaining() or in isTrial() whatever you want) is just a question of time. There is a pefect example with the BirdsEye and Map signature patchers, that already exist for years in PND world. Patch firmware -> install any trial app that will be non-trial.
It's related to privacy issues. I'm not a security expert, but we had engineers from other teams that spoke up when we first proposed exposing the unit ID and gave reasons why it's not a good idea. For example, you as the developer are interested in identifying a particular installation of your app, but the unit ID allows an app to track a particular device. There's a growing precedent across the industry moving away from device IDs. You can google around for more examples, but here's one example that describes the potential risks:
So it would appear that the risk comes from the possibility of hackers aggregating customer data from multiple apps on the watch using the same device ID. If there are a number of apps on the watch transmitting the same device ID related to their particular application area, the hacker may be able to put those pieces together and build up some sort of private profile of the user.
OK, it seems an impossibly unlikely scenario to me, but let's go with that for a minute.
One solution might be for the firmware to generate a unique ID by securely combining the watch's device ID and my app's application ID. That way each application on the watch would have a different ID, thwarting the hacker's ability to aggregate the data, but still providing me with the ability to identify my app running on the same watch after a re-install.
But really...what are the chances of watch app developers like you and me getting access to sufficiently sensitive user data and being dumb enough to transmit it, and on the other hand, for hackers to bother to put in the time and effort to go fishing for it?
I read about App Trial feature and it is completely not clear how it works without Unit ID. If purchased one app, will it be for all devices in customers' account active? What if developer do not want to license app to all?
I can't see how to enable app across multiple devices on a customer's account, so one account, one device.
Is it possible to delete device and add again into the one account and purchased apps will be restored?
Yes, that is the plan
What if customer sold device and it was registered to another account, are any apps saved as purchased?
That would require a separate application to remove a device from an account.Then the new owner would register the device in his new account
And finally, bad bad news. All of these makes no sense until Garmin allows to alter firmware and load it to device, or do not verify .GCD file signature before load, or allow to start bootblock and flash 0x0E region without signature... Modified patcher that can alter firmware for all possible watches that includes patch for the VM (i.e. always return in getTrialDaysRemaining() or in isTrial() whatever you want) is just a question of time. There is a pefect example with the BirdsEye and Map signature patchers, that already exist for years in PND world. Patch firmware -> install any trial app that will be non-trial.
I really don't understand any of this: what is .GCG, bootlock and flash 0x0E region....? Are these things that an app developer knows about? I'm developing in Eclipse on W10 for a VA-HR and haven't come across any of this.
I read about App Trial feature and it is completely not clear how it works without Unit ID.
from what i see running the beta the app trial just allows you to set a url. I assume this url would then be a link to your own order page, where you process the customer details, process the payment, generate some kind of key, etc.... The unlock process is then of course also something you have to implement yourself eg by inputting the key as a property and processing it inside your app to unlock the full functionality.
So there's no possibility to upload 2 iq files for trial/full, you have just one app. The trial link just makes it more clear to people that when downloading the app from the store they'll only get full functionality after purchasing the item.
I really don't understand any of this: what is .GCG, bootblock and flash 0x0E region....? Are these things that an app developer knows about? I'm developing in Eclipse on W10 for a VA-HR and haven't come across any of this.
Probably you don't need to if you have only free of charge apps. I just described obvious vulnerability of the whole app market with Trial App function. Customer can download _any_ trial app and on device it runs as non-trial.
Attack vector - is to modify firmware code (in part of the VM, that includes timer functions or similar) and put this code into the watches. It looks tricky, but at the same time it was done in PND world (map signature check removal, and BirdsEye sat imagery from 3rd party usage) and exists for years. There are different ways to do this: - modify update file gupdate.gcd and put it into the device, update - craft manually update file and upload via service mode (formely known as a factory mode).
GCD - is the file, container for the firmware. Usually updates for your watches are placed into Garmin folder under the name gupdate.gcd If you place modified file, watches can accept it and update device firmware. If you have no "signature" inside this file, or ignore this signature during update process, any code can be placed into the device firmware.
Bootblock - very complex and very simple - it is a small part of the code in the CPU that initializes every part of the hardware and launches the main firmware. Bootblock has several levels of code, rarely or never updated. This code has a special mode (activated by some key binding) and watches in this mode allow to access flash memory via regular Garmin tools. That means you can upload into the device RAM loader and firmware code you want (unsigned and modified as you wanted of course) and watches do not restrict it in any manner.
0x0E region - is the index number of the region in Garmin internals, regions are the chunks of flash. This particular holds main firmware code.
All I want to hear from Garmin - do they made any attempts to sign code and refuse update regions without signature?
One solution might be for the firmware to generate a unique ID by securely combining the watch's device ID and my app's application ID. That way each application on the watch would have a different ID, thwarting the hacker's ability to aggregate the data, but still providing me with the ability to identify my app running on the same watch after a re-install.
Yes... this is precisely the sort of thing we're considering. But you must understand that features, even something seemingly simple like this, often have underlying complexity and require time for design and implementation. :)
But really...what are the chances of watch app developers like you and me getting access to sufficiently sensitive user data and being dumb enough to transmit it, and on the other hand, for hackers to bother to put in the time and effort to go fishing for it?
We don't know--and that's kind of the point. It's impossible for us to plan for all contingencies, but we must at least make a good faith effort to protect the privacy of our customers.
