Re: Proposal: "private" execution mode

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