[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Mozilla Persona and Tor

Thus spake NoName (antispam06@xxxxxxx):

> Myself I'm quite happy with OpenID. I have been using it for a few
> years and I am sad it has not expanded as I don't use FB and I have
> some doubts about Twitter being any better than FB.
> I have heard in the past about Persona. Actually BrowserID. It
> sounded like a bad idea, but I can't recall why I have set this
> oppinion.

I actually really like the privacy properties Persona *could* provide in
theory. In theory, it can solve most (or maybe even all) of the problems
we have with third party identity providers today.

There seem to be some wrinkles in practice, though.

> Today I went to a site that requires registration. This is not the
> New York Times, so no need of Bug Me Not. It asks for FB (out of the
> question), MSN (out of the question), Google (limited number of Tor
> accounts) or Persona. I would not sacrifice the Google account.

I'm glad that it is seeing use, but I'm not sure exactly how, since
navigator.id (where its browser-side API is supposed to live) doesn't
exist in any browsers I have installed, including Firefox 19.

> So how does Persona relate with Tor? Would New Identity be enough?
> Could it be safely used while browsing other sites without making
> TorBrowser sing to the other sites? Is there a restart imposed?
> Could it survive the way LSOs from Flash survive the restart?

Here's the best documentation I've found that gives you an idea of what
happens when a site deploys Persona:

This page is also interesting:

From my perspective the most important properties of Persona are:

1. In theory, the identity provider does not discover the sites that you
visit. It merely issues a signed statement that your browser stores to
later present to websites. If this property holds, it's quite awesome.

2. Sites that you visit do not get to inspect which identity statements
you have installed. The user is prompted to send the site either zero or
one of their potentially many signed identity statements. This is also

3. From my read of the spec, there also seems to be no technical reason
why the identity provider can't be kept offline -- except for the fact
that they recommend user certificate expiration times on the order of 24
hours for some reason (which introduces potentially serious privacy
problems. See below).

The first two properties make me think that if the user is allowing disk
history records, there should be no remaining content-facing privacy
reasons that prevent these certs from being stored and persisting
forever (or until the user deletes them). That is also pretty awesome.

However, the following general privacy issues seem to exist with the
specific deployment and implementation that the spec seems to suggest:

0. Can sites determine if I have at least one identity statement? Do the
APIs behave differently in this case? Perhaps this is why I don't have
navigator.id, for example? If so, that's a fingerprinting bit. From the
point of view of the website, the APIs should behave identically
regardless of how many certificates I have, even if I have zero. (Note
this doesn't mean that what the user actually sees has to be the same in
that case).

1. Why do users have to get their certs re-signed by the Identity
Provider every 24 hours? This means the Identity Provider gets to know
which of their users are using the web on a given day, and from which IP
addresses. Worse, the specs seem to suggest this re-signing should
happen transparently in the background without user input. That means by
installing an identity cert, you are actually handing over your daily IP
address history to your Identity Provider, regardless of how frequently
you really want to interact with them. Even worse, if the Identity
Provider sets lower cert expiration times, it seems that they would get
even higher resolution IP address data, perhaps down to the minute!

2. What authenticates an Identity Provider to a website? If their IdP
certs have to be signed by the CA model, that kinda sucks, but at least
authentication could still be done offline. However, if their certs have
to be fetched by the authenticating site over CA-authenticated HTTPS,
that *really* sucks (because it damages privacy property #1 - identity
providers would know if at least one of their users visited a site). It
would be nice to have both options.

3. The combination of issues 1 and 2 might actually completely destroy
the main privacy benefit of Persona. Ie: the identity provider may still
be able to infer which sites each of their users is visiting, especially
over a number of days of repeated activity, and especially for smaller
identity providers (or malicious providers that set very low cert
expiration times for both user certs and their own IdP certs).

I guess I probably should bring these issues up with someone at Mozilla
before it's too late..

Mike Perry

Attachment: signature.asc
Description: Digital signature

tor-talk mailing list