S27: Onion Services Project Planning

Coordinating the work on Onion Services

Facilitator(s): pili

Audience: Network team, UX team, Browser, mcs/brade, syverson, httpse, namecoin, mozilla?

Duration: 1 hour

Prep

Topics for discussion:

• Revising, evaluating and acknowledging S27 roadmap
• Discussion on vague S27 topics: O2A3 (redirects) and O2A5 (naming)
• Identifying future blockers between teams
• Available time of TB team during ESR68 transition
• Mapping S27 features/deliverables to Tor Browser and tor releases

And maybe:

• Subsequent funding for onions after S27 is done (probs not the right session)

Desired outcomes:

• Making a decision on some of the alternatives we have been exploring for O2A3, e.g naming space, prioritizing onions in tor browser, suggesting onions in tor browser
• Rough plan of releases for S27 deliverables

** Rough Agenda: **

• Where are we right now?
  • Updates from teams
    • What is done-done (if anything :) )
    • What is in progress?
    • What is next
  • Is there anything we can bill for (at least 50% completed)?
• Review S27 Roadmap
  • What are the different teams going to work on in the next few months
  • Any dependencies?
    • e.g when is the next tor alpha containing some of these changes going to be released?
• Can we start mapping features to releases?
• Discussion on vague S27 topics: O2A3 (redirects) and O2A5 (naming)

Notes

Status reports:

George (asn): - Helping Brave with doing thec lient auth. Took much more time than expected Worked a lot of DoS stuff. Still much to do.

antonela shows mockups: - Working on authentication password field - Notify users if the current website has an onion version for onion-redirect [horziontal line // preferences] - Better client side errors

mcs/brade: - client auth went down rabbithole - we know how to do the plumbing to get the errosr out of the browser - optimistic data (if the tor daemon starts sending data, firefox gets confused and errors dont get displayed (?))

Dependency:

• Fix the timeout issue before September.
• An alpha 043 before October 22nd.
• Optimistic data work is gonna happen when?
• Error stuff for network team

Roadmap O2A5

• namecoin has trouble with windows and mac.

  • we are not concerned about android support

• SAT extension can be used as an HTTPS-E alternative.

• namecoin can be at a good stage by the end of the year.

• HTTPS-E is a lower risk alternative to namecoin

• Centralization issues with HTTPS-E? Needs a convenient user-friendly workflow for subscribing to different rulesets.

• Need to specify exactly the workflow of HTTPS-E and specify the exact interface.

• HTTPS-E ruleset API can be used as part of namecoin

• Namecoin does redirects using TCP level redirects so the address on the URL bar is a namecoin domain The HOST header sent to the server is a namecoin domain, so it's differnet from HTTPS-E.

================================================================================

george questions (notes):

• do we planb to show alt-svc that it's an onion. the onion icon and the dot com url.
• do we really need onion-redirect? Namecoin: The usefuleness of a normal website signalling to its users that an onion domain is available. Jeremy thinks it's a useful thing. Can this be used to redirect v2 to v3?