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: 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk