[tor-dev] Your 'Relay Web Status Panel' GSoC idea (was: r26589: {website} Adding 'Relay Web Status Panel' Adding a project I'm interes (website/trunk/getinvolved/en))

[Karsten Loesing]

Hi Damian,

this sounds like a fun project and a great GSoC project idea!

Some quick feedback: Have you considered suggesting this relay web 
status panel for a possible Torouter?  I could imagine making this the 
primary interface for a little Torouter box, so that people don't have 
to ssh into it or install a desktop application to connect to it.

Which brings up two my questions: why not make this a "relay web status 
and *control* panel"?  Are the security risks really that much higher 
compared to using arm?  And if you distrust the web server part of this 
design, how do you prevent an attacker from breaking into the web server 
and abusing the controller connection to reconfigure the relay?

And question number two: why not make this a "relay and *client* web 
status and control panel"?  In the Torouter case, people might want to 
use their tor only as a client to route all their connections through 
tor.  Think of a little box that provides wifi access to nearby 
strangers but tunnels everything through the local tor client to avoid 
legal trouble.  Or, if strangers need anonymity, the guy running the box 
could configure it as (private) bridge and mention the address on its 
local website for strangers to use with their own tor client.

I'm not at all suggesting to include all this in the GSoC project.  But 
maybe these ideas could be mentioned or kept in mind?

Looking forward to seeing this happen!

All the best,
Karsten


On 05/02/14 18:01, Damian Johnson wrote:
> Author: atagar
> Date: 2014-02-05 17:01:31 +0000 (Wed, 05 Feb 2014)
> New Revision: 26589
>
> Modified:
>     website/trunk/getinvolved/en/volunteer.wml
> Log:
> Adding 'Relay Web Status Panel'
>
> Adding a project I'm interested in mentoring this summer.
>
>
>
> Modified: website/trunk/getinvolved/en/volunteer.wml
> ===================================================================
> --- website/trunk/getinvolved/en/volunteer.wml	2014-02-05 03:18:48 UTC (rev 26588)
> +++ website/trunk/getinvolved/en/volunteer.wml	2014-02-05 17:01:31 UTC (rev 26589)
> @@ -629,6 +629,7 @@
>       <p>
>       <b>Project Ideas:</b><br />
>       <i><a href="#txtorcon-stemIntegration">Txtorcon/Stem Integration</a></i><br />
> +    <i><a href="#relayWebPanel">Relay Web Status Panel </a></i><br />
>       </p>
>
>       <a id="project-txtorcon"></a>
> @@ -917,6 +918,53 @@
>       bonus points if it's Twisted.</p>
>       </li>
>
> +    <a id="relayWebPanel"></a>
> +    <li>
> +    <b>Relay Web Status Panel</b>
> +    <br>
> +    Effort Level: <i>Medium</i>
> +    <br>
> +    Skill Level: <i>Medium</i>
> +    <br>
> +    Likely Mentors: <i>Damian (atagar)</i>
> +    <p>
> +    Relay operators presently have a couple options for monitoring the status
> +    of their relay: <a
> +    href="https://www.torproject.org/getinvolved/volunteer.html.en#project-vidalia">Vidalia</a>
> +    which is a gui and <a href="https://www.atagar.com/arm/">arm</a> which uses
> +    curses. This project would be to make a new kind of monitor specifically
> +    for relay operators that provides a status dashboard site on localhost.
> +    </p>
> +    <p>
> +    The interface will likely <a
> +    href="https://www.atagar.com/arm/screenshots.php">borrow heavily from
> +    arm</a>, except of course in areas where we can improve upon it. Two
> +    important design constraints is that a localhost controller provides a
> +    bigger attack surface than guis or curses, so we should be a little more
> +    wary of what it does. This should be a read-only controller (ie, you can't
> +    *do* anything to the relay) and by default not surface any sensitive
> +    information (such as arm's connection panel).
> +    </p>
> +    <p>
> +    This project will likely include two parts: an AJAX site and a localhost
> +    daemon to fulfill those requests. <a
> +    href="https://stem.torproject.org/">Stem</a> is the backend of arm, and can
> +    be used to get everything you see in arm's interface (making it a natural
> +    choice for the daemon). That said, this project might entail some Stem
> +    improvements if we run across any gaps.
> +    </p>
> +    <p>
> +    Applicants should be familiar with Python, JavaScript, and learn about
> +    <a href="https://stem.torproject.org/">Stem</a>. <b>As part of your
> +    application for this project please make both mockups of the interface and
> +    a proof of concept demo application using JS to surface something with
> +    Stem. <a
> +    href="https://trac.torproject.org/projects/tor/wiki/doc/stem/bugs">Involvement
> +    with Stem development</a> during the application process is also a big
> +    plus.</b>
> +    </p>
> +    </li>
> +
>       <a id="httpsImpersonation"></a>
>       <li>
>       <b>HTTPS Server Impersonation</b>
>
> _______________________________________________
> tor-commits mailing list
> tor-commits at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
>