[docs] add working document about snowflake

just a dump from a working pad, comments are welcome

1 files changed, 77 insertions, 0 deletions

diff --git a/docs/research/snowflake.txt b/docs/research/snowflake.txt
new file mode 100644
index 0000000..19e32d2
--- /dev/null
+++ b/docs/research/snowflake.txt
@@ -0,0 +1,77 @@
+Initial brainstorm
+==================
+
+Date: 16 Jun 2021
+Authors: cyberta, kali
+
+Goal
+====
+
+Using snowflake to help circumvent blocks on leap VPN.
+
+Assumptions
+===========
+
+* 1. Not all the gateways (or obfs4 endpoints, or tls proxies etc) are blocked.
+
+Phases
+======
+* 1. Use snowflake ONLY in the bootstrap of the VPN connection <- we're here now.
+* 2. Use snowflake as a pluggable transport to tunnel an openvpn connection - aka "mutual aid" scenario.
+
+
+Comparison of approaches
+========================
+
+Approach A: depend on Tor binary
+--------------------------------
+
+- Pros: 
+    + no complexity on the backend side
+    + probably more snowflake proxies available
+    + we might even depend on a preinstalled tor binary instead of shipping it -> no negative effect on app size
+- Cons: 
+    + Not valid for PHASE 2 (actually moving traffic)
+    + Shipping Tor binary (how big is it, static?) - but we can just assume that an user that needs to use this is sufficiently motivated to install Tor
+    + Need to control failures, probably more difficult than with a better integrated solution
+    + SLOW - need to stablish the circuit, bootstrap can get interrupted, either by censorship or other reasons.
+      - BUT: Is it possible to build a single-hop circuit?
+    + This whole approach for this phase might be a good PoC, but stupid -
+    under censorship, we should expect DNS blocking, so if we're going to rely
+    on domain fronting, we could just domain-front the api (plus the certs,
+    there can be some complexities there). - However Domain fronting is
+    probably going to die sooner or later
+
+    QUESTION: what's the status of azure df? what's the status of the
+    alternatives to domain fronting for snowflake? (cecylia was working on
+    this, should look for the issue) 
+
+Approach B: no dependency on Tor
+--------------------------------------------------------
+This is a bit fuzzy, because we could still improve over the previous approach
+by using Tor as a library.
+
+- Pros:
+    + no Tor binary dependencies, only go code.
+    + might be a solution to route vpn traffic: a censorship resistant approach
+    that might not require sysadmins to regularly change ips for the PT bridges 
+    + less boring :), explorative work that might get further funding
+    + little bit faster (no establishment of the circuit, no additional 3 tor hops) to fetch data from the api
+- Cons:
+    + We need to fork or modify snowflake :(
+
+      + We need to change the webrt connection proxy <-> tor relay by something else.
+
+    + Either maintain the fork ourselves, or convince Tor of making
+    modification s that allow a more generic "snowflake-not-as-a-Tor-transport"
+    codebase -> this is a key point that we should explore with tor
+    anticensorship team, I think. agreed
+    + We *will* always have a much lesser pool of volunteers than what Tor is
+    able to nurture (Tor is orders of magnitude better funded/governed than
+    leap is).
+    See  https://snowflake-broker.torproject.net/debug - we don't have traction
+    to have some 100s of volunteers, even with the expected churning rates.
+    + wrt. routing VPN traffic: how well does the ephemerality of the proxies
+    play with the users expectation of a uninterrupted internet connection -
+    really good point. is it preferrable bad internet or no internet at all? we
+    need to start asking people.