Minutes 2023 01 25

GPU Web 2023-01-25

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: KG

Scribe: KR

Location: Google Meet

Attendance

• Apple
  • Mike Wyrzykowski
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Ben Clayton
  • Brandon Jones
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
  • Shannon Woods
  • Shrek Shao
  • Stephen White
• Microsoft
  • Rafael Cintron
• Mozilla
  • Erich Gubler
  • Jim Blandy
  • Kelsey Gilbert
  • Teodor Tanasoaia

Administrivia

• F2F
  • MM: Any ideas for group dinner locations?
  • Agenda for the F2F
  • MM: would like to discuss shading language stuff in AM - have a remote attendee from Europe. API discussion we'd prefer in the afternoon (?) - have attendee in Australia.

CTS Update

• KN: continuing integrating tests. Approaching Chrome's target release date. Have some impl work to finish - balancing that with CTS work. Hopefully continuing expanding out the CTS.
• Test work in past couple weeks going OK, despite recent news.
• Major refactoring to texture helpers, touching many tests. Then multisampling helpers.
• KG: Erich working on integrating WebGPU CTS in Mozilla's CI.

“Tacit Resolution” Queue

Passive Fingerprinting Surface #3101

• 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
• 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.

Use automatic expiry for imported textures, remove .expired #3633

• KN: editors didn't talk about this this week. Probably OK. Landed the change to do automatic expiry for canvas textures. This was sitting on top of that. Additionally, removes the .expired property, to provide a pattern, because we changed the pattern we expect people to use. Think this is what we agreed upon months ago. Pretty self-contained change.
• KG: would like to look at this again. Agree it's probably the thing we discussed earlier.

copyTextureToBuffer, should we add native API limits or workaround them? #3729

• MM: we had a resolution on this. Rare enough - we'll honor what the application tells us to do, and work around it.
• KG: +1. We do this on WebGL sometimes - line-by-line uploads, which is worse than the workaround we're discussing here.

Agenda for next meeting

• Remaining V1 issues!
• Agenda
  • (your topic here)
• MM: FYI, room for F2F claims it seats 23 people. It has 18 seats and a bench along the wall. It's the largest conference room in Apple Park. I'll bring in some extra chairs.
• RC: in email it says "check in". When should I click that?
• MM: not sure. I'll ask the folks.
• KN: 24 hours before. I tried clicking the link.
• RC: email said to do at-home analysis of health. What's that?
• MM: will add notes.