5 ms·

WebGPU hits 40% availability 2 weeks after Chrome releases support

128 points by bhouston 3y ago

superkuh 3y ago
WebGPU hits 40% availability in the subset of websites that intentionally put an WebGPU testing iframe that runs bleeding edge JS in their sites. Even the JS used in collector.js uses vanilla JS features that aren't even in all browsers and so will simply miss out on collecting any information about them, or browsers that don't run it's JS, at all.
- bhouston 3y ago
  Do you have better stats on its adoption? I am basing this on collecting capabilities from roughly 30K browser per day, which is at least decent. You can argue it is biased, but that is what the breakdowns are for. Also, what features in collector.js do not have wide browser support? If you let me know, I can address it. Is the amount of browsers who can not run this script statistically significantly, like more than 1% of devices? I do have error reporting on the script so I know that if the script runs I catch all the errors. I guess I am missing if the script fails to compile in the first place. BTW I just pushed a new version that uses ES6 as the TypeScript compile target rather than ES2020 for collector.js.
  - ComputerGuru 3y ago
    You need error reporting as a separate script injected early on into the html page before your script is ever loaded. This error reporting script should be as bare bones and backwards compatible as possible. You can grab mine from our site, if you like.
    - bhouston 3y ago
      Sure. Which site is that? I can do this easily on the iframe embed.
      - roqi 3y ago
        [flagged]
      - ComputerGuru 3y ago
        Here you go, this is taken from production, copied from the browser's "view source" feature so there are a few dynamic values hard-coded (they're obvious, though): https://gist.github.com/mqudsi/2f570cf58d7d293ba27217a308659dfe https://gist.github.com/mqudsi/2f570cf58d7d293ba27217a308659... It's from a checkout page (the most important page where fancy JS isn't worth a single lost sale) so it goes to great pains to catch all errors and not be itself a source of JS errors. It intercepts errors and POSTs them to the server with a good-faith attempt at getting the browser, faulting script, line number, column number, error message, and stack trace. It was actually in a <script> tag and not in an external js, but that shouldn't matter too much. You can see the comments and code to support actually ancient browsers (predating IE6 and Firefox 24).
  - superkuh 3y ago
    If you only use JS to collect statistics you are only collecting statistics about JS users. And that is not everyone. And I'm not just talking about weird nerds like myself that intentionally disable it but also the underserved billions of the world without the latest year's smartphone. It's a fatal flaw in pretty much all modern web stats collection that makes it seem like JS and bleeding edge JS support are far more of the pie than they are. And any time it's brought up those same people say it's not worth actually collecting information about all hits, say, via the webserver logs, because it's small. But they never connect the dots...
    - bhouston 3y ago
      > you are only collecting statistics about JS users. And that is not everyone. Okay. I can assume that anyone who has JS disabled, and I know how to detect that in the iframe, as also not having WebGPU available. Because WebGPU is exclusively JS and if JS is disabled, it effectively disables WebGPU. I'll add that.
      - danielheath 3y ago
        Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request.
        bhouston 3y ago
        > Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request. Hmm... technically correct, but I wonder if this is statistically relevant? Remember that I am currently collecting 30K browser samples per day. I'd have to miss 300 samples in a day this way for it to cause an error of 1%.
        superkuh 3y ago
        From what kind of sites? The kind that know and care about WebGPU support enough to include your iframe? That's some heavy selection bias if my assumption is true. Not a lot of low end smart phones visiting the kind of person that runs that kind of site.
  - Dalewyn 3y ago
    >Do you have better stats on its adoption? Chrome (to include the original Chromium and forks like Edge and Brave) holds 80~90% of the browser market share, and the vast majority of those installations will either autoupdate or be manually updated on a regular basis. The logical conclusion thus is that whatever feature(s) introduced by Chrome will be widely available for common use in a short period of time. This is the positive side to a monopolized browser market: Whatever Chrome supports is what the commons can support.
    - Andrew_nenakhov 3y ago
      It is not a positive, but a negative side to a monopolized browser market. Unrestrained power to define communication standards and protocols will eventually be used for malicious purposes and there will be no players in the market who would oppose it. Use Firefox, the last bastion of the Free Web.
      - Dalewyn 3y ago
        [flagged]
        Andrew_nenakhov 3y ago
        Yeah right. IE6 'just worked' too and you didn't have to worry about compatibility if you used it.
        account42 3y ago
        I too would be more than happy for Mozilla to be replaced but thinking that Google is any less cancerous is simply retarded. In fact, one of the biggest problems with Mozilla (but not the only one) is that they are effectively a Google vassal that can't afford to challenge its master. As for all the other non-Google-reliance problems, you can bet that as another SV tech corp, Google has them all too and then some.
      - AshleysBrain 3y ago
        Firefox is working on implementing WebGPU support too.
