[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12193 [Ponies]: Set up a Mozilla Persona testing server
#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@xxxxxxxxxxxx`
([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@xxxxxxxxxxxx`.)
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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs