W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > December 2017

Re: [mediacapture-fromelement] Investigate and document the fingerprintability of user media rendering

From: Tom Ritter via GitHub <sysbot+gh@w3.org>
Date: Mon, 04 Dec 2017 15:54:29 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-349004712-1512402868-sysbot+gh@w3.org>
Nothing to forgive, I'm the ignorant one here, thanks for engaging with me. I'm trying to get up to speed on this draft and some web features I haven't used much myself.

It seems like you can render a video onto a canvas, and then use getImageData to expose rendered media to the web - so I was wrong when I said this was the first time that's exposed. (I'm not sure if you could do frame-by-frame playback and getImageData to accurately capture in-motion video rendering but the safe thing would be to assume yes.)

Anyway, my understanding of things is that <canvas> and <media>, with respect to allowing the server to learn how data is rendered, are overlapping but not inclusive circles.  <canvas> can render data not related to <media> (like text with system fonts) and expose the result - that's a unique technique to canvas using canvas APIs. <media> can also render video and expose the result using this new media API. And then canvas can also render video and expose the result - that's exposing the same data through canvas APIs and media APIs.

This is a new API. We learned of the risks exposed by canvas fingerprinting after canvas was exposed. We should learn from that experience and not make the same mistakes, nor should we codify even more inflexible vectors into the web.

The canvas APIs are synchronous. UAs who want to resist canvas fingerprinting have no good options to do so. Turning a synchronous API asynchronous blocks expected script execution and breaks sites. Lying about the result kind of works but breaks website functionality in unexpected ways. 

Assuming that video rendering is fingerprintable, and that it can't be made normalized across systems - it would be ideal to expose these APIs as Promises. That way a UA can decide whether they want to resolve the promise immediately (and not prompt the user) or prompt the user and wait for a response before resolving the promise. That flexibility will allow UAs who want to resist fingerprinting the option of doing so.  

GitHub Notification of comment by tomrittervg
Please view or discuss this issue at https://github.com/w3c/mediacapture-fromelement/issues/68#issuecomment-349004712 using your GitHub account
Received on Monday, 4 December 2017 15:54:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:33 UTC