[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Information leakage and the extension regisrty.



If we are really serious about stopping information leakage then having
even a few individual queryable extensions is a terrible idea - and we
need to stop this registry right now and do something different to
account for different levels of hardware capability without exposing the
details.  (eg we categorize hardware as: "WebGL Level 1", "WebGL Level
2", etc and every card has to fully support all of the features at it's
level and expose none of the others).

If we're not really serious about information leakage - then there is no
reason to cripple glGet and screw with the RENDERER/VERSION strings that
application authors will really benefit from.  If we're going to have an
extension registry then we should have those things fully and usefully
implemented on all browsers so that application writers can rely upon them.

Having a fat extension registry and NOT having RENDERER/VERSION strings
and accurate glGet returns is a half-assed hack.   It both cripples
WebGL *AND* leaks way too much information to the bad guys...it's the
worst of both worlds!

Having one major browser choose one of these two paths and the other one
taking the other is the beginning of the end.   Now you have two kinds
of WebGL that don't really work the same...well, maybe they do on
paper...but not as far as an application writer is concerned.

So one or the other please!

We need a clear outcome to the previous discussion about the
RENDERER/VERSION issue or we can't rationally move on to
what-goes-into-the-registry.  It's insanely counter-productive to have
one browser team not giving a damn about information leaks where the
other is going to cripple WebGL for the sake of it...leaving the poor
application developer to clean up the resulting mess by having to
support both.

We're heading directly towards a half-assed solution in which we leak
information bits whenever someone here thinks that some shiney new
feature is "worth it" - yet limit the kinds of routine information that
application authors need in the name of preserving web anonymity.  Yes,
I do agree that a floating-point texture extension is "worth it" - but
maybe I don't agree that half-float textures are "worth it".   We'll all
soon agree that geometry shaders are a "must have"...and so are texture
arrays...and so is multi-buffer shader output...and NPOT textures...but
maybe we don't agree about instancing.  Deciding what things make it
into a crippled registry and what doesn't (because the amount of
information leakage is a driving factor) is a truly nightmareish task.  
One man's "Must Have" is another mans'  "Meh...we can do without that". 
Scientific visualization folks will disagree with game writers who have
different needs to people who want to display interactive 3D models of
naked women ("Can haz subsurface scattering plz?").

If information leakage doesn't matter (eg because we can whitelist what
sites get to run anything more than the "lowest-common-denominator"
WebGL) - then we need full support for ALL of the information queries -
including RENDERER/VERSION.   If it does matter - then we can't have
something like this information registry because it'll leak enough bits
to make the entire discussion moot and we might as well have good
RENDERER/VERSION reports because it won't make any difference.

We know that we can't afford to leak more than a handful more bits
without giving away everything to the bad guy (The world Internet
population is around 2 billion...31 bits...and we already leak 20
bits)...but every new extension feature is some large fraction of a
bit.  Those bits are a strictly non-renewable resource - maybe four or
five more bits of leakage is safe?   But that's for the entire life of a
graphics chipset technology (10 years?) - and across ALL of the things
that browsers do...not just WebGL...(the features for detecting
multitouch screens leak more bits, so will support for cameras and
microphones, CUDA/physics hardware, you name it).

-- Steve

-----------------------------------------------------------
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: