Author: atagar Date: 2013-04-28 21:50:53 +0000 (Sun, 28 Apr 2013) New Revision: 26172 Modified: website/trunk/getinvolved/en/volunteer.wml Log: EFF Project Ideas for GSoC and OPW Adding Peter's project ideas for this year's GSoC and OPW. Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2013-04-28 14:24:33 UTC (rev 26171) +++ website/trunk/getinvolved/en/volunteer.wml 2013-04-28 21:50:53 UTC (rev 26172) @@ -1343,7 +1343,126 @@ </p> </li> + <a id="reportingBuggyRulesets"></a> <li> + <b>Automated Reporting of Buggy Rulesets</b> + <br> + Effort Level: <i>Medium</i> + <br> + Skill Level: <i>Medium</i> + <br> + Likely Mentors: <i>Peter Eckersley (pde), Seth Schoen</i> + <p> +When users manually disable an HTTPS Everywhere ruleset via the toolbar menu, +that's a strong hint that that ruleset might be buggy. If we could obtain +statistics about which rulesets are manually disabled by the users of which +HTTPS E versions, we could get a statistical picture of which rulesets need +the most urgent debugging and/or disablement. This would enormously improve +the quality of the HTTPS Everywhere user experience. + </p> + + <p> +HTTPS Everywhere already includes a pipeline for anonymised user submissions +(via Tor where available) that is used for the Decentralized SSL Observatory. +We should do a popup that asks the users to submit anonymous reports of +disabled rules, when they manually disable one for the first time. + </p> + + <p> +Perhaps this feature could optionally let users submit the URL of the page +they were looking at when the bug occurred, although we would need to take +care in handling those, and perhaps implement some countermeasures against +sending passwords or auth tokens when URLs contain those. + </p> + </li> + + <a id="httpsEverywhereForFirefoxModile"></a> + <li> + <b>Port HTTPS Everywhere to Firefox Mobile</b> + <br> + Effort Level: <i>Medium</i> + <br> + Skill Level: <i>Medium</i> + <br> + Likely Mentors: <i>Peter Eckersley (pde), Seth Schoen</i> + <p> +In the past a Firefox Mobile port of HTTPS Everywhere was made impractically +complicated by the Electrolysis threading architecture used in that variant of +Firefox (<a href="https://trac.torproject.org/projects/tor/ticket/2471">ticket</a>). However with +the implementation of the simple NSIHTTPChannel.redirectTo() API in Firefox +20+ (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=765934">ticket</a>) we are probably very +close to having a trivial port of HTTPS Everywhere to Firefox on Android. + </p> + + <p> +This would make a great GSOC project for someone who'd like to learn some +introductory skills with hacking on the internals of real web browsers! + </p> + </li> + + <a id="httpsEverywhereMixedContentHandling"></a> + <li> + <b>HTTPS Everywhere mixed content detection and handling</b> + <br> + Effort Level: <i>Medium</i> + <br> + Skill Level: <i>Medium</i> + <br> + Likely Mentors: <i>Peter Eckersley (pde), Seth Schoen</i> + <p> +Since version 20, Chrome has automatically blocked the loading of insecure +HTTP scripts and CSS in HTTPS pages. Firefox version 23 will do the same. +This is good security practice, but it causes havoc with many sites where +HTTPS Everywhere can secure some, but not all, of the site's content. + </p> + + <p> +Before Firefox 23 launches, we will need a more coherent plan for detecting +sites where we are causing these mixed content situations, and either +disabling or working around the limitation. Failure to do so will mean that +HTTPS Everywhere user experience worsens dramatically when Firefox 23 is +released. Success will mean a dramatic improvement in user experience with +HTTPS Everywhere for Chrome. + </p> + + <b>Critical-path tickets:</b> + + <ul> + <li><a href="https://trac.torproject.org/projects/tor/ticket/6975">6975</a></li> + <li><a href="https://trac.torproject.org/projects/tor/ticket/8664">8664</a></li> + <li><a href="https://trac.torproject.org/projects/tor/ticket/8776">8776</a></li> + </ul> + + <b>Related tickets:</b> + + <ul> + <li><a href="https://trac.torproject.org/projects/tor/ticket/3777">3777</a></li> + <li><a href="https://trac.torproject.org/projects/tor/ticket/6977">6977</a></li> + </ul> + </li> + + <a id="httpsEverywhereRulesetTesting"></a> + <li> + <b>Incorporate Ruleset Testing into the HTTPS Everywhere release process</b> + <br> + Effort Level: <i>Medium</i> + <br> + Skill Level: <i>Medium</i> + <br> + Likely Mentors: <i>Peter Eckersley (pde), Seth Schoen</i> + <p> +Ondrej Mikle has implemented a codebase for testing HTTPS Everywhere rulesets +by crawling pages that are affected by the ruleset (<a href="https://github.com/hiviah/https-everywhere-checker">repository</a>). + </p> + + <p> +This codebase still has some rough edges that need to be smoothed over, but +once those are done it should be incorporated into the HTTPS Everywhere build +process, in order to improve the quality of our releases. + </p> + </li> + + <li> <b>Bring up new ideas!</b> <br> Don't like any of these? Look at the <a