Hi everyone,
A short time ago BridgeDB learned how to accept some more commands via email[0]. Below is an example of the current help/overview autoresponse email[1] that users receive (in English, we do have translations).
These commands may not be optimal, so we'd love to be given feedback on this so we can improve it. Currently, with the recent changes, we require all commands begin with 'get' and then we check which keyword follows it ('bridges', 'transport', 'help', 'key', etc). This certainly makes the parsing logic easy (and I am a fan of KISS), but it may be true that this is a bit too strict and decreases its usability. Would it be better if we were more lax? For example, instead of requiring:
'get transport <TYPE>'
we change this to:
'[[get] transport] <TYPE>'
Therefore the 'get' and 'transport' keywords are optional (and 'get' is only used if you use 'transport'). <TYPE> is the pluggable tranport method name you want the bridges to support.
I think this simplifies the user interaction but I don't know if it's significant and to what extent most users care about this. It should be mentioned that prior to the recent changes, sending a blank email to bridges@bridges.torproject.org was equivilent to sending an email that contained 'get bridges' because we didn't actually check for 'get bridges' at all, we do this now, though.
So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved?
Thanks! Matt
[0] https://trac.torproject.org/projects/tor/ticket/7550
[1]
Hey, <you>! Welcome to BridgeDB!
COMMANDs: (combine COMMANDs to specify multiple options simultaneously) get bridges Request vanilla bridges. get transport [TYPE] Request a Pluggable Transport by TYPE. get help Displays this message. get key Get a copy of BridgeDB's public GnuPG key. get ipv6 Request IPv6 bridges.
Currently supported transport TYPEs: obfs2 obfs3 scramblesuit
BridgeDB can provide bridges with several types of Pluggable Transports[0], 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.
-- <3 BridgeDB ______________________________________________________________________ Public Keys: https://bridges.torproject.org/keys This email was generated with rainbows, unicorns, and sparkles for your@email.com on Sunday, 20 July, 2014 at 16:59:19.
On Sun, Jul 20, 2014 at 06:52:44PM +0000, Matthew Finkel wrote:
So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved?
Non-technical users might be confused by the parameters. Perhaps we could drop the "transport" parameter and have the following flat hierarchy? get vanilla get ipv6 get obfs3 get fte get scramblesuit etc
An even simpler option would be to also drop "get" and simply look for the keywords "vanilla", "obfs3", ... in the email subject and body.
Also, if the user fails to form a valid email, I think we should still reply with a set of bridges.
Cheers, Philipp
On Sun, Jul 20, 2014 at 06:07:03PM -0400, Philipp Winter wrote:
On Sun, Jul 20, 2014 at 06:52:44PM +0000, Matthew Finkel wrote:
So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved?
Non-technical users might be confused by the parameters. Perhaps we could drop the "transport" parameter and have the following flat hierarchy? get vanilla get ipv6 get obfs3 get fte get scramblesuit etc
So you think we should accept (roughly) the regex "^.*(\w*)$" and return bridges based on the last token? I think we can do something like this. I do think, based on other responses, that we have some other open questions, though. Listing multiple token on a single will become more difficult, but we can figure something out.
An even simpler option would be to also drop "get" and simply look for the keywords "vanilla", "obfs3", ... in the email subject and body.
Also, if the user fails to form a valid email, I think we should still reply with a set of bridges.
This is a tricky problem:
"I'm TorBrowser, I know about N bridges, but I don't know which ones I should use, so I will pick a few and try them."
"I'm <adversary>. Wow, look at this traffic coming from <ip address>! That looks odd, I see this traffic that looks like Tor, BLOCK! And another flow that looks like obfs2, BLOCK! and another that looks like...huh, I don't recognize it. Let's play it safe. BLOCK!"
Alternatively the adversary could simply detect recognizable tor-flows and then track all subsequent traffic and see what it does and how it behaves, thus building a profile of it.
We need to be very careful about blindly giving out different transports together. We can default to a few obfs3 bridges, though, instead of obfs3, scramblesuit, and fteproxy.
The above example is obvious contrived, and my not be used (often), but it is a risk, and I'm mostly against playing that game unless we are significantly harming peoples' abilities to access the internet.
Thanks for the feedback Philipp, very much appreciated!
COMMANDs: (combine COMMANDs to specify multiple options simultaneously) get bridges Request vanilla bridges. get transport [TYPE] Request a Pluggable Transport by TYPE. get help Displays this message. get key Get 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, <you>!
Please respond to this email with one of the following commands: (You can combine commands to request multiple items simultaneously)
get bridges Requests vanilla bridges. get transport obfs2 Requests obfs2 bridges[*]. get transport obfs3 Requests obfs3 bridges[*]. get transport scramblesuit Requests scramblesuit bridges[*]. get help Displays this message. get key Gets 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 your@email.com on Sunday, 20 July, 2014 at 16:59:19.
On 7/23/2014 10:57 AM, Matt Pagan wrote:
COMMANDs: (combine COMMANDs to specify multiple options simultaneously) get bridges Request vanilla bridges. get transport [TYPE] Request a Pluggable Transport by TYPE. get help Displays this message. get key Get 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, <you>!
Please respond to this email with one of the following commands: (You can combine commands to request multiple items simultaneously)
get bridges Requests vanilla bridges. get transport obfs2 Requests obfs2 bridges[*]. get transport obfs3 Requests obfs3 bridges[*]. get transport scramblesuit Requests scramblesuit bridges[*]. get help Displays this message. get key Gets 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 your@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?
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 bridges Request vanilla bridges. get transport [TYPE] Request a Pluggable Transport by TYPE. get help Displays this message. get key Get 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, <you>!
Please respond to this email with one of the following commands: (You can combine commands to request multiple items simultaneously)
get bridges Requests vanilla bridges. get transport obfs2 Requests obfs2 bridges[*]. get transport obfs3 Requests obfs3 bridges[*]. get transport scramblesuit Requests scramblesuit bridges[*]. get help Displays this message. get key Gets 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 your@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: [...]
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:
`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.
`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,
El jue, 24-07-2014 a las 06:54 +0000, 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:
`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.
`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
Nima Fatemi nima@riseup.net:
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?
On Thu, Jul 24, 2014 at 04:16:44PM +0000, harmony wrote:
Nima Fatemi nima@riseup.net:
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?
Yes, but this does make parsing the emails more difficult, perhaps we can simply ask translators to translate the respective tokens and then the email distributor checks each of them. It seems that we may make some people sad if we only do this for some users. Adding this will probably be non-trivial, though :(
Thanks for the idea!
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 nima@riseup.net:
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:
- `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.
- `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
On Thu, Jul 24, 2014 at 04:01:34PM -0400, Israel Leiva wrote:
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,
I actually think your idea about accepting "[get] transport" as a valid help request, returning a description of each supported PT, is a great idea. We currently have some information about PTs on the website distributor, but the email distributor is lacking.
I believe we are also planning on signing every email (soonish?) and will provide the same footer as the help message (if this changed, then we should change it back).
We also do try to discard fake requests, isis actually added another yesterday!
Basically, what I've gotten from this thread is that the email distributor is doing an Okay job right now, but if it was smarter about how it parsed messages and made more assumptions about what the user actually wanted then this would make it more usable and could, possibly, make the world a better place. I think this latter decision deserves a separate thread, so I won't sidetrack this, but bring this back on-point, do you have any other suggestions related to the current format of the email or of the flow?
Thanks for your feedback!
On Sat, Jul 26, 2014 at 09:42:04PM -0700, Ken Keys wrote:
On 7/26/2014 1:54 AM, Matthew Finkel wrote:
We also do try to discard fake requests, isis actually added another yesterday!
Could you elaborate on this? I don't understand what you mean my fake requests but the incident sounds interesting.
Sure :) Fake requests meaning requests that do not appear to be from users who need bridges to access the Tor network.
The way we currently do it is by keeping a blacklist of known-spammy email addresses. When we receive a request for bridges we compare the source email address against the email addresses in the blacklist. If they are identical or very similar[0] then we probably deny[1] the request. See the ticket[2] for some more details.
[0] https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/20b3063ffb81... [1] https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/98a1ed16d711... [2] https://trac.torproject.org/projects/tor/ticket/9385
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:
`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.
`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/aut... [1]: https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/lib/bridgedb/email/req...
isis:
PS: why are we still shipping obfs2 bridges?!
tl;dr: Because we have them.
The protocol is known to be broken and fingerprintable. That's something we know. Not users. If BridgeDB is giving them out, then it must be that it's ok to use, right?
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Lunar wrote:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
We should really be reaching out to those running obfs2 nodes and convincing them to move to obfs3 if at all possible.
Related question: are there geographic areas where standard bridges are being blocked, where obfs2 are still usable? If so, maybe in the future it would be possible to restrict distribution of remaining obfs2 bridges to those areas. But on the whole I agree that giving those out is problematic. Unless they comprise a large portion of bridges, maybe it's time to phase them out of bridgeDB (not necessarily TBB).
best, Griffin
- -- Wherever truth, love and laughter abide, I am there in spirit. - -Bill Hicks
Griffin Boyce transcribed 1.6K bytes:
Lunar wrote:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
We should really be reaching out to those running obfs2 nodes and convincing them to move to obfs3 if at all possible.
Related question: are there geographic areas where standard bridges are being blocked, where obfs2 are still usable?
Yes, some university/corporate networks.
If so, maybe in the future it would be possible to restrict distribution of remaining obfs2 bridges to those areas.
Unfortunately, this is rather hard to detect in automated fashion, and I would have no interest in building nor maintaining such a list.
But on the whole I agree that giving those out is problematic. Unless they comprise a large portion of bridges, maybe it's time to phase them out of bridgeDB (not necessarily TBB).
Well, you're correct that obfs2 isn't the majority anymore (finally!), but there still is a rather huge chunk of bridges which are obfs2:
bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport obfs2' from-authority/cached-extrainfo* | wc -l 2071 bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport obfs3' from-authority/cached-extrainfo* | wc -l 2840 bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport scramblesuit' from-authority/cached-extrainfo* | wc -l 2221 bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport fte' from-authority/cached-extrainfo* | wc -l 625
best, Griffin
-- Wherever truth, love and laughter abide, I am there in spirit. -Bill Hicks _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
isis transcribed 4.0K bytes:
bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport obfs2' from-authority/cached-extrainfo* | wc -l 2071 bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport obfs3' from-authority/cached-extrainfo* | wc -l 2840 bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport scramblesuit' from-authority/cached-extrainfo* | wc -l 2221 bridgedb@ponticum:/srv/bridges.torproject.org$ grep 'transport fte' from-authority/cached-extrainfo* | wc -l 625
I forgot to mention that these are non-deduplicated. Perhaps a little rough, but the numbers appear to be accurate.
Lunar transcribed 2.1K bytes:
isis:
PS: why are we still shipping obfs2 bridges?!
tl;dr: Because we have them.
The protocol is known to be broken and fingerprintable. That's something we know. Not users. If BridgeDB is giving them out, then it must be that it's ok to use, right?
It still works to get past many corporate/university firewalls, from what I understand. And the UI clearly says that "obfs3" is recommended. It even defaults to giving "obfs3" if you ask for transports. You'd have to specifically request "obfs2" to get them.
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out.
isis:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL.
That's news to me. Any pointers?
On Fri, 25 Jul 2014 10:00:01 +0200 Lunar lunar@torproject.org wrote:
isis:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL.
That's news to me. Any pointers?
Well, the protocol is ok, but it is vulnerable to active probing (eg: See something they don't recognize, flag the destination IP/Port, call back later). Doing so on a mass scale is *quite* expensive since the obfs3 handshake isn't exactly cheap, but probably is in the reach of a nation-state adversary (China springs to mind).
There also are a few interesting statistical attacks that are possible vs the obfs3 protocol if you make guesses about the inner payload, but such things are unnecessary for obfs3 (and ScrambleSuit/obfs4 both have some defenses against those, although not all are enabled as a performance tradeoff).
Regards,
isis:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out.
The holy grail will never exist, indeed. I fail too see why this would be a reason to continue giving out solutions that are known to be bad when they have suitable replacement.
On Fri, 25 Jul 2014 13:25:31 +0200 Lunar lunar@torproject.org wrote:
isis:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out.
The holy grail will never exist, indeed. I fail too see why this would be a reason to continue giving out solutions that are known to be bad when they have suitable replacement.
For what it's worth, the official plan is to kill off obfs2 once we figure out how we want to handle deprecating old transports.
https://trac.torproject.org/projects/tor/ticket/10314
Personally I think when we deploy the next round of transports (meek, and either ScrambleSuit or obfs4) would be the right time to revisit this, and I can't think of a good reason to keep obfs2 around beyond "there are bridges that only support obfs2" which is a fairly terrible reason keep distributing the protocol to new users.
My other objection to the idea a while back was that Orbot only supported obfs2, but that's been fixed for a while now.
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Yawning Angel transcribed 2.9K bytes:
On Fri, 25 Jul 2014 13:25:31 +0200 Lunar lunar@torproject.org wrote:
isis:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out.
The holy grail will never exist, indeed. I fail too see why this would be a reason to continue giving out solutions that are known to be bad when they have suitable replacement.
For what it's worth, the official plan is to kill off obfs2 once we figure out how we want to handle deprecating old transports.
Thanks, I was looking for that one. :)
Personally I think when we deploy the next round of transports (meek, and either ScrambleSuit or obfs4) would be the right time to revisit this, and I can't think of a good reason to keep obfs2 around beyond "there are bridges that only support obfs2" which is a fairly terrible reason keep distributing the protocol to new users.
Scramblesuit is "deployed", if you ask me... We've got roughly 2221 scramblesuit supporting bridges.
My other objection to the idea a while back was that Orbot only supported obfs2, but that's been fixed for a while now.
So... I'm going to wait for an update from the Huggable Transport folks, telling me to phase out obfsXYZ, whenever that happens. Until then, obfs3 is still the default transport distributed.
Does this sound okay to everyone? Otherwise you're shoving me back into the hell where I get yelled at if I don't make a unilateral decision, and also get yelled at if I do make a decision. It's kind of annoying to get yelled at all the time. :(
- -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
On Fri, 25 Jul 2014 22:19:40 +0000 isis isis@torproject.org wrote:
Personally I think when we deploy the next round of transports (meek, and either ScrambleSuit or obfs4) would be the right time to revisit this, and I can't think of a good reason to keep obfs2 around beyond "there are bridges that only support obfs2" which is a fairly terrible reason keep distributing the protocol to new users.
Scramblesuit is "deployed", if you ask me... We've got roughly 2221 scramblesuit supporting bridges.
Kind of. TBB/Orbot and the FirefoxOS code all need to move to 0.2.5.x for those bridges to actually be useful which I belive is Real Soon Now. Just having bridges that only people that build stuff on their own can connect to is a bit silly.
My other objection to the idea a while back was that Orbot only supported obfs2, but that's been fixed for a while now.
So... I'm going to wait for an update from the Huggable Transport folks, telling me to phase out obfsXYZ, whenever that happens. Until then, obfs3 is still the default transport distributed.
Does this sound okay to everyone? Otherwise you're shoving me back into the hell where I get yelled at if I don't make a unilateral decision, and also get yelled at if I do make a decision. It's kind of annoying to get yelled at all the time. :(
That's fine by me. I belive obfs3 should be ok for a while, and there are easier ways to identify bridges via active probing than doing on obfs3 handshake anyway (Fixing such things is also on my TODO list).
Regards,
On Fri, Jul 25, 2014 at 10:19:40PM +0000, isis wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Yawning Angel transcribed 2.9K bytes:
On Fri, 25 Jul 2014 13:25:31 +0200 Lunar lunar@torproject.org wrote:
isis:
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out.
The holy grail will never exist, indeed. I fail too see why this would be a reason to continue giving out solutions that are known to be bad when they have suitable replacement.
For what it's worth, the official plan is to kill off obfs2 once we figure out how we want to handle deprecating old transports.
Thanks, I was looking for that one. :)
Personally I think when we deploy the next round of transports (meek, and either ScrambleSuit or obfs4) would be the right time to revisit this, and I can't think of a good reason to keep obfs2 around beyond "there are bridges that only support obfs2" which is a fairly terrible reason keep distributing the protocol to new users.
Scramblesuit is "deployed", if you ask me... We've got roughly 2221 scramblesuit supporting bridges.
Nice!
My other objection to the idea a while back was that Orbot only supported obfs2, but that's been fixed for a while now.
So... I'm going to wait for an update from the Huggable Transport folks, telling me to phase out obfsXYZ, whenever that happens. Until then, obfs3 is still the default transport distributed.
Does this sound okay to everyone? Otherwise you're shoving me back into the hell where I get yelled at if I don't make a unilateral decision, and also get yelled at if I do make a decision. It's kind of annoying to get yelled at all the time. :(
I thought Roger made all of them decisions ;)
I think this is a fine plan for now, at least for the next n tags. We know it's only a matter of time before it will be deprecated, but I think it's worth squeezing as much out of them as possible. Scramblesuit (and obfs4 at some future time) can become default(s) at a future time when the arms race nears equilibrium (as far as we can tell).
On Fri, Jul 25, 2014 at 07:32:42AM +0000, isis wrote:
Lunar transcribed 2.1K bytes:
isis:
PS: why are we still shipping obfs2 bridges?!
tl;dr: Because we have them.
The protocol is known to be broken and fingerprintable. That's something we know. Not users. If BridgeDB is giving them out, then it must be that it's ok to use, right?
It still works to get past many corporate/university firewalls, from what I understand. And the UI clearly says that "obfs3" is recommended. It even defaults to giving "obfs3" if you ask for transports. You'd have to specifically request "obfs2" to get them.
I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them.
obfs2 is dangerous when used to circumvent the strongest adversaries in the world. Luckily we have a very diverse userbase and not all users have the same requirements :) (I honestly do say this in the most loving way possible)
We can't just make Tor Browser stop accepting obfs2 because some people are using obfs2 bridges right now. But we shouldn't add more people to the set of users of a broken protocol.
Obfs3 is also "broken", it's just that we haven't yet seen a DPI box do it IRL. If you want me to only hand out the holy grail, I'm never going to hand anything out.
It's probably safer to say that obfs3 is a weaker protocol than we think may adequately protect users against some powerful adversaries. (Yes, I'm splitting hairs/bikeshedding, please don't throw your laptop! but I think we, as a community, have not seen evidence to support this yet (as far as I know) and saying it is broken is unnecessarily scary right now). This could change at any time, though, so we should make sure we're ready to flip the default to the next transport when that time comes (and I do think we are). <3
Matthew Finkel:
I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them.
But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2?
Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]?
Sorry, but as a fail to see good reasons, I just don't get the logic.
For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them?
What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3?
What does the Tor Project get when misleading users?
[1]: https://bugs.debian.org/725779
Lunar transcribed 2.9K bytes:
Matthew Finkel:
I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them.
But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2?
Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]?
Sorry, but as a fail to see good reasons, I just don't get the logic.
For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them?
What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3?
Alice's university sysadmin / corporate IT department / highschool administration / overly-conservative techie parents block tor, by protocol identification after watching Alice's tor handshake with the first hop. They block relays from the public list. Their firewall runs Bro or similar, and they're able to detect and block bridges too. [0]
They see an obfs2 handshake, and they try to connect to the obfs2 IP:port using vanilla tor (without any PTs). It doesn't work. Isn't not their job to spend all day trying to figure out what that weird protocol was, and they're not savvy enough to realise that the handshake is also fingerprintable.
That's where obfs2 still works just fine.
[0]: https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTr...
isis:
Lunar transcribed 2.9K bytes:
Matthew Finkel:
I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them.
But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2?
Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]?
Sorry, but as a fail to see good reasons, I just don't get the logic.
For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them?
What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3?
Alice's university sysadmin / corporate IT department / highschool administration / overly-conservative techie parents block tor, by protocol identification after watching Alice's tor handshake with the first hop. They block relays from the public list. Their firewall runs Bro or similar, and they're able to detect and block bridges too. [0]
They see an obfs2 handshake, and they try to connect to the obfs2 IP:port using vanilla tor (without any PTs). It doesn't work. Isn't not their job to spend all day trying to figure out what that weird protocol was, and they're not savvy enough to realise that the handshake is also fingerprintable.
That's where obfs2 still works just fine.
But obfs3 will work just as fine. Why continue giving out obfs2 bridges?
Lunar transcribed 3.7K bytes:
isis:
Lunar transcribed 2.9K bytes:
Matthew Finkel:
I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them.
But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2?
Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]?
Sorry, but as a fail to see good reasons, I just don't get the logic.
For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them?
What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3?
Alice's university sysadmin / corporate IT department / highschool administration / overly-conservative techie parents block tor, by protocol identification after watching Alice's tor handshake with the first hop. They block relays from the public list. Their firewall runs Bro or similar, and they're able to detect and block bridges too. [0]
They see an obfs2 handshake, and they try to connect to the obfs2 IP:port using vanilla tor (without any PTs). It doesn't work. Isn't not their job to spend all day trying to figure out what that weird protocol was, and they're not savvy enough to realise that the handshake is also fingerprintable.
That's where obfs2 still works just fine.
But obfs3 will work just as fine. Why continue giving out obfs2 bridges?
Because we have only finite obfs3 bridges. If we had infinite, sure, everyone should use them. But in the meantime, I still see several uses for obfs2 bridges. Using obfs2, when the obfuscation provided is sufficent for your situation, allows for more obfs3 bridges to be distributed to people with a greater need for them.
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
Griffin Boyce transcribed 0.8K bytes:
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.
Okay, this one works for me. If people are going to continue complaining, this one's in the bucket of possible new names.
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.
+1 for naming transports after Pokémon. Or the transformerish Voltron cartoon.
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
Matt Pagan transcribed 2.6K bytes:
COMMANDs: (combine COMMANDs to specify multiple options simultaneously) get bridges Request vanilla bridges. get transport [TYPE] Request a Pluggable Transport by TYPE. get help Displays this message. get key Get 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, <you>!
Please respond to this email with one of the following commands: (You can combine commands to request multiple items simultaneously)
get bridges Requests vanilla bridges. get transport obfs2 Requests obfs2 bridges[*]. get transport obfs3 Requests obfs3 bridges[*]. get transport scramblesuit Requests scramblesuit bridges[*]. get help Displays this message. get key Gets 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 your@email.com on Sunday, 20 July, 2014 at 16:59:19.
Thanks for the UI feedback! This is really helpful.
If it seems like users will be less confused with the "transport TYPEs" section gone, I'm totally happy to try something else. To be honest, I had no idea what would be the best way to design that part.
It probably needs a new ticket.
-
Griffin Boyce -
harmony -
isis -
Israel Leiva -
Ken Keys -
Lunar -
Matt Pagan -
Matthew Finkel -
Nima Fatemi -
Noel David Torres Taño -
Philipp Winter -
Yawning Angel