Opened 10 months ago

Closed 5 weeks ago

#9156 closed task (fixed)

BridgeDB: Users try to add obfsbridges to their normal TBB

Reported by: asn Owned by: isis
Priority: major Milestone:
Component: BridgeDB Version:
Keywords: pt, usability, torlaucher, ui, important Cc: sysrqb, admin@…, isis@…, mcs, brade
Actual Points: Parent ID:
Points:

Description

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.

Child Tickets

TicketSummaryOwner
#5851Make BridgeDB's output compatible with both Vidalia & TorLauncherisis

Attachments (4)

bug9156_index.png (78.9 KB) - added by sysrqb 10 months ago.
Front page mockup
bug9156_bridges.png (84.5 KB) - added by sysrqb 10 months ago.
Bridges mockup
bug9156_sidebyside.png (157.5 KB) - added by sysrqb 10 months ago.
index.html and bridges.html side-by-side
bug9157_descr_pt.png (66.3 KB) - added by sysrqb 8 months ago.
Description of pluggable transports

Download all attachments as: .zip

Change History (41)

comment:1 follow-up: Changed 10 months ago by sysrqb

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?

comment:2 Changed 10 months ago by sysrqb

  • Status changed from new to needs_information

comment:3 Changed 10 months ago by phoul

  • Cc admin@… added

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.

comment:4 follow-up: Changed 10 months ago by hsn

Best is to add support for obfs3 transport to default TBB.

comment:5 in reply to: ↑ 4 Changed 10 months ago by 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?

Or, we differentiate between bridges and obfsbridges via some clickable UI element?

comment:6 Changed 10 months ago by hsn

yes, this is even better. drop TBB entirely and replace it with PTTBB

comment:7 Changed 10 months ago by sysrqb

Replying 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 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.

comment:8 in reply to: ↑ 1 ; follow-up: Changed 10 months ago by runa

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..

Changed 10 months ago by sysrqb

Front page mockup

Changed 10 months ago by sysrqb

Bridges mockup

comment:9 in reply to: ↑ 8 Changed 10 months ago by sysrqb

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.

comment:10 follow-up: Changed 10 months ago by 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.

comment:11 follow-up: Changed 10 months ago by asn

Also see #6724 for another reason that you would get "Error parsing Bridge address".

comment:12 in reply to: ↑ 11 Changed 10 months ago by asn

Replying to asn:

Also see #6724 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 Bridge line in a torrc without a corresponding ClientTransportPlugin line? I thought the user was only supposed to get the weird "We were supposed to connect to bridge..." message.

comment:13 follow-up: Changed 10 months ago by asn

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.

comment:14 follow-up: Changed 10 months ago by sysrqb

Replying to asn:

Replying to asn:

Also see #6724 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 Bridge line in a torrc without a corresponding ClientTransportPlugin line? 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?

comment:15 in reply to: ↑ 13 Changed 10 months ago by sysrqb

Replying to asn:

IMO, the new messages are a bit hacky and don't look particularly nice, but they will probably help users do the right thing.

I agree, and I think these should only be temporary, until the two bundles are merged or we find another solution.

comment:16 in reply to: ↑ 10 ; follow-up: Changed 10 months ago by 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?

comment:17 in reply to: ↑ 16 Changed 10 months ago by runa

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.

comment:18 in reply to: ↑ 14 Changed 10 months ago by runa

Replying to sysrqb:

Replying to asn:

Replying to asn:

Also see #6724 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 Bridge line in a torrc without a corresponding ClientTransportPlugin line? 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.

comment:19 follow-up: Changed 10 months ago by sysrqb

  • Status changed from needs_information to needs_review

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.

Changed 10 months ago by sysrqb

index.html and bridges.html side-by-side

comment:20 in reply to: ↑ 19 ; follow-up: Changed 10 months ago by runa

Replying 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)?

comment:21 in reply to: ↑ 20 Changed 10 months ago by sysrqb

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.

comment:22 follow-up: Changed 9 months ago by 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?
Should I hit the merge/deploy button?

comment:23 in reply to: ↑ 22 ; follow-up: Changed 8 months ago by sysrqb

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."

Changed 8 months ago by sysrqb

Description of pluggable transports

comment:24 Changed 8 months ago by sysrqb

  • Keywords important added

comment:25 in reply to: ↑ 23 ; follow-up: Changed 8 months ago by isis

  • Cc isis@… added
  • Keywords important removed
  • Owner set to isis
  • Status changed from needs_review to accepted

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.

comment:26 in reply to: ↑ 25 ; follow-up: Changed 8 months ago by arma

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'.

comment:27 Changed 8 months ago by isis

Deployed from branch deploy/2013-08-09-isis-5332-9156-9264.

comment:28 in reply to: ↑ 26 ; follow-up: Changed 8 months ago by isis

  • Keywords pt usability torlaucher ui added

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.

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\n becomes obfs3\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.

comment:29 Changed 8 months ago by isis

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:9999

This is fixed in this hotfix branch.

comment:30 in reply to: ↑ 28 ; follow-up: Changed 8 months ago by mcs

  • Cc mcs brade added

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\n becomes obfs3\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?

comment:31 follow-ups: Changed 8 months ago by 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. 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?

comment:32 in reply to: ↑ 31 ; follow-up: Changed 8 months ago by 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. 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). 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 [0].

comment:33 in reply to: ↑ 32 Changed 8 months ago by asn

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. 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). 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 [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

comment:34 in reply to: ↑ 30 Changed 8 months ago by isis

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 1 and at least one Bridge 1.2.3.4:5555 line 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\n becomes obfs3\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_method and the address: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, if anyone has input.

Basically, we need to specify how a Tor relay acting as a bridge writes the transport line 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.

comment:35 in reply to: ↑ 31 Changed 8 months ago by isis

  • Keywords important added
  • Status changed from accepted to needs_information

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. 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 form
Bridge [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.

comment:36 Changed 8 months ago by isis

  • Priority changed from normal to major

Should 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.

comment:37 Changed 5 weeks ago by isis

  • Resolution set to fixed
  • Status changed from needs_information to closed

This was fixed long ago, and even if it wasn't it's now irrelevant, as PTTBB and TBB are one and the same thing as of TBB-3.6.x.

Note: See TracTickets for help on using tickets.