Re: Proposal: "private" execution mode

On Thu, Nov 28, 2013 at 11:44 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> Hi Eric,
>
> Replies inline.
>
>
> On 28/11/2013 2:22 PM, Eric Rescorla wrote:
>
> > Oops. Somehow pushed send too early.
> >
> > Correct version:
> > I don't believe that it is practical to build a system which provides the
> > desired security properties because it is generally so hard to prevent
> > information leakage. (I note that you don't describe how the browser
> > would do so.)
>
>
> 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.


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


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

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.

-Ekr

Received on Thursday, 28 November 2013 21:34:23 UTC