radio24/TorBox

menu-bridge rewritten - discussion

Closed this issue · 7 comments

nyxnor commented

Planning a PR, opening discussion for this.

QUESTION
Is this type of menu suitable for this project?
If you say no, that is ok. If you say there is more menues to change, Im editing them too. (Need some more days to finish)
If not evertyhing is suitable, such as the menu type, but one change or another works, let me now.

CHANGES

  • Title now includes if there is a bridge type on, not if its online, but if it is on! as configured in the torrc.
  • Reworded the README bridges to explain in depth what are bridges, pluggable transport and their types. Removed how to acquire bridges from this text, as it was redundant when adding bridges with 4 Add additional bridges > Add bridges manually.
  • Can move from option to option faster by typing the first letter.
  • OFF and ON at the end was changed to Enable/Disable and Activate/Deactivate (variables) in the front of TOGGLE, SNOWFLAKE and MEEK

CONS
Yes, would need to rework the text for the options number to fit the option name/command.

TOGGLE BRIDGES MODE

  • Yours 2 Toggle OBFS4 Bridge Mode from OFF to ON is inside obfs4, but actually it enables all bridges mode (obfs4, meek, snowflake), this does not cause problems, but can be improved as it could cause confusion or a bug in the future (works for now).
    This uncomments all of these lines, even though it is inside OBFS4 section:
UseBridges 1
UpdateBridgesFromAuthority 1
ClientTransportPlugin meek_lite,obfs4 exec /usr/bin/obfs4proxy
ClientTransportPlugin snowflake exec snowflake-client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com ...

If you want the same methodology, one option for toggle is just setting UseBridges 0,1, for this to be global to all bridges, enable and disable bridge mode simpler, and distinguish it from OBFS4 section. With this, there would be no need to uncomment ClientTransportPlugin lines, just the Bridge transport lines.

  • For now, activating obfs4 bridges are a 2 step process, toggling to on then activating. This does not need to be a 2 step process, activating OBFS4, MEEK or SNOWFLAKE should be the same structure, they check if there is other bridges active, and if not, activate them, not asking to toggle on another option.

NOTE
PS: The other options that are in the counter measure menu (bypass idle, restart tor and edit torrc) I can include in the PR, this menu-bridges I did was explicitly just bridges options.

temp

radio24 commented

Hello nyxnor
Thank you for your constructive input and your work!

My inputs to your mentioned points are the following:

  • Type of menu: Currently, we use whiptail for all menus and almost all dialogue boxes. One of the negative points is that it doesn't support shortcut by tipping the first letter (however, what will you do if the first letter is the same as shown in the example above). Even the possibilities of whiptail are limited, its use and the look of the menus/dialogues were a deliberate choice. Therefore, we don't plan to change it. We would be more interested in adding a menu system in the long run, which can be used with a web browser.
  • 2 step process: I agree with you that activating/deactivating OBFS4 should be handled the same way as Snowflake/Meek-Azure - a two-step process for OBFS4 bridges is too complicated and unnecessary.
  • Reword README: This makes sense after abolishing the two-step process. I agree with you that it is not necessary to explain in the README how to acquire bridges.
  • Switch from ON/OFF to Activate/Deactivate: That makes sense but has to be consistent in other menus, too
  • ON/OFF sign: I like your idea to put the on/off sign and the activated bridge-type into the title instead of in the menu line. I agree that we should remove the on/off indication from the menu line, but I don't think the menu's title would be the right place. As we have in the main menu with the Tor status, I think it would be better to put it in the top right corner.

For transparency, I will share with you my short-term timetable so that you know what you can expect from my side working on TorBox. Because I'm on the road starting next week, my idea is to release the image file for TorBox v.0.4.1 no later than at the end of this week (Sunday). This means that end of the code work for v.0.4.1 has to be on this Friday - all other changes have to wait for v.0.4.2.

Currently, my priorities are the following (including your points):

  • Testing and dealing with issue #47 (can't disable TorBox wlan)
  • Entry 2 in the update and reset menu should only work on a RPI 4 (is that menu entry still necessary?)
  • The switch from the two-step to the one-step process using OBFS4 bridges + integration of your other proposals, which are not in question (I have to know if you want to work on that or if I should start working on the code).
  • Addressing issue #40 (TorBox ships with same host-keys)
  • Including DNS server in torbox.run instead in different files + an entry in the configuration menu to change it + test the implementation of DNSCrypt (or similar) for local DNS resolution (Problem: only feasible if the possibility to pass captive portals will not be broken).
  • Adding Realtek RTL8812BU driver

It is more of a wish list than a binding requirement for v.0.4.1 because I'm currently working on other projects. However, the goal is to come as far as possible.

nyxnor commented

The switch from the two-step to the one-step process using OBFS4 bridges + integration of your other proposals, which are not in question (I have to know if you want to work on that or if I should start working on the code).

Reword README: This makes sense after abolishing the two-step process. I agree with you that it is not necessary to explain in the README how to acquire bridges.

ON/OFF sign: I like your idea to put the on/off sign and the activated bridge-type into the title instead of in the menu line. I agree that we should remove the on/off indication from the menu line, but I don't think the menu's title would be the right place. As we have in the main menu with the Tor status, I think it would be better to put it in the top right corner.

Give me 24 hours, if I don't respond, you can continue.

Switch from ON/OFF to Activate/Deactivate: That makes sense but has to be consistent in other menus, too

This would take more time to be consistent,for v.0.4.2 to be a proper change and revised.

  • 👍1
nyxnor commented
  • Bridge mode in the backtitle - DONE but I need to see if I can show it on the right corner as you asked, by default --backtitle $string is always the top left corner.
  • Reword readme
  • Swith from the 2step to 1step obfs4 activation

Bridge mode, if none is set, it will be Bridge mode: OFF. You said right n
temp

radio24 commented

Don‘t lose your time with the indicator placing in the top right corner. Let that point open, and I will do that after merging your code with the „v.0.4.1“ branch.

  • 👍1
nyxnor commented

Question
Should toggle remain an option or remove it?
If TOGGLE remains, it is better to just comment UseBridges, so it is global for all bridges. The way this would work is OBFS, MEEK and SNOW would uncomment it either way and activate bridges in 1 step, but if user wants active bridges, but not to use them for now, he could activate the other bridges options and TOGGLE OFF. Also would distinct TOGGLE option to another section outside OBFS.
One concern I have with letting a toggle option is confusion for new people, for me it is clear, maybe writing some text will help.

So: remove TOGGLE option or use as explained above?|
I prefer removing for simplicity, Commenting UseBridges is just for advanced usage, same as UseBridges 0.

Information

  • Already changed obfs4 activation to only 1 step, organizing readme text remaining, will merge it with the toggle text.
  • Changes were to bridges_deactivate_old, bridges_activate_old, menu-bridges and texts.
  • Some other changes that will list in the PR.
radio24 commented

With the one-step activation, OBFS4 bridges should be activated with the menu entry "Activate configured OBFS4 bridges". Therefore, in my understanding, the TOGGLE option is not needed anymore.

  • 👍1
nyxnor commented

I finished, was quite a lot of changes to multiple text files to math the menu entries, also changed 5 executables total.
Just trying to get the ipv6 problem straight to PR #55

Changes too

menu-bridges
bridges_add_old
bridges_activate_old
bridges_deactivate_old
bridges_remove_old
help-bridges-text
add-bridges-manually-text
add-bridges-automatically-text
deactivate-selected-bridges-text
activate-selected-bridges-text
activate-bridges-text
deactivate-bridges-text
delete-all-bridges-text
delete-selected-bridges-text