[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- To: "Mark Callow" <callow_mark@hicorp.co.jp>
- Subject: Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- From: steve@sjbaker.org
- Date: Wed, 1 Dec 2010 07:19:57 -0800
- Cc: "Kenneth Russell" <kbr@google.com>, "Benoit Jacob" <bjacob@mozilla.com>, "Steve Baker" <steve@sjbaker.org>, "public webgl" <public_webgl@khronos.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:subject:from:to:cc:mime-version:content-type: content-transfer-encoding; s=sjbaker.org; bh=42/Nw23qyibhiDEw6HE 7203nVaE=; b=AI3IHXQbLoKSoUTqABcUmWUHuYIOESNOrAwTIc/IPbETRV0o3Da 1CHinTbGZC6wBiND2o27G3g54bPIjeuV7Ah90xabIZFwX52A893IeAVuCJwA5oda 4DAat8cUWGH6H5mDU2FV7gn0q2Istu5nkr9INsbm2naHKTvNB7NWUeoY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :subject:from:to:cc:mime-version:content-type: content-transfer-encoding; q=dns; s=sjbaker.org; b=j0YRNIwZPv2tt AKTSlcXFxB/8RlyfnVDS7wft+10OsIwAMLA8j14yECzT1Vzu8/gnwcJVjBAO6xPU Q4WOUgC3an8QBLFyZLu07OjOsC3xu7H5XKk47jvfLmifeHin+ilNT/oGO6/HCRUB f/5BRXklANuI469QwAcpnQ2eXwR3dg=
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- Sender: owner-public_webgl@khronos.org
- User-agent: SquirrelMail/1.4.21
So if we think that there are ~10 bits of information leaked through the
VENDOR/RENDERER/VERSION strings - the important question is how much of
that is also leaked through gl.GetParameter and other easily testable
means?
If that number is anywhere close to 10 bits then simply disabling the
VENDOR/RENDERER/VERSION strings just makes life inconvenient for the good
guys without buying us anything in terms of privacy from the bad guys.
The only way to fix THAT would be to dumb everything down to the lowest
common denominator...and IMHO, that's suicide for WebGL...or at least for
whichever browser does it if others do not.
There certainly COULD be 10 bits of information here - but it's hard to
tell how much variability there is out there without doing some kind of
large-scale survey. Also, we don't know how well that correlates with the
other bits of data that can already be obtained. We'd also have to worry
that every time we introduce a WebGL extension (some of which are too
important to miss out on) or provide any other kind of optional feature,
that we're leaking more data. Adding extensions to WebGL would probably
be the strongest 'signal' we could be sending.
The values that seem most useful are:
ALIASED_LINE_WIDTH_RANGE, ALIASED_POINT_SIZE_RANGE,ALPHA_BITS
COMPRESSED_TEXTURE_FORMATS, DEPTH_BITS, MAX_COMBINED_TEXTURE_IMAGE_UNITS
MAX_CUBE_MAP_TEXTURE_SIZE, MAX_FRAGMENT_UNIFORM_VECTORS
MAX_RENDERBUFFER_SIZE, MAX_TEXTURE_IMAGE_UNITS, MAX_TEXTURE_SIZE
MAX_VARYING_VECTORS, MAX_VERTEX_ATTRIBS, MAX_VERTEX_TEXTURE_IMAGE_UNITS
MAX_VERTEX_UNIFORM_VECTORS, MAX_VIEWPORT_DIMS,
NUM_COMPRESSED_TEXTURE_FORMATS, NUM_SHADER_BINARY_FORMATS, SAMPLE_BUFFERS
STENCIL_BITS, SUBPIXEL_BITS
I still think this is too tough. Dumbing everything down to lowest common
denominator is too painful when that lowest common denominator is a
cellphone.
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: