Re: Proposal: "private" execution mode

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. I don't doubt that this will require a lot of work, but it's 
less man-hours in the grand scheme of things. That being said, if this 
proposal doesn't really prevent fingerprinting then the amount of work 
involved is not really relevant. More on this below.

>>> Now, I haven't leaked any data directly, but I've just created a timing
>>> channel that returns the resolution profile. Obviously, this would be harder
>>> if there was >1 device, but there are ways to deal with that as well.
>> Are there well-understood ways of tackling timing channels? Google certainly
>> brings up many whitepapers on the topic.
> Yeah, it's super-hard--and this isn't the only side channel, just
> the most obvious one. Basically, stopping covert channels is
> incredibly hard.
>
>
>> I am no expert, but couldn't the
>> browser reduce the effectiveness of this technique using
>> setTimeout(onSuccess, random) instead of invoking onSuccess immediately?
> 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?

>> 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? :) If so, I agree with 
you that it's virtually impossible to prevent fingerprinting attacks.

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

Gili

Received on Thursday, 28 November 2013 22:14:56 UTC