[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 <email@example.com>
- Subject: Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Tue, 30 Nov 2010 22:25:53 -0800
- Cc: Steve Baker <email@example.com>, public webgl <firstname.lastname@example.org>, Mark Callow <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291184756; bh=uM8k4Qf3f+MEyZuOU8MLV4e/twE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=LNydeWSmC56t9JcIny1z7H0vLJn3krcxPDezjrWo81cXADn98CVhFZhxEJ2dl2Yp+ cyforQH2pL5NMHTRDopbg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WYV/DqaGLTEjpJz3SQYaMPMlAqIBKdQ+KEs7BLkdoiY=; b=WLOS7euhQjhyW1tPF/vB0mJakKM36acgCKdZs0IFlJdGXU5xdSAVYz7foZFmv84qVj 6Nt0tWbjjcrUfsbSd4FQ==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CxQ/jynzQWaAmuCH9MgjzagT8T92q5AzeplYdZ8wTrdo42iG10BOIgr4uwUOODf8pQ WfTqPmyP2MxyPL3XWwRQ==
- In-reply-to: <728363962.452246.1291171914300.JavaMail.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4CF5A3CE.email@example.com> <728363962.452246.1291171914300.JavaMail.firstname.lastname@example.org>
- Sender: email@example.com
On Tue, Nov 30, 2010 at 6:51 PM, Benoit Jacob <firstname.lastname@example.org> wrote:
> ----- 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. 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
>> 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.
>> Taking the second option may salve your personal conscience - but
>> realistically it allows 90% as much data leakage as option (1) and
>> 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
>> - and I'm pretty sure that if you do, you'll find that the problem
>> 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
>> - 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
>> 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
>> 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
>> 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
>> 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: