[tor-dev] IRC meeting to plan sponsor L milestones on Wed July 18, 15:00 UTC in #tor-dev

[Roger Dingledine]

On Thu, Jul 19, 2012 at 09:37:46AM +0200, Karsten Loesing wrote:
> here's a summary from talking about sponsor L deliverables in #tor-dev
> yesterday.

Thanks for working on this!

> To quickly recap what what the meeting was about: Sponsor L is very
> likely to happen, but the contract is not yet signed.  The contract is
> supposed to run from October 2012 to August 2013 and would have
> quarterly milestones.  The purpose of the IRC meeting was to get some
> developer feedback on the deliverables before negotiating and signing
> the contract.  The sponsor L wiki page is here:
> 
> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorL
> 
> Note that I'd like to add the (possibly revised) paragraphs below to the
> wiki page, so that they don't get lost in everybody's inboxes.  Please
> somebody let me know if that's a dumb idea.

You should definitely put them somewhere. But be sure to retain the
original text too, so we can go back and compare if we need to later.

> The phrasing of deliverable 1, which explicitly mentions "DNS" and
> "HTTP", is problematic.  George thinks that DNS and HTTP are hard
> transports to write properly.  George is okay with doing a stupid
> attempt at an HTTP transport, but he's not prepared to promise a "good"
> HTTP/DNS transport.  We should try to take out the words "DNS" and
> "HTTP" from the deliverable text.  If it's too late to do that, we
> should make sure that we can replace them with better transports, maybe
> after writing down why we think the transports we picked are better.  If
> the focus of this deliverable isn't just on building and deploying
> transports, George would prefer to take care of the pluggable transport
> ecosystem for future deployment: develop and deploy pyptlib and a Python
> transport or two; develop (and potentially deploy) obfs3; keep an eye
> out (and help) on academic research; help Zack with Stegotorus,
> especially if he is interested in porting it to Python.  We didn't talk
> about milestones, because the question of deliverable phrasing or
> internal interpretation needs to be answered first.

Helping with Stegotorus should count as working on an http transport, yes?
There are still a lot of barriers to having a good http transport, but
I think the prize is worthwhile enough that we should keep working to
reduce the number of barriers.

I think it would be worthwhile to explore how much of a mess it would
be to use DNS as a transport in practice. Does the bridge side need
to run a hacked nameserver on port 53? That sounds like a deployment
problem for some bridge operators (but not for others). More generally,
this topic like a great task to write up as a research problem for some
student to tackle.

For our "one more", we're already looking into pretending to be Skype
video as a transport (Skypemorph). It would be great to put some effort
into the deployment side of Skypemorph -- better READMEs, identify and
start fixing Tor issues like #5483, etc.

All of that said, I totally agree that for #1, we need to be sure Andrew
and the funder both understand that we can't promise that we'll deploy
any particular transport protocol -- the first step is research, and
that means step two must stay flexible.

> George and Nick say that, in order to complete deliverable 2, we'll have
> to finish #5040 which depends on #4773 (which overlaps with deliverable
> 3).  Nick thinks we can promise "progress towards" these two tickets for
> December, and aim to implement them in December, with a possibility of
> slipping to a March deliverable.  Then we'll have some time for
> obfsproxy bridges to report stats, so that Karsten can make graphs for
> June or August at the latest.

Sounds great. We should be sure to generalize what we do with obfsproxy
and metrics.tp.o, so it will be smoother to do for our next pluggable
transports (e.g. the ones we mention in #1 above). I think from #5040
and friends that it looks like this is already the plan?

Is "extended OR protocol" api support part of the planned python library
that Blanu and George are working on? If not, we should get it on
somebody's list.

> The remaining part of deliverable 3, minus #4773 which is part of
> deliverable 2, is to implement the safe-cookie authentication mechanism.
>  The same milestones apply here as to deliverable 2, so "progress
> towards" in December and "done" in March.

Ok.

> Deliverable 4 will already be done before the sponsor L contract would
> start.  It's promised for sponsor G for September 2012.  Aaron says that
> BridgeDB is ready, minus any tweaks we want to make, and a Tor 0.2.4
> build that people can run.  Aaron would like to get some public
> obfsproxy bridges running Tor 0.2.4 listed in bridges.tpo before end of
> September 2012.

I'd like to see that happen too.

We might also choose to say that "bridgedb remains running the whole time"
is a prerequisite for finishing deliverable 4.

>  We'll probably have to promise something else for
> deliverable 4.

Not really. In the research world, it is totally normal to 1) do X, 2)
ask for money to do X, 3) spend that money to do Y, 4) ask for money to
do Y, rinse/repeat. It's the only sane way to do long-term research on
predictable timelines. Or said another way, I think nobody will mind that
we've made great progress on the deliverable already, given that there's
plenty more work to do on the topic.

That said, now would be a great time to brainstorm some SponsorZ-style
items we'd like to do on this topic next, and plan to get those started
too (i.e. do the above step 3). The first thing that comes to mind is
having bridgedb know when some of its bridge addresses are blocked in
some countries.

> Deliverable 5 is totally doable, says Runa.  This deliverable involves a
> few substeps which we might derive milestones from: rewriting parts of
> the website is something we can do ourselves; planning some kind of
> campaign around the videos to be created and not just putting them out
> there is something we can do, too; writing screenplays for videos is
> something we'll have to do together with a partner; creating videos is
> something we'll have to find a partner for; starting the campaign is
> something we can do.

We should involve Karen in this discussion, since she's already doing some
sample videos, and she's a plausible fit for parts of the "tech writer"
role we describe. The question for Karen is how much of a distraction
it will be for her relative to her fundraising work.

We should figure out what Runa had in mind by "partner", and how much
of that we can do ourselves; there is currently no money in the 2012
budget for said partner.

> Deliverable 6 is doable.  Runa thinks she could either be the community
> manager by extending her tasks, or we could hire a new person.  She also
> has an idea who to hire for English, Farsi, and Arabic; there was a
> brief discussion between Runa and Nick about making an open call for
> these hires vs. only asking people we know.  Runa thinks that the trick
> for paid support is to find a way to let anonymous users pay for support
> and still make sure they get a reply in time according to the service
> level agreement we have to create.

Andrew is hoping to use this as an opportunity to explore "hire people who
will do great work and not charge American prices". Apparently our current
Farsi translator is one such person, and Andrew hopes we find more.

We have four separate directions in mind for this "community manager"
notion (not all funded by SponsorL, mind you):
1) Relay operator coordinator. Somebody to keep relay operators happy
and in touch with us, encourage people to set up new relays, organize
recommended configurations, etc. Especially important in tandem with our
"network diversity" work at #6232.
2) Volunteer-developer coordinator. Somebody to take incoming volunteers
and help them find good existing projects to work on. Likely involves
making our volunteer page more usable. Should also include knowing enough
about every project to recognize and identify good low-hanging fruit,
and knowing enough about our priorities to make smart decisions.
3) Blog/forum/mailinglist coordinator, to make sure our users have useful
answers, and ultimately to manage and organize the volunteers who make
sure our users have useful answers.
4) Social media person, to be our face on twitter, etc.

I believe the plan is for Runa to cover #4, and for us to contract
somebody in our relay operator community part-time for #1 to start. I
think there is no plan for #2 and #3 yet; but I'd love it if we could
get somebody part-time for #2.

>  Runa is wondering why we want
> funding for languages no one has emailed us in (Spanish and French);
> though nobody has emailed us in Arabic, either.

Countries like Venezuela are likely to be on more peoples' radar in
the coming years. As for French, a lot of North Africa can do French
better than they can do English. I bet that's at least partly the case
in Vietnam too.

> Deliverable 7 is doable.  Runa is somewhat unhappy that funding doesn't
> include Arabic.  She says a large number of our users speak either Farsi
> or Arabic, so not having funding for Arabic translations (and thus
> relying on volunteers) seems silly; if we have funding for Arabic
> support, we should also include Arabic translations.  Runa has an idea
> of who to hire for Farsi and Arabic translation, no idea about
> Vietnamese and Chinese (but can't be too hard to find someone).

There's totally time to write 'Arabic' into the list if we want. Note
that just because we promise more languages doesn't mean we get any more
money though.

Here's a list of languages the funder thought we might want to put on
the contract: "Arabic, Farsi, Mandarin, Vietnamese, Burmese, Spanish".

> We didn't talk about deliverable 8 at the meeting.  Maybe Mike can reply
> here and give some quick feedback on this deliverable with respect to
> phrasing/interpreting the deliverable text and possible tasks to promise
> for the four milestones?

One phrasing of this deliverable I've seen is "fix top 15
torbutton/torbrowser bugs as seen in ticket system". Mike wants somebody
who can jump into the Firefox code and bend it to our will. He posted
a job description at
https://www.torproject.org/about/jobs-browserhacker.html.en
and is waiting on Andrew and tor-exec to say "yes you can announce and
start interviewing". See other thread responses.

> Deliverable 9 substantially overlaps with Sebastian working on Thandy in
> Q3.  Sebastian is unclear whether his work will be funded by sponsor L
> money, and if not, what work remains to be funded by sponsor L.

I believe there's no funding specifically for Thandy work other than
this upcoming SponsorL contract. So I would guess Sebastian's Q3 work
was going to be this deliverable 9.

> Sebastian's plan for Q3 is that Thandy bundles should exist and work at
> the end of Q3, which is probably the hardest part of deliverable 9.
> Deliverable 9 further requires coordination between Vidalia and Tor with
> respect to updating config options.  Sebastian suggests to complete
> deliverable 9 by March 2013.  December 2012 would give us just three
> months of testing which may not be sufficient to make Thandy the new
> default distribution mechanism, but we also shouldn't push it back
> further than March 2013.  Aaron is also interested in working on Thandy
> and will talk to Sebastian about it.

Ok. This work does tie into SponsorJ's hopes that we'll be able to
automate builds for our bundles -- Thandy deployment without buildbot
and easy automated build and QA will leave us pretty frustrated. Maybe
that's what Sebastian meant when he talked about Q3 above.

We should also involve Nick in the discussion for deliverable 9, since
it's going to need bugfixes/etc on the Thandy code. And Tomas from the
Vidalia side.

> We didn't talk about deliverable 10 at the meeting.  Maybe Erinn or Jake
> can reply here and give some quick feedback on this deliverable with
> respect to phrasing/interpreting the deliverable text and possible tasks
> to promise for the four milestones?

I think what we have in mind here is a harness for running TBB on a
given OS in a VM, having it do some stuff, and then having an automated
way to see what changed on the system.

I think the funder would be satisfied if we hack together something to
do the comparison once per OS, and then write a report categorizing the
traces and describing what can be done about each.

But imo that would be a waste of the time/money, since it would cost the
same amount of time and money to do it a second time. Instead we should
focus on building a framework for running TBB and automatically noticing
regressions -- whether that's new traces left behind, or anonymity leaks
when you do a websocket query, or whatever. This topic clearly ties into
the "QA automation" topic.

--Roger