[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Mozilla Persona and Tor
Tom or a number of us can intro you to Ben Adida there who would love to
discuss trade-offs/improvements in Persona. best, Joe
On Thursday, March 28, 2013, Mike Perry wrote:
> > 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
tor-talk mailing list