- Camillo 3y ago
  WebGPU availability factoid is actually just statistical error. Noscript Georg, who lives in a cave and browses over 10 sites a day using Emacs, is not an outlier and should have been counted.
- AshleysBrain 3y ago
  It would be great if browser makers published their own statistics on this kind of thing. They presumably have the real data. But they don't share it, so the next best thing is for a community of interested developers to try to collect it themselves. Of course that's not as good as the real data that the browser makers have, but what better option is there if you need data like this?
deleted 3y ago
[deleted]
villgax 3y ago
I want the ANE+Android equivalent along with haptics to also come to all browser runtime...just feels like kneecaping websites
- jeroenhd 3y ago
  Haptics were part of the web spec but scammers abused them (making the phone vibrate to simulate a virus alert or whatever) so the feature got disabled in most browsers I believe. It's officially supported on all platforms except for Safari (big surprise there) but for browsers supposedly supporting the spec on MDN (https://developer.mozilla.org/en-US/docs/Web/API/VIBRATION_API https://developer.mozilla.org/en-US/docs/Web/API/VIBRATION_A...) I'm not getting any vibrations our of demo pages I can find online. Edit: actually, it only seems broken in Firefox and Bromite now, Chrome still has vibration support. Firefox seems to have lost vibration somewhere during development of the rewrite that also took away most addons, so I'm sure it'll be a few years before this bug gets fixed. Still, with Chrome supported, that's the majority of mobile devices out there fully supporting vibration patterns!
  - pjmlp 3y ago
    It works just fine on Android browsers. https://whatwebcando.today/ https://whatwebcando.today/
    - jeroenhd 3y ago
      You're right, it'll work for most users. It's still bugged on Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1653318 https://bugzilla.mozilla.org/show_bug.cgi?id=1653318 and also on Bromite on my phone, which is why I thought Chrome also disabled the feature.
    - villgax 3y ago
      Didn't work on Chrome113 or Brave on Android 13
      - pjmlp 3y ago
otabdeveloper4 3y ago
> Chrome is a monopoly Oh wow, not news.
inetknght 3y ago
"WebGPU availability" ... have you asked your users if you can use their GPU? Have you asked your users if you can query their capabilities? Availability isn't consent.
- hulitu 3y ago
  You are asking too much. Chrome must execute remote code. WebGPU is CIAs wet dream.
  - wraptile 3y ago
    Javascript already brought all 3 letter agencies to climax long time ago. Javascript based fingerprinting is capable of uniquely identifying every single one of us and the reason it's not everywhere because it's too slow for commercial web. I haven't looked into webGPU yet but it seems like this could greatly speed up the fingerprinting process.
    - arp242 3y ago
      The alternative to webapps in JavaScript are desktop apps. Do you really think the situation would have been better with desktop apps? sha256(/etc/passwd) or whatever the equivalent of that is on Windows and you're done. Even in a sandbox where you don't have access to these files there are still plenty of opportunities, such as just reading the environment, solib versions, testing support for hardware features, etc.
- pjmlp 3y ago
  Yes, when they decided to install ChromeOS on their computer.
  - account42 3y ago
    It's hardly consent when Chrome or another browser that implements all this shit ends up being required to access your bank, do your taxes, interact with your friends etc.
- 3y ago
kenver 3y ago
40% seems disengenuous when it's essentially 0 on mobile...
- marginalia_nu 3y ago
  I always feel there's probably a lot of selection bias involved in these sorts of figures. If you build a mobile first website, most traffic you're going to get is mobile since mobile first websites suck on desktop. If you build a website that doesn't perform well on mobile, mobile users are going to bounce and your traffic is going to make it look like desktop is the primary paradigm. FWIW, something like 60-70% of the traffic to my sites is from desktop users. They work on both desktop and mobile, but they just cater to the sort of people who use desktop. It's really hard to get objective measures.
  - bhouston 3y ago
    > I always feel there's probably a lot of selection bias involved in these sorts of figures. I am aware of this and if the collector gets more widely adopted I can get better numbers -- I only created this site in March 2023. Luckily, I do show the platform breakdowns as well.
lofaszvanitt 3y ago
Adoption will be dead slow. People just copy each other or something they see and like. The css 3d options and other neat things in the ecosystem are also dead in the water. Maybe because its too complex for the average ppl or no proper examples were provided.
andrewstuart 3y ago
What will people actually use WEbGPU for?
- Am4TIfIsER0ppos 3y ago
  Surveillance. Even basic HTML is used for surveillance with things like "tracking pixels".
  - kypro 3y ago
    What are you basing this on? I can't think of any reason it would be used for surveillance, but curious if I'm just out of the loop on this one. Also, I'm not sure you understand what a tracking pixel is – tracking pixels don't track pixels on your screen.
    - bhouston 3y ago
      Unfortunately, some major ad tracking companies are using WebGL capabilities to aid in their fingerprinting of browsers. As WebGPU is rolled out, they'll probably add WebGPU capabilities to their collection list as well. These companies do not single out WebGL or WebGPU for fingerprinting but they query any optional browser feature they can in order to develop as complete and robust of a fingerprint as possible.
    - Am4TIfIsER0ppos 3y ago
      A tracking pixel is an external image loaded from a server for analytics purposes. All web technologies facilitate this. Pictures, css, fonts, video, audio, javascript, and all the new Web* tech. Requests link you together on different servers. Scripts actively spy on you by logging keystrokes and more, then funneling that to a surveillance company who launder it for the government. Rendering tech like canvas and webgpu help uniquely identify the machine by carefully timing and positioning things.
      - XCSme 3y ago
        Can't the server already kind of uniquely identify a machine using the IP, User Agent, timing of requests, times of visit, navigating patterns, etc., without even relying on any client-side data?

128 points by bhouston 3y ago

WebGPU hits 40% availability in the subset of websites that intentionally put an WebGPU testing iframe that runs bleeding edge JS in their sites. Even the JS used in collector.js uses vanilla JS features that aren't even in all browsers and so will simply miss out on collecting any information about them, or browsers that don't run it's JS, at all.

bhouston 3y ago
Do you have better stats on its adoption? I am basing this on collecting capabilities from roughly 30K browser per day, which is at least decent. You can argue it is biased, but that is what the breakdowns are for. Also, what features in collector.js do not have wide browser support? If you let me know, I can address it. Is the amount of browsers who can not run this script statistically significantly, like more than 1% of devices? I do have error reporting on the script so I know that if the script runs I catch all the errors. I guess I am missing if the script fails to compile in the first place. BTW I just pushed a new version that uses ES6 as the TypeScript compile target rather than ES2020 for collector.js.
- ComputerGuru 3y ago
  You need error reporting as a separate script injected early on into the html page before your script is ever loaded. This error reporting script should be as bare bones and backwards compatible as possible. You can grab mine from our site, if you like.
  - bhouston 3y ago
    Sure. Which site is that? I can do this easily on the iframe embed.
    - roqi 3y ago
      [flagged]
    - ComputerGuru 3y ago
      Here you go, this is taken from production, copied from the browser's "view source" feature so there are a few dynamic values hard-coded (they're obvious, though): https://gist.github.com/mqudsi/2f570cf58d7d293ba27217a308659dfe https://gist.github.com/mqudsi/2f570cf58d7d293ba27217a308659... It's from a checkout page (the most important page where fancy JS isn't worth a single lost sale) so it goes to great pains to catch all errors and not be itself a source of JS errors. It intercepts errors and POSTs them to the server with a good-faith attempt at getting the browser, faulting script, line number, column number, error message, and stack trace. It was actually in a <script> tag and not in an external js, but that shouldn't matter too much. You can see the comments and code to support actually ancient browsers (predating IE6 and Firefox 24).
- superkuh 3y ago
  If you only use JS to collect statistics you are only collecting statistics about JS users. And that is not everyone. And I'm not just talking about weird nerds like myself that intentionally disable it but also the underserved billions of the world without the latest year's smartphone. It's a fatal flaw in pretty much all modern web stats collection that makes it seem like JS and bleeding edge JS support are far more of the pie than they are. And any time it's brought up those same people say it's not worth actually collecting information about all hits, say, via the webserver logs, because it's small. But they never connect the dots...
  - bhouston 3y ago
    > you are only collecting statistics about JS users. And that is not everyone. Okay. I can assume that anyone who has JS disabled, and I know how to detect that in the iframe, as also not having WebGPU available. Because WebGPU is exclusively JS and if JS is disabled, it effectively disables WebGPU. I'll add that.
    - danielheath 3y ago
      Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request.
      - bhouston 3y ago
        > Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request. Hmm... technically correct, but I wonder if this is statistically relevant? Remember that I am currently collecting 30K browser samples per day. I'd have to miss 300 samples in a day this way for it to cause an error of 1%.
        superkuh 3y ago
        From what kind of sites? The kind that know and care about WebGPU support enough to include your iframe? That's some heavy selection bias if my assumption is true. Not a lot of low end smart phones visiting the kind of person that runs that kind of site.
- Dalewyn 3y ago
  >Do you have better stats on its adoption? Chrome (to include the original Chromium and forks like Edge and Brave) holds 80~90% of the browser market share, and the vast majority of those installations will either autoupdate or be manually updated on a regular basis. The logical conclusion thus is that whatever feature(s) introduced by Chrome will be widely available for common use in a short period of time. This is the positive side to a monopolized browser market: Whatever Chrome supports is what the commons can support.
  - Andrew_nenakhov 3y ago
    It is not a positive, but a negative side to a monopolized browser market. Unrestrained power to define communication standards and protocols will eventually be used for malicious purposes and there will be no players in the market who would oppose it. Use Firefox, the last bastion of the Free Web.
    - Dalewyn 3y ago
      [flagged]
      - Andrew_nenakhov 3y ago
        Yeah right. IE6 'just worked' too and you didn't have to worry about compatibility if you used it.
      - account42 3y ago
        I too would be more than happy for Mozilla to be replaced but thinking that Google is any less cancerous is simply retarded. In fact, one of the biggest problems with Mozilla (but not the only one) is that they are effectively a Google vassal that can't afford to challenge its master. As for all the other non-Google-reliance problems, you can bet that as another SV tech corp, Google has them all too and then some.
    - AshleysBrain 3y ago
      Firefox is working on implementing WebGPU support too.
Camillo 3y ago
WebGPU availability factoid is actually just statistical error. Noscript Georg, who lives in a cave and browses over 10 sites a day using Emacs, is not an outlier and should have been counted.
AshleysBrain 3y ago
It would be great if browser makers published their own statistics on this kind of thing. They presumably have the real data. But they don't share it, so the next best thing is for a community of interested developers to try to collect it themselves. Of course that's not as good as the real data that the browser makers have, but what better option is there if you need data like this?

deleted 3y ago

[deleted]

villgax 3y ago

I want the ANE+Android equivalent along with haptics to also come to all browser runtime...just feels like kneecaping websites

jeroenhd 3y ago
Haptics were part of the web spec but scammers abused them (making the phone vibrate to simulate a virus alert or whatever) so the feature got disabled in most browsers I believe. It's officially supported on all platforms except for Safari (big surprise there) but for browsers supposedly supporting the spec on MDN (https://developer.mozilla.org/en-US/docs/Web/API/VIBRATION_API https://developer.mozilla.org/en-US/docs/Web/API/VIBRATION_A...) I'm not getting any vibrations our of demo pages I can find online. Edit: actually, it only seems broken in Firefox and Bromite now, Chrome still has vibration support. Firefox seems to have lost vibration somewhere during development of the rewrite that also took away most addons, so I'm sure it'll be a few years before this bug gets fixed. Still, with Chrome supported, that's the majority of mobile devices out there fully supporting vibration patterns!
- pjmlp 3y ago
  It works just fine on Android browsers. https://whatwebcando.today/ https://whatwebcando.today/
  - jeroenhd 3y ago
    You're right, it'll work for most users. It's still bugged on Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1653318 https://bugzilla.mozilla.org/show_bug.cgi?id=1653318 and also on Bromite on my phone, which is why I thought Chrome also disabled the feature.
  - villgax 3y ago
    Didn't work on Chrome113 or Brave on Android 13
    - pjmlp 3y ago

otabdeveloper4 3y ago

> Chrome is a monopoly Oh wow, not news.

inetknght 3y ago

"WebGPU availability" ... have you asked your users if you can use their GPU? Have you asked your users if you can query their capabilities? Availability isn't consent.

hulitu 3y ago
You are asking too much. Chrome must execute remote code. WebGPU is CIAs wet dream.
- wraptile 3y ago
  Javascript already brought all 3 letter agencies to climax long time ago. Javascript based fingerprinting is capable of uniquely identifying every single one of us and the reason it's not everywhere because it's too slow for commercial web. I haven't looked into webGPU yet but it seems like this could greatly speed up the fingerprinting process.
  - arp242 3y ago
    The alternative to webapps in JavaScript are desktop apps. Do you really think the situation would have been better with desktop apps? sha256(/etc/passwd) or whatever the equivalent of that is on Windows and you're done. Even in a sandbox where you don't have access to these files there are still plenty of opportunities, such as just reading the environment, solib versions, testing support for hardware features, etc.
pjmlp 3y ago
Yes, when they decided to install ChromeOS on their computer.
- account42 3y ago
  It's hardly consent when Chrome or another browser that implements all this shit ends up being required to access your bank, do your taxes, interact with your friends etc.
3y ago

kenver 3y ago

40% seems disengenuous when it's essentially 0 on mobile...

marginalia_nu 3y ago
I always feel there's probably a lot of selection bias involved in these sorts of figures. If you build a mobile first website, most traffic you're going to get is mobile since mobile first websites suck on desktop. If you build a website that doesn't perform well on mobile, mobile users are going to bounce and your traffic is going to make it look like desktop is the primary paradigm. FWIW, something like 60-70% of the traffic to my sites is from desktop users. They work on both desktop and mobile, but they just cater to the sort of people who use desktop. It's really hard to get objective measures.
- bhouston 3y ago
  > I always feel there's probably a lot of selection bias involved in these sorts of figures. I am aware of this and if the collector gets more widely adopted I can get better numbers -- I only created this site in March 2023. Luckily, I do show the platform breakdowns as well.

lofaszvanitt 3y ago

Adoption will be dead slow. People just copy each other or something they see and like. The css 3d options and other neat things in the ecosystem are also dead in the water. Maybe because its too complex for the average ppl or no proper examples were provided.

andrewstuart 3y ago

What will people actually use WEbGPU for?

Am4TIfIsER0ppos 3y ago
Surveillance. Even basic HTML is used for surveillance with things like "tracking pixels".
- kypro 3y ago
  What are you basing this on? I can't think of any reason it would be used for surveillance, but curious if I'm just out of the loop on this one. Also, I'm not sure you understand what a tracking pixel is – tracking pixels don't track pixels on your screen.
  - bhouston 3y ago
    Unfortunately, some major ad tracking companies are using WebGL capabilities to aid in their fingerprinting of browsers. As WebGPU is rolled out, they'll probably add WebGPU capabilities to their collection list as well. These companies do not single out WebGL or WebGPU for fingerprinting but they query any optional browser feature they can in order to develop as complete and robust of a fingerprint as possible.
  - Am4TIfIsER0ppos 3y ago
    A tracking pixel is an external image loaded from a server for analytics purposes. All web technologies facilitate this. Pictures, css, fonts, video, audio, javascript, and all the new Web* tech. Requests link you together on different servers. Scripts actively spy on you by logging keystrokes and more, then funneling that to a surveillance company who launder it for the government. Rendering tech like canvas and webgpu help uniquely identify the machine by carefully timing and positioning things.
    - XCSme 3y ago
      Can't the server already kind of uniquely identify a machine using the IP, User Agent, timing of requests, times of visit, navigating patterns, etc., without even relying on any client-side data?