W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 19803] "Fingerprint" is unclear

From: <bugzilla@jessica.w3.org>
Date: Fri, 07 Dec 2012 22:52:59 +0000
To: public-audio@w3.org
Message-ID: <bug-19803-5429-wsjbRbcsll@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19803

--- Comment #8 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #7)
> Your code example is missing too many
> function implementations for me to completely confirm, but I think that's
> essentially what it's doing?

Well, the function definitions don't really matter, it could be:

var createUUID = (str) => str

Port.prototype = {
  get entropyPool () {
    return [
      this.name,
      this.manufacturer,
      this.version,
      this.type
    ].join(String.fromCharCode(0))
  }
}

Although that's not a very appealing unique identifier. The important part is
that createUUID is deterministic. And oops, I meant 'port', not 'device in the
the original example.

Anyway, that's not what I meant. In cases where the user has changed the port
ordering and the ports can't be uniquely identified, things will go wrong,
there's nothing that can be done to prevent this. But the algorithm I just
typed gives correct behavior in for example this case:

Ports A and B have the same entropy pool. Port B gets a fingerprint that has
something added to its entropy pool to indicate that it's natural fingerprint
was taken. The application uses both A and B. The user disconnects port A, and
its fingerprint gets freed, while port B still has the same fingerprint that
was associated to it for the session. The user reconnects port A and here,
magic happens, the algorithm tries if the natural fingerprint for the port is
available, and it is because port B has a modified entropy pool, so the
application can associate port A back to its rightful task, even though the
port ordering has possibly been flipped. Of course, when the user restarts the
application, the ports will be flipped but there's really nothing we can do
about that. Sound good? I don't think it's possible to get a better fallback
mechanism than this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 7 December 2012 22:53:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC