BridgeDB: Users try to add obfsbridges to their normal TBB
Phoul told me today that some users get bridges from the new BridgeDB page, and then try to add them to a normal Tor Browser Bundle (that doesn't understand PTs).
This means that those users completely ignored 'Step 1: Get the Pluggable Transports Tor Browser Bundle'. Can we help those users out somehow?
We could force users to download the bundle by making BridgeDB a wizard that actually requires you to do step 1 before proceeding to step 2. I'm not sure if this is a good idea though. It might infuriate users who know what they are doing.
Activity
I was worried about this. Some users may not realize the TBB is different from the PTTBB. I don't know the best way to help them differentiate them but you're right that we shouldn't have them download the PTTBB each time they want bridges.
What if we add another paragraph on the bridges.html page that says something similar to "If you are not certain you downloaded the PTTBB, please download it now and then add these bridges using the following instructions." which is followed by 'To use the above lines, go to Vidalia's Network settings page, and click "My ISP blocks connections...'.
This isn't a great solution and it won't help users who think they know what they're doing (and therefore won't read the directions), but maybe it will help the new users who only assumed they had the PTTBB when they read Step 1.
This having been said, do we know which type of user is having trouble with this?
It appears to be mostly new users who have never used bridges before encountering this issue.
However, there have also been a few long time bridge users confused by this. I believe it is because they were following their old process of visiting bridges.torproject.org and throwing whatever it spat out into Vidalia.
Trac:
Cc: sysrqb to sysrqb, admin@insecure-complexity.comReplying to aagbsn:
Replying to hsn:
Best is to add support for obfs3 transport to default TBB.
Or, the default TBB is PTTBB? It is via bridges.torproject.org. What about the download page?
Current non-PT-TBB is the "official" TBB. Maybe talking with mikeperry about merging the two once 3.0 stabilizes is a good idea. I don't know the current plan.
Or, we differentiate between bridges and obfsbridges via some clickable UI element?
The idea of the new interface is that it's as simple as possible. Your idea sounds a lot like #9127 (moved) but in terms of default behavior it was assumed that is will be best for bridgedb to distribute PTs by default because, in general, that's what censored users actually need. Making it more difficult to give users what they need didn't seem wise. So the plan is to return all PTs that the current PTTBB supports. This works great, but only if the user is actually using the most recent PTTBB and not the TBB.
Replying to sysrqb:
What if we add another paragraph on the bridges.html page that says something similar to "If you are not certain you downloaded the PTTBB, please download it now and then add these bridges using the following instructions." which is followed by 'To use the above lines, go to Vidalia's Network settings page, and click "My ISP blocks connections...'.
Is there an easy way to help users figure out if they have TBB or PTTBB? We should have a warning on step 2 which says that (1) you will need PTTBB, and (2) if you are trying to use TBB for this, you will see the following error..
Replying to runa:
Is there an easy way to help users figure out if they have TBB or PTTBB?
As far as I know, there is not obvious indication which version the user has.
We should have a warning on step 2 which says that (1) you will need PTTBB, and (2) if you are trying to use TBB for this, you will see the following error..
I think I covered both of these in the mockup, please provide comments/critiques. The wording may need to be revised, so please suggest new messages, also.
Also see #6724 (closed) for another reason that you would get "Error parsing Bridge address".
-
Replying to asn:
Also see #6724 (closed) for another reason that you would get "Error parsing Bridge address".
Actually, are we sure that a user gets "Error parsing Bridge address" when he inserts an obfsuscated
Bridgeline in a torrc without a correspondingClientTransportPluginline? I thought the user was only supposed to get the weird "We were supposed to connect to bridge..." message. -
IMO, the new messages are a bit hacky and don't look particularly nice, but they will probably help users do the right thing.
After fixing them up based on Runa's comments, I'd suggest to deploy them and see what happens. If in the future we find a more elegant solution we can take them down.
Replying to asn:
Replying to asn:
Also see #6724 (closed) for another reason that you would get "Error parsing Bridge address".
Actually, are we sure that a user gets "Error parsing Bridge address" when he inserts an obfsuscated
Bridgeline in a torrc without a correspondingClientTransportPluginline? I thought the user was only supposed to get the weird "We were supposed to connect to bridge..." message.Oh hm, I guess I screwed that up. When I first tested this, I added 'bridge obfs3 x.x.x.x:y' and I got "[Warning] Error parsing Bridge address 'obfs3'" followed by "[Warning] Controller gave us config lines that didn't validate: Bridge line did not parse. See logs for details."
However, when I added 'obfs3 x.x.x.x:y' I received "We were supposed to connect to bridge 'x.x.x.x:y' using pluggable transport 'obfs3', but we can't find a pluggable transport proxy supporting 'obfs3'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running."
phoul, when users have this problem, what do they see?
Replying to runa:
On bug9156_bridges.png, below the box with bridges, please add a description of what the user will see if she tries to add these to TBB and not PTTBB. After that, you can follow with the sentence about downloading PTTBB.
Ok, so you suggest moving the "This is the error message you see if you are using the TBB instead of the PTTBB" part so that it is before the "If you're not 100% sure you have the PTTBB, please download it now" part?
Right now, the third paragraph which contains the error message is supposed to be how the user knows if she is using the wrong bundle. If I understand your suggestion, this will become the first paragraph?
Replying to sysrqb:
Replying to runa:
On bug9156_bridges.png, below the box with bridges, please add a description of what the user will see if she tries to add these to TBB and not PTTBB. After that, you can follow with the sentence about downloading PTTBB.
Ok, so you suggest moving the "This is the error message you see if you are using the TBB instead of the PTTBB" part so that it is before the "If you're not 100% sure you have the PTTBB, please download it now" part?
Right now, the third paragraph which contains the error message is supposed to be how the user knows if she is using the wrong bundle. If I understand your suggestion, this will become the first paragraph?
Yes. The error message should be before the line about downloading PTTBB.
Replying to sysrqb:
Replying to asn:
Replying to asn:
Also see #6724 (closed) for another reason that you would get "Error parsing Bridge address".
Actually, are we sure that a user gets "Error parsing Bridge address" when he inserts an obfsuscated
Bridgeline in a torrc without a correspondingClientTransportPluginline? I thought the user was only supposed to get the weird "We were supposed to connect to bridge..." message.Oh hm, I guess I screwed that up. When I first tested this, I added 'bridge obfs3 x.x.x.x:y' and I got "[Warning] Error parsing Bridge address 'obfs3'" followed by "[Warning] Controller gave us config lines that didn't validate: Bridge line did not parse. See logs for details."
However, when I added 'obfs3 x.x.x.x:y' I received "We were supposed to connect to bridge 'x.x.x.x:y' using pluggable transport 'obfs3', but we can't find a pluggable transport proxy supporting 'obfs3'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running."
I assume that users run into the first error more frequently than the second (i.e. they add "bridge obfs3 ...." to Vidalia because that's what bridges.tpo says they should do). If users should add "obfs3 ..." without "bridge" in front of it, then we need to specify that on the page - or stop giving out bridges in that format.
Comments/feedback on strings? Is anything ambiguous? Will any of them be difficult to translate? Should we include the entire warning the user will see in the message log or will this be enough?
Message on index.html:
Attention: We now distribute pluggable transport bridges, if you have never used these or don't know what these are, please start at Step 1.
Instructions on bridges.html:
To use the above bridge lines, go to Vidalia's Network settings page, and click "My ISP blocks connections to the Tor network". Then add each bridge address one at a time.
Check Vidalia's Message Log, click on the Advanced tab and if you see either of "Error parsing Bridge address" or "We were supposed to connect to bridge 'x.x.x.x:y' using a pluggable transport" then you must download the Pluggable Transports Tor Browser Bundle before you can use these bridges.
If you are not certain you downloaded the Pluggable Transports Tor Browser Bundle, please download it now and then add these bridges using the above instructions.
Trac:
Status: needs_information to needs_reviewReplying to sysrqb:
Comments/feedback on strings? Is anything ambiguous? Will any of them be difficult to translate? Should we include the entire warning the user will see in the message log or will this be enough?
The messages you provided should be enough, but we'll see what happens when we roll this out. Does PTTBB/Vidalia support bridges of the form "IP:port" (i.e. without "bridge" or "obfs2" in front)?
Replying to runa:
Does PTTBB/Vidalia support bridges of the form "IP:port" (i.e. without "bridge" or "obfs2" in front)?
So this goes back to:
Replying to runa:
I assume that users run into the first error more frequently than the second (i.e. they add "bridge obfs3 ...." to Vidalia because that's what bridges.tpo says they should do). If users should add "obfs3 ..." without "bridge" in front of it, then we need to specify that on the page - or stop giving out bridges in that format.
If the only instruction we are providing right now is for Vidalia, I'm not sure if there's a good reason to tell the users to add "bridge ...." if that is invalid syntax. For the screenshot I removed the "bridge" keyword while I was testing, Vidalia expects either "ip:port" or "pt ip:port". We'll need to chat with mikeperry to see what format TorButton expects in TBB 3.0.
Replying to asn:
People are still getting confused by this, right?
BTW, is there a git branch with code for what is seen in
bug9156_sidebyside.png? Indeed there is :)Should I hit the merge/deploy button?
https://github.com/sysrqb/bridgedb.git bug9156_rebased
There is one addition to this patch. I added a description of pluggable transports to the page, just below "What are bridges?".
"What are pluggable transports? Pluggable Transports are used with specific bridges to help you circumvent censorship. They accomplish this by transforming the network traffic between you and the bridge so that a censor should not be able to detect that you are using Tor."
Replying to sysrqb:
Replying to asn:
Should I hit the merge/deploy button?
https://github.com/sysrqb/bridgedb.git bug9156_rebased
There is one addition to this patch. I added a description of pluggable transports to the page, just below "What are bridges?".
"What are pluggable transports? Pluggable Transports are used with specific bridges to help you circumvent censorship. They accomplish this by transforming the network traffic between you and the bridge so that a censor should not be able to detect that you are using Tor."
Look good! Thanks! cherry-pick'd into my master here for the next deployment. (The cherry-pick was because it was only one commit, and there was a tiny bit of EOL whitespace.)
Though, it seems that currently, for TBB-3.x, TorButton has no concept of bridges. Or, at least, I could find none in the preferences menu, nor in about:config. Perhaps there is some sekrit FF magic variable somewhere that I do not know of, but then I would wager that most users do not know of it either.
So this is fine for TBB-2.x users, but might need to get changed again later.
Trac:
Cc: sysrqb, admin@insecure-complexity.com to sysrqb, admin@insecure-complexity.com, isis@torproject.org
Keywords: important deleted, N/A added
Owner: N/A to isis
Status: needs_review to accepted
Replying to isis:
Though, it seems that currently, for TBB-3.x, TorButton has no concept of bridges. Or, at least, I could find none in the preferences menu, nor in about:config. Perhaps there is some sekrit FF magic variable somewhere that I do not know of, but then I would wager that most users do not know of it either.
Click on the green onion, and go to "Open Network Settings". This is also the dialog you get on first startup if you click 'configure' rather than 'connect'.
Replying to arma:
Click on the green onion, and go to "Open Network Settings". This is also the dialog you get on first startup if you click 'configure' rather than 'connect'.
I think I knew that at some point, a long, long time ago, when I didn't disable TorButton. Thanks.
I put the details of testing with TBB-3.0.3a in ticket #9445 (moved).
tl;dr:
- TBB-3.0.3a handles regular bridges (input as
<bridge_ipaddr>:<bridge_orport>correctly, but only after closing and restarting TBB. - TBB-3.0.3a doesn't handle PT bridges correctly. Specifically, it seems to parse the text box of user input, and strangely it inserts newlines after the transport name strings which it didn't understand, i.e.
obfs3 3.3.3.3:3333\nbecomesobfs3\n3.3.3.3:3333\n. If it is doing this parsing, perhaps it can just remove those lines entirely, because using the bridge on a port configured for PT-use 1) isn't going to work, and 2) is going to give away by a normal Tor connection the location of the bridge to surveilling parties and/or censors.
An even better thing to do would be an "Uh-oh spaghettios. Did you mean to download <link_to_PT_bundle>?" and if the user responds "no" then strip the lines which began with PT transport name strings.
Trac:
Keywords: N/A deleted, pt, usability, torlaucher, ui added- TBB-3.0.3a handles regular bridges (input as
As of right now, only vanilla bridges have the "bridge" prefix removed on the web interface. PT bridges still have it, i.e.:
1.2.3.4:4444 bridge obfs3 2.2.2.2:8888 99.88.77.66:9999This is fixed in this hotfix branch.
Replying to isis:
- TBB-3.0.3a handles regular bridges (input as
<bridge_ipaddr>:<bridge_orport>correctly, but only after closing and restarting TBB.
Does the above comment mean that Tor Launcher needs to tell the tor process to start using the bridges right away? Does this scenario (add bridges while tor is up and running) work better with the older TBB 2.x/Vidalia?
- TBB-3.0.3a doesn't handle PT bridges correctly. Specifically, it seems to parse the text box of user input, and strangely it inserts newlines after the transport name strings which it didn't understand, i.e.
obfs3 3.3.3.3:3333\nbecomesobfs3\n3.3.3.3:3333\n. If it is doing this parsing, perhaps it can just remove those lines entirely, because using the bridge on a port configured for PT-use 1) isn't going to work, and 2) is going to give away by a normal Tor connection the location of the bridge to surveilling parties and/or censors.
An even better thing to do would be an "Uh-oh spaghettios. Did you mean to download <link_to_PT_bundle>?" and if the user responds "no" then strip the lines which began with PT transport name strings.
Tor Launcher tries to be smart and accept bridge lists even when the newlines are missing. See: https://gitweb.torproject.org/tor-launcher.git/blob/fb97857c0e06eaa5d69ea4f9f7a75a330dad2331:/src/chrome/content/network-settings.js#l842
But it sounds like that is a mistake. Is there a spec that indicates what BridgeDB will output? Or can someone please describe the possibilities?
Trac:
Cc: sysrqb, admin@insecure-complexity.com, isis@torproject.org to sysrqb, admin@insecure-complexity.com, isis@torproject.org, mcs, brade- TBB-3.0.3a handles regular bridges (input as
mcs: Yeah, I think we should make Tor Launcher accept a direct cut and paste from bridges.tp.o and send it to Tor. See #9445 (moved). I think the only santization we should do there is to check for 'bridge ' in the beginning of the line, and if it's there, send it directly, and if it's not, add it in.
Unless someone more deeply familiar with the full scope of what PT strings contain can say why this is a bad idea?
Replying to mikeperry:
mcs: Yeah, I think we should make Tor Launcher accept a direct cut and paste from bridges.tp.o and send it to Tor. See #9445 (moved). I think the only santization we should do there is to check for 'bridge ' in the beginning of the line, and if it's there, send it directly, and if it's not, add it in.
I think this is a good idea. I added a section to the updated BridgeDB spec for this. This is correct, for now, but I suspect this will change in the near future. 1) When Vidalia is deprecated, ideally Tor Launcher should accept/expect the "bridge" keyword again, thus bringing TBB's expectations in alignment with valid torrc syntax. 2) We will likely begin distributing the bridge fingerprint, again, when Vidalia is out of the picture (#9499 (moved)). So it will look something like:
"bridge" SP <address:port> SP <fingerprint> NLI think we need to clarify how tor expects the fingerprint on PT lines [https://trac.torproject.org/projects/tor/ticket/9462#comment:3 [0]].
-
Replying to sysrqb:
Replying to mikeperry:
mcs: Yeah, I think we should make Tor Launcher accept a direct cut and paste from bridges.tp.o and send it to Tor. See #9445 (moved). I think the only santization we should do there is to check for 'bridge ' in the beginning of the line, and if it's there, send it directly, and if it's not, add it in.
I think this is a good idea. I added a section to the updated BridgeDB spec for this. This is correct, for now, but I suspect this will change in the near future. 1) When Vidalia is deprecated, ideally Tor Launcher should accept/expect the "bridge" keyword again, thus bringing TBB's expectations in alignment with valid torrc syntax. 2) We will likely begin distributing the bridge fingerprint, again, when Vidalia is out of the picture (#9499 (moved)). So it will look something like:
"bridge" SP <address:port> SP <fingerprint> NL }}} I think we need to clarify how tor expects the fingerprint on PT lines [https://trac.torproject.org/projects/tor/ticket/9462#comment:3 [0]].Actually, a full-fledged bridge line would look like this: {{{ Bridge method address:port [[keyid=]id-fingerprint] [k=v] [k=v] [k=v]
I'm fine with completely removing the optional `keyid`, since the fingerprint can be distinguished from `k=v` values by using its length or the fact that it shouldn't contain equal signs. So, a bridge line could look like this:Bridge obfs666 7.145.2.41:1338 D586D18309DED4CD6D57C18FDB97EFA96D330566 shared-secret=nosecrets texture-type=bamboo
Replying to mcs:
Replying to isis:
- TBB-3.0.3a handles regular bridges (input as
<bridge_ipaddr>:<bridge_orport>correctly, but only after closing and restarting TBB.
Does the above comment mean that Tor Launcher needs to tell the tor process to start using the bridges right away?
Yes. Before the Tor process is initialized, actually.
Does this scenario (add bridges while tor is up and running) work better with the older TBB 2.x/Vidalia?
As far as I know, a Tor process must be started with
UseBridges 1and at least oneBridge 1.2.3.4:5555line in its torrc to use bridges, and it will not work to put these lines into the torrc of an already-running Tor process and send a SIGHUP to it -- it must be started with the lines already present.So no, it does not work better with the older TBB-2.x and Vidalia. I think (?) that Vidalia forces you to restart TBB entirely if you tell it that you want to use bridges. I don't actually remember.
- TBB-3.0.3a doesn't handle PT bridges correctly. Specifically, it seems to parse the text box of user input, and strangely it inserts newlines after the transport name strings which it didn't understand, i.e.
obfs3 3.3.3.3:3333\nbecomesobfs3\n3.3.3.3:3333\n. If it is doing this parsing, perhaps it can just remove those lines entirely, because using the bridge on a port configured for PT-use 1) isn't going to work, and 2) is going to give away by a normal Tor connection the location of the bridge to surveilling parties and/or censors.
An even better thing to do would be an "Uh-oh spaghettios. Did you mean to download <link_to_PT_bundle>?" and if the user responds "no" then strip the lines which began with PT transport name strings.
Tor Launcher tries to be smart and accept bridge lists even when the newlines are missing. See: https://gitweb.torproject.org/tor-launcher.git/blob/fb97857c0e06eaa5d69ea4f9f7a75a330dad2331:/src/chrome/content/network-settings.js#l842
I see... That is great. :)
But it sounds like that is a mistake.
No, not at all! The problem is actually that it is overdoing it: extra newlines are being inserted between the
transport_methodand theaddress:port.Is there a spec that indicates what BridgeDB will output? Or can someone please describe the possibilities?
Unfortunately there is not yet, because it is not yet precisely specified what BridgeDB should be expecting from descriptors it gets from the BridgeAuthority. But it is being sorted out currently. The ticket is #9013 (moved), if anyone has input.
Basically, we need to specify how a Tor relay acting as a bridge writes the
transportline of its@type bridge-extra-info 1.1+descriptor (see this metrics page for explanations of descriptor@types), which will get sent to the BridgeAuthority, who then sends all of these to BridgeDB. BridgeDB will then need to parse these descriptors, and output<something>for TBB users.Historically, the only reason why BridgeDB added the string prefix
"bridge "to the beginning of the<something>lines which it returned was because it was assumed that people would be copy+pasting these directly into their torrc. Vidalia freaks out if you give it, for example, the input"bridge 1.2.3.4:5555", so we recently removed the"bridge "prefix.For the future, BridgeDB can give users a
<something>which can be any format at all, so if there is something which is easier for TorLaucher to parse/handle, please say so. I am for whichever formats causes the least pain/overhead/parsing for all the components involved, ergo alternating adding in and taking away the"bridge "prefix in every other component seems ridiculous.- TBB-3.0.3a handles regular bridges (input as
Replying to mikeperry:
mcs: Yeah, I think we should make Tor Launcher accept a direct cut and paste from bridges.tp.o and send it to Tor. See #9445 (moved). I think the only santization we should do there is to check for 'bridge ' in the beginning of the line, and if it's there, send it directly, and if it's not, add it in.
So, I propose the following:
If TorLauncher decides that it wants the
"bridge "string prefix, i.e. bridge lines returned by BridgeDB to be of the formBridge [transport_method] address:port [keyid=fingerprint] [K=V] [K=V](where square brackets indicate that the field is optionally present), then BridgeDB should revert commits 20d6171844d275f768229a1a4052a31fd42cd4bd and 792cfd99bb3a4d5a116202e76532232aba6e6312 and re-add the prefix back in now, to avoid confusing people by switching back and forth.If TorLauncher would like otherwise, i.e. to keep the prefix removed, then we should likewise switch now.
Unless someone more deeply familiar with the full scope of what PT strings contain can say why this is a bad idea?
At present, they can contain anything, and be any length.
Trac:
Keywords: N/A deleted, important added
Status: accepted to needs_informationShould BridgeDB keep the "bridge " prefix or get rid of it? We can't stay in limbo with it half removed, and I really don't want to switch back and forth.
This basically boils down to:
PlanA
We get rid of the
"bridge "prefix on the lines that BridgeDB returns to users. Doing so means:- Continuing to cause problems for Vidalia users.
- Continuing to cause problems for anyone still using TBB-2.x (though this problem will disappear with time).
PlanB
We keep the prefix. Doing so means:
- We won't have to explain to torrc-using people that they need to add it to the beginning of every line.
- We remain backward-compatible with anything which parses this output and was expecting there to be lines starting with
"bridge ". - TorLauncher can continue to parse for it, instead of having to parse for the IP address right away (which is likely more difficult, though in JS I don't know).
I say fuck Vidalia, and vote for PlanB.
Trac:
Priority: normal to majormentioned in issue #9445 (moved)
mentioned in issue #9865 (moved)
mentioned in issue #16895 (moved)
