- From: Matt Reynolds <notifications@github.com>
- Date: Fri, 10 May 2024 11:58:09 -0700
- To: w3c/gamepad <gamepad@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/gamepad/pull/202/review/2050698831@github.com>
@nondebug commented on this pull request. > + <dfn>productId</dfn> attribute + </dt> + <dd> + The product identifier assigned by the device vendor, or `null` if + the gamepad has no product identifier or it is not available. + </dd> + <dt> + <dfn>name</dfn> attribute + </dt> + <dd> + <p> + A human-readable identifier for the gamepad. The exact content of + the {{Gamepad/name}} string is left unspecified. The [=user agent=] + MAY use a product name string provided by the device firmware. The + {{Gamepad/name}} MUST NOT be the empty string and MUST NOT include + unique identifiers like serial numbers or Bluetooth device I don't consider vendor/product IDs unique identifiers since they typically have the same values for all instances of the same product. The language here was intended to stop implementers from doing something like appending the USB serial number string descriptor to the name attribute as a way to provide a unique identifier. We want to give the implementation some leeway to pick a good name but we shouldn't allow this attribute to be used to hold a unique identifier since that would violate our assumptions around fingerprintability. Including vendor/product IDs shouldn't make the name string any more useful as a unique identifier since we expect these IDs will correlate strongly with the product name, but I'd argue it still doesn't satisfy the spec because vendor and product IDs aren't really human-readable. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/gamepad/pull/202#discussion_r1597121426 You are receiving this because you are subscribed to this thread. Message ID: <w3c/gamepad/pull/202/review/2050698831@github.com>
Received on Friday, 10 May 2024 18:58:13 UTC