next steps for WebGPU and fingerprinting issue

We have had some extended discussion of fingerprintability and the
WebGPU specification [0], and I took it as an action at the last
meeting to try to summarize and identify any potential productive
areas. For those catching up on this topic, I think particularly
relevant are the minutes from PING discussion in July 2023 [1] and the
minutes from last week's Privacy Working Group call [2].

[0] https://github.com/gpuweb/gpuweb/issues/3101
[1] https://www.w3.org/Privacy/IG/summaries/PING-minutes-20230706#1-webgpu
[2] https://github.com/w3c/privacywg/blob/main/minutes/privacywg-20241205.md#3-webgpu

Thanks to Kelsey for joining our last two Privacy WG calls to be
available to discuss, Pete for conducting the privacy review here, and
all involved for working respectfully and constructively through this
issue.

## Permission as a mitigation

In previous discussion, there seemed to be an opportunity to move
towards a permission model. Not all implementers would prompt the user
for permission -- it could be a tricky permission to explain to the
user and we generally don't want users to be inundated with permission
prompts -- but it would make it possible for UAs to take different
choices on how they protect users in different contexts. My
understanding from the issue is that the GPU for the Web Working Group
has made the relevant calls asynchronous in part to enable this -- UAs
that want to prompt the user can wait to finish the aysnc call until
that happened.

But a previous suggestion had been to define a permission string
("gpu" or "webgpu" or whatever) and integrate that with the
Permissions API. Some implementers would just autogrant that
permission, but different UAs could handle it differently and web
developers could request the permission or see when the permission is
denied and if so explain the situation to the user or fall back to
more limited functionality in those cases. Would that be a potential
improvement to the spec?

## Ease of access to surface through alternative means

The conclusion of the WebGPU WG was that providing hardware
accelerated access to the GPU at all would grant some fingerprinting
surface to sites or scripts that had access to it (based on the
results of mathematical calculations that are different for different
GPU hardware), and wouldn't provide significantly different amounts of
fingerprinting surface from what will be exposed through the API's
Optional Capabilities configurations. I believe this was the point
that both Ben and Kelsey were making on last week's call.

One question that we may just want to confirm is whether that
comparable surface is similarly easily available -- a few lines of
JavaScript with a deterministic return value -- or whether that
surface is provided by the hardware only in the sense of timing
attacks which can be slow and unreliable. The Privacy Considerations
of the spec currently note that there are hardware details that are
determinable -- and intractable -- through timing differences, but
that these are "low signal" because of the practices for calculating
performance differences.

## Availability

The last item and potential mitigation that was raised in the privacy
review was limiting availability -- should this functionality be
limited to top-level documents or require user activation or similar,
so that it isn't primarily used in the background or embedded settings
primarily as a fingerprinting surface and not for site functionality.
My understanding is that the Working Group has already considered and
decided against these limitations. The only open item I see here is
whether it should be noted in the Privacy Considerations, or elsewhere
in the document, that web developers should be prepared for WebGPU
functionality to not be available in some contexts for browsers
configured with certain fingerprinting protections.

---

My sense during the last call is that there's likely not enough
further progress between the reviewer (Pete, Brave) and the WebGPU
Working Group (Kelsey, Mozilla and others) to warrant additional
calls, and that there isn't broader interest from others in the
PrivacyWG on the particular details of the issue and mitigations to
make a PrivacyWG decision or call for consensus. If anything in the
above list is of interest for further discussion, however, that would
be welcome either as a call or just via email or github.

Thanks,
Nick

P.S. Kelsey, Corentin, please feel free to CC in the public-gpu
mailing list or suggest an alternative form of communication if that
would work better for the relevant folks involved.

-- 
Nick Doty | https://npdoty.name
Senior Technologist
Center for Democracy & Technology | https://cdt.org

Received on Friday, 13 December 2024 17:22:25 UTC