[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
----- Original Message -----
> On Tue, Nov 30, 2010 at 6:51 PM, Benoit Jacob <firstname.lastname@example.org>
> > ----- Mail original -----
> >> On 11/30/2010 05:28 PM, Benoit Jacob wrote:
> >> > Fair enough. Do you have a better suggestion? I need a solution
> >> > that
> >> > preserves the user's privacy. Remember the amount of noise that
> >> > Evercookie made when it was released.
> >> > http://en.wikipedia.org/wiki/Evercookie
> >> > The privacy issue that we're discussing here is potentially worse
> >> > than that as, given enough bits of unique user info leaked, it
> >> > allows to build a server-side "Evercookie" associated to a unique
> >> > browser/computer id. I am inexperienced in the Web world so would
> >> > be
> >> > very happy if one explained me how my fears are unfounded,
> >> > otherwise
> >> > I am very interested in doing what I can to limit the
> >> > possibilities
> >> > of this happening, and consider this a priority over allowing web
> >> > pages to adjust their rendering to the graphics card model faster
> >> > than we can update browsers.
> >> >
> >> >
> >> I already gave you a better suggestion!
> >> Put a checkbox in that gives the user the choice:
> > I'll consider this, but will default to privacy mode.
> This is going to significantly reduce the usefulness of WebGL.
> Graphics chips, even on mobile devices, are far more capable than the
> OpenGL ES minimums.
I'm not going to restrict to the OpenGL ES minimums. Rather, I'm going to look for a compromise. There are two different approaches I'm considering:
* try to leak mostly only a one-dimensional parameter. Need to look at which of those MAX_... parameterers can be grouped together as a one-dimensional parameter. I understand that not all of them can at all.
* try to leak mostly information that's strongly correlated with information that can be obtained anyways.
> In the Chromium WebGL implementation I am going to
> continue to push for the maximum amount of functionality, whether it
> be the number of available uniforms and varyings, or the available
> WebGL extensions.
Fine, but this will leak roughly 10 bits of identification information, for the most part not correlated with already leaked information, so almost completely adding up with the number of bits already leaked. This can easily make the difference allowing to implement server-side evercookies.
> >> 3) Close access to useful VENDOR/RENDERER/VERSION and provide
> >> utterly
> >> minimal settings via glGet
> > We'll see about that, I need to examine each of the relevant MAX_...
> > pnames here, see what the possible values are if a good compromise
> > can be found.
> >> (and never offer extensions
> > We'll see when there are extensions.
> >> note that this would require dumbing every desktop
> >> computer down to 5/6/5 RGB).
> > The color depth is already leaked to web content anyway. See
> > Panopticlick.eff.org.
> > We just have to agree to disagree on this topic.
> > Cheers,
> > Benoit
> >> Taking the second option may salve your personal conscience - but
> >> realistically it allows 90% as much data leakage as option (1) and
> >> does
> >> nothing but make life harder for the application developers. That's
> >> a
> >> big win for Adobe and a significant loss for everyone else.
> >> So it's a choice between (1) and (3)...that's a tough choice - do
> >> you
> >> want or care or even understand the need for utter anonymity (half
> >> a
> >> billion facebook users evidently don't)? If so - then you check the
> >> box. Do you want cutting edge games right there on any computer on
> >> the
> >> web? If so - uncheck the box. You absolutely can't have both.
> >> I don't think you have the right to make that decision for Firefox
> >> users
> >> - and I'm pretty sure that if you do, you'll find that the problem
> >> will
> >> go away because all of the gamers (and people who want 3D pictures
> >> of
> >> stuff they buy online and people who want interactive 3D maps and
> >> so
> >> forth) will be using Chrome.
> >> Of course you could go with option (2) - which might make you feel
> >> good
> >> - but is a laughably poor decision because it inconveniences the
> >> good
> >> guys and does nothing to slow down the bad guys.
> >> So - let's agree we need the checkbox to choose between (1) and (3)
> >> -
> >> and we can arm-wrestle over how it's set by default - and whether
> >> it
> >> can
> >> be overridden per-website on a white-list or black-list basis.
> >> Personally - I think that anyone who REALLY wants to know who you
> >> are
> >> and who can coerce you into visiting their website can use timing
> >> tricks, roundoff-error detection and bug sniffing to gain more bits
> >> of
> >> information about you than VENDOR/RENDERER/VERSION could ever
> >> provide
> >> because they can also figure out the clock speed and memory
> >> capacity
> >> of
> >> your GPU.
> >> There are so many other information leaks in so many other
> >> subsystems
> >> that I'm 100% sure that this is a lost cause. eg:
> >> * CSS3: Does your computer have such-and-such font installed
> >> locally -
> >> or does it fetch it from the server?
> >> * Basic browser: How many bytes of data can we download - and then
> >> redownload without a server hit to sniff out your cache size
> >> settings?
> >> * Security settings: By probing your security settings I can find
> >> out
> >> what cookies you accept and deny - so the very act of turning on
> >> more
> >> privacy settings gives away more of your privacy.
> >> I can come up with these kinds of data-gathering tricks about as
> >> fast
> >> as
> >> I can type them in. How many do you think a black hat web expert
> >> could
> >> find in a month of concentrated effort?
> >> It's a lost cause - but as a salve to people's consciences - let's
> >> put
> >> a
> >> checkbox on the security page so that people can get a warm, fuzzy,
> >> false sense of security from it.
> >> -- Steve
> > -----------------------------------------------------------
> > You are currently subscribed to email@example.com.
> > To unsubscribe, send an email to firstname.lastname@example.org with
> > the following command in the body of your email:
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: