Re: [tor-dev] What are some aspects of Tor that are suffering right now due to lack of speed?
On Fri, Jul 25, 2014 at 04:10:50AM +0100, Virgil Griffith wrote: > Hidden services quickly come to mind. > > Are there other candidates? I can imagine people deciding not to view > certain content through Tor because of speed (e.g., pornhub). But I > suspect I am missing some use cases. Hi Virgil, Threads like this one will do better on tor-talk. Tor dev is about developing Tor, not the place you go to talk about your topic because the developers are there. (Several people have pointed this out to me from previous threads, so I'm taking the opportunity to actually say it on this one.) And to add a bit of content here, long ago I maintained https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/Performance but then I was wearing too many hats so it fell by the wayside. More recently I revived it into http://freehaven.net/~arma/tor-performance-outline.txt but then the same thing happened. In my copious free time I'd like to write the "why else is Tor slow" document, to follow the first one. Other fires are burning higher lately though. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] What are some aspects of Tor that are suffering right now due to lack of speed?
Hidden services quickly come to mind. Are there other candidates? I can imagine people deciding not to view certain content through Tor because of speed (e.g., pornhub). But I suspect I am missing some use cases. -V ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
Nima Fatemi transcribed 4.0K bytes: > isis: > [...] > >> Are some of our least technical users, many of whom have never even seen a > >> command line before and who may live in Sub-Saharan Africa or one of the > >> Stan countries with only a rudimentary knowledge of English going to > >> understand the difference between vanilla bridges and, say, chocolate > >> almond > >> bridges? Wouldn't it be better to choose terms that at least translate into > >> something resembling what they actually mean? > > > > Noted. What to call bridges without any pluggable transports has been argued > > about for years, with the result that everyone ended up calling them > > different > > things all over the place, which I believe is worse. > > > > Eventually, everyone figured out what "obfsproxy" meant, even if they didn't > > understand how it worked, nor how to pronounce it. My hope is that a > > consistent usage of consistently confusing and untranslatable terminology > > will > > eventually produce predictable and steadily decreasing levels of user > > confusion. > > > > Should the interface say "get transport unhuggable", perhaps? The obvious > > choices were: > > > > 1. `get tor bridges` / `get transport tor` > > This is no good because it could potentially cause users to > > erroneously think that pluggable transport bridges somehow aren't using > > tor. > > > > 2. `get plain bridges` > > I think this one is bad because people might assume that this one > > is > > somehow plaintext, especially if the string were to be translated. > > > > Do you have a better suggestion for what to call "vanilla bridges"? > > > > I think "bridges" works just fine for "vanilla bridges" and I want to > take the opportunity to +1 Philipp's idea on looking for keywords > instead of commands, regardless of how they're phrased. Actually, we do look for keywords! [0][1] This is why you can currently do: get ipv6 transport scramblesuit And if BridgeDB had any scramblesuit bridges with IPv6 addresses (it doesn't, AFAIK), it would give them to you (if it felt like it). Typing `get bridges` *does* get you vanilla bridges; you don't have to type the word "vanilla" (but if you did, it would still give you vanilla bridges). I'm just trying to have something to call them, which is clear immediately that I mean a normal Tor bridge without any tranports. When someone says "i have a problem connecting to a bridge", the first question is always "are you using transports? if so, which one?". Calling them "vanilla bridges" saves one RT in the Q&A game. > For instance, if someone emails BridgeDB with "please send me some > bridges" it should reply with a list of "vanilla bridges". or if someone > emailed the word "obfs" and nothing else, the bot should return a list > of obfs3 bridges. > > PS: why are we still shipping obfs2 bridges?! tl;dr: Because we have them. Imagine a bunch of kids in Halloween costumes. If every kid dressed up in the same zombie costume, you'd still be able to easily tell the kids apart because some are taller, and some of them maybe that green makeup stuff doesn't stick so well to their face, and some of them have longer hair or higher voices than others. Now imagine the same group of kids and everyone's wearing a different costume. Some kids have stilts or are standing on some other kid's shoulders. Some kids have super crazy fancy rubber masks with builtin vocoders to pitch shift their voices. Some have pogo sticks and wigs and fake blood and lazers. With all this madness going on, it's too much to keep track of. Hopefully. And while maybe one costume isn't the best disguise for a certain kid, we shouldn't necessarily pull the costume out of the closet and toss it away; the point is that we're trying to make the censors, spooks, and spies do a hell of a lot of work to figure out what's going on underneath all this insanity. > > Bests, > -- > Nima > 0XC009DB191C92A77B | @nimaaa | mrphs > > "I disapprove of what you say, but I will defend to the death your right > to say it" --Evelyn Beatrice Hall > [0]: https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/lib/bridgedb/email/autoresponder.py#l43 [1]: https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/lib/bridgedb/email/request.py#l86 -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] New Version of OnionMail 1.6.0.667B is Out
* Thunderbird autoconfiguraticon. * Web Server. * User subscription webpages. * Full integrated PGP key generation and keyServer sender. * Mail Queue (onli exit/enter server). * Bash OnionMail Setup wizard. * And much more... You can activate an OnionMail server in 5 minutes! You can create a new user account in 100 seconds! The mode is easier to get a mail box is described here: http://onionmail.info/network/ >From this new version you can get a mail box via web directly. Download the new version at: http://onionmail.info/download/ User Manual: http://www.onionmail.info/manual.html What is OnionMail? http://onionmail.info/paper.html OnionMail Project http://onionmail.info ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] DEFAULT_ROUTE_LEN [was: Silly (or not so silly) question]
On Thu, 24 Jul 2014 16:48:21 -0400 grarpamp wrote: > On Wed, Jul 23, 2014 at 6:34 PM, Roger Dingledine > wrote: > > On Wed, Jul 23, 2014 at 11:24:47PM +0100, Noel David Torres Taño > > wrote: > >> What would happen if a Tor node changes behaviour and uses four or > >> five relay steps instead of three? > > At around DEFAULT_ROUTE_LEN 8 or above I get a lot of these, with > EXTEND being shown in various command locations, and no connectivity > to hidden services. Lower values or 4 or 5 probably work just fine > but I didn't bother testing more than a couple clearnet and onion > circuits since it's not yet a controller/config tunable and thus takes > edit/compile/run time. So even my test of 9 > 5 > 7 > 8 take with > salt. Don't know if this likely represent a bug to test more, or just > timeouts... the circuits that did work setup in times not feeling > much more than time/3*LEN. I'd suggest an undocumented tunable and > unit test if it's worth research/statistic/function_checking purpose. > > > relay_send_command_from_edge_(): Bug: Uh-oh. We're sending a > RELAY_COMMAND_EXTEND cell, but we have run out of RELAY_EARLY cells on > that circuit. Commands sent before: > (unrecognized),(unrecognized),(unrecognized),(unrecognized),EXTEND,EXTEND,(unrecognized) This is working exactly as specified, and despite the error message, is not a Bug. The number of hops each circuit can extend to is limited by the number of RELAY_EARLY cells allowed per circuit (8), as EXTENDs that are not contained in RELAY_EARLY are dropped. Roger linked prop 110, but this is also documented in the tor-spec (section 5.6). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] DEFAULT_ROUTE_LEN [was: Silly (or not so silly) question]
On Wed, Jul 23, 2014 at 6:34 PM, Roger Dingledine wrote: > On Wed, Jul 23, 2014 at 11:24:47PM +0100, Noel David Torres Taño wrote: >> What would happen if a Tor node changes behaviour and uses four or five >> relay steps instead of three? At around DEFAULT_ROUTE_LEN 8 or above I get a lot of these, with EXTEND being shown in various command locations, and no connectivity to hidden services. Lower values or 4 or 5 probably work just fine but I didn't bother testing more than a couple clearnet and onion circuits since it's not yet a controller/config tunable and thus takes edit/compile/run time. So even my test of 9 > 5 > 7 > 8 take with salt. Don't know if this likely represent a bug to test more, or just timeouts... the circuits that did work setup in times not feeling much more than time/3*LEN. I'd suggest an undocumented tunable and unit test if it's worth research/statistic/function_checking purpose. relay_send_command_from_edge_(): Bug: Uh-oh. We're sending a RELAY_COMMAND_EXTEND cell, but we have run out of RELAY_EARLY cells on that circuit. Commands sent before: (unrecognized),(unrecognized),(unrecognized),(unrecognized),EXTEND,EXTEND,(unrecognized) >> Would it enhance Tor's security? > > I assume you mean a Tor client? > > https://www.torproject.org/docs/faq#ChoosePathLength > >> Is it possible to relay Tor through a Tor connection? I mean using Tor >> with its three steps to reach a Tor entry node to get three extra steps. > > Yes, it is possible. But it is currently considered a flaw, because it > can be used to work around the 'infinite path length' defenses. > http://freehaven.net/anonbib/#congestion-longpaths > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-infinite-circuits.txt > https://trac.torproject.org/projects/tor/ticket/2667 > >> Would that difficult correlation attacks? > > Defending against correlation attacks is an open research, so "maybe". > But it's not clear how it would, since an adversary who can see or > measure your first hop (on the first circuit) and also your last hop > (on the last circuit) would still be in the right place to do the attack. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
Hi. I support what Philipp and Nima say about keywords. The given commands surely look simple for technical users, but what about non-technical users? If the purpose of the distributor is to give info, and you're already filtering emails to *try* to avoid fake requests (correct if i'm wrong), then you may assume that if somebody sends you an email is because he/she is requesting for info, and if the email contains "bridges", it's quite possible he/she wants bridges, right? You could, for example, filter for "transport" (ignoring case) and send a reply with info for all types, explaining what they do, and let the user decide which one to use. You could also send both ipv4 and ipv6 IPs when requesting bridges. And why not sending a public key link in all the replies (except help)? IMHO, this reduces the effort on the user side (this is how we're doing it on the revamp GetTor project). best, 2014-07-24 2:54 GMT-04:00 Nima Fatemi : > isis: > [...] > >> Are some of our least technical users, many of whom have never even > seen a > >> command line before and who may live in Sub-Saharan Africa or one of the > >> Stan countries with only a rudimentary knowledge of English going to > >> understand the difference between vanilla bridges and, say, chocolate > almond > >> bridges? Wouldn't it be better to choose terms that at least translate > into > >> something resembling what they actually mean? > > > > Noted. What to call bridges without any pluggable transports has been > argued > > about for years, with the result that everyone ended up calling them > different > > things all over the place, which I believe is worse. > > > > Eventually, everyone figured out what "obfsproxy" meant, even if they > didn't > > understand how it worked, nor how to pronounce it. My hope is that a > > consistent usage of consistently confusing and untranslatable > terminology will > > eventually produce predictable and steadily decreasing levels of user > > confusion. > > > > Should the interface say "get transport unhuggable", perhaps? The obvious > > choices were: > > > > 1. `get tor bridges` / `get transport tor` > > This is no good because it could potentially cause users to > > erroneously think that pluggable transport bridges somehow aren't > using > > tor. > > > > 2. `get plain bridges` > > I think this one is bad because people might assume that this > one is > > somehow plaintext, especially if the string were to be translated. > > > > Do you have a better suggestion for what to call "vanilla bridges"? > > > > I think "bridges" works just fine for "vanilla bridges" and I want to > take the opportunity to +1 Philipp's idea on looking for keywords > instead of commands, regardless of how they're phrased. > > For instance, if someone emails BridgeDB with "please send me some > bridges" it should reply with a list of "vanilla bridges". or if someone > emailed the word "obfs" and nothing else, the bot should return a list > of obfs3 bridges. > > PS: why are we still shipping obfs2 bridges?! > > Bests, > -- > Nima > 0XC009DB191C92A77B | @nimaaa | mrphs > > "I disapprove of what you say, but I will defend to the death your right > to say it" --Evelyn Beatrice Hall > > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- israel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
Nima Fatemi : > > I think "bridges" works just fine for "vanilla bridges" and I want to > take the opportunity to +1 Philipp's idea on looking for keywords > instead of commands, regardless of how they're phrased. Help desk frequently sees bridge keywords in other (supported/unsupported) languages, like 'pol' and 'spisok mostov', that were obviously intended for the BridgeDB mailer. I think 'pol' should return obfs3 bridges (for Iranians), not sure about other defaults. Does this sound like a useful thing to do? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] channel_t to IP Address
On Thu, Jul 24, 2014 at 01:55:43PM +0100, Gareth Owen wrote: > Andrea > > Thanks for taking the time to reply and for the advice. I have just this > second discovered this method: > > TO_OR_CIRCUIT(circ)->p_chan->get_remote_descr(TO_OR_CIRCUIT(circ)->p_chan, > 0) > > which returns the endpoint as a string. I wonder, is this safer/future > proof or should this approach be discouraged? Don't call channel methods directly like that. Do call something like channel_get_actual_remote_descr(), channel_get_actual_remote_address(), or channel_get_canonical_remote_descr() (see code in channel.c for differences among them) on TO_OR_CIRCUIT(circ)->p_chan. Note: only do this if you want a string to show the user or something like that. If you're going to parse it, it's very much brittle and not future- proof. -- Andrea Shepard PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5 pgp8LTosxltAG.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] channel_t to IP Address
Andrea Thanks for taking the time to reply and for the advice. I have just this second discovered this method: TO_OR_CIRCUIT(circ)->p_chan->get_remote_descr(TO_OR_CIRCUIT(circ)->p_chan, 0) which returns the endpoint as a string. I wonder, is this safer/future proof or should this approach be discouraged? Best Gareth On 24 July 2014 12:20, Gareth Owen wrote: > Hi all > > Quick question, how does one turn channel_t into an IP address, e.g. given > a circuit_t how do I get the IP address of the previous and next hop > (noting that they might not be in the consensus so I cant use the identity > hash). I can see the information is in the connection_t struct but I don't > know how to get that from the channel/circuit. > > Any help appreciated. > > Thanks > Gareth > > -- > Dr Gareth Owen > Senior Lecturer > School of Computing, University of Portsmouth > > Tel: 02392 846423 > Web: ghowen.me > -- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth Tel: 02392 846423 Web: ghowen.me ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] channel_t to IP Address
On Thu, Jul 24, 2014 at 12:20:52PM +0100, Gareth Owen wrote: > Hi all > > Quick question, how does one turn channel_t into an IP address, e.g. given > a circuit_t how do I get the IP address of the previous and next hop > (noting that they might not be in the consensus so I cant use the identity > hash). I can see the information is in the connection_t struct but I don't > know how to get that from the channel/circuit. The IP address (and the fact that the channel_t even is over IP) are specific to particular transport; you'll have to downcast it to a channel_tls_t using the BASE_CHAN_TO_TLS macro and then look at the or_connection_t pointer in that structure. -- Andrea Shepard PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5 pgpD4i2EOymVx.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] channel_t to IP Address
Hi all Quick question, how does one turn channel_t into an IP address, e.g. given a circuit_t how do I get the IP address of the previous and next hop (noting that they might not be in the consensus so I cant use the identity hash). I can see the information is in the connection_t struct but I don't know how to get that from the channel/circuit. Any help appreciated. Thanks Gareth -- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth Tel: 02392 846423 Web: ghowen.me ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
isis wrote: Do you have a better suggestion for what to call "vanilla bridges"? I keep calling them standard bridges (as opposed to fancy, monocle-wearing bridges). People seem to understand immediately that other types of bridges are special somehow if I call regular/vanilla/non-obfs bridges Standard. And then I explain how obfs bridges and flashproxy are used in different circumstances. Also, I vote that we ditch the 'obfs' name from obfs5 and beyond in favor of 'crypto-voltron.' This will also make user education 40% more awesome. As an aside, I'm happy that 'huggable transports' [1] is a thing now :D best, Griffin [1] https://twitter.com/abditum/status/431665969627672576 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
El jue, 24-07-2014 a las 06:54 +, Nima Fatemi escribió: > isis: > [...] > >> Are some of our least technical users, many of whom have never even seen a > >> command line before and who may live in Sub-Saharan Africa or one of the > >> Stan countries with only a rudimentary knowledge of English going to > >> understand the difference between vanilla bridges and, say, chocolate > >> almond > >> bridges? Wouldn't it be better to choose terms that at least translate into > >> something resembling what they actually mean? > > > > Noted. What to call bridges without any pluggable transports has been argued > > about for years, with the result that everyone ended up calling them > > different > > things all over the place, which I believe is worse. > > > > Eventually, everyone figured out what "obfsproxy" meant, even if they didn't > > understand how it worked, nor how to pronounce it. My hope is that a > > consistent usage of consistently confusing and untranslatable terminology > > will > > eventually produce predictable and steadily decreasing levels of user > > confusion. > > > > Should the interface say "get transport unhuggable", perhaps? The obvious > > choices were: > > > > 1. `get tor bridges` / `get transport tor` > > This is no good because it could potentially cause users to > > erroneously think that pluggable transport bridges somehow aren't using > > tor. > > > > 2. `get plain bridges` > > I think this one is bad because people might assume that this one > > is > > somehow plaintext, especially if the string were to be translated. > > > > Do you have a better suggestion for what to call "vanilla bridges"? > > > > I think "bridges" works just fine for "vanilla bridges" and I want to > take the opportunity to +1 Philipp's idea on looking for keywords > instead of commands, regardless of how they're phrased. There is a word that is quite similar in spanish (all Latin America), english (a lot of places) and french (almost all Africa): "simple". We can use the term "simple bridges" to mean those bridges with no extra complications, no extra technology, no extra security... no chocolate nor almonds. My two (euro) cents Noel er Envite signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
isis: [...] >> Are some of our least technical users, many of whom have never even seen a >> command line before and who may live in Sub-Saharan Africa or one of the >> Stan countries with only a rudimentary knowledge of English going to >> understand the difference between vanilla bridges and, say, chocolate almond >> bridges? Wouldn't it be better to choose terms that at least translate into >> something resembling what they actually mean? > > Noted. What to call bridges without any pluggable transports has been argued > about for years, with the result that everyone ended up calling them different > things all over the place, which I believe is worse. > > Eventually, everyone figured out what "obfsproxy" meant, even if they didn't > understand how it worked, nor how to pronounce it. My hope is that a > consistent usage of consistently confusing and untranslatable terminology will > eventually produce predictable and steadily decreasing levels of user > confusion. > > Should the interface say "get transport unhuggable", perhaps? The obvious > choices were: > > 1. `get tor bridges` / `get transport tor` > This is no good because it could potentially cause users to > erroneously think that pluggable transport bridges somehow aren't using > tor. > > 2. `get plain bridges` > I think this one is bad because people might assume that this one is > somehow plaintext, especially if the string were to be translated. > > Do you have a better suggestion for what to call "vanilla bridges"? > I think "bridges" works just fine for "vanilla bridges" and I want to take the opportunity to +1 Philipp's idea on looking for keywords instead of commands, regardless of how they're phrased. For instance, if someone emails BridgeDB with "please send me some bridges" it should reply with a list of "vanilla bridges". or if someone emailed the word "obfs" and nothing else, the bot should return a list of obfs3 bridges. PS: why are we still shipping obfs2 bridges?! Bests, -- Nima 0XC009DB191C92A77B | @nimaaa | mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
Ken Keys transcribed 3.4K bytes: > On 7/23/2014 10:57 AM, Matt Pagan wrote: > > > >>> COMMANDs: (combine COMMANDs to specify multiple options simultaneously) > >>> get bridgesRequest vanilla bridges. > >>> get transport [TYPE] Request a Pluggable Transport by TYPE. > >>> get help Displays this message. > >>> get keyGet a copy of BridgeDB's public GnuPG key. > >>> get ipv6 Request IPv6 bridges. > >>> > >>> Currently supported transport TYPEs: > >>> obfs2 > >>> obfs3 > >>> scramblesuit > >>> > > I'm starting to see usability issues with this interface show up on > > the help desk. For example, a person who received the above message > > emailed the help desk asking what to do next. BridgeDB's response is > > reminiscent of a command line program interface. I personally find this > > appealing, but remember that bridges are needed by some of our least > > technical users, many of whom have never even seen a command line > > before. > > > > I'm wondering if the following message would be any less confusing > > (Should I put this suggestion on the ticket?): > > > > > > > > Hey, ! > > > > > > Please respond to this email with one of the following commands: > > (You can combine commands to request multiple items simultaneously) > > > > get bridgesRequests vanilla bridges. > > get transport obfs2Requests obfs2 bridges[*]. > > get transport obfs3Requests obfs3 bridges[*]. > > get transport scramblesuit Requests scramblesuit bridges[*]. > > get help Displays this message. > > get keyGets a copy of BridgeDB's public GnuPG key. > > get ipv6 Requests IPv6 bridges. > > > > BridgeDB can provide bridges with several types of Pluggable > > Transports[*], which can help obfuscate your connections to the > > Tor Network, making it more difficult for anyone watching your > > internet traffic to determine that you are using Tor. > > > > Some bridges with IPv6 addresses are also available, though some > > Pluggable Transports aren't IPv6 compatible. > > > > Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges - > > without any Pluggable Transports - which maybe doesn't sound as > > cool, but they can still help to circumvent internet censorship > > in many cases. > > > > [*]: You may need to request Pluggable Transport type bridges if > > Tor is censored for everyone in your country. > > https://www.torproject.org/docs/pluggable-transports.html > > > > -- > > <3 BridgeDB > > __ > > Public Keys: https://bridges.torproject.org/keys > > This email was generated with rainbows, unicorns, and sparkles > > for y...@email.com on Sunday, 20 July, 2014 at 16:59:19. > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > Are some of our least technical users, many of whom have never even seen a > command line before and who may live in Sub-Saharan Africa or one of the > Stan countries with only a rudimentary knowledge of English going to > understand the difference between vanilla bridges and, say, chocolate almond > bridges? Wouldn't it be better to choose terms that at least translate into > something resembling what they actually mean? Noted. What to call bridges without any pluggable transports has been argued about for years, with the result that everyone ended up calling them different things all over the place, which I believe is worse. Eventually, everyone figured out what "obfsproxy" meant, even if they didn't understand how it worked, nor how to pronounce it. My hope is that a consistent usage of consistently confusing and untranslatable terminology will eventually produce predictable and steadily decreasing levels of user confusion. Should the interface say "get transport unhuggable", perhaps? The obvious choices were: 1. `get tor bridges` / `get transport tor` This is no good because it could potentially cause users to erroneously think that pluggable transport bridges somehow aren't using tor. 2. `get plain bridges` I think this one is bad because people might assume that this one is somehow plaintext, especially if the string were to be translated. Do you have a better suggestion for what to call "vanilla bridges"? -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
