Re: [w3ctag/design-reviews] Cross-spec device identification & association (#64)

On availability of device/group ids:
* Leave it up to the feature -- don't try to normalize, as privacy implications may be different across various types of devices (some are more sensitive to discover than others)
* It would explicitly not be a goal to create a one-size-fits-all, one-stop-shop for getting all devices and their ids, etc.

On correlation:
* For device/group ids that can be obtained (see previous point), correlation among them within a single web app should be the default (e.g., not require any special API to correlate). The fingerprinting aspect is already possible, and the entropy of device uniqueness and characteristics is sufficiently high that implicit correlation is already trivial, and thus attempting to obfuscate the correlation is only making the web platform harder to use for legitimate correlation scenarios.

On persistence:
* As a general rule of thumb, implicit persistence of any device ids without permission seems risky. It is a convenient feature for return-visits to a particular origin because explicitly-saved device ids can be retrieved bypassing the discovery phase, but in nearly every other scenario it leaves breadcrumbs around for cross-origin correlation. Trying to keep the persistence origin-unique is one approach, but may not be suitable for all devices. My preference would be to issue general guidelines that no device/group ids are persisted, and that a new API to "persist" a device/group id is designed so that this is always a specific permission-based action that users could understand (e.g., "web site X wants to remember your YYY Bluetooth device").

On device/group hierarchy:
* I don't know that I understand the use cases that drove the separation of device ids from group ids from container ids. In the container id scenario mentioned earlier, I would expect (in my correlated approach thinking) that the device id generated for the USB printer would be the same id generated by some Wifi connection API (e.g., the UA would have an internal table of device-to-generated-id and each time that device was requested from any API, the lookup table would return the id. The said table would be flushed at navigation time to avoid persistence).
* It seems reasonable for devices to be grouped. These groupings may need to be uniquely identified from each other such groups, and hence a group id is necessary. Do these group ids need correlation (when they are groups of devices)? Maybe. Is an 'id' the right way of grouping? Maybe not. 
* When a single device provides many services, do these "sub-devices" get exposed as regular device ids? Do they all have the same device id in this case? Or is a new field needed to separate them? I would be personally inclined to go with a simpler approach and avoid proliferating different hierarchical id representations throughout the platform if possible. Where the ship has sailed we should try not to make it worse. E.g., if five sensor devices are exposed to the web platform, it should be OK to give them all the same device id (if they are all essentially the same sensor-fusion device), or if a photo camera device and video camera are the same device, but exposed through different interfaces--let them have the same id. There are always other ways of telling the devices apart, rather than through their id alone, and these will be contextually apparent.

API for device id persistence:

Just food for thought. Something relatively trivial, async-based (to allow for permission prompt), and which allows for subsequent checking on a previously-generated persistent id (since these may be cleared at the UA's discretion).

```idl
partial interface Navigator {
   Promise<DOMString> getPersistentDeviceId(DOMString deviceId);
   Promise<boolean> hasPersistentDeviceId(DOMString persistentDeviceId);
};
```
With the 'get' API, a non-persisted device id (all of them by default, ideally) is provided, and the UA asks for permission to persist it. If granted, a new persistent id is generated by the user agent, persisted associated with the origin, and returned.

The same persisted id, if passed to the 'has' method answers true or false, if the UA knows about it (still). It's async to allow the UA to implement mitigations against frequent requests like exponentially increasing time-out periods between fulfilling the promise.

Presumably, the 'get' API would return the same persisted id when called with the same device id multiple times.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/64#issuecomment-303243097