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: > Thus spake NoName ([email protected] <javascript:;>): > > > 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: > > https://github.com/mozilla/id-specs/blob/prod/browserid/index.md#web-site-signin-flow > > This page is also interesting: > https://developer.mozilla.org/en-US/docs/persona/Crypto > > > 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 > awesome. > > 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 > -- https://josephhall.org/ _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
