- From: Eric Rescorla <ekr@rtfm.com>
- Date: Thu, 28 Nov 2013 14:18:25 -0800
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Thu, Nov 28, 2013 at 2:13 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > On 28/11/2013 4:33 PM, Eric Rescorla wrote: >>> >>> I thought I did...? Any method that could be used to leak data (e.g. >>> XMLHttpRequest.send()) would throw a permission denied error when invoked >>> in >>> "private" mode. >> >> That's not a description. It's an open-ended invitation to individually >> study each API point. Given how much effort it has taken to just >> get a sense of (and not remove) the fingerprinting surface, I'm >> not sanguine this can be done in finite time. > > > There are only a limited number of native API functions implemented by the > browser that needs to be secured, versus an unlimited number of user-defined > functions that would benefit from fingerprinting protection. Limited but very large. And this would mean that every new function we add needs to be audited for this. >> Well, at the cost of making things slower for the user. Also, this >> depends on (among other things) whether we also rate limit calls >> to gUM and how much random padding you add. > > > Wouldn't the same be true for the attacker? Meaning, by forcing them to > resort to timing channels, aren't we substantially slowing down > fingerprinting-related attacks? The problem is that it's different time scales. Stalling the user for a second is a big deal, but stalling the attacker for 10 seconds not so much, as he can run fingerprinting on people in parallel. >>> We could look at further restricting the calls that would be legal within >>> "private" mode, though obviously I'd prefer to avoid this if possible. >> >> What calls? The example I provide doesn't use any API calls at >> all. I'm just using SHA-1 to chew up the CPU, so it can be inlined >> perfectly well. > > > At the limit, you could prevent the function from invoking any other > function. You could still use control structures and the comparison > operators. I'm going to go out on a limb and guess that you can use those to > stage timing channel attacks as well? :) Of course. If I can do mathematics and control, I can chew up CPU. >> More importantly, this seems to be a solution in search of a problem: >> all the available evidence is that it's not practical to remove >> fingerprinting >> surfaces from the browser in general. Given that, why spend a lot of >> time trying to file off this particular one. > > > Well, to be fair, I'm targeting all of WebRTC, not just a single API point. > > Furthermore, this argument cuts both ways. If it isn't practical to remove > fingerprinting surfaces, why are we attempting to do exactly that for this > particular API point with Jan-Ivar's proposal? I believe that's what I said previously. :) -Ekr
Received on Thursday, 28 November 2013 22:19:33 UTC