[tor-dev] Feature Request: please consider ship default, Tor bridges

[iry]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Roger:
> On Thu, Aug 17, 2017 at 07:57:53PM +0000, iry wrote:
>> 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) 
>> BridgeDB mirror on Github or AWS 3. #22402: 
>> https://trac.torproject.org/projects/tor/ticket/22402
> Some hopefully useful thoughts along these lines:
> 

Hi Roger! Thank you for sharing your insights!

> 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 improvement
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 BTS
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 am
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,
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
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZmHZUAAoJEKFLTbxtzdU8Y2gP+wfDoSOTprVqe4rByzHVhUup
LXvy4WnfHeUq03t+H8W5QwJCPdsFssFZae/EsfUU5Q490GqhAFryi8rHmOHluSGl
FmX9SIxQXT3RV7iEFN7w4qKqYHLEKrRTklWOLrDauHZe3eJEUyn49VCROtBat88Y
bdnrav4D443fFD/ugk8C3K5u4oNEWgtaq9natsLkPFbXpNcB06gd/S23Vj4VsOP0
+FUmIHmtzzMk0iTAVjGrW8X/z6/lyqk6Nj/lvwfNhdIJ5gbk5F848sl71VBeK3of
Q7rdCjglZ3/tPRfrE+d40cfQWmOpw7doozC7LKdDbxCtx/LJ0WFq2PvwmO+uUFOG
3QMAV0w58JWsUsLW80ifcx7T+0O7QeAMASqWqKva7d1Y2PgqNCJfDJDHOX/KuEy3
TUi8o5WkIUUtyPaMwnYXW9VkaEKIHBXxfjYBwg0llfGU9HKJmTj+yCrMMHB2t0m0
OlZUFx9E7U11mhWzGM64sICHuob8VjwsLgLPMJc1+ocDobo0HrJr1ZtWmMZScp60
SpK35EwU8jKZJTSXtI/SKtDdHGhGmxm4NvLy26TWSqHbEzlcelK+yqkifnLHr3tb
we61NdV2ZA7XCrp+o3Q7NprMjRGtaP1aze2bQTjJfkLDdrShkZFw3/hYk75cRpvk
tkf7Tl4oLtoa5lnNhB/S
=sP5G
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6DCDD53C.asc
Type: application/pgp-keys
Size: 4674 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170819/78d1484d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6DCDD53C.asc.sig
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170819/78d1484d/attachment.sig>