|
|
# 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? |