[tor-bugs] #12193 [Ponies]: Set up a Mozilla Persona testing server
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Oct 25 07:28:36 UTC 2014
#12193: Set up a Mozilla Persona testing server
---------------------------+---------------------------------------------
Reporter: mikeperry | Owner: isis
Type: project | Status: needs_review
Priority: major | Milestone:
Component: Ponies | Version:
Resolution: | Keywords: SponsorP, TorBrowserTeam201410D
Actual Points: | Parent ID:
Points: |
---------------------------+---------------------------------------------
Comment (by isis):
Replying to [comment:12 isis]:
> I'm also inclined to believe that this is a blocker, meaning "there is
no feasible way that we could ever actually use and massively deploy
Persona to allow for 'anonymous' logins". Any real deployment of whatever
we could build out of Persona's scraps of code is either going to result
in RPs 1) sending Tor users to login.persona.org, or 2) being forced to
source our JS.
To expand upon my previous statement above, the previously mentioned
problem essentially boils down to forcing us to choose between one of two
options for real-world deployment:
== Option 1 ==
We would need to accept that our so-called "anonymous" users would be sent
from the website they are trying to log into (Wikipedia, for example) to
https://login.persona.org, and that the latter would speak to the Tor
Project IdP.
There is not even remotely a chance for even pseudonymity, if we went this
route, as the https://login.persona.org server could:
- Log which websites a Tor user tries to log into,
- Log when a Tor user tried to log into or out of any website,
- Potentially link a user's pseudonyms (yes, even if we handed out
blinded signatures in our credentials),
- Arbitrarily decide to block all Tor users without the consent of
either Wikipedia or the Tor Project IdP,
- and probably a bunch of other horrible stuff.
== Option 2 ==
We would need to try to force every single website that wants to allow
anonymous users to login to source custom Javascript that we make
available, which is specific to allowing logins from our IdP.
[https://github.com/isislovecruft/browserid-
certifier/blob/master/srv/login.persona.torproject.org/document_root/include.js
Our custom Javascript] would be specific to allowing logins from our IdP.
Overall, it means we'd be expecting everyone on the internet (including
every other Persona server) to trust us, and/or we'd break half the things
for half the people (by "people", I mean "anyone using Persona whether
they are using our primary IdP or someone else's").
For example, if we went this route, and put the Tor Project IdP at
https://persona.torproject.org, and we convinced Wikipedia to use our code
on their login page, this would mean:
'''ex. 1A1: Alice the Mozilla employee tries to log in to Wikipedia
using Persona.'''
She would be sent to https://login.persona.torproject.org where she'd
enter `alice at mozilla.org` into the email input field. Our IdP would talk
to https://persona.mozilla.org to determine if Alice's credential is
valid.
'''RESULT:''' The website's login works successfully, but the Tor
Project Persona IdP gets to know a lot of details about Alice that it
really shouldn't be allowed to know.
We could, of course, add some error handling around our customised
Javascript which makes the file only actually get sourced for Tor Browser
users. One might naïvely think that this would fix Alice's example above.
If we continue trying to use Persona, and we continue to try to use our
own primary IdP, we would need to set, by default, the following Tor
Browser preference: {{{dom.identity.enabled true}}} to enable Firefox's
native Persona code. This causes the `navigator.mozId` attribute become
available, [4] and causes, on a Persona-enabled site, the `navigator.id`
attribute to be missing. All current Persona-aware websites source the
official Mozilla Persona Javascript. Mozilla's documentation states that
`navigator.id` is a "fallback implementation of `navigator.mozId` for
compatibility", but the two appear to be entirely incompatible. I tried
everything to get the two implementations to play nicely together; I
tested both variants for the Tor Project IdP that I created, with every
variant of revelant preference settings; I eventually dug around through
Firefox's source code, and realised the two were incompatible, and then
asked questions in both `#identity` and `#developers` on irc.mozilla.org.
Therefore, because we must set the `dom.identity.enabled` pref, and every
Persona-aware site on the internet uses the official Mozilla Javascript,
we would be completely, entirely incompatible with the rest of Persona
infrastructure on the internet (and likewise make the rest incompatible
with us). Half the sites would be broken for half the people, all the
time. What I'd consider to be privacy violations would happen on both
sides, and end-user usability (as if Persona weren't already unusable
enough for providers and websites) starts to drop into the GnuPG range.
To demonstrate how broken this would make absolutely everything, let's
look at another set of examples! These examples are exactly the same as
example '''1A1''', except now, Wikipedia is using our "improved" custom
Javascript which has some error handling. Said Javascript it only ever
fully executes for Tor Browser users, and for regular Firefox users it
displays a message saying that they need to toggle a preference. Amazon is
also in the game now, except that they're running the official Mozilla
Persona Javascript.
'''ex. 2A1: Alice from Mozilla (meaning they have an `@mozilla.org`
account, or an `@persona.org` account) uses Tor Browser to log in to
Wikipedia.'''
She clicks the friendly `Login with Persona` button, and everything in
example '''1A1''' happens in exactly the same way. The Tor Project gets a
record of Alice's browsing habits, and the "horrible things" from Option
!#1 above would happen, except with the tables turned.
(Unless she also has, or registers for, an
`alice at persona.torproject.org` account, then she could use that to log in
without the Tor Project IdP talking to the Mozilla server... but then that
case would be example '''2B1'''.)
'''RESULT:''' The website's login works successfully, but the Tor
Project Persona IdP gets to know a lot of details about Alice that it
really shouldn't be allowed to know.
'''ex. 2A2: Alice from Mozilla uses regular Firefox (or, anything not TBB)
to log in to Wikipedia.'''
She clicks the friendly `Login with Persona` button, and nothing
happens. Well, almost nothing; our [https://github.com/isislovecruft
/browserid-
certifier/blob/master/srv/login.persona.torproject.org/document_root/browserid/signin.js#L70
error handler does something] like displaying a message which explains
that she needs to toggle a browser preference.
'''RESULT:''' The website is effectively broken.
'''ex. 2A3: Alice from Mozilla uses Tor Browser to log in to Amazon.'''
She clicks the `Login with Persona` button, and nothing happens. Well,
almost nothing; a single error message goes to her TB WebConsole:
"TypeError: navigator.id is undefined", but she'll probably never see it.
'''RESULT:''' The website is completely broken.
'''ex. 2A4: Alice from Mozilla uses regular Firefox to log in to
Amazon.'''
She clicks the `Login with Persona` button, and she's sent to
https://login.persona.org where she uses her `alice at mozilla.org` account
to log in.
'''RESULT:''' Everything's fine.
'''ex. 2B1: Barbara the Tor user (meaning they have an account with the
Tor Project IdP) uses Tor Browser to log in to Wikipedia.'''
She clicks the `Login with Persona` button, and she's sent to
https://persona.torproject.org where she uses her
`barbara at persona.torproject.org` account to log in.
'''RESULT:''' Everything's fine.
'''ex. 2B2: Barbara the Tor user uses regular Firefox to log in to
Wikipedia.'''
She clicks the `Login with Persona` button, and our error handler
displays a message which explains that she needs to toggle a browser
preference in order to log in to Wikipedia.
'''RESULT:''' The website is effectively broken.
'''ex. 2B3: Barbara the Tor user uses Tor Browser to log in to Amazon.'''
She click the `Login with Persona` button, and Amazon tries to send
her to https://login.persona.org, but can't. The button doesn't do
anything, and Barbara can't log in because her browser has the
`dom.identity.enabled` preference set. Somewhere in her TBB WebConsole,
there's an error message that says: `TypeError: navigator.id is
undefined`, but Barbara probably won't see it.
'''RESULT:''' The website is completely broken.
'''ex. 2B4: Barbara the Tor user uses regular Firefox to log in to
Amazon.'''
She clicks the `Login with Persona` button, and she's sent to
https://login.persona.org where she uses her
`barbara at persona.torproject.org` account to log in. The Mozilla Persona
IdP gets a record of Barbara's browsing habits, and the "horrible things"
from Option !#1 above would happen.
'''RESULT:''' The website's login works successfully, but the Mozilla
Persona IdP gets to know a lot of details about Barbara that it *super*
shouldn't be allowed to know.
-------
I think we can all agree that Option !#1 is unacceptable.
I hope we can also agree that Option !#2 is never going to happen. Even
if it did happen, we don't want to be a single point of failure for other
Persona-aware things on the internet, nor do we want become the internet
equivalent of the Berlin Wall. Additionally, if we actually expect online
services to be sourcing our code, and we're insane enough to think this is
deployable, scalable, maintainable, and a good idea, why limit ourselves
to work within Persona's constraints and deal with their vaporware and
mistakes? We could just as easily start from scratch, write our own thing
the way we would like to see it done.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12193#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list