On 14-01-15 04:02 AM, Dean Jackson
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
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.
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 arguments here probably won’t even be noticed
(although I am enjoying the discussion).
proposal at the moment is:
Google would like to remove the stern privacy warning in the
Google would like other browsers to implement and enable the
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.
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
2, it’s not really something the Working Group can decide,
other than making it a required part of the spec.