[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- To: Benoit Jacob <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- From: Steve Baker <email@example.com>
- Date: Tue, 30 Nov 2010 19:24:30 -0600
- Cc: public webgl <firstname.lastname@example.org>, Mark Callow <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=a1vq5 gnqNVdA9jbns0xn2bXZh/4=; b=iWTsr6J92o0hnnxGMNH90h+oa9L8wlRD7+AVI dhyW6ran5FyRqi+9luvlN03At16pvri6RIhOU5CWz512yhhiO2awwCGI/1JmJhyB yH7ZGNplNCBQpUeOf+8p7zGkyAxpKadsYq1t71SJEJN4PGwvx6Sy+6aNR98x6HP2 MWpSXo=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=Qo9nA0xdm9xOyD80i4TCYodYiXuQL2Zyr9BnIW62mWxAbpfgYnzjWupnXYCF2 Ofh1pyO7XcuG5QynFcVABoVLqbbYTDSYuadL/d2dbLHkxOsGYTFp30t1lsE72Zs1 /0zKKG971liq63bsyTq3xWP0xIRjsRP6++3gMKu26MmA/w=
- In-reply-to: <233976510.450587.1291159701944.JavaMail.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <233976510.450587.1291159701944.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
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.
> 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: your way where we get
poor graphics performance and marginally better protection against user
identification - or my way where the web becomes an exciting new
platform for games and we kick the crap out of Flash.
There are basically three options here:
1) Provide free access to useful VENDOR/RENDERER/VERSION by passing on
the OpenGL strings essentially without modification.
2) Close access to useful VENDOR/RENDERER/VERSION but continue to
provide useful information via glGet and other means.
3) Close access to useful VENDOR/RENDERER/VERSION and provide utterly
minimal settings via glGet (and never offer extensions - and limit the
context creation code to lowest-common denominator - and shut off every
single feature and metric that cannot be replicated identically on every
card in the world - note that this would require dumbing every desktop
computer down to 5/6/5 RGB).
Taking the third option gives you much less data leakage - but results
in even the nicest highest-end graphics card performing with a feature
set no better than the crappiest cellphone.
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
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.
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: