[tor-bugs] #12193 [Ponies]: Set up a Mozilla Persona testing server

[Tor Bug Tracker & Wiki]

#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:             |
---------------------------+---------------------------------------------
Changes (by isis):

 * status:  assigned => needs_review


Comment:

 Another potential problem: Persona is not "decentralised". It's pseudo-
 federated and semi-centralised.

 Any Relying Party (RP; a.k.a the third-party site that wishes to allow
 their users to login via Persona) must source an `include.js` file. There
 can only one ''primary'' IdP at a time, as the `ipServer` in these
 `include.js` files is hardcoded.

 As such, for a RP to send its users to different IdPs, the RP would need
 to dynamically source different `include.js` files, depending on the IdP
 specified by the user.  To my knowledge, no sites which support logging in
 through Persona have implemented this, meaning that ''all Persona-aware
 sites currently on the internet are hardcoded to send users to
 https://login.persona.org'', https://login.anosrep.org, or
 https://login.dev.anosrep.org.

 To see this in action:

   1. Install the RequestPolicy Firefox plugin and configure it to use full
 addresses/domains.
   2. Configure NoScript to deny everything by default.
   3. Go to http://beta.123done.org, which is an example RP which uses
 Mozilla's Persona staging server (https://login.anosrep.org) as its IdP.
   4. Open up the WebConsole and reload the http://beta.123done.org page.
   5. Allow scripts from http://beta.123done.org. (You still won't have
 beta.123done.org's `include.js` file because they remotely source it.)
   6. Allow requests from http://beta.123done.org to
 https://login.anosrep.org, and reload.
   7. Allow scripts from https://login.anosrep.org. (You've now loaded the
 `include.js` file.)
   8. At this point, if you have the `dom.identity.enabled` pref set to
 `true` (meaning you prefer that Persona implementations use Firefox's
 native `navigator.mozId` code, rather that the `navigator.id` fallback JS
 code) you must set it to `false`. The choice of whether or not to use
 native code versus JS is also not up to the user, and the two appear to be
 incompatible. If you had to change the pref, reload the
 http://beta.123done.org page. (This would seem to imply that the so-called
 "fallback" code isn't really a fallback, as once the pref is disabled,
 entering `navigator.mozId` into the WebConsole will return `null`.)
   9. Go to the "Other origins" RequestPolicy menu and allow requests from
 https://login.anosrep.org to https://static.login.anosrep.org, and reload.
 (You should now see a `Sign in…` button.)
   10. Click the `Sign in…` button. (You should now have either a new
 window/tab which loads https://login.anosrep.org/sign_in.)
   11. Go to the "Other origins" RequestPolicy menu and allow requests from
 https://static.login.anosrep.org to https://login.anosrep.org, and reload.
 (Hooray! Your tab/window now magically closes because Persona expects you
 to allow sourcing shit from all over the web. Sorry for all the steps,
 and, yes, this one is the fault of RequestPolicy, but it's important to
 understand what's actually happening.)
   12. Do Step !#10 again.
   13. In the new/window tab that has opened, type `whatever at mockmyid.com`
 ([https://github.com/callahad/mockmyid mockmyid] is an IdP which
 automatically signs `*@mockmyid.com` without authentication) into the
 `email address` input field. Click `next`.
   14. Allow requests from https://login.anosrep.com to
 https://mockmyid.com, and reload. (Hooray! Again! Your tab/window is
 gone!)
   15. Do Steps !#10 and !#13 again.
   16. Go to the "Other origins" RequestPolicy menu and allow requests from
 https://mockmyid.com to https://login.anosrep.org, and close the
 tab/window. (At least this time there's a error page...)
   17. Do Steps !#10, and !#13, again. (Finally, the tab/window says you're
 logged in, closes itself, and you're back on the http://beta.123done.org
 page logged in as `whatever at mockmyid.com`.)

 I've implemented a Persona IdP at https://https://93.95.228.166/. It's
 probably still buggy but I can't test further because we need a domain and
 valid^Wpurchased certificate for it. It's similar to mockmyid.com, except
 even more lenient, in that it currently signs literally ''anything''.

 If you want to imagine the "under-the-hood" (assuming they don't block
 scripts and aren't using RequestPolicy) steps taken for our users to login
 to the RP (Wikipedia for example), then (assuming we've talked Wikipedia
 into sourcing our `include.js` file) do
 `'s/beta\.123\.org/wikipedia\.com/'` and
 `'s/login\.anosrep\.org/93\.95\.228\.166/'` on the above steps.

 I'm honestly a bit ashamed for Mozilla that they designed something so
 horrible.

 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.

 Opinions? Is this a blocker? Should I move forward with this thing?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12193#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online