add some details on why we haven't done proposal 127 yet, and may

not ever do it.


svn:r13884

1 files changed, 20 insertions, 0 deletions

diff --git a/doc/spec/proposals/127-dirport-mirrors-downloads.txt b/doc/spec/proposals/127-dirport-mirrors-downloads.txt
index 9a07dcdc0d..1b55a02d61 100644
--- a/doc/spec/proposals/127-dirport-mirrors-downloads.txt
+++ b/doc/spec/proposals/127-dirport-mirrors-downloads.txt
@@ -135,3 +135,23 @@ Status: Draft
       answers to popular requests, so we don't have to keep getting
       them again.)
 
+6. Outstanding problems
+
+  1) HTTP proxies already exist.  Why waste our time cloning one
+  badly? When we clone existing stuff, we usually regret it.
+
+  2) It's overbroad.  We only seem to need a secure get-a-tor feature,
+  and instead we're contemplating building a locked-down HTTP proxy.
+
+  3) It's going to add a fair bit of complexity to our code.  We do
+  not currently implement HTTPS.  We'd need to refactor lots of the
+  low-level connection stuff so that "SSL" and "Cell-based" were no
+  longer synonymous.
+
+  4) It's still unclear how effective this proposal would be in
+  practice. You need to know that this feature exists, which means
+  somebody needs to tell you about a bridge (mirror) address and tell
+  you how to use it. And if they're doing that, they could (e.g.) tell
+  you about a gmail autoresponder address just as easily, and then you'd
+  get better authentication of the Tor program to boot.
+