[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Information leakage and the extension regisrty.
----- Original Message -----
> > ----- Original Message -----
> >> If we are really serious about stopping information leakage then
> >> having
> >> even a few individual queryable extensions is a terrible idea -
> > Please, please, let's not have this discussion again!
> We don't have an acceptable answer yet...it's not "again".
> > So I'm *not* trying to have zero leakage. I'm just trying to keep
> > the
> > leakage limited. In this respect, it's relatively OK to have some
> > extensions and getParameter()'s. I'd be surprised if one could
> > extract
> > more than 5 or 6 bits from all that, because these things are
> > mutually
> > correlated.
> Look at this numerically:
> World Internet user population: 2 billion - 31 bits.
> Current Leakage: 20 bits.
> Available bits to avoid server-side evercookies: 10 bits.
I really can't afford to spend much more time in this discussion at the moment, so I'll try to be as synthetic as possible. I have 2 points to make.
Point 1. It's not realistic to try to give precise overall leakage figures and a precise threshold not to cross:
Ways in which "current leakage" may be OVERestimated:
* Here, panopticlick gives this 20 bits based on UA string in nightlies where the UA changes everyday. Not representative.
* panopticlick uses plugins, which personally I don't think I need to care about.
* panopticlick uses a too small dataset for its approach to be reliable (it's not hard to be unique among panopticlick visitors).
* therefore we don't really have data on the correlation between current leakage factors.
Way in which "current leakage" may be UNDERestimated:
* We haven't yet started accounting for JS timing attacks (and that would be a full time job)
* We haven't yet started accounting for GPU rendering analysis (not just WebGL: in the upcoming generation of browsers, most rendering goes through the GPU and is subject to GPU/driver/config-based rendering differences)
Ways in which the threshold (for server side cookies) may be OVERestimated:
* A given attacker may be interested only in a smaller population of targeted users.
Point 2. There is info leakage anyway, even without WebGL.
Explanation: see my above points about how current leakage may be underestimated (JS timing attacks, rendering analysis). Rendering analysis could proceed by rendering stuff into a canvas 2D and getting its ImageData.
Point 3. The additional leakage brought specifically by WebGL doesn't need to be very significant.
Explanation: since hardware-accelerated browsers leak some GPU info anyway, WebGL getParameter(MAX...) and (reasonable) extensions only leak a bit more of that.
One may argue that WebGL mandates use of the GPU while other content keeps it optional, but that's not really true, IE9 demos show canvas 2D apps that only get usable if you have good Direct2D acceleration.
the productive thing for me to do is to ensure that we don't leak significantly more info than we do anyways just by using the GPU (which is where browsers are going even regardless of WebGL). That's why not exposing RENDERER/VERSION is good enough for me right now.
I do agree that people will have to have a much more in-depth look at these issues sooner rather than later, but as far as I'm concerned, my current solution makes Firefox not leak much more info through WebGL than it does by general JS execution and HTML rendering, so there's no need to continue discussing that on this WebGL mailing list.
What I will do is that I will talk with JS engine people when I can. Implementing a 'privacy sensitive' bit on JS variables is the only way that I can conceive this whole problem getting fixed without crippling features.
> You're proposing to reduce the margin by 5 or 6 bits - meaning that
> bad guys can identify an individual down to one person in 16 to 32
> now, it's one person in 2048 or so). I believe that's an underestimate
> today...but let's suppose you're right.
> As the years go by that number will be eroded to zero by a combination
> (a) new WebGL extensions and (b) other browser features that'll leak
> information. Some of those - such as geometry shaders and the Mozilla
> extensions for touch-screen detection - are already coming - so pretty
> soon it won't be 5 to 6 bits but 7 to 8 - and other browser
> will push several more bits - and the game is over.
> If continue we work this way - we WILL lose the battle to avoid
> server-side evercookies within a year.
> So - we need to take a cold, dispassionate view here and either admit
> and stop with this business of shutting off important information to
> application - or we have to come up with a different way to represent
> hardware capabilities that hides MUCH more information - and permits
> future growth without more leakage. Tricks such as grouping a bunch of
> capabilities into one "level of performance" indicator that your
> either meets or doesn't meet...kinda like Microsoft do with DirectX
> versioning and "shader model N" and marking old hardware as "obsolete"
> order that we don't have to describe it to the application.
> > By contrast, the RENDERER/VERSION strings give 13 bits right
> > away, and moreover allow user categorization as Oliver noted.
> But once you've leaked more than just a couple more bits - that's
> irrelevant because you've already leaked enough to give away the farm.
> Rationally, we don't give a damn whether the total leakage is 31 bits
> or a
> thousand bits...but we (perhaps) do care if we can keep it down below
> (say) 24 bits.
> > Furthermore,
> > as Vladimir noted, the RENDERER string had the (to many people, even
> > more
> > important) problem that it was going to create a new
> > user-agent-string
> > epic.
> That's the way both DirectX and OpenGL have always worked on the
> desktop -
> and it hasn't caused any terrible grief as a result.
> > So I don't have a particular problem with extensions as they
> > currently are
> > looking like.
> I don't see how can you reconcile that view with the simple numerical
> truth above.
> -- 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: