W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: getUserMedia use cases

From: Robin Berjon <robin@berjon.com>
Date: Tue, 31 Jan 2012 20:31:33 +0100
Cc: Chris Rogers <crogers@google.com>, Doug Schepers <schepers@w3.org>, public-audio@w3.org, Dom Hazael-Massieux <dom@w3.org>, Henrik Andreasson <henrika@google.com>
Message-Id: <23BDB30A-14F7-4161-B430-43D6427410F2@berjon.com>
To: Chris Wilson <cwilso@google.com>
Hi Chris,

On Jan 31, 2012, at 19:38 , Chris Wilson wrote:
> True.  Even MORE true is that when I have carefully set up a multi-track recording session in my DAW, I don't want to have to go through and re-enumerate the I/O channels.  Note that the same kind of pattern will be somewhat true for MIDI - there are potentially many I/Os, and the user would be frustrated if they had to set them up by hand every session.  Even as a "hobby" home studio nearly ten years ago, I had a 16-audio-track and 16-MIDI-ins/16-MIDI-outs (x16 channels each) setup.  And my audio recordings didn't typically use all 16 channels, but did regularly use a dozen or so simultaneously.  That "fingerprint" is going to be important - even if you treat it as an opaque "suggested multitrack identifier" (i.e., the API is called with "multiple" turned on, and returns a unique opaque ID that the system can use later (in a different session) to try to recreate the same setup.)

So long as that fingerprint is only available to sites with which you use this feature rather than to arbitrary pages that could enumerate your capabilities, then we probably don't care. Chances are that you're already identified in some other way because it's a source you use and trust. So the case of setting up your inputs once for a given site/webapp and then having them be reused, available every time you go back, etc. is not a fingerprinting concern and certainly sounds like good usability to me.

> Is this worse than cookies, or other potentially identifying features?  (Not saying that's to be ignored, just trying to understand what category it is in.)

Fingerprinting is worse than cookies because it is harder to mitigate. If you tell your browser to refuse cookies from origins that don't match the top-level browser context, then you can eliminate a fair bit of the across-the-entire-web tracking that can be done through ad networks and all sorts of badges and add-ons.

With fingerprinting, you just can't do much. Script simply uses the features exposed through your browser to come up with a reasonably unique identifier. Cross that with some geo-IP or stats about the demographics likely to visit a given page and you pretty much have enough information to narrow it down to a single person on Earth. See http://panopticlick.eff.org/ for more details.

As a result of all this there's an effort across the board for JS APIs to do their best to minimise fingerprinting. Right now this "across the board" effort is largely propagated through lore, legend, and word-of-mouth. Give me a few weeks to try to change that ;)

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 31 January 2012 19:32:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:57 UTC