Hacker News Reader

Comment by superkuh | Hacker News Reader

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

View on HN

What do you mean by "the underserved billions of the world without the latest year's smartphone"?

Sure, there is a small set of people who choose not to run JS, or use something like lynx that doesn't support it, but almost every browser version released in the last 20 years, certainly all the graphical ones, have by default good enough JS support to gather basic statistics and send them back to the server.

Look at collector.js, in the first dozen characters it's already using ECMAScript 6 standards like promises. At the very least you need to change that "last 20 years" to the last 5 years.

Promises have been supported since 2014 in both Chrome for Android and Safari on iOS. Even pretty old phones generally run web browsers more recent than that — and that's not "the last five years," that's nearly twice as long.

If you are going by the dates that Google and Apple browsers supported it for the first time. But if you tried to use ECMAScript 6 features back in 2014? Hah! The support would not be there. 5 years is a realistic number.

You argued that using these features today blocked "billions" of people using old smartphones. Promises have been supported by smartphone browsers for over nine years. I do not think that using promises today prevents anywhere near billions of people from running your code, nor do I think that "5 years is a realistic number" for a feature that has been supported for 9. We're discussing whether using promises today impacts a significant number of web users.

I get what you're trying to say, but a lot of these ES6 things have been supported for longer than you'd think a while now, and are near-universal.

Near-universal: not universal. But people still running very old devices or browsers are not going to have a fun time on many sites regardless, and WebGPU is not likely to be used casually on random sites: it will be used for the same stuff that WebGL and canvas is today: mostly for special-purpose things like games, some visualisations, etc. – the sort of stuff that very old and slow devices will have trouble with in the first place.

> it will be used for the same stuff that WebGL and canvas is today

So for fingerprinting, got it.

> Look at collector.js, in the first dozen characters it's already using ECMAScript 6 standards like promises.

According to caniuse, promises are supported by Chrome since v33, by Edge since v12, by Firefox since v29, and by Safari since 7.1.

https://caniuse.com/promises

Both Chrome 33 and Firefox 29 were released in 2014.

You are gently omitting IE which doesn't have this at all. Doesn't matter when others were released, at that time IE had a market share that was non-neligible.

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

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.

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

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.

I list the "supporters" of https://web3dsurvey.com prominently on the homepage.

That's what I figured. So that supports the idea that it's only measuring a very skewed set of visitors from Webgl, JS, and gfx designer type sites. I'd put the iframe on my very non-JS, non-webgl, non-gfx sites to skew the other way but I don't put JS scripts on sites.

But then it wouldn't report anything, and assuming those cases are roughly representative for cases where it does work, it doesn't really skew the results.

Reply on news.ycombinator.com