iry
2017-08-19 17:33:07 UTC
Btw, Collateral Freedom seems to be one of the most effective
ways to circumvent Internet censorship in China. Circumvention
tools that depend on Collateral Freedom usually works fine,
including meek, lantern, psiphon3 etc. Therefore, I see a lot of
potential work which may benefit the Internet freedom in China.
For example: 1. package meek into Debian 2. host (part of the)
https://trac.torproject.org/projects/tor/ticket/22402
ways to circumvent Internet censorship in China. Circumvention
tools that depend on Collateral Freedom usually works fine,
including meek, lantern, psiphon3 etc. Therefore, I see a lot of
potential work which may benefit the Internet freedom in China.
For example: 1. package meek into Debian 2. host (part of the)
https://trac.torproject.org/projects/tor/ticket/22402
A) Most places around the world that need bridges these days need
pluggable transport bridges, not just vanilla bridges. So if we
want to bundle bridge addresses, we should bundle PT bridge
addresses.
I agree! This also makes me think about a small potential improvementpluggable transport bridges, not just vanilla bridges. So if we
want to bundle bridge addresses, we should bundle PT bridge
addresses.
on the design of BridgeDB web. When users click the big "Just give me
some bridge" on https://bridges.torproject.org/options , they will be
provided with vanilla bridges instead of obfs4 bridges.
However, those users who choose not to use "Advanced Options" are most
likely to be inexperienced and have no idea on what obfd4, PT etc are.
Therefore, is it a good idea to provide obfs4 bridges, rather than
vanilla ones, in "Just give me some bridge" for better usability and
higher success rate?
B) ...and that means we need to make sure that those PTs are well
packaged in Debian too, since the Tor deb by itself would not be
able to use them.
Agreed. I can help to report a bug against obfs4proxy on Debian BTSpackaged in Debian too, since the Tor deb by itself would not be
able to use them.
when the idea is mature.
C) I wonder if we could use the new %include torrc directive in
this situation: https://bugs.torproject.org/1922
I don't have a say on the final decision, but this is also what I amthis situation: https://bugs.torproject.org/1922
thinking about:> 3. "Bridge" + plain text which is ready to be
appended to a torrc file
or to be one of the torrc files in /etc/torrc.d/ (or whatever
torrc.d path Debain decides to use)
That is, when you apt-get install obfs4proxy, is that the right
time to populate /etc/torrc.d/obfs4-bridges with some (probably
commented out to start) lines that let you use those bridges if
you want?
How about not commenting out the bridge info as the switch? Instead,torrc.d path Debain decides to use)
That is, when you apt-get install obfs4proxy, is that the right
time to populate /etc/torrc.d/obfs4-bridges with some (probably
commented out to start) lines that let you use those bridges if
you want?
user who would like to use bridge can comment out or add the following
two lines in /etc/tor/torrc:
#UseBridges 1
#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
I have being considering /etc/torrc.d/ as a place to store all the
available settings and considering /etc/tor/torrc as a panel that let
user decide what they would like to enable and disable. But I am not
sure if this is a good way to think about the relationship between
/etc/tor/torrc and /etc/torrc.d/
One thing I am concerned about is, when applying the method above, how
can user choose different PTs in the future? For example, when meek in
packaged into Debian, the meek package will probably also have a
/etc/torrc.d/meek-bridges file. Can we just choose to use obfs4 or
meek in /etc/tor/torrc by switching between the following two lines?
#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
#ClientTransportPlugin meek exec /usr/bin/meek-client
(I can test with that, but people who is familiar with the mechanism
behind it can probably answer that.)
Best,
iry