Remove Flashproxy from Tor Browser

We should remove Flashproxy from Tor Browser as it basically has zero users. dcf and yawning are fine with that (see discussion in #16756 (moved) for more details).

added TorBrowserTeam201601R component::applications/tor bundles/installation owner::erinn priority::medium resolution::fixed severity::normal status::closed tbb-5.5 type::enhancement labels

Yes, fine with me. We might want to add it back later when we do the WebRTC transport; that will probably be different code, however.

Maybe as a first step, just remove it from bridge_prefs.js. Then if anyone complains, we can give them a bridge line to paste in.

Replying to dcf:

Maybe as a first step, just remove it from bridge_prefs.js. Then if anyone complains, we can give them a bridge line to paste in.

Sounds like a good idea. I pushed commit fc32287aa1c0519998b31ab560ccccd45b0ea1df which removes the Flashproxy default bridges from bridge_prefs.js. I guess mcs' comment in #17330 (moved) applies here as well which is good.

When this is moving to Tor Browser stable we should remove the remaining Flashproxy parts out of Gitian. Leaving this ticket open for this task.

I can almost guarantee the reason why people aren't using this transport is because it has the word "Flash" in it.

Replying to cypherpunks:

I can almost guarantee the reason why people aren't using this transport is because it has the word "Flash" in it.

That's a fair point, but I'll bet a bigger reason is because to use it, [[FlashProxyHowto|you have to do all this]]. Have you tried it? It's not easy.

Replying to dcf:

Replying to cypherpunks:

I can almost guarantee the reason why people aren't using this transport is because it has the word "Flash" in it.

That's a fair point, but I'll bet a bigger reason is because to use it, [[FlashProxyHowto|you have to do all this]]. Have you tried it? It's not easy.

I agree with that too. It's definitely something the causes most if not all users to avoid using it. I'm not sure of exact specifics of the protection it provides in comparison to newer transports but I'm sure now there's more time that can be put into developing newer, better transports that will used.

That's a fair point, but I'll bet a bigger reason is because to use it, you have to do all this. Have you tried it? It's not easy.

TorBrowser must edit torrc automatically.

It's not a matter of editing torrc that makes deploying flashproxy unrealistic, it's the port forwarding requirement. And no, uPNP/NAT-PMP are not the answer, at least not until the router implementations aren't terrible (so basically never).

Trac:
Keywords: N/A deleted, tbb-5.5 added

Trac:
Keywords: N/A deleted, TorBrowserTeam201601 added

Trac:
Cc: yawning, dcf, arma to yawning, dcf, arma, mcs

bug_17428_v2 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_17428_v2&id=83b5f81ecf80357740e068faa069a56f15f08837) removes all the Flashproxy bits and is up for review.

Trac:
Status: new to needs_review

Trac:
Keywords: TorBrowserTeam201601 deleted, TorBrowserTeam201601R added

Replying to gk:

bug_17428_v2 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_17428_v2&id=83b5f81ecf80357740e068faa069a56f15f08837) removes all the Flashproxy bits and is up for review.

It looks good to me. I asked if there are any support requests since the disabling of the bridge lines in 5.5a4: https://lists.torproject.org/pipermail/tor-talk/2016-January/039907.html

I think you can also remove m2crypto, because flashproxy is the only thing that used it.

Replying to dcf:

Replying to gk:

bug_17428_v2 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_17428_v2&id=83b5f81ecf80357740e068faa069a56f15f08837) removes all the Flashproxy bits and is up for review.

It looks good to me. I asked if there are any support requests since the disabling of the bridge lines in 5.5a4: https://lists.torproject.org/pipermail/tor-talk/2016-January/039907.html

I think you can also remove m2crypto, because flashproxy is the only thing that used it.

Ah, that's nice because this will solve #12240 (moved) for us. bug_17428_v3 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_17428_v3&id=969136e13861c1cc6d983a66a82736a1fae971c3) is removing m2crypto as well.

This looks good except we also need to remove the references to flashproxy from the following files: Bundle-Data/PTConfigs/bridge_prefs.js Bundle-Data/PTConfigs/linux/torrc-defaults-appendix Bundle-Data/PTConfigs/mac/torrc-defaults-appendix Bundle-Data/PTConfigs/windows/torrc-defaults-appendix

Replying to mcs:

This looks good except we also need to remove the references to flashproxy from the following files: Bundle-Data/PTConfigs/bridge_prefs.js

This got removed in commit fc32287aa1c0519998b31ab560ccccd45b0ea1df already, no?

Bundle-Data/PTConfigs/linux/torrc-defaults-appendix Bundle-Data/PTConfigs/mac/torrc-defaults-appendix Bundle-Data/PTConfigs/windows/torrc-defaults-appendix

Yeah, that is one part the patch (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_17428_v3&id=969136e13861c1cc6d983a66a82736a1fae971c3) is doing or do you have something else in mind?

Replying to gk:

Replying to mcs:

This looks good except we also need to remove the references to flashproxy from the following files: Bundle-Data/PTConfigs/bridge_prefs.js

This got removed in commit fc32287aa1c0519998b31ab560ccccd45b0ea1df already, no?

You are right. I was looking at an outdated tree. My mistake.

Bundle-Data/PTConfigs/linux/torrc-defaults-appendix Bundle-Data/PTConfigs/mac/torrc-defaults-appendix Bundle-Data/PTConfigs/windows/torrc-defaults-appendix

Yeah, that is one part the patch (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_17428_v3&id=969136e13861c1cc6d983a66a82736a1fae971c3) is doing or do you have something else in mind?

No, you are right. Ship it!

Done with commit 969136e13861c1cc6d983a66a82736a1fae971c3 on master and commit 4ebec5b9feaae342ed53c70005c6946c96fa0fe1 on hardened-builds. I will close #12240 (moved) in case the next release build is really matching when built on an LXC machine.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #18066 (closed)