[tor-commits] [tor/master] Add TODO file for padding work.

[nickm@xxxxxxxxxxxxxx]

commit 0658c729cf3c6be27ff774d9d219402a6cf6cf53
Author: Mike Perry <mikeperry-git@xxxxxxxxxxxxxx>
Date:   Fri Aug 24 21:37:43 2018 +0000

    Add TODO file for padding work.
    
    Note to self/others: don't merge this.
    
    Co-authored-by: George Kadianakis <desnacked@xxxxxxxxxx>
---
 PADDING_TODO.txt | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/PADDING_TODO.txt b/PADDING_TODO.txt
new file mode 100644
index 000000000..a2e97f7ca
--- /dev/null
+++ b/PADDING_TODO.txt
@@ -0,0 +1,58 @@
+TODO sketch for this branch, in rough priority order:
+
+- Clean up/fix XXX's and FIXMEs
+  - Test event entry points into circuitpad?
+    - Most of our events come from completely untested code :/
+
+- Compat-breaking changes to be decided/done ASAP
+  - Option to keep circuits open if machine present
+  - Specify an ordered preference list of padding machines
+  - Specify exit policy for machine conditions?
+    - short_policy_t looks good, except for its flexible array member :/
+      - Can we make our own struct with a small, fixed number of policy
+        entries? Say 3-4? Or is that a bad idea to lose this flexibility?
+    - Check conditions based on attached streams on the circuit
+      - Accept should mean "only apply if matched"
+      - Reject should mean "don't apply if matched"
+      - If a policy is specified, Reject *:* is implicit default (so reject
+        policies need an Accept entry).
+      - With no policy, Accept *:* is implicit default.
+
+
+- Misc fixes:
+  - Remove circuitsetup machine (but place it in unittests -- they depend on it)
+  - Circuit RTT measurement will break on var_cell/EXTEND2 cells
+    - Are there any heuristics we can use here?
+      - If RELAY_EARLY is only for the first cell of an EXTEND2 series,
+        we can use that. But the proposal currently says MAY, but not MUST
+        for this behavior.
+
+======== 0.3.6 ========
+
+- Come up with some good histograms for eg circuit setup fingerprinting,
+  website fingerprinting, and vanguards usage.
+
+- Vanguards compatibility for MiddleNodes (via changes to vanguards addon)
+
+- circpad_machine_validate() function to sanity-check histograms loaded from
+  consensus/torrc (can also be used to help guide a GA).
+  - Check bin construction
+  - no type overflow (start_usec + range_sec, etc)
+  - no conflicting state transitions (or overlap with cancel events)
+  - no use of both histograms and iat_dist
+  - at least two histogram bins
+  - min_hop vs target_hop
+
+- Support torrc load+serialization of state machines
+  - ??
+
+- Support consensus load+serialization of state machines
+  - ??
+
+- Prop #265 load balancing
+
+- Rephist timer stats
+  - Is this a privacy risk? The adversary could create lots of circuits
+    to find a layer2 vanguard.. Otherwise they will be spread across middles.
+
+



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits