[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 14-01-15 04:02 AM, Dean Jackson wrote:

On 15 Jan 2014, at 7:06 pm, Florian Bösch <pyalot@gmail.com> wrote:

2) If a user comes to you with a problem (app crashes, graphics glitches etc.) you usually ask him about his hardware. You can shortcut this a lot, so that's one benefit. But also, you might want to know, well if this user had this problems, is it possible users with the same configuration have the same problems? In other words, say you have users that stay 10 minutes or more, and return the other day, but you also have users that stay 30 seconds and never return, is it because they don't find you interesting, or because they have the same hardware as the user that reported the problem to you and they would be interested but just saw garbage on screen? What action you derive from that information (develop a workaround, file a conformance test, file browser or GPU vendor bug report etc.) is a different topic. But it's important to know if visitors you didn't capture, you didn't capture because of a bug, rather than because you made boring content to them.

This goes for all applications/sites - not just WebGL. Anyway, the issue I’m going to have to have a great justification for is why WebGL should expose extra user information, for all users, without their knowledge. As you say, you can ask the user about their hardware, but then it is their choice to reveal it (and be aware of what they are giving). With this extension enabled, any web site can detect "AMD FirePro D700” and instantly know exactly what black cylinder-shaped machine I have, and that I spent more than $5000 on a computer in the last 28 days (“ooh, a fairly wealthy individual, maybe she’s interested in holidays to Maldives”).

Of course the majority of Web sites will use this information to improve the user experience - I’m not denying that. But we’ve also learnt that restricting the amount of user information we share with third parties helps users as well.

I should be clear that, for Apple products, enabling this extension is not my decision. Any matter of privacy is decided at a much higher level.

For what it's worth, the situation is similar at Mozilla. If the present conversation resulted in a decision to expose GL strings, we would still have to run that by Mozilla's people responsible for Web APIs and privacy. But before we take this to these people, we first need to agree on the usefulness of this proposal on a purely technical level.

Technical arguments here probably won’t even be noticed (although I am enjoying the discussion).

The proposal at the moment is:

1. Google would like to remove the stern privacy warning in the extension specification
2. Google would like other browsers to implement and enable the extension

I’m talking to people internally about our official position on 1. At the moment I see some hesitation from Mozilla, but maybe due to fears of UA sniffing rather than privacy?

Both issues, UA sniffing and privacy, are important. I believe that UA sniffing is the more basic technical issue, that needs to be resolved first. Mailing list archives should show that Mozilla's opposition to exposing GL strings for the past few years, has revolved about UA sniffing rather than privacy.


. A fair few people on this list support the extension (I assume that implies they agree the privacy warning should be removed), and are mostly WebGL developers or Chrome engineers.

As for 2, it’s not really something the Working Group can decide, other than making it a required part of the spec.