[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Implementing OffscreenCanvas
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2019-10-10 17:47:18
Message-ID: EFD9FC33-32B7-4F81-B509-3BB54489B368 () apple ! com
[Download RAW message or body]
> On Oct 10, 2019, at 10:18 AM, John Wilander <wilander@apple.com> wrote:
>
> > On Oct 10, 2019, at 9:42 AM, Maciej Stachowiak <mjs@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@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@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@lists.webkit.org
> > > > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> > > _______________________________________________
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic