Fingerprinting Surface

[pes10k]

This issue is part of PING review https://github.com/w3cping/privacy-request/issues/85

From my read of the current spec, it seems that that there is significant passive fingerprinting surface, particularly around the capabilities in the Optional Capabilities section. This surface seems to both mirror and exceed the fingerprinting surface exposed by existing canvas capabilities, and actively exploited in the wild.

I appreciate that these risks are discussed in the privacy considerations section (which is very detailed and very appreciated). It is great that the spec authors have thought through these issues in such depth to document them. However, its equally important that spec authors mitigate the risks they're introducing, and the risks this functionality would expose users to.

More specifically, spec should to (in-spec) mitigate or address the passive fingerprinting surface the spec exposes.

Here are some suggested ways, for the WG's considerations, for how that might be done. Note that these are not PRs or specific recommended changes, though I and PING would be happy to work with the authors to try and address these issues.

• move the WebGPU capabilities behind a permission
• expose an implementation with lower fingerprinting risk w/o a permission, and allow users to opt-into the higher risk, higher performance implementation
• limit these capabilities to visible contexts
• limit these capabilities to frames that have received an activation
• reduce the granularity of the values exposed in the 3.2.6 subsections

Again, its beyond the horizontal review process for PING to offer PRs or specific text changes, but I'd be happy to work with the proposal's authors to address these vulnerabilities

[kdashg]

WebGPU meeting minutes 2022-06-29

* KG: filed as part of PING review. * KG: not requesting specific PRs or spec changes, but they'd be happy if things get better. * KN: rather they're not proposing specific changes but they're requesting them. * MM: they're presenting 5 options. * BJ: 5 avenues to look into, rather. * MM: agree, correct. * BJ: one thing - last item, reduce granularity of values exposed - on Chrome, we're already doing. Spec has language - bucketing values. Unclear if that was recognized when they put in this comment, or if we should make this spec text stronger. Would like clarification. On Chrome side, already implementing. Hope other vendors hope to do the same. Like to know how much of a mitigating effect this has on their opinion. * MM: word "can" is used here - if all browsers have plans to do this, suggest using "should". * KG: concern with "must" - details we don't need to agree on. Prefer to leave up to UAs. * MM: we can use "must" but not specify what gets bucketed how. "A browser must make similar devices appear as though they're identical" or something like that. * KG: we can. * BJ: I think this is a "should" situation. "must" feels a little strong. Think we can and should be more prescriptive about that we strongly recommend browsers take some of these steps. * MM: I wouldn't push harder than that. * KG: PRs welcome. * MS: one issue about not standardizing this - something that works in one browser, but not another, on the same hardware. "Use this browser" - want to avoid. * MM: good point. If you're on GPU X you have to use this browser… * KG: boils down to: what do UAs want to support? * MM: if one browser's more finely grained than another… * KG: all UAs voluntarily handcuffed in the same way? Don't think it's worth getting into specific details of how we handle these. * MM: **think we'll discuss this when the group's less pressed for time**. * MM: what does "visible contexts" mean? * BJ: we have visibility APIs on the web. Making some assumptions based on its behavior. * MM: IntersectionObserver? * BJ: window/tab visibility. Need to clarify - limit these capabilities to visible contexts. Capabilities are fairly static once device's created. Visibility can be fluid. With model we have now - reluctant to change - can't say, you got new capabilities because you're looking at the page. Seems bad for a variety of reasons. Limiting caps to frames that have received activation - few ideas here that you get really limited caps until later, when adapter gives you more stuff. Awkward model. Would like to not do anything along those lines. * MM: **discuss in future meeting**?

[kdashg]

GPU Web 2022-10-05

* CW: something we have to talk about one day, but no time today. * KN: what will we discuss about this? * KG: I've been drafting something that crystallizes my opinions. Want to clean it up before sharing. * KG: high level, there are certain un-hidable bits of information, and if we don't diverge from those, it's fine. Can tell difference between Intel, NVIDIA. Also probably GPU families. Not useful for us to restrict max texture size to prevent fingerprinting, if you can deduce the same from shader math that we can't possibly hide. * CW: sounds like our general agreement, and is why we were comfortable exposing architecture in the GPUAdapterInfo.

[Kangz]

@kdashg a small reminder that you mentioned you'd post a part of your blog post / article here. (if you don't have time to make it short that's probably ok IMHO)

[kdashg]

Thanks for bringing these concerns up! Apologies for the length here, but there's a bunch of pieces to this that I want to touch on.

We're on-board with looking out for ways to reduce what fingerprinting we enable by default as UAs, and some UAs are working on ways to pare back the information reported by older "more revealing" APIs (e.g. WebGL, Canvas2D).

I hope it is reassuring that, of the avenues for consideration that you've given us here, (if my memory serves me right) only "limit these capabilities to frames that have received an activation" has not been discussed yet in the group. It's an interesting idea that is worth considering as part of a passive fingerprinting mitigation toolkit for our UAs. Thank you!

Unfortunately, I think it is very difficult to get a consensus here on how specifically how to (and to what degree) to constrain what we reveal in webgpu. In my mind, it's a very UA-centric question, without good closed-form solutions.

However, I think there are some very important subtleties here, including that for example GPUSupportedLimits does not in practice reveal bits(maxTextureDimension1D) + bits(maxTextureDimension2D) + bits(maxTextureDimension3D) + bits(maxTextureArrayLayers) + ..... Instead, what's revealed here in practice is likely about ~3-5 bits for all limits. I actually expect this to be better in-practice than WebGL (e.g. there are no webgpu devices with less than 8k texture size support).

Another subtlety is that certain math and rasterization artifacts that reveal information about which GPU is being used are in-practice inescapable without reverting to CPU rendering for the implementation. As such it's unfortunately just not viable for privacy-absolute (e.g. Tor) users to use hardware rendering for canvas2d/webgl/webgpu, and they must rely on software rendering. However, even these artifacts reveal very few bits. While it's possible to trivially observe whether you're running on e.g. Intel vs Nvidia gpus via rasterization artifacts alone, you generally can't tell at all which e.g. Intel gpu you're running on, not even what specific generation it's from.

I know our implementations are each quite concerned with privacy, but we simply disagree at specifically how to address such concerns with these APIs today. (and in many ways, we're still experimenting!) I also believe that we simply lack the knowledge of precisely how to compromise here.

I understand that, absent background info here, it's very scary to see so many theoretically-orthogonal limits (and other additive bits of information), but in practice these bits of info are extremely non-orthogonal, and what differences there are are sometimes (and unpredictably) infeasable to eliminate without usefulness-eliminatingly extreme compromises.

---

I think the short answer is "we're working on it", but on a broader scale than right here in WebGPU. For the forseable future, it's not viable to ship with webgpu without webgl/canvas2d, and so in order for a full shipping UA to move the needle on privacy, webpu is not the limiting factor, but rather the UA must have mitigations in place also for webgl (and canvas2d), or there's no meaningful progress on fingerprinting. Unfortunately this will be true for many years.

I believe our current feeling (average, if not consensus) is that we aren't exposing users to any major new risks that they do not currently endure, and that this will be true for quite some time. But this is not to say that we're satisfied with the status quo. We are actively investigating UA-level approaches, working within too-flexible specs and experimenting in ways that have no clear immediate path towards consensus. We are making design decisions that preserve and extend our ability as UAs to experiment and implement fingerprinting mitigations. (Additionally, webgpu is much more capable in its minimum-limits form, and so we expect it will be generally easier for UAs to expose very few bits of information via webgpu) These efforts are earnest and ongoing, and in the end, there's no way to handcuff a defecting UA into not exposing such information, except by our mutual trust and consent.

---

I will say that if it helps satisfy any concerns, I think we could add open-ended mandates directionally towards making things better, I just don't believe we have a path towards consensus on precise or specific mitigations.

For example:

MM: we can use "must" but not specify what gets bucketed how. "A browser must make similar devices appear as though they're identical" or something like that.

While I worry that this kind of spec wording is not directly actionable, testable, or enforceable, but I believe there's room for consensus if we feel it's productive or otherwise important. I do trust UAs will do better than a pessimal implementation of the spec though, and I want to focus on areas where I see more concerns blocking us from a shipping v1.

[yoavweiss]

I'd just like to state that given that WebGPU is a Javascript API, none of the entropy it exposes is passive. Attackers would need to call those high-entropy APIs in order to get and exfiltrate that information, making it an active fingerprinting surface.

[kdashg]

GPU Web 2023-01-04/05 APAC-timed

* KG: not concerned about the # bits revealed in fingerprinting here (e.g. by limits), considering number of entropy bits exposed in other ways. Not sure how much we could do at the spec level. Our UAs are interested in reducing fingerprinting. Forcing it to be done in the spec is counterproductive. * MM: suggestion from a few months ago - implementers in this group agree on common fingerprinting buckets. Last time I brought this up, realized defining those buckets wouldn't be feasible for MVP. That's our preferred response. * KG: why do you want this across UAs? * MM: for same reasons the issue suggests. * KG: you can already tell browsers apart. * MM: agree. * KG: so why coordinate this across UAs? We've had to change the way we do bucketing in Firefox based on security bugs. Think it's harder than you might. * MM: think we should cross that bridge later. Can have longer discussion later when it's more relevant. * KG: Do other people also feel like this is maybe-hard to coordinate, or do people think it’s maybe-easy? * KN: Maybe-hard * (more discussion) * KG: what part do you want deferred? * MM: what's the particular outcome this topic's on the agenda for? * KG: I want feedback from other people that the thing I wrote accurately reflects our general consensus feelings. Half from my POV as Gecko impl, half trying to capture group's consensus. * MM: let's take AI to review this in more detail.

[litherum]

what's revealed here in practice is likely about ~3-5 bits for all limits

How did you calculate this?

[kainino0x]

what's revealed here in practice is likely about ~3-5 bits for all limits

How did you calculate this?

Technically I think the implementation can freely choose this. IIUC if we want to expose no more than 5 additional bits, then we make sure the smallest bucket, within a subpopulation with other fingerprinting bits like browser/OS/viewport size, is no smaller than 1/32 of that subpopulation. Obviously easier said than done, but at least in principle.

[kdashg]

GPU Web 2023-01-25

* KG: since posting larger comment, did double-check with more senior standards & privacy folks at Moz. Consensus, these are hard realities. Nice if we can get more of an understanding of what we can actually implement - or provide leads for research into mitigations. * KG: concrete proposal, pretty much Myles' from a while ago: * KG: pretty convinced we want to bucket in some way * KG: even if we say "UAs should bucket in a way that reduces how much is revealed", I think it's better to say something concrete. * KG: We already do something similar for WebGL in Firefox. Don't have a lot of data about how restrictive it'd be if we reduced e.g. 16 textures in some place to only 8. Hope to have telemetry/dashboards for WebGL side of this; in collecting this, hope to pore through it and figure out if we can bucket reliably. * MM: re: bucketing: agree it's a good thing. One step further: in interest of normative requirements, we propose spec normatively say that each UA can have no more than 32 "buckets". Probably enough to differentiate different use cases like mobile vs. high-perf GPU. Having a specific number of buckets would be helpful to remove concern about too-small buckets. * MM: if we do adopt this number - OK for WebGPU CG to raise it in the future. E.g. if we need 5 more buckets, no problem with raising it. * MM: would help - if an impl needs 7 billion buckets, the CG could advise against that. * MM: up to the UA to define their own bucketing strategy. * KG: hesitance - I hope we don't write something in the spec we fall short of. 3-5 bits is what I put out - think that's what we put out in our WebGL renderer, and that that falls under 32 buckets. If we fall short, either feel bad about it or change the spec. * KN: concern: to know how many buckets we have, we have to define the buckets rather than our rounding scheme. If we round, we don't know the number of buckets without telemetry data or broad device testing. Not sure how practical the stipulation is. * JB: to implement - you don't know what the device queries will be in the wild. You'd choose the 32 buckets in advance. Then take device data, find the closest bucket. Then have a vector distance in the wild, do clustering on it. Non-trivial. Good to have a bound on the number of bits you give out. Then, do you really have more than 32 cases users need to distinguish between? * KG: you'll be able to tell Mac/Linux/Windows - but as long as that's non-orthogonal info w.r.t. rest of the web platform, that's OK. * KG: [https://searchfox.org/mozilla-central/source/dom/canvas/SanitizeRenderer.cpp](https://searchfox.org/mozilla-central/source/dom/canvas/SanitizeRenderer.cpp) * KG: This is where we choose what RENDERER string to pretend to be for WebGL in Firefox. There are 28 different possibilities, which isn’t exactly what we’re getting at, but it’s very interestingly related. * KN: 32 buckets don't mean 5 bits unless all buckets are the same size. Smaller bucket - more bits of fingerprinting info. * KN: in principle - want to limit number of bits added to the platform in addition to what's already there. Not trivial to decide. Think 32 buckets is a fair proxy, but wanted to point out. * MM: specific number 32 is less important than the concept. Really interested in - there shouldn't be 7 billion. Also - browsers de facto have buckets. It's a fact that users are grouped. This proposal - intentional that UAs should be doing analysis on the buckets. If it's challenging - it's the point. Want the bucketing to be intentional, not just what falls out of the hardware. * KR: Before our team would agree to putting a hard number on this, we’d like to have time to enumerate all the parameters where we think there’s going to be variability, and see whether the combinatoric product is going to be well above that number. I’m not sure that 32 or 64 is reasonable. There are wildly different GPU families, that have large numbers of one thing and small numbers of other things. I’m not sure it’s going to be practical to a priori come up with a bucketing scheme that’s going to do well for applications. * KR: Also, the Chrome team objected to efforts to gather the data needed to choose buckets, because just finding the lay of the land isn’t sufficient justification to collect the data. We might not be able to get the data at all. So I’m not sure our team can agree to this. * KG: think you should look at it. Combinatoric aspect. Main thing - the feature levels you get for different hardware generations are bits for the entire generation. Eg. 30-series GeForce cards all look the same. Probably only need a few buckets per vendor. Doesn't add up quickly. I'm hopeful that this can be done. 32 might be an aggressive goal. This is an attempt for us collectively to aim for a reduced fingerprint. For data collection - I suspect if you go back to your privacy team and say you're trying to reduce fingerprinting on the web, they'll be agreeable. Previously the motivation was probably "we want WebGLStats in Chromium". I'm hopeful. Worst case, we try to do it and fall short. Then at least we tried. * MM: first time I've proposed this publicly, so taking time to do internal investigations is fine. Contrasting data point - in Metal, devices don't describe their limits, rather than a family. There are 12 families, so 12 buckets. Just one input of where we got the 32, 64, etc. number. Understand that other APIs run on more varied hardware. * JB: significance of Kai's earlier remark just dawned on me. If you have only 2 buckets, and one is "Myles' machine", the other is "everybody else", "Myles' machine" carries a lot of info and the other one doesn't. Rarity of the bucket informs how many bits of info you get. Only way to minimize conveyance of info - a broad survey so that we can make sure the defined buckets are roughly equal. * MM: from school - building decision tree, want branches to be roughly equal size. * JB: negative log base 2. * MM: I cede this point. Up to the UA. Make a bucket for Myles' machine? That's compatible with my proposal. * KN: we can try to define max # fingerprinting bits to add to the web platform. I think there's no harm in this proposal specifically, but scoped to the specific problem. Ideally we'd say here's a specific number of entropy bits for the entire platform. Hard to extricate ourselves from the rest of the platform. Understood it's a much harder problem. Putting lots of constraints on ourselves. More meaningful to do this at a wider level. * MM: totally agree. But, trying to get something that can actually be done. Let's not let the perfect be the enemy of the good. * KG: +1. People can already tell what UA they're on. Hard to do this perfectly, but think we should try. Maybe easy for me to say because I was trying to do it for FF's WebGL impl. * MM: take a week to think about this proposal? * KG: SGTM. * KN: not sure how much time I can devote to this personally. * KG: I can help give input on Firefox's WebGL fingerprint reduction; can chat offline. * KR: our team will try, but a lot of stuff going on right now. *

[kainino0x]

Resolved to have spec say "must" not expose more than 32 buckets. @kdashg assigned to make spec change.

[kdashg]

GPU Web F2F 2023-02-16/17

Passive Fingerprinting Surface [#3101](https://github.com/gpuweb/gpuweb/issues/3101) [Myles] * CW: We thought about it. * KG: Mozilla and Google chatted. Think there was room for consensus where implementations “should” restrict the uniquely identifiable configurations to at most 32. Act in good faith. * MM: why "should" not "must"? * KG: think "must" is tolerable too. * KN: didn't want "must" because it's difficult to ensure you're conformant. * KG: hard part about "must" - is it OK to be wrong? Write "must" in a spec and be confident it's true? Backward compatibility isn't an absolute. Think we should say we "must" keep it under 32 buckets and try our best. * MM: think the "out" is - bring it back to the group. * DJ: what if you have 32 buckets and a 33rd one comes along? Merge buckets, add a new one? * CW: another one - this is non-testable. E.g. Chrome right now has 48 buckets for the limits. But, a bunch of these are probably not used by any device. * KG: that would be a good time to come back to the group, e.g. if there are 60 configs we want to support. Consensus for "must be 32 or less"? * CW: likely yes, but would like to see internally. * MM: OK. * DJ: are you aiming for 48 buckets and some are empty because devices are similar enough, or you've defined the bucket and don't see any devices in the wild? * AE: we have 4 * 4 * 3. We don't have data. * KG: we have ~27 unique renderer strings possible from our renderer string sanitization. Recent NVIDIA cards for example. * MM: realistically we'll have a few of them. * **Resolution**: Google will discuss internally. Expected resolution: "must be 32 buckets or less". * MM: when you normalize renderer strings - does that feed into other limits? * KG: de facto, but not in code. Max texture size won't change in a GPU generation. * CW: may be able to resolve this tomorrow.

[kdashg]

GPU Web F2F 2023-02-16/17

* CW: Google discussed internally about “must” 32 bucket limit. Seems fine to us. * MM: OK, ship it. * KG: I can write up the spec language.

[pes10k]

@yoavweiss

making it an active fingerprinting surface

Yes your right, i'll update the issue title. I was using the term passive to mean "detectable w/o the user needing to interact w/ the site/frame" but i appreciate thats a different way the term "passive" is used in W3C

Resolved to have spec say "must" not expose more than 32 buckets.

I do not think this addresses the concern in my issue. This is still 5 bits, which is an enormous amount of fingerprinting for a single API describing (generally) just one piece of hardware. I dont see how we could add that much identifiability to the platform w/o seriously undermining the platform's privacy goals.

I appreciate you all have had several conversations about this from the minutes posted (thank you for sharing them!). When thinking through all this, it would be useful to understand:

1. which of these features and limits are already detectable through the WEBGL_debug_renderer_info and similar. All of them? If not, which are new?
2. for each features and limits already learnable through WEBGL_debug_* and similar, would WebGPU expose the same, additional, or less information that is currently visible
3. what the expected distribution of unique combinations of values are. Given the 10,100,1000,etc most common supported devices, do the authors expect to see 10,100,1000,etc unique combinations of feature & limit values? Or in practice is most hardware clustered into a small number of reported values
4. does the relevant hardware different independently for each of the limits and features, or are there clusters of limits and features such that graphics hardware that has a high (for example) maxTextureDimension1D value is very likely to have a high maxBindGroups and a high maxSampledTexturesPerShaderStage value? If there are clusterings like this, than maybe the API could instead report one of a small number of bucketed values (e.g., high capability device, medium capability device, etc) and that would capture most (if not all) of the use cases for the spec.

[Kangz]

@pes10k, thank you for the discussion.

5 bits is not insignificant, but these bits should be highly correlated with other sources of fingerprinting like the ones that @kdashg detailed:

Another subtlety is that certain math and rasterization artifacts that reveal information about which GPU is being used are in-practice inescapable without reverting to CPU rendering for the implementation. As such it's unfortunately just not viable for privacy-absolute (e.g. Tor) users to use hardware rendering for canvas2d/webgl/webgpu, and they must rely on software rendering. However, even these artifacts reveal very few bits. While it's possible to trivially observe whether you're running on e.g. Intel vs Nvidia gpus via rasterization artifacts alone, you generally can't tell at all which e.g. Intel gpu you're running on, not even what specific generation it's from.

1) and 2) In general what WebGPU will expose is much less than WEBGL_debug_renderer_info allows the browser to expose (which can be the exact GPU model). The value 5 was influenced by the sanitization Firefox does of the debug renderer string, turning it into one of 31 (IIRC) representative debug info strings. Even if WebGPU implementation were to expose exactly the underlying limits, the limits would give less information than an unsanitized WEBGL_debug_renderer_info.

3) and 4) Like you guessed, most limits and features come in bundles that only depend on the hardware vendor and device generation (and maybe driver version in a few cases, but it should be minor). This means that already the number of clusters should be small given that on Windows for example there are essentially three GPU vendors, with less than 10 relevant device generations. But user agents are expected to bucket even more than this. Chromium plans to do it. The idea of high/medium/low devices is what the group previously referred to as "feature levels" and while there is interest in such a mechanism, the group didn't agree to defining them for V1 because there are significant challenges both technical and organizational to agree to such feature levels. However it is a subject that is very likely to be raised again in the future.

[kdashg]

GPU Web 2023-03-08

* CW: Kelsey answered with current state of things and group's opinion. Talking about 32 buckets, people asked questions about how they're defined. Tried to answer. If you're interested in this topic, please chime in. * KG: think your answer was good. There's a PR open for this. As resolved, we can close that PR? * [https://github.com/gpuweb/gpuweb/pull/3840](https://github.com/gpuweb/gpuweb/pull/3840) * CW: **I think we can merge it.** * KN: +1 * KN: There was an editorial fix if you (or I) can fix it.

[pes10k]

@Kangz thank you for your reply. Its encouraging that the group is optimistic about the "feature levels" approach (and thank you for the term, thats much more convenient than my word salad trying to convey the same idea).

However, the 5bits / privacy risk in the current spec still needs to be addressed, I don't think thats something that can wait for a v2. Maybe that means figuring out the "feature levels" approach for v1, or maybe it means some other option, but adding 5 bits of identifiability is a frightening amount that alone is almost certainly going to be enough to uniquely identify a non-trivial number of people, especially among the groups of visitors on medium-to-small popularity sites. Unfortunately, if we've learned anything about trying to address fingerprinting in specs, its that once fingerprinting surface has been standardized and shipped, the web quickly calcifies around it and it becomes nearly-impossible to back it out remove it.

And if the group is pushing the "feature levels" approach past v1 because of uncertainty about whether there is a workable path, then thats doubly concerning, since it means there may be no standardizable, workable path for addressing the privacy risks in the proposal at all.

I appreciate that the group has worked extremely hard at addressing the fingerprinting concerns in the spec, but I dont think standardizing 5 bits of fingerprinting surface for a single spec works with the privacy goals and principals of the W3C. If it'd be helpful though, Im happy to work with you all though as much as possible, to try and find other solutions

[Kangz]

I understand the concern that 5 whole new additional bits not correlated with anything else already on the Web platform would bring. This is not the case here. As described by @kdashg's comment above, these 5 bits are very highly correlated included in the fingerprinting that you can get by doing a canvas hash fingerprint due to subtle rasterization pattern difference between GPUs. These bits are also a strict subset of what you could get with the WebGL debug renderer string.

I haven't followed the most recent developments on this, but there used to be a proposal around a "privacy budget" for pages. Having a general framework agreed by all UAs and more to handle this on the Web would be ideal instead of having each spec invent their own ways to deal with fingerprinting. UAs all do their best to prevent fingerprinting, and AFAIK sometimes have different mechanisms to do so. The WebGPU spec is not a good place to force a specific way for fingerprinting to be handled because that's very UA dependent at the moment. Instead it should provide allowances for the UAs to do whatever they need to do to protect the user, which is the case with the current WebGPU spec.

Because of these affordances in the WebGPU spec, if in the future there is a cross-cutting way to handle fingerprinting that all UAs agree to, then it would be backwards compatible to add it. It would be amazing to have agreement on an fingerprinting mitigation approach that all UAs and other actors agree too, but AFAIK we don't have one right now. The status quo that I understand right now is that each UA tries its best with its own approach. WebGPU shouldn't and can't force one approach over another because it is only a tiny fraction of the Web platform.

[pes10k]

These bits are also a strict subset of what you could get with the WebGL debug renderer string.

Understood, but, as I understand it, the purpose of this API is to replace the existing WebGL debug render string. It is important then to make sure that this new proposal does not replicate the privacy risks and harms of the of the legacy API. And, as use of that API has shown, its extremely-difficult-to-impossible to retrofit privacy protections onto an API once its standardized.

Standardizing APIs that have privacy harming features, and then relying on browsers to figure out how to mitigate those privacy harms after the fact is the anti-pattern thats lead to browser fingerprinting being the entrenched problem it is today. UAs needing to rely on non-standardized privacy mitigations causes a race to the bottom privacy wise, with vendors afraid to try to reduce fingerprinting surface bc of webcompat risk, and fingerprinting surface of the least-private browser becoming the defacto standard.

This kind of anti pattern is exactly why its important to make sure that new APIs don't reintroduce much of, if not all of, the fingerprinting surface of the legacy APIs they mean to replace.

I haven't followed the most recent developments on this, but there used to be a proposal around a "privacy budget" for pages

I know Google has discussed this as a possible solution to fingerprinting problems, but i am not aware of specifics yet on how it'd be deployed / with what parameters budget / over what life time, or other kinds of details that'd be critical to understand if it was a practical solution to fingerprinting. Even more importantly, I'm not aware of any progress on standardizing it in the last 2-3 years, and so I its not something we could assess the privacy properties of a new standard against.

It would be amazing to have agreement on an fingerprinting mitigation approach that all UAs and other actors agree too, but AFAIK we don't have one right now

I appreciate what you're saying, but this is exactly the concern (and the common pattern for fingerprinting on the Web).

1. Spec authors aren't able to agree on how to address the fingerprinting surface, and so plan to fix the privacy harms in follow up revisions
2. in the meantime websites ship code expecting the initial privacy-harming API values/shape, and then
3. webcompat problems prevent both standards bodies and UAs from addressing the known-from-the-beginning privacy harms

Again, I appreciate the large amount of hard work the group has done here, and I'm eager to try and keep this conversation productive and not calcify into an argument. But I also don't see how the current proposal can be standardized as is w/o seriously harming the privacy properties and goals we all have for the Web.

As a possible way forward, would it be helpful to re-start discussion around the "feature levels" approach (since it seems like there was general enthusiasm for it in the abstract), and try to bring in some more participants to see if some agreement can be reached there?

[grovesNL]

@pes10k

As a possible way forward, would it be helpful to re-start discussion around the "feature levels" approach (since it seems like there was general enthusiasm for it in the abstract), and try to bring in some more participants to see if some agreement can be reached there?

Could you clarify how feature levels would avoid exposing the same information already exposed by either querying debug renderer info directly (e.g., WEBGL_debug_renderer_info), detecting canvas rasterization differences, or running specialized WebGL shaders to expose hardware differences?

If WebGPU hid this information, I think most application developers would source it from WebGL as a roundabout way to achieve the same goal.

[pes10k]

Could you clarify how feature levels would avoid exposing the same information already exposed by either querying debug renderer info directly

I'm assuming a goal of exposing this information in WebGPU's APIs is either because a) some of it is not available from other APIs, not easy to perfectly extract, or looks very odd to a UA (i.e., like fingerprinting), and/or b) because at some point the goal is to depreciate and remove things like WEBGL_debug_renderer_info in favor of this new, more explicit API.

If "a)" isn't the case, then why mirror this information in another API? And "b)" seems like a likely (and laudable) goal, but why its important to be careful and protective about how identifying these APIs are.

And even if the plan is to have all routes to GPU hardware info on the platform indefinitely, both the legacy ones you mention and the new ones in this proposal, new APIs should not make it easier for sites to access this information. This case is well described by case 3 in Section 2.3.3. of the TAG's recently drafted privacy principals.

[grovesNL]

@pes10k

If "a)" isn't the case, then why mirror this information in another API?

I might be misunderstanding, but I believe the intent is to match the same level of detail exposed in WebGL or less. It's useful to mirror the details in a slightly different form because developers are already working with a WebGPU context, so sourcing it from WebGL would add resource overhead (an extra WebGL context that is only used to source this information) and worsen ergonomics and portability (e.g., hard-coded limits lookup tables based on device names).

[pes10k]

@grovesNL yes, precisely, the privacy principal I linked to in the TAG’s draft document is saying is if your API is mirroring privacy-risking data (inc fingerprint inputs) in a new API, you should make sure it’s more difficult to extract information from the API than existing methods. This is to 1. avoid making it easier for sites to extract the information (I.e leading them away from the legacy API to the new one) and 2. to avoid further entrenching privacy-harming expectations around the data.

[kdashg]

[If you're only following along in the comments here, you might be missing the shape of the consensus that we landed on for addressing this, since those discussions happen primarily on conference calls, and the minutes are not routinely posted back into github for non-wgsl topics.]

More or less, yes, the API superficially looks privacy-harming, but in practice it is not and will not be. If a UA were to go rogue and expose info in contravention to our consensuses (including about 32ish buckets) and other shared goals around protecting privacy, no spec'd shape of API here could prevent that.

We care deeply about privacy, but we don't see clear ways to make the spec technically match that guiding principle while also retaining the flexibility we need as UAs. (i.e. we can't spec a list of adapters and what to [pretend to] call them)

This leaves this topic in the category of things that cannot be technically specified any tighter in consensus, where we cede flexibility (and extend trust) to UAs. The UAs involved here are mutually sufficiently satisfied on this topic, even if maybe we aren't all perfectly or happily satisfied, and may wish we could do better.

I believe my comment here remains the group's consensus Response to the privacy concerns raised in this issue: https://github.com/gpuweb/gpuweb/issues/3101#issuecomment-1370274528 We do consider this issue Closed for now, but since I don't know the PING's Process for this, I have been hesitant to close this issue for you.

If this response doesn't feel satisfactory to you, I think we should set up a call to talk about it with you in more detail.

[pes10k]

More or less, yes, the API superficially looks privacy-harming, but in practice it is not and will not be. If a UA were to go rogue and expose info in contravention to our consensuses (including about 32ish buckets) and other shared goals around protecting privacy, no spec'd shape of API here could prevent that.

I do not understand this framing of the problem. My concern isn't that a implementor might expose some privacy harm by not following the spec's guidance; my concern is that following the spec's guidance exposes ~5 bits of fingerprint surface.

We do consider this issue Closed for now, but since I don't know the PING's Process for this, I have been hesitant to close this issue for you.

PING's W3C contact encouraged me to be as direct as possible, to avoid possible misunderstandings. So I don't mean the below to read combative, only to be clear about my position and my understanding of W3C process.

I do not consider the issue resolved, and I do not think the spec should advance until the privacy issues in this spec (~5 bits of unprotected fingerprint surface) are addressed. If the group wants to close this issue, the group can do so, but issues tagged with privacy-needs-resolution are mirrored PING side and I expect your W3C team contact will continue to encourage you to try and resolve the issue before advancing the proposal further.

And if the group decides to move towards rec without addressing the privacy concern, I understand that the group can do so, but I expect to issue a formal objection in that case.

If this response doesn't feel satisfactory to you, I think we should set up a call to talk about it with you in more detail.

I would be glad to join a call with the group. If you could let me know when a good time would be for the group, i will do my absolute best to be available then.

[Kangz]

I do not understand this framing of the problem. My concern isn't that a implementor might expose some privacy harm by not following the spec's guidance; my concern is that following the spec's guidance exposes ~5 bits of fingerprint surface.

What @kdashg describes is that the consensus in the WebGPU group is that allowing implementations to expose at most 5 bits of fingerprinting highly correlated to other sources of fingerprinting (WEBGPU_debug_renderer_info, canvas hashing, and more!) is acceptable. Especially with the agreement among UAs that we are striving to expose less depending on circumstances, and the spec allowing exposing no extra bits of information if the UA so chooses.

The spec does not mandate that 5 additional bits be exposed, and in fact is built such WebGPU can be used without the browser giving any explicit bits of additional fingerprinting (of course canvas hashing stays a possibility for example).

And even if the plan is to have all routes to GPU hardware info on the platform indefinitely, both the legacy ones you mention and the new ones in this proposal, new APIs should not make it easier for sites to access this information. This case is well described by case 3 in Section 2.3.3. of the TAG's recently drafted privacy principals.

The new API makes it harder than WEBGPU_debug_renderer_info so I believe it follows the guideline in section 2.3.3:

• The data is quantized by the browser, both in limits, features and adapter info. The spec calls out that this should not expose more than 5 bits on its own (irrespective of correlations which are definitely present!)
• Getting the information is an asynchronous process with multiple awaits necessary to get to the adapter info.
• The website needs to handle the browser returning any valid value, including empty string and default limits (in WebGL it is a single string that you can easily just hash or send).
• The data is spread out among multiple calls, objects and properties.
• Contrary to the debug renderer info, the data is not an exact GPU model but a broad category of device.

I don't think any UA expects to expose GPUAdapterInfo.device and GPUAdapterInfo.description in the wild (in Chromium they are empty string unless you pass special command line flags), so if this help make it more clear that the information is not exposed, we could consider removing these properties.

I would be glad to join a call with the group. If you could let me know when a good time would be for the group, i will do my absolute best to be available then.

This has been discussed at huge length in the WebGPU group, I think it might be more productive to have WebGPU folks that are interested join a PING call which I understand are at 9AM PT on Thursdays. We'll gather the list of interested folks and contact the PING to put this issue on a meeting's agenda.

[pes10k]

I don't think any UA expects to expose GPUAdapterInfo.device and GPUAdapterInfo.description in the wild (in Chromium they are empty string unless you pass special command line flags), so if this help make it more clear that the information is not exposed, we could consider removing these properties.

This would be a very good improvement. It would not address the main concerns in this issue, but it would be a very good change, and would be very appreciated.

The new API makes it harder than WEBGPU_debug_renderer_info so I believe it follows the guideline in section 2.3.3:

I dont think # of function calls or similar is the intended idea of "is it easier to access" in section 2.3.3. The relevant difference here is things like "is the method guaranteed to be present" or "is it intended to be used in debug or privileged environments". The orig WebGL specs explicitly say "browsers should be careful about whether to make this available". WebGPU says the methods should be there.

This scrapes down to the same thing: define the privacy harming behavior, and leave the "how to make it private" part up to implementors. This has been a very harmful pattern for privacy in Web standards (as demonstrated by the WebGL_* extensions, among many others specs) and so its important for new specs to do much better than old ones, and to be fingerprinting-resistant in their default implementations. And especially for specs that could someday lead to the deprecating and removal of current FP-harmful specs (again, like the WebGL_* extensions).

This has been discussed at huge length in the WebGPU group, I think it might be more productive to have WebGPU folks that are interested join a PING call which I understand are at 9AM PT on Thursdays. We'll gather the list of interested folks and contact the PING to put this issue on a meeting's agenda.

I asked the other PING chairs and staff about this, and they agreed that this has already been discussed by PING when the initial review was completed. PING reviews are done by individuals and not the group though, and if it'd be helpful I'm happy to join with members of this group if it'd be helpful. If so, happy to find a time that works however is convenient.

[jyasskin]

@pes10k, can you link to the PING minutes in which the details here were discussed? I suspect that the specific considerations the WebGPU folks are bringing up didn't occur to us when we discussed the review in the PING, and that the group as a whole would appreciate the opportunity to consider them. If I'm wrong about that, the minutes will demonstrate it.

[pes10k]

Its here in the minutes: https://www.w3.org/Privacy/IG/summaries/PING-minutes-20220616#webgpu

I dont think "Maybe worth saying in text, report default value if you’re in privacy mode" captures my full POV, but heres where we discussed fingerprinting risk from WebGPU in PING.

[jyasskin]

Yeah, even if the discussion was somewhat more detailed than

Nick: on timing attacks or fingerprinting, “exposing device capabilities” sounds like fingerprint risk

Pete: reminds me of conversations about privacy-preserving path in the standard. Maybe worth saying in text, report default value if you’re in privacy mode

Dan: vs what browser could do, would be great to standardize what they should do so developers know what to expect.

I don't think it covered the mitigations the WG has designed in. Further, even though the PING delegates to individuals to do the actual privacy reviews, in order for something to be a "PING review", it has to reflect the consensus of the PING. Given that the PING hasn't discussed these mitigations, I don't think we have any basis to think we know the PING's consensus on them. I think it'd be worth having folks from the WebGPU WG visit the PING in order to find out what the PING's consensus is.

[pes10k]

in order for something to be a "PING review", it has to reflect the consensus of the PING.

That does not match my understanding of the W3C HR process, nor what we've been told from W3C staff. HR reviews are coordinated and discussed with the HR group, but filed by the individual reviewers. PING (or other HR) reviews do not (necessarily) reflect a consensus view of the HR group. For among other reasons, if that was a requirement, then entire HR process would grind to a halt. Authors of the proposal being reviewed could just join the HR group and kill a "needs consensus" review.

I've also reached out to our new W3C team contact to verify the above is still correct, but it is the guidance we were given by our previous team contact.

That said, if the group would like to still join a PING call to discuss more, I will talk with the other PING chairs and find a call time that works. But the (I believe) misunderstanding around "consensus" is why I kept suggesting a direct call would be more useful than a PING-wide call.

[pes10k]

Ive talked with the other PING chairs and the team contact and we've put this issue on our agenda for our next meeting, at 9am PST on July 6th. We have it scheduled for the start of the call, for the first 20 min. If that works for your group, let me know and I can share call coordinates. Thanks!

[Kangz]

Sounds good, that works for the group. If you can share the call coordinates I'll forward them to the WebGPU group.

[plehegar]

The event notification is at https://lists.w3.org/Archives/Public/public-gpu/2023Jul/0000.html

[tidoust]

Adding a link to the minutes of the discussion with PING back in July 2023.