Re: [w3c/permissions] A new permission for canvas data (#165)

@annevk 

@tomrittervg It seems like it'd be fine for the TOR browser if its host offered a software (or otherwise consistent) rendering path, which TOR could opt into, even if that host browser didn't make that the default for non-TOR users. This wouldn't help you blend into the larger non-TOR population, but as you said, sites can already retrieve those bits of identifying entropy.

That said, I'm not insisting that you have that argument with the Mozilla rendering folks before adding the PermissionName.

----

I don't expect @annevk to be successful in pausing execution while a user responds to a permission prompt. 

I do think there's appetite to add an asynchronous variant of Canvas.toDataURL() (and [getImageData()](https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-getimagedata) and any other synchronous image-reading functions): it handles bulk data that we might prefer to live on another thread, on the GPU, or even on disk. Tab Atkins and Ojan Vafai are excited about this idea.

There's probably similar interest in making isPointInPath() asynchronous, since evaluating it could be expensive.

I *think* that  OffscreenCanvas.transferToImageBitmap() is safe to leave synchronous because the ImageBitmap doesn't actually provide any pixel data: it's just a handle to put the pixels somewhere else.

----

I think @KOLANICH's worry that query("canvas-imagedata") will be a net negative for fingerprinting is the same as the worry in #52 that allowing sites to know whether a prompt will happen, will allow them to more sneakily gather private data. We've basically rejected that concern, although we weren't explicit about it in that issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/165#issuecomment-353136917

Received on Wednesday, 20 December 2017 17:59:09 UTC