One advantage of doing it on first boot is the possibility of letting the user decide a "human readable label" for the device that will be consistent all through the device's life.
It all depends on what features and user experiences we want to implement. For example: user reinstalls device, then the store suggests "want to reinstall all your apps". That implies that the store will know this newly installed device is the same one as a device the user used before, which then implies we should ID it somehow, either via the human-friendly label or some HW serial number. If we use a serial number, there are a number of privacy concerns (which could be alleviated using a hash? No?) If we use the human-friendly label, then we need to let the user change it somehow and preserve the device's identity. I suspect we should first come up with user stories and then design the feature. On Thu, Jan 30, 2014 at 5:06 PM, Marc Deslauriers < [email protected]> wrote: > On 14-01-30 03:00 PM, Martin Albisetti wrote: > > We are planning some work related to optionally tracking installed > > apps per device so we can provide users a list of apps (both current > > and past) of apps installed on each device (planning ahead for > > convergance). > > Besides allocating a unique id for a device, we need to gather some > > information from the client about the device is running on, a nice > > user-readable name, but also some hardware specs so we can provide > > developers with meaningful numbers on what their userbase is running > > (we won't track unique hardware IDs like mac addresses and such). > > > > > > Proposed API: > > > > POST /api/register-device (OAuth signed) > > Expected data (json encoded dict): device brand, device model(, other > > device specs and capabilites) > > Return value: a unique device id (string, uuid like) that will > > identify this device with the click store > > > > Use case: the client running in the device will register such device > > against the click store once per "first setup" (for example when first > > booting the device or using the store for the first time, client > > choice) passing the device's metadata/hardware information, through an > > OAuth signed request. The server will generate a unique id, will store > > it (along with the device details) and link to the signing user, and > > will return this (device) id to the client for future usage against > > the API. > > > > This device id must be passed as API parameter each time this client > > requests an app download to the click store (besides the already known > > package name parameter, using existent API endpoint). > > > > If no device ID is passed, for backward compatibility and for people > > who would rather we don't track their devices, we'll assume a "default > > device" and move on. > > > > Are there any concerns with this approach? Security or otherwise? > > > > Sounds fine to me. Perhaps it should be when the user accesses the store > for the > first time, not at first boot. > > We have a good reason for doing this: so the store can display apps that > are > compatible with the device. It would make sense that it's done when the > user > accesses the store for the first time. > > Any reason why the device id is generated by the server, and not generated > by > the device? (presumably the privacy zealots would rather be able to change > it > themselves at some point...) > > Marc. > > > -- > Mailing list: https://launchpad.net/~ubuntu-appstore-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
