[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [research-web/master] add another set of documents to 2016-01 trsb case



commit b98732baef0d3b8383a7f09c7b8d016555bc4d46
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
Date:   Wed Aug 9 00:20:00 2017 -0400

    add another set of documents to 2016-01 trsb case
---
 htdocs/trsb/2016-01-questionnaire-answers.txt | 113 +++++++++++++++++++++++++
 htdocs/trsb/2016-01-questionnaire.txt         | 115 ++++++++++++++++++++++++++
 htdocs/trsb/2016-01-request.txt               |   2 -
 htdocs/trsb/2016-01-response.txt              |   5 +-
 4 files changed, 229 insertions(+), 6 deletions(-)

diff --git a/htdocs/trsb/2016-01-questionnaire-answers.txt b/htdocs/trsb/2016-01-questionnaire-answers.txt
new file mode 100644
index 0000000..0f1e909
--- /dev/null
+++ b/htdocs/trsb/2016-01-questionnaire-answers.txt
@@ -0,0 +1,113 @@
+
+From: QI ZHONG <zhongqi92@xxxxxxxxxxxx>
+Date: Mon, 10 Oct 2016 02:34:11 -0700
+
+A draft template/questionaire to promote safer Tor experiments
+
+1a. What are you trying to learn about? Is it:
+- New algorithm(s) that enhances current algorithm(s) in Tor.
+- New system that interacts with Tor.
+- New attack(s) that degrade(s) Tor properties.
+- The characteristics of the real-world Tor network and its clients, operators, network topology, etc.
+- Something else.
+
+The characteristics of the real-world Tor network and its clients, operators, network topology, etc.
+
+1b. What about the above are you trying to learn? Is it:
+- Performance enhancement/reduction.
+- Security enhancement/reduction.
+- Privacy enhancement/reduction.
+- Actual real-world trends, details, etc of the Tor network.
+-- Could we use this data to construct models about the Tor network?
+- Something else.
+
+Actual real-world trends, details, etc of the Tor network. It might be possible to construct better model.
+
+1c. Why is it important to learn the above?
+- It justifies the new algorithm/system/attack.
+- It would reveal (alarming) significant information about the Tor network, and:
+-- Tor should change its design (and we have suggestions on how).
+-- We can model this aspect of the Tor network and use it henceforth (and avoid collecting data like this again).
+- Something else.
+
+Something else. We hope it can make Tor more censorship-resistant.
+
+2. Could you learn this by doing a closed-form analysis from the design?
+- Yes, and it would be pretty close to reality.
+- Yes, but it would not be realistic.
+-- Can you estimate how significant a deviation you expect from the closed-form analysis compared to the real-world results? Is it more like a) anyone's guess, or b) bounded by some amount/factor.
+- No, due to difficulties in performing closed-form analysis from the design.
+- No, because it would not be the real-world behavior of the network. 
+
+No, because it would not be the real-world behavior of the network. 
+
+3a. What data points do you need to learn the above?
+- How many?
+We will be testing the reachability of the default bridges.
+- Over what time period and duration?
+Indefinite.
+- From which vanatage points on the network? (e.g. clients, relays, directory servers, network, ISP, HSdir, etc).
+We test it from off the network.
+- What granularity is the data that is collected.
+It is only the reachability of different bridges during different time.
+- How will they be kept ``safe'' while they are collected and stored?
+We don't have any secret data. All our results will be published after our research.
+-- Describe what you mean by ``safe'' here.
+
+3b. How do these data points tell you about the thing you want to learn about?
+- Would it be conclusive?
+No, but it would give us better insights.
+- Would it be valid for only a snap-shot-in time?
+Yes.
+- Would it have to be updated regularly to remain relevant?
+Yes.
+
+3c. Does the data need to be released to justify your experiments/system?
+- Yes.
+-- With what granularity would it be reported?
+-- Would it be obfuscated in some fashion?
+- No.
+-- How will you justify your results instead?
+Yes. We will obfuscate our probe locations. None of the other data is secret.
+
+4. Is there an alternative, and existing, source of data you could use instead of collecting your own?
+- Yes.
+- No, it
+-- doesn't exist.
+-- is too old.
+-- is not released by the collector.
+No, it doesn't exist. We can use Tor collector data as supplyment though.
+
+5. Could you evaluate your enhancement/attack on a (local) test Tor network?
+- Yes.
+- Yes, but limited by the models we could use.
+- No, since the models we have are insufficient, or don't exist, or not robust enough. We need:
+-- Realistic client behviour.
+-- Realistic networking behaviour.
+-- Realistic bandwidth and computation load.
+-- Realistic system/Tor interaction.
+- No, for another reason.
+No. We need a realistic adversary.
+
+6. Describe your experimental methodology for running experiments to learn about/attack the live Tor-network.
+6a. When running your experiment on the live-network, you will collect and/or process:
+- Only data generated and realted to our own clients and nodes.
+- The above as well as those of other users of the Tor network.
+- Only data of other users of the Tor network.
+Only data generated and realted to our own clients and nodes.
+
+6b. Will you introduce resources (relays and bandwidth) into the network.
+- Yes.
+-- We will run clients (honest but curious, and/or malicious).
+-- We will run Directories (honest but curious, and/or malicious).
+-- We will run relays (guard, middle, exit) (honest but curious, and/or malicious).
+- No.
+-- How will you observe/influence the network if not directly through Tor nodes?
+We will run clients (honest but curious, and/or malicious).
+
+6c. Will you run custom Tor code on your Tor nodes?
+- Yes, but only to log certain events.
+- Yes, but it changes the original behavior.
+-- How would this affect the Tor network in general? Is it part of an attack? Describe the impact.
+No.
+
diff --git a/htdocs/trsb/2016-01-questionnaire.txt b/htdocs/trsb/2016-01-questionnaire.txt
new file mode 100644
index 0000000..7603966
--- /dev/null
+++ b/htdocs/trsb/2016-01-questionnaire.txt
@@ -0,0 +1,115 @@
+
+From: "M. Tariq Elahi" <Tariq.Elahi@xxxxxxxxxxxxxxxx>
+Date: Fri, 30 Sep 2016 14:08:13 +0200
+
+Hi David,
+Thanks for reaching out about conducting safer experiments on the Tor
+network. I am taking the lead to assist you with that.
+I have gone over your responses to the guide questions and think you
+have done a pretty good job of figuring things out on your own.
+
+I have created a template (to someday replace the more generic questions
+on the webpage) that I am attaching here which is aimed at helping
+researchers work through their methodology and aims. Since you have
+already provided a lot of the responses, you can ignore those parts of
+the document, but do take a look at section 3(a-c), 4, and 6(a-c). It is
+more about how you'd do your experiments, store the data you collect,
+and keep everything super safe.
+
+The plan is to take those responses, get together and discuss/clarify
+where needed, and then I would write a recommendation for you and the
+board to consume stating whether your plan seems plausible. Since this
+is our first time and still figuring things out ourselves there is a lot
+of flexibility about how we go about this and the end result. Hopefully,
+it will be useful for your project, and for the Tor community.
+
+Look forward to hearing back from you.
+
+Cheers,
+Tariq
+
+A draft template/questionaire to promote safer Tor experiments
+
+1a. What are you trying to learn about? Is it:
+- New algorithm(s) that enhances current algorithm(s) in Tor.
+- New system that interacts with Tor.
+- New attack(s) that degrade(s) Tor properties.
+- The characteristics of the real-world Tor network and its clients, operators, network topology, etc.
+- Something else.
+
+1b. What about the above are you trying to learn? Is it:
+- Performance enhancement/reduction.
+- Security enhancement/reduction.
+- Privacy enhancement/reduction.
+- Actual real-world trends, details, etc of the Tor network.
+-- Could we use this data to construct models about the Tor network?
+- Something else.
+
+1c. Why is it important to learn the above?
+- It justifies the new algorithm/system/attack.
+- It would reveal (alarming) significant information about the Tor network, and:
+-- Tor should change its design (and we have suggestions on how).
+-- We can model this aspect of the Tor network and use it henceforth (and avoid collecting data like this again).
+- Something else.
+
+2. Could you learn this by doing a closed-form analysis from the design?
+- Yes, and it would be pretty close to reality.
+- Yes, but it would not be realistic.
+-- Can you estimate how significant a deviation you expect from the closed-form analysis compared to the real-world results? Is it more like a) anyone's guess, or b) bounded by some amount/factor.
+- No, due to difficulties in performing closed-form analysis from the design.
+- No, because it would not be the real-world behavior of the network. 
+
+3a. What data points do you need to learn the above?
+- How many?
+- Over what time period and duration?
+- From which vanatage points on the network? (e.g. clients, relays, directory servers, network, ISP, HSdir, etc).
+- What granularity is the data that is collected.
+- How will they be kept ``safe'' while they are collected and stored?
+-- Describe what you mean by ``safe'' here.
+
+3b. How do these data points tell you about the thing you want to learn about?
+- Would it be conclusive?
+- Would it be valid for only a snap-shot-in time?
+- Would it have to be updated regularly to remain relevant?
+
+3c. Does the data need to be released to justify your experiments/system?
+- Yes.
+-- With what granularity would it be reported?
+-- Would it be obfuscated in some fashion?
+- No. 
+-- How will you justify your results instead?
+
+4. Is there an alternative, and existing, source of data you could use instead of collecting your own?
+- Yes.
+- No, it
+-- doesn't exist.
+-- is too old.
+-- is not released by the collector.
+
+5. Could you evaluate your enhancement/attack on a (local) test Tor network?
+- Yes.
+- Yes, but limited by the models we could use.
+- No, since the models we have are insufficient, or don't exist, or not robust enough. We need:
+-- Realistic client behviour.
+-- Realistic networking behaviour.
+-- Realistic bandwidth and computation load.
+-- Realistic system/Tor interaction.
+- No, for another reason.
+
+6. Describe your experimental methodology for running experiments to learn about/attack the live Tor-network.
+6a. When running your experiment on the live-network, you will collect and/or process:
+- Only data generated and realted to our own clients and nodes.
+- The above as well as those of other users of the Tor network.
+- Only data of other users of the Tor network.
+6b. Will you introduce resources (relays and bandwidth) into the network.
+- Yes.
+-- We will run clients (honest but curious, and/or malicious).
+-- We will run Directories (honest but curious, and/or malicious).
+-- We will run relays (guard, middle, exit) (honest but curious, and/or malicious).
+- No.
+-- How will you observe/influence the network if not directly through Tor nodes?
+6c. Will you run custom Tor code on your Tor nodes?
+- Yes, but only to log certain events.
+- Yes, but it changes the original behavior.
+-- How would this affect the Tor network in general? Is it part of an attack? Describe the impact.
+
diff --git a/htdocs/trsb/2016-01-request.txt b/htdocs/trsb/2016-01-request.txt
index 47e3ff4..3e01adc 100644
--- a/htdocs/trsb/2016-01-request.txt
+++ b/htdocs/trsb/2016-01-request.txt
@@ -1,8 +1,6 @@
 
 Date: Thu, 18 Aug 2016 10:47:45 -0700
 From: David Fifield <david@xxxxxxxxxxxxxxx>
-To: Roger Dingledine <arma@xxxxxxx>
-Cc: Lynn Tsai <lynntsai@xxxxxxxxx>
 Subject: Tor Research Safety Board: default bridge reachability
 
 We're seeking comments on a continuation of our research on the blocking
diff --git a/htdocs/trsb/2016-01-response.txt b/htdocs/trsb/2016-01-response.txt
index a77b7a5..e6b4306 100644
--- a/htdocs/trsb/2016-01-response.txt
+++ b/htdocs/trsb/2016-01-response.txt
@@ -1,10 +1,7 @@
 
 Date: Fri, 16 Dec 2016 16:54:52 +0100
 From: "M. Tariq Elahi" <Tariq.Elahi@xxxxxxxxxxxxxxxx>
-To: tor-research-safety@xxxxxxxxxxxxxxxxxxxx, david@xxxxxxxxxxxxxxx,
-        lynntsai@xxxxxxxxx, QI ZHONG <zhongqi92@xxxxxxxxxxxx>
-Subject: Re: [tor-research-safety] (FWD) Tor Research Safety Board: default
-        bridge reachability
+Subject: Re: Tor Research Safety Board: default bridge reachability
 
 Yesterday, I wrote to David et al. with a short summary of our review.
 The tl;dr was that we (Damon McCoy and I) don't see anything

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