-----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-----
Attachment:
0x6DCDD53C.asc
Description: application/pgp-keys
Attachment:
0x6DCDD53C.asc.sig
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev