It wouldn't be that hard to devise a quick test to determine the expense in your example. If you were on Mac Safari, start at checking if the person's horizontal resolution is 12k; if not run a few quick perf tests and unless the browser was intentionally crippled, you could rapidly determine if it had the characteristics of a MacPro6%2C1 even if the user agent or GL_RENDERER string didn't tell you that; so not providing wouldn't really help that much in hiding the expense of your device.

Providing this detail, or some other run-time performance characteristic; gives us somewhere to start in the huge range of possibilities to give the user the best experience; from low end phone to high-end desktop.

I do also know there is a "trap" that would be easy to fall into where an a set-up could become blacklisted; even if in the future it became capable. For example Internet Explorer will never be able to run the Epic Citadel demo as it is currently. If IE enabled compressed textures (the current feature detection fail); then it would fail the second explicit _javascript_ test that its not Safari, Firefox, Chrome or Opera.

As it stands there is no indication other than user agent sniffing or perhaps resolution checking to pre-determine whether to attempt to run the same thing on for example a low-end phone or a high-spec'd Mac Pro; which isn't really where we want to be.

However; I also do strongly see the "hangers on" trackers issue; be it +1, Like, comment, tweet etc - coupled with the needs of things you may want to explicitly allow - like http://webglstats.com/

Perhaps an adjustment to CSP and iframe sandboxing to disallow webgl; when not from an allowed or self origin? Not sure it would really work as generally these are offered as cut and paste items. CSP headers may work best; e.g. script doing webgl must be from an allowed domain, as if you are doing WebGL you probably will run into CORS and understand the concepts.

I would really step back from the general perf test approach of needlessly hammering someone's device to determine how capable it is (whether or not you then cache that result)

On 15 January 2014 18:39, Dean Jackson <dino@apple.com> wrote:

On 16 Jan 2014, at 2:04 am, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

>
> On 1/15/14 4:02 AM, Dean Jackson wrote:
>
> > “ooh, a fairly wealthy individual, maybe she’s interested in holidays
> > to Maldives”
>

> Or "maybe we should show them a higher price for this item". A number of retailers are already experimenting with this sort of differential pricing based on whatever information they can get on the user….

Right and, as I said in another email, this is a real example of a relatively large, recent purchase by the user that would be exposed by GL_RENDERER. Some people might think that’s ok, but we’d have to make the decision for *all* users.

>
>> At the moment I see some hesitation from Mozilla, but maybe due to fears of
>> UA sniffing rather than privacy?
>
> What you've seen so far is me (not Mozilla officially) not being entirely unconvinced that the UA sniffing issue is as irrelevant as people seem to think it is.

I remain unconvinced as well.

> The privacy situation is separate from those concerns, and as you said decided on a much higher level. I can't speak to what our position on that is in this instance yet, though historically we've been very leery of exposing this sort of information.

Agreed.

Dean

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------

Re: [Public WebGL] GL_RENDERER string needed for performant apps