Does MIDIPort.id need to be origin-scoped and/or regenerated with cookies?

[cwilso]

From AnneVK:

You need to state how MIDIPort.id is scoped (prolly to origin, no?)
and you should state that it should not be the same across origins. We
don't want to make it easy to track users using these new identifiers.
Furthermore, once the user clears cookies these MIDIPort.id thingies
need to be regenerated too. (I gave similar feedback to the WebRTC
guys.)

[annevk]

I guess this is also concern with name and manufacturer to a lesser extent. If you have a unique device or are a user of a rather unique localization, tracking will be easier. Of course, it's opt-in, but calling it out and having people look at it would be good. I've been told we lost the war on preventing tracking, but identification is hopefully not entirely lost yet.

[cwilso]

We've lost that battle. There are plenty of other APIs that expose system-specific data like this - the Gamepad API, for example, has precisely the same data.

I'm not sure what you mean by "user of a rather unique localization" - the name and manufacturer are coming from the device, so I presume you mean "user of a relatively rare device produced with a relatively rare localized USB device name", or something like that? This has gotten extremely narrow - you would catch far more users looking for a
MIDI devices are relatively mainstream in production - you don't find a lot of one-off device manufacturers/ids - and they are also frequently unplugged - you can't rely on them always being there; my MIDI configuration changes constantly.

Actually, the harder I've thought about this, the more I think we should NOT regenerate with cookies. Origin-scoped is okay - you wouldn't be handing this identifiers across domains - but other than that, it's not worse than index and name (in fact, my polyfill just generates an ID from the index and the name).

[annevk]

If you do not regenerate with cookies you can revive the cookies if the ID is a uuid.

[cwilso]

It's not intended to a UUID, just a GUID (that can be used to revive the right connections when an app is run a subsequent time). Perhaps a comment to that effect would be best.

[annevk]

It still seems like that would allow for reviving given enough other fingerprinting data. If you clear cookies you really want that particular site to have forgotten about you and have no information retained.

[cwilso]

I'm not clear I understand the issue well enough then, because it seems
like there is far more than enough other fingerprinting data elsewhere to
do this. Can you point me to where to understand this better?

On Thu, Apr 25, 2013 at 7:56 AM, Anne van Kesteren <notifications@github.com

wrote:

It still seems like that would allow for reviving given enough other
fingerprinting data. If you clear cookies you really want that particular
site to have forgotten about you and have no information retained.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-17011953
.

[annevk]

See e.g. HTML for "fingerprinting".

[jussi-kalliokoski]

I'm fine with the idea of resetting the ID with cookies. This is pretty simple to implement by just salting the IDs with something like the timestamp when cookies were last created, which would be just now in case of private browsing for example. I agree with Anne that even though the API is opt-in, it's better that there's as little linking to the user's identity as possible when cookies are cleared.

That said, I don't see the advantage of extending this to the manufacturer and name, they become pretty useless if they're obfuscated.

[cwilso]

Well, I'd suggest this kinda makes the id pretty useless anyway - shouldn't
we just cut id, and rely on order, manufacturer and name, avoiding the
potential issue here?

On Sun, Apr 28, 2013 at 9:43 AM, Jussi Kalliokoski <notifications@github.com

wrote:

I'm fine with the idea of resetting the ID with cookies. This is pretty
simple to implement by just salting the IDs with something like the
timestamp when cookies were last created, which would be just now in case
of private browsing for example. I agree with Anne that even though the API
is opt-in, it's better that there's as little linking to the user's
identity as possible when cookies are cleared.

That said, I don't see the advantage of extending this to the manufacturer
and name, they become pretty useless if they're obfuscated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-17137115
.

[jussi-kalliokoski]

Well, I'd suggest this kinda makes the id pretty useless anyway - shouldn't we just cut id, and rely on order, manufacturer and name, avoiding the potential issue here?

Huh?! What do you mean it makes the ID useless? It's not like users go incognito every time, expecting sites to remember their preferences.

[cwilso]

If I'm an ISV writing MIDI software, I'm going to have to rely on a weird
combination of ID, order, manufacturer and name. It just doesn't seem to
buy much utility anymore.

On Wed, May 1, 2013 at 10:27 AM, Jussi Kalliokoski <notifications@github.com

wrote:

Well, I'd suggest this kinda makes the id pretty useless anyway -
shouldn't we just cut id, and rely on order, manufacturer and name,
avoiding the potential issue here?

Huh?! What do you mean it makes the ID useless? It's not like users go
incognito every time, expecting sites to remember their preferences.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-17293482
.

[jussi-kalliokoski]

If I'm an ISV writing MIDI software, I'm going to have to rely on a weird combination of ID, order, manufacturer and name.

Why?