[webkit-dev] Implementing OffscreenCanvas

Thu Oct 10 10:47:18 PDT 2019

> On Oct 10, 2019, at 10:18 AM, John Wilander <wilander at apple.com> wrote:
> 
>> On Oct 10, 2019, at 9:42 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> 
>> For clarity, it’s already possible to render to a regular canvas offscreen. The <canvas> can be hidden using any of the techniques that can make any other canvas invisible. Name notwithstanding, OffscreenCanvas is mainly about being able to render from a Worker, not about enabling rendering offscreen.
>> 
>> Thus, I would not expect it to make it easier to invisibly fingerprint using canvas.
> 
> My thinking here is that viable mitigations for device fingerprinting could be requiring a Canvas to be visible on screen or even for it to get user interaction before it’ll get access to hardware acceleration. Such restrictions would make it harder for tracking scripts to get away with GPU fingerprinting that the site owner never wanted or accepted. If we allow offscreen Canvas in workers, site owners will stay in the dark and we can’t tie user interaction to it.

That is neat thinking. If a mitigation like this was effective, and we did it across the board, that would mean OffscreenCanvas is basically always disabled.

But I’m not sure it’s viable. A few concerns:
- It’s notoriously hard to tell if an element is really visible onscreen.
- Canvas backing store size is independent of its layout size, so even if we could solve the visibility problem, a rather small canvas could still get all the fingerprinting bits. (And the minimum size can’t be too low.)
- Rendering offscreen for multiple buffering or to to implement sprites is a legit use case and necessary for games.
- Rendering a canvas that’s currently scrolled below the fold is valuable. Otherwise you get a scrolling glitch later, or show the user blank content.
- Even software rendering is fingerprintable.
- Drawing itself isn’t even the fingerprinting step, it’s the readback.

I think canvas fingerprinting mitigations will have to be more along the lines of identifying the true source of the script attempting to perform readback and returning fake values, injecting noise (either into drawing or into readback), or things along these lines. It might also be possible to specifically block readback from invisible/offscreen canvases (as long as copying directly to another canvas is still allowed).

Thus, on reflection, I still do not think OffscreenCanvas hurts our ability to do fingerprinting mitigations.

But it is very good to consider tracking and fingerprinting risk for every feature, so I’m glad you brought this up!

Regards,
Maciej

> 
>   Regards, John
> 
>>> On Oct 10, 2019, at 9:32 AM, Chris Lord <clord at igalia.com> wrote:
>>> 
>>> Hi John,
>>> 
>>> I don't know what the current state is of counter-measures for such an
>>> attack, but I don't immediately imagine OffscreenCanvas would make them
>>> more effective. The patch series doesn't add any new rendering paths, so
>>> whatever was possible before will likely still be possible and whatever
>>> wasn't will hopefully still not be possible. That said, I'll look into
>>> this and discuss it with some people that will know better than me and
>>> try to get a better picture.
>>> 
>>> Thanks,
>>> 
>>> Chris
>>> 
>>> On 2019-10-10 17:32, John Wilander wrote:
>>>> Hi Chris!
>>>> 
>>>> Canvas is a very popular GPU fingerprinting vector and allowing it
>>>> offscreen sounds like a more convenient way to perform such an attack
>>>> on user privacy. Do you know if Blink or Gecko have elaborated on
>>>> this? What is your assessment?
>>>> 
>>>> Given the cross-engine effort to fight device fingerprinting and
>>>> WebKit and Gecko’s recently published tracking prevention policies, we
>>>> should do a threat analysis of this feature.
>>>> 
>>>> Regards, John
>>>> 
>>>>> On Oct 10, 2019, at 4:24 AM, Chris Lord <clord at igalia.com> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I've spent the last month or so 'finishing' the implementation of
>>>>> OffscreenCanvas[1], based on Žan Doberšek's work from a year ago[2].
>>>>> OffscreenCanvas is an API for being able to use canvas drawing without a
>>>>> visible canvas, and from within Workers. It's supported by Blink and has
>>>>> partial support in Gecko.
>>>>> 
>>>>> It's at the point now where I'd consider it a finished draft - it is
>>>>> almost fully implemented and passes the majority of relevant tests in a
>>>>> debug build without crashing, but has some areas that need completion on
>>>>> other platforms (async drawing on non-Linux) and some missing parts (Web
>>>>> Inspector, ImageBitmapRenderingContext). It almost certainly needs
>>>>> reworking in places.
>>>>> 
>>>>> My work is on GitHub[3] - I'd like to solicit reviews and comment. Some
>>>>> of the bugs hanging off [2] have patches that need review and I think
>>>>> are near ready to being landable as the foundation of this work. It is
>>>>> broadly split up like so:
>>>>> 
>>>>> - Refactor to move functionality from HTMLCanvasElement to CanvasBase
>>>>> - Refactor to not unnecessarily require HTMLCanvasElement in places
>>>>> - Implement OffscreenCanvas functionality
>>>>> - Make font loading/styling usable from a Worker and without a Document
>>>>> - Implement AnimationFrameProvider on DedicatedWorkerGlobalScope
>>>>> - Implement asynchronous drawing updates on placeholder canvases
>>>>> 
>>>>> I expect the font-related stuff to be the most contentious, and my
>>>>> AnimationFrameProvider implementation may be too trivial (but might be
>>>>> ok for a first go?)
>>>>> 
>>>>> All feedback appreciated. Best regards,
>>>>> 
>>>>> Chris
>>>>> 
>>>>> [1]
>>>>> https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface
>>>>> [2] https://bugs.webkit.org/show_bug.cgi?id=183720
>>>>> [3] https://github.com/Cwiiis/webkit/tree/offscreen-canvas
>>>>> _______________________________________________
>>>>> webkit-dev mailing list
>>>>> webkit-dev at lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 