Skip to content
Snippets Groups Projects
New look: Off

Activity 4.1: Improve how circuits are displayed to the user

    • Closed (moved) Issue created by Isabela Fernandes @isabela

    Problem we are trying to solve:

    Many users expect the guard node to change when asking for a new circuit.

    There is nothing on circuit display that tells the user the first node is a guard, what guards are, and how it works when Tor creates new circuits for the user.

    Expected behavior

    If no other condition, guards will only change for a client every 3 months. Even if the user pick 'new identity' the guard should stay the same.

    Proposed solution:

    First of all we need to update the Tor Browser User Manual to have an explanation about how the guard selection works, it should be in this section: https://tb-manual.torproject.org/en-US/managing-identities.html

    All the solutions below will link to the manual, this will allow us to send the user to a place with more information. And not necessary have to explain everything in the display or UI.

    Managing users expectations: I believe that for now we are better served if we managed user expectation about what will change when they request such change, not in the circuit display. The current places where the user will be asking for a new circuit are:

    1 - Tor Button -> New Identity At this action, Tor Browser will open a confirmation window (see screenshot: https://trac.torproject.org/projects/tor/attachment/ticket/24309/new_identity_confirmation_window.png) We should change the text here to set the right expectation about guards.

    2 - Tor Button -> New Tor Circuit for this Site Could we have a tool tip here that helps user know that guards won't change.

    Circuit display UI: keep IP and country name. Add 'guard' to the first node - guard should be a link to manual page. Add a link at the bottom for "Learn More" which should also link to the manual page.

    I am suggesting 2 links to the manual as an intentional effort of over communicating to the user.

    Things I would like to test

    • User understanding of Tor Browser User Manual explanation about how guards selection works.
    • Did we managed to set the right expectation for user? Test it with New Identity flow and New Tor Circuit flow.
    • Do we need both links on circuit display?

    Things I am suggesting to be left for a second iteration or not doing and why

    • Suggesting to not add functionality to let user pick a different guard. I think such a feature should be deeply discussed and done as a project of it own. Not as part of this solution.
    • Suggestion to leave for a second iteration making the IP addresses linkable to more information about the relay (from atlas).
    • Suggestion to not use JS for the more information on the relay feature mentioned above. We should never jeopardize the user safety for 'better UX'. We should be able to deliver better UX within the limitations we have by building a product that has security by design in mind.

    Tickets related to the problem:

    This is the main ticket that contains lots of information describing the user problem in the comments posted. Would recommend reading it fully for better understanding.

    This ticket has some suggestions for displaying more information about the relays (using atlas). We are taking into consideration these suggestions in the hypothesis above.

    This ticket is more a bug then a UX issue. Although we should make sure that we set a rule of what font to use in the display, and fall back options. Let's make sure we are aligning this with: Activity 1.2: Make sure Firefox Photon UI works with our style guidelines -- on UX Team roadmap (for March 2018)

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Isabela Fernandes added TorBrowserTeam201805R component::applications/tor browser owner::tbb-team priority::high resolution::fixed reviewer::antonela severity::normal status::closed type::defect ux-team labels

      added TorBrowserTeam201805R component::applications/tor browser owner::tbb-team priority::high resolution::fixed reviewer::antonela severity::normal status::closed type::defect ux-team labels

    • Isabela Fernandes
      Isabela Fernandes @isabela ·
      Author

      Trac:
      Description: The UX team will look into the problems described in these tickets:

      And work on the best way to solve them in Tor Browser circuit display.

      to

      Problem we are trying to solve:

      Many users expect the guard node to change when asking for a new circuit.

      There is nothing on circuit display that tells the user the first node is a guard, what guards are, and how it works when Tor creates new circuits for the user.

      Expected behavior

      If no other condition, guards will only change for a client every 3 months. Even if the user pick 'new identity' the guard should stay the same.

      Proposed solution:

      First of all we need to update the Tor Browser User Manual to have an explanation about how the guard selection works, it should be in this section: https://tb-manual.torproject.org/en-US/managing-identities.html

      All the solutions below will link to the manual, this will allow us to send the user to a place with more information. And not necessary have to explain everything in the display or UI.

      Managing users expectations: I believe that for now we are better served if we managed user expectation about what will change when they request such change, not in the circuit display. The current places where the user will be asking for a new circuit are:

      1 - Tor Button -> New Identity At this action, Tor Browser will open a confirmation window (see screenshot: ) We should change the text here to set the right expectation about guards.

      2 - Tor Button -> New Tor Circuit for this Site Could we have a tool tip here that helps user know that guards won't change.

      Circuit display UI: keep IP and country name. Add 'guard' to the first node - guard should be a link to manual page. Add a link at the bottom for "Learn More" which should also link to the manual page.

      I am suggesting 2 links to the manual as an intentional effort of over communicating to the user.

      Things I would like to test

      • User understanding of Tor Browser User Manual explanation about how guards selection works.
      • Did we managed to set the right expectation for user? Test it with New Identity flow and New Tor Circuit flow.
      • Do we need both links on circuit display?

      Things I am suggesting to be left for a second iteration or not doing and why

      • Suggesting to not add functionality to let user pick a different guard. I think such a feature should be deeply discussed and done as a project of it own. Not as part of this solution.
      • Suggestion to leave for a second iteration making the IP addresses linkable to more information about the relay (from atlas).
      • Suggestion to not use JS for the more information on the relay feature mentioned above. We should never jeopardize the user safety for 'better UX'. We should be able to deliver better UX within the limitations we have by building a product that has security by design in mind.

      Tickets related to the problem:

      This is the main ticket that contains lots of information describing the user problem in the comments posted. Would recommend reading it fully for better understanding.

      This ticket has some suggestions for displaying more information about the relays (using atlas). We are taking into consideration these suggestions in the hypothesis above.

      This ticket is more a bug then a UX issue. Although we should make sure that we set a rule of what font to use in the display, and fall back options. Let's make sure we are aligning this with: Activity 1.2: Make sure Firefox Photon UI works with our style guidelines -- on UX Team roadmap (for March 2018)

    • Isabela Fernandes
      Isabela Fernandes @isabela ·
      Author

      Trac:
      new_identity_confirmation_window

    • Isabela Fernandes
      Isabela Fernandes @isabela ·
      Author

      New identity confirmation window

    • Isabela Fernandes
      Isabela Fernandes @isabela ·
      Author

      Trac:
      Description: ## Problem we are trying to solve: Many users expect the guard node to change when asking for a new circuit.

      There is nothing on circuit display that tells the user the first node is a guard, what guards are, and how it works when Tor creates new circuits for the user.

      Expected behavior

      If no other condition, guards will only change for a client every 3 months. Even if the user pick 'new identity' the guard should stay the same.

      Proposed solution:

      First of all we need to update the Tor Browser User Manual to have an explanation about how the guard selection works, it should be in this section: https://tb-manual.torproject.org/en-US/managing-identities.html

      All the solutions below will link to the manual, this will allow us to send the user to a place with more information. And not necessary have to explain everything in the display or UI.

      Managing users expectations: I believe that for now we are better served if we managed user expectation about what will change when they request such change, not in the circuit display. The current places where the user will be asking for a new circuit are:

      1 - Tor Button -> New Identity At this action, Tor Browser will open a confirmation window (see screenshot: ) We should change the text here to set the right expectation about guards.

      2 - Tor Button -> New Tor Circuit for this Site Could we have a tool tip here that helps user know that guards won't change.

      Circuit display UI: keep IP and country name. Add 'guard' to the first node - guard should be a link to manual page. Add a link at the bottom for "Learn More" which should also link to the manual page.

      I am suggesting 2 links to the manual as an intentional effort of over communicating to the user.

      Things I would like to test

      • User understanding of Tor Browser User Manual explanation about how guards selection works.
      • Did we managed to set the right expectation for user? Test it with New Identity flow and New Tor Circuit flow.
      • Do we need both links on circuit display?

      Things I am suggesting to be left for a second iteration or not doing and why

      • Suggesting to not add functionality to let user pick a different guard. I think such a feature should be deeply discussed and done as a project of it own. Not as part of this solution.
      • Suggestion to leave for a second iteration making the IP addresses linkable to more information about the relay (from atlas).
      • Suggestion to not use JS for the more information on the relay feature mentioned above. We should never jeopardize the user safety for 'better UX'. We should be able to deliver better UX within the limitations we have by building a product that has security by design in mind.

      Tickets related to the problem:

      This is the main ticket that contains lots of information describing the user problem in the comments posted. Would recommend reading it fully for better understanding.

      This ticket has some suggestions for displaying more information about the relays (using atlas). We are taking into consideration these suggestions in the hypothesis above.

      This ticket is more a bug then a UX issue. Although we should make sure that we set a rule of what font to use in the display, and fall back options. Let's make sure we are aligning this with: Activity 1.2: Make sure Firefox Photon UI works with our style guidelines -- on UX Team roadmap (for March 2018)

      to

      Problem we are trying to solve:

      Many users expect the guard node to change when asking for a new circuit.

      There is nothing on circuit display that tells the user the first node is a guard, what guards are, and how it works when Tor creates new circuits for the user.

      Expected behavior

      If no other condition, guards will only change for a client every 3 months. Even if the user pick 'new identity' the guard should stay the same.

      Proposed solution:

      First of all we need to update the Tor Browser User Manual to have an explanation about how the guard selection works, it should be in this section: https://tb-manual.torproject.org/en-US/managing-identities.html

      All the solutions below will link to the manual, this will allow us to send the user to a place with more information. And not necessary have to explain everything in the display or UI.

      Managing users expectations: I believe that for now we are better served if we managed user expectation about what will change when they request such change, not in the circuit display. The current places where the user will be asking for a new circuit are:

      1 - Tor Button -> New Identity At this action, Tor Browser will open a confirmation window (see screenshot: https://trac.torproject.org/projects/tor/attachment/ticket/24309/new_identity_confirmation_window.png) We should change the text here to set the right expectation about guards.

      2 - Tor Button -> New Tor Circuit for this Site Could we have a tool tip here that helps user know that guards won't change.

      Circuit display UI: keep IP and country name. Add 'guard' to the first node - guard should be a link to manual page. Add a link at the bottom for "Learn More" which should also link to the manual page.

      I am suggesting 2 links to the manual as an intentional effort of over communicating to the user.

      Things I would like to test

      • User understanding of Tor Browser User Manual explanation about how guards selection works.
      • Did we managed to set the right expectation for user? Test it with New Identity flow and New Tor Circuit flow.
      • Do we need both links on circuit display?

      Things I am suggesting to be left for a second iteration or not doing and why

      • Suggesting to not add functionality to let user pick a different guard. I think such a feature should be deeply discussed and done as a project of it own. Not as part of this solution.
      • Suggestion to leave for a second iteration making the IP addresses linkable to more information about the relay (from atlas).
      • Suggestion to not use JS for the more information on the relay feature mentioned above. We should never jeopardize the user safety for 'better UX'. We should be able to deliver better UX within the limitations we have by building a product that has security by design in mind.

      Tickets related to the problem:

      This is the main ticket that contains lots of information describing the user problem in the comments posted. Would recommend reading it fully for better understanding.

      This ticket has some suggestions for displaying more information about the relays (using atlas). We are taking into consideration these suggestions in the hypothesis above.

      This ticket is more a bug then a UX issue. Although we should make sure that we set a rule of what font to use in the display, and fall back options. Let's make sure we are aligning this with: Activity 1.2: Make sure Firefox Photon UI works with our style guidelines -- on UX Team roadmap (for March 2018)

    • Isabela Fernandes
      Isabela Fernandes @isabela ·
      Author

      Trac:
      Description: ## Problem we are trying to solve: Many users expect the guard node to change when asking for a new circuit.

      There is nothing on circuit display that tells the user the first node is a guard, what guards are, and how it works when Tor creates new circuits for the user.

      Expected behavior

      If no other condition, guards will only change for a client every 3 months. Even if the user pick 'new identity' the guard should stay the same.

      Proposed solution:

      First of all we need to update the Tor Browser User Manual to have an explanation about how the guard selection works, it should be in this section: https://tb-manual.torproject.org/en-US/managing-identities.html

      All the solutions below will link to the manual, this will allow us to send the user to a place with more information. And not necessary have to explain everything in the display or UI.

      Managing users expectations: I believe that for now we are better served if we managed user expectation about what will change when they request such change, not in the circuit display. The current places where the user will be asking for a new circuit are:

      1 - Tor Button -> New Identity At this action, Tor Browser will open a confirmation window (see screenshot: https://trac.torproject.org/projects/tor/attachment/ticket/24309/new_identity_confirmation_window.png) We should change the text here to set the right expectation about guards.

      2 - Tor Button -> New Tor Circuit for this Site Could we have a tool tip here that helps user know that guards won't change.

      Circuit display UI: keep IP and country name. Add 'guard' to the first node - guard should be a link to manual page. Add a link at the bottom for "Learn More" which should also link to the manual page.

      I am suggesting 2 links to the manual as an intentional effort of over communicating to the user.

      Things I would like to test

      • User understanding of Tor Browser User Manual explanation about how guards selection works.
      • Did we managed to set the right expectation for user? Test it with New Identity flow and New Tor Circuit flow.
      • Do we need both links on circuit display?

      Things I am suggesting to be left for a second iteration or not doing and why

      • Suggesting to not add functionality to let user pick a different guard. I think such a feature should be deeply discussed and done as a project of it own. Not as part of this solution.
      • Suggestion to leave for a second iteration making the IP addresses linkable to more information about the relay (from atlas).
      • Suggestion to not use JS for the more information on the relay feature mentioned above. We should never jeopardize the user safety for 'better UX'. We should be able to deliver better UX within the limitations we have by building a product that has security by design in mind.

      Tickets related to the problem:

      This is the main ticket that contains lots of information describing the user problem in the comments posted. Would recommend reading it fully for better understanding.

      This ticket has some suggestions for displaying more information about the relays (using atlas). We are taking into consideration these suggestions in the hypothesis above.

      This ticket is more a bug then a UX issue. Although we should make sure that we set a rule of what font to use in the display, and fall back options. Let's make sure we are aligning this with: Activity 1.2: Make sure Firefox Photon UI works with our style guidelines -- on UX Team roadmap (for March 2018)

      to

      Problem we are trying to solve:

      Many users expect the guard node to change when asking for a new circuit.

      There is nothing on circuit display that tells the user the first node is a guard, what guards are, and how it works when Tor creates new circuits for the user.

      Expected behavior

      If no other condition, guards will only change for a client every 3 months. Even if the user pick 'new identity' the guard should stay the same.

      Proposed solution:

      First of all we need to update the Tor Browser User Manual to have an explanation about how the guard selection works, it should be in this section: https://tb-manual.torproject.org/en-US/managing-identities.html

      All the solutions below will link to the manual, this will allow us to send the user to a place with more information. And not necessary have to explain everything in the display or UI.

      Managing users expectations: I believe that for now we are better served if we managed user expectation about what will change when they request such change, not in the circuit display. The current places where the user will be asking for a new circuit are:

      1 - Tor Button -> New Identity At this action, Tor Browser will open a confirmation window (see screenshot: https://trac.torproject.org/projects/tor/attachment/ticket/24309/new_identity_confirmation_window.png) We should change the text here to set the right expectation about guards.

      2 - Tor Button -> New Tor Circuit for this Site Could we have a tool tip here that helps user know that guards won't change.

      Circuit display UI: keep IP and country name. Add 'guard' to the first node - guard should be a link to manual page. Add a link at the bottom for "Learn More" which should also link to the manual page.

      I am suggesting 2 links to the manual as an intentional effort of over communicating to the user.

      Things I would like to test

      • User understanding of Tor Browser User Manual explanation about how guards selection works.
      • Did we managed to set the right expectation for user? Test it with New Identity flow and New Tor Circuit flow.
      • Do we need both links on circuit display?

      Things I am suggesting to be left for a second iteration or not doing and why

      • Suggesting to not add functionality to let user pick a different guard. I think such a feature should be deeply discussed and done as a project of it own. Not as part of this solution.
      • Suggestion to leave for a second iteration making the IP addresses linkable to more information about the relay (from atlas).
      • Suggestion to not use JS for the more information on the relay feature mentioned above. We should never jeopardize the user safety for 'better UX'. We should be able to deliver better UX within the limitations we have by building a product that has security by design in mind.

      Tickets related to the problem:

      This is the main ticket that contains lots of information describing the user problem in the comments posted. Would recommend reading it fully for better understanding.

      This ticket has some suggestions for displaying more information about the relays (using atlas). We are taking into consideration these suggestions in the hypothesis above.

      This ticket is more a bug then a UX issue. Although we should make sure that we set a rule of what font to use in the display, and fall back options. Let's make sure we are aligning this with: Activity 1.2: Make sure Firefox Photon UI works with our style guidelines -- on UX Team roadmap (for March 2018)

    • Antonela
      Antonela @antonela ·

      Trac:
      24309

    • Antonela
      Antonela @antonela ·

      I created a few UI mockups that are trying to render all the ideas emerged around this ticket so we can discuss how the next iteration will look, before the implementation.

      I'd like to suggest moving this windows to a doorhanger. This component is used by Firefox Photon UI on their latest version and seems a good move looking forward to March 18 items.

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309.png

      Version A Nothing is clickable but the [i] icon. [i] icon will link to external link [guard node explainer]

      Version B All relay's IPs clickables to external link [atlas relay information] Guard Badge Added. Will link to external link [guard node explainer]

      Version C All relay's IPs clickables to external link [atlas relay information] Info Icon Added. Will link to external link [guard node explainer]

      Version D - Experimental I wanted to render a version where the user can find more information in a collapsible menu inside the relay. This option could be useful if we see extremely necessary adding more information before the user clicks to Learn More.

      Let me know what do you think

    • A
      Arthur Edelstein @arthuredelstein ·

      Replying to antonela:

      Let me know what do you think

      I like all these suggestions -- I think they could be combined into one design. I think the (i) symbol in Version A is a nice touch and could even be combined the the "Guard" annotation in Version B. We might also consider hiding the Guard IP address so that users are less likely to leak their Guard information.

      Regarding Version D, I would suggest using a tooltip so that when the user clicks or hovers over (i) symbol, an explanatory message appears.

    • A
      Arthur Edelstein @arthuredelstein ·

      Replying to antonela:

      I'd like to suggest moving this windows to a doorhanger. This component is used by Firefox Photon UI on their latest version and seems a good move looking forward to March 18 items.

      I wonder where the doorhanger should hang from. Should it be another toolbar button, or something inside the URL bar? I think it's important to keep the "New Tor Circuit for this Site" button associated with the "Tor Circuit for this Site" diagram.

    • Antonela
      Antonela @antonela ·

      Trac:
      24309-1

    • Antonela
      Antonela @antonela ·

      Replying to arthuredelstein:

      I like all these suggestions -- I think they could be combined into one design. I think the (i) symbol in Version A is a nice touch and could even be combined the the "Guard" annotation in Version B. We might also consider hiding the Guard IP address so that users are less likely to leak their Guard information.

      Thanks Arthur for your comments! I made a new version based on your review. Also, I added the browser windows to show the context for the doorhanger. Seems like HTTPS Everywhere is running a doorhanger on our current version.

      Take a look here:

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309-1.png

      In this case, [guard][i] will link to an external link.

    • Antonela
      Antonela @antonela ·

      Trac:
      24309-2

    • Antonela
      Antonela @antonela ·

      Replying to arthuredelstein:

      I think it's important to keep the "New Tor Circuit for this Site" button associated with the "Tor Circuit for this Site" diagram.

      This is interesting! I'm trying something. Let me know your throughs :)

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309-2.png

    • Antonela
      Antonela @antonela ·

      Trac:
      24309-3

    • Antonela
      Antonela @antonela ·

      Trac:
      24309-4

    • I
      Igor Oliveira @igt0 ·

      Looks amazing, what do you think about changing the color of the country instead of adding a label? so the word France would be purple-ish. Does it make sense? (this way we have enough space to show the guard IP as well).

      Feel free to ignore my comments, tho. :)

      Replying to antonela:

      Replying to arthuredelstein:

      I think it's important to keep the "New Tor Circuit for this Site" button associated with the "Tor Circuit for this Site" diagram.

      This is interesting! I'm trying something. Let me know your throughs :)

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309-2.png

    • Antonela
      Antonela @antonela ·

      Hi team,

      A quick detail about the latest UX team delivery on this task.

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309-3.png https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309-4.png

      Versions 1 and 2 are hanging from the Tor Button, as we currently have.

      Version 3 is hanging from new icon specific for Circuits.

      Version 4, 5, 6, 7 and 8 are trying to introduce a new concept.

      Based on our .onions discussions on #21952 (moved) and #23247 (moved) (and I'm sure somewhere else too) we thought that could be coherent if we show the circuit information at the domain doorhanger.

      Since the circuit is running per domain/tab, it will allow us to control the Tor features that just affects the domain on the panel.

      With this scenario, we have a couple of benefits:

      • Cross-browser consistency: If we can take a place at the main doorhanger, users can expect to have it, no matter which browser they are using.

      • Using the main doorhanger made explicit that the setting will run just on the affected tab and is not a general configuration.

      • Using a second level panel (version 5) will allow us to show more detailed information about the implications of a new circuit and also to have a double-confirm pattern.

      For us, the optimal user flow is at the version 5. As we mentioned, it has lot of benefits.

      It may have technical implications which we need to discuss. For sure, we are open to talking about it :)

      Let us know what do you think!

    • Georg Koppen
      Georg Koppen @gk ·

      Thanks! I like the idea of getting the circuit display out of the Torbutton menu and adding it to the doorhanger which is supposed to show/make accessible all the relevant website information (like TLS state, permissions etc.).

      I think something like version 8 is my favorite right now. My feeling is we should avoid versions with extra clicks to load new circuits (version 5 and 6) as this gets annoying over time. And having this extra click just for the first time or until the user opts out seems overkill to me as well. Additionally, the button should not be "Load a New Circuit" as we are not loading circuits but web sites. :) And we should not lose the "for this site" aspect. It's not some arbitrary circuit that gets somehow deployed: what happens is that the website the user has open in the focused tab gets loaded over a new circuit. I am also inclined to add just a "Learn more" link next to the button and skip the guard node related message. It might confuse users knowing nothing about Tor. And once they start wondering why the first node rarely changes we have the "i" icon next to it AND there would still be the "Learn More" link available.

      FWIW: "All sessions will be lost" on version five is not true or at least highly misleading. First of all reloading the website to use a new circuit is only affecting sessions related to the website in question and not necessarily "all" (sure if there is just that one open then that statement is correct). Secondly, depending on how the website is detecting users it's not inconceivable that changing the circuit does not even affect any session because login cookies and other state in the browser is deliberately not touched by this option.

    • C
      cypherpunks @cypherpunks ·

      I think the shortcut Ctrl+Shift+L for a new circuit should be mentioned somewhere.

    • Georg Koppen
      Georg Koppen @gk ·

      One thing I forgot: If we follow the doorhanger idea we should think quite a bit about how to communicate that change to Tor Browser users who are used to circuit display being behind the onion menu.

    • irl
      irl @irl ·

      We now have an icon for the "Guard" and "Exit" concepts. If any iconography is to be used in the circuit display, then this should be consistent with other usage in Tor. antonela will be aware of these icons, as they did the design work. For others, see https://people.torproject.org/~irl/icons/

      I'm not saying that there should be icons, but if there are icons, they should be these icons.

    • C
      cypherpunks @cypherpunks ·

      Replying to gk:

      One thing I forgot: If we follow the doorhanger idea we should think quite a bit about how to communicate that change to Tor Browser users who are used to circuit display being behind the onion menu. There's https://trac.torproject.org/projects/tor/ticket/23489#comment:1 for that.

    • C
      cypherpunks @cypherpunks ·

      Also with the doorhanger idea one functionality is lost: One has to wait until the doorhanger appears before you can see which circuit was chosen. Previously, you can leave the Torbutton window open and you can see the chosen circuit as soon as it's set to go.

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Keywords: N/A deleted, TorBrowserTeam201801 added

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to gk:

      One thing I forgot: If we follow the doorhanger idea we should think quite a bit about how to communicate that change to Tor Browser users who are used to circuit display being behind the onion menu.

      That's #24918 (moved).

    • Georg Koppen
      Georg Koppen @gk ·

      So that the are all on the same page: the UX folks think they are done with the design for this ticket (which is fine to me). I think we should block coding on coming up with a good UX part for #24918 (moved). Otherwise we might be ready with the bulk of the work but can't ship it as we have not figured out how to help the users finding and using the new display. That in turn would probably result in bitrot which we should avoid.

    • Georg Koppen
      Georg Koppen @gk ·

      Moving tickets to Feb

      Trac:
      Keywords: TorBrowserTeam201801 deleted, TorBrowserTeam201802 added

    • S
      Sukhbir Singh @sukhbir ·

      Trac:
      Cc: N/A to sukhbir

    • S
      Sukhbir Singh @sukhbir ·

      Please feel free to ignore this comment since I realize I am late to the discussion. Adding the "guard" text here is a great idea not only for when users expect it to have changed, but also for why two different tabs have the same first (guard) node. A suggestion: can we also add something for the "Exit" with the similar "i" icon next to it? That helps show the website will see the IP address of the last node (and therefore will see traffic from the country) and helps solidify the idea of the three hops. Just a thought!

    • C
      cypherpunks @cypherpunks ·

      Wouldn't what antonela proposed apply to the Android version as well so as to incorporate a circuit display and a new identity button in the Tor Browser for mobile? Firefox for Android, just like the desktop version, does show the padlock icon with HTTPS and shows a globe icon with HTTP, when clicking on them one can have the same result as when one clicks on the "i" icon in the URL bar in the desktop version.

      (Credits: This idea was inspired by gk's proposal, in particular the discussion in 2.2 https://lists.torproject.org/pipermail/tbb-dev/2018-February/000756.html ;)

    • Georg Koppen
      Georg Koppen @gk ·

      Adding to our March plate.

      Trac:
      Keywords: TorBrowserTeam201802 deleted, TorBrowserTeam201803 added

    • C
      cypherpunks @cypherpunks ·

      Modest and incomplete prototype for the idea in comment:23 :

      https://i.stack.imgur.com/m6jOf.png

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      short-circuit

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      long-circuit

    • A
      Arthur Edelstein @arthuredelstein ·

      I have a working prototype for a patch. I have posted two screenshots below. I made a few tweaks to Antonela's version 8 design.

      I simplified the title of the circuit section to just "Tor Circuit," because the domain or website name is shown in the "Secure Connection" section right above it. I moved the domain name to the last node in the circuit.

      It occurs to me that the Tor Circuit section needs an icon at left, similar to the lock in the "Secure Connection" section and the Permissions [✓|x] icon below. Any ideas what this icon should be? (An onion is probably not the right choice, because we're already using that for onion sites.) One possibility would be the "relay" icon in https://people.torproject.org/~irl/icons/

      Any thoughts about where the "Guard (i)" and "Learn More" links should lead to? Somewhere in the Tor Browser manual? Or should these be tooltips? Or perhaps a single large info section could pop up next to the circuit display whenever the user hovers over it. Also I'm wondering if it's bad to have both the Guard (i) and "Learn More" links, since they seem to be redundant.

      Also, I liked Sukhbir's suggestion about adding an "Exit" label. We could even add a "Middle relay" label or more information about an onion site's relays. But I don't want it to look too cluttered either. Maybe tooltips are the best thing?

      All feedback will be very welcome, no matter how seemingly trivial. I want to make it pixel perfect. :)

      short-circuit.png long-circuit.png

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to arthuredelstein:

      I have a working prototype for a patch. I have posted two screenshots below. I made a few tweaks to Antonela's version 8 design.

      I simplified the title of the circuit section to just "Tor Circuit," because the domain or website name is shown in the "Secure Connection" section right above it. I moved the domain name to the last node in the circuit.

      Looks good to me!

      It occurs to me that the Tor Circuit section needs an icon at left, similar to the lock in the "Secure Connection" section and the Permissions [✓|x] icon below. Any ideas what this icon should be? (An onion is probably not the right choice, because we're already using that for onion sites.) One possibility would be the "relay" icon in https://people.torproject.org/~irl/icons/

      What makes you believe it needs an icon, too? I think it's fine without one.

      Any thoughts about where the "Guard (i)" and "Learn More" links should lead to? Somewhere in the Tor Browser manual? Or should these be tooltips? Or perhaps a single large info section could pop up next to the circuit display whenever the user hovers over it. Also I'm wondering if it's bad to have both the Guard (i) and "Learn More" links, since they seem to be redundant.

      I think it depends on how much text we want to show. I am inclined to give a bit of text ("it stays the same for an amount of time") conveying the most important thing for users and link to the Tor Browser manual because

      a) there one can explain this in more details (referencing other sources) b) users that might be confused by guard nodes might be confused by other parts of Tor Browser and having the manual open might help with that, too.

      Yes, the "Learn more" link should go. Actually, the more I think about the more I feel the whole text below the "Load New Circuit"-button should go because users might think the text is related to the button (which it is not). I think just sticking to the "i" icon and giving the most-pressing information while hovering over it is quite sufficient. At least for a first round of testing in the alpha versions of Tor Browser.

      Also, I liked Sukhbir's suggestion about adding an "Exit" label. We could even add a "Middle relay" label or more information about an onion site's relays. But I don't want it to look too cluttered either. Maybe tooltips are the best thing?

      Let's think about that in the next round of iteration, if we really want it? I am not convinced yet and we might want to incorporate feedback from testing our current design idea before putting more info into the display.

    • Antonela
      Antonela @antonela ·

      Trac:
      032718

    • Antonela
      Antonela @antonela ·

      Replying to gk:

      Replying to arthuredelstein:

      I have a working prototype for a patch. I have posted two screenshots below. I made a few tweaks to Antonela's version 8 design.

      I simplified the title of the circuit section to just "Tor Circuit," because the domain or website name is shown in the "Secure Connection" section right above it. I moved the domain name to the last node in the circuit.

      Looks good to me!

      Indeed. Looks great Arthur! \

      It occurs to me that the Tor Circuit section needs an icon at left, similar to the lock in the "Secure Connection" section and the Permissions [✓|x] icon below. Any ideas what this icon should be? (An onion is probably not the right choice because we're already using that for onion sites.) One possibility would be the "relay" icon in https://people.torproject.org/~irl/icons/

      What makes you believe it needs an icon, too? I think it's fine without one.

      At first glance, I thought we need an icon, so I made a mockup to see how it looks. But I think looks pretty crowded. Anw, in case we want it, the relay icon can make the job there. Please, take a look here https://trac.torproject.org/projects/tor/attachment/ticket/24309/032718.png \

      Any thoughts about where the "Guard (i)" and "Learn More" links should lead to? Somewhere in the Tor Browser manual? Or should these be tooltips? Or perhaps a single large info section could pop up next to the circuit display whenever the user hovers over it. Also I'm wondering if it's bad to have both the Guard (i) and "Learn More" links, since they seem to be redundant.

      I think it depends on how much text we want to show. I am inclined to give a bit of text ("it stays the same for an amount of time") conveying the most important thing for users and link to the Tor Browser manual because

      a) there one can explain this in more details (referencing other sources) b) users that might be confused by guard nodes might be confused by other parts of Tor Browser and having the manual open might help with that, too.

      Yes, the "Learn more" link should go. Actually, the more I think about the more I feel the whole text below the "Load New Circuit"-button should go because users might think the text is related to the button (which it is not). I think just sticking to the "i" icon and giving the most-pressing information while hovering over it is quite sufficient. At least for a first round of testing in the alpha versions of Tor Browser. Guard (i) -> A tooltip inside the doorhanger seems weird. I see the [guard] label as an indicator and the (i) as a link to more info about guards and how TTB works. The manual seems the best place. "Learn More" -> I'm inclined to link the [learn more] to a wiki section where we explain specifically why guards don't change often. \

      Also, I liked Sukhbir's suggestion about adding an "Exit" label. We could even add a "Middle relay" label or more information about an onion site's relays. But I don't want it to look too cluttered either. Maybe tooltips are the best thing?

      Let's think about that in the next round of iteration, if we really want it? I am not convinced yet and we might want to incorporate feedback from testing our current design idea before putting more info into the display.

      I like the idea too. But agreed with GeKo. Let's test it and we can iterate on it later. Things like colored dots to show connection progress or visual feedback on the status of the relays seems cool to explore too.

      \

      I love how it is looking Arthur! I like that long and short circuits are working good with our structure. Do you think "relay" should be capitalized like "Relay"?

      Also, I think the subtle background on the bottom section [New Circuit + Links] helps a lot to group actions for better user understanding.

    • Kathleen Brade
      Kathleen Brade @brade ·

      Replying to arthuredelstein:

      ... It occurs to me that the Tor Circuit section needs an icon at left, similar to the lock in the "Secure Connection" section and the Permissions [✓|x] icon below. Any ideas what this icon should be? (An onion is probably not the right choice, because we're already using that for onion sites.) One possibility would be the "relay" icon in https://people.torproject.org/~irl/icons/

      I like the icon proposed by Antonela's attachment since I think it helps non-technical users understand what a "circuit" is (common understanding in US is that a circuit has to do with electronics). I'm also OK with not having an icon since it does add some busy-ness to that section.

      Any thoughts about where the "Guard (i)" and "Learn More" links should lead to? Somewhere in the Tor Browser manual? Or should these be tooltips? Or perhaps a single large info section could pop up next to the circuit display whenever the user hovers over it.

      If we only needed a few words of text, a tooltip would be fine but I think that we need more text to explain some concepts such as guard node. Expanding the display horizontally would be a great long-term design. In the short-term, it would be OK to just load a web page of documentation.

      Also I'm wondering if it's bad to have both the Guard (i) and "Learn More" links, since they seem to be redundant.

      I disagree that they are redundant but I defer to Antonela as the designer. To me, the Guard (i) icon should provide a general explanation about guards and maybe circuits. The "Learn More" link has to do with the specific issues that users are confused why the whole circuit doesn't change when they request a new circuit.

      Another thought or two about these links: If we are going to remove one of the links, I'd remove the (i) icon. I find that the (i) icon is much too small; it's just a purple dot and not very recognizable as something that is clickable to get more info. We know that this is a common area where users have questions so having an explicit "Learn More" link will stand out more and hopefully reduce user support in this area.

      Also, I liked Sukhbir's suggestion about adding an "Exit" label. We could even add a "Middle relay" label or more information about an onion site's relays. But I don't want it to look too cluttered either. Maybe tooltips are the best thing? ...

      Mark and I think that including both "Exit" and the IP address will add a lot of clutter. Do we need to provide the IP address? Maybe it would be better for the IP address to be shown in a tooltip and we should show middle relay and exit with links to help.

      One other comment about your prototype: The "Load New Circuit" button label is new text for Tor Browser. The current menu label for this functionality is "New Tor Circuit for this Site". I think we should not use such different labels for the same functionality. I propose labeling this button "New Circuit for this Site"; Mark proposes: "Reload Using a New Circuit".

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      Cc: sukhbir to sukhbir, arthuredelstein

    • Antonela
      Antonela @antonela ·

      Trac:
      Cc: sukhbir, arthuredelstein to sukhbir, arthuredelstein, antonela

    • Roger Dingledine
      Roger Dingledine @arma ·

      Replying to brade:

      I like the icon proposed by Antonela's attachment since I think it helps non-technical users understand what a "circuit" is

      While we're going for Arthur's pixel perfect: there's no reason necessarily that we need to force the word "circuit" on our users. If we find another word like "path" that we like more, we could use that instead. Maybe even in more places than just here.

    • Isabela Fernandes
      Isabela Fernandes @isabela ·
      Author

      Hi there! Jumping in the discussion :)

      Thanks Arthur for the work! Is looking great! Here are some thoughts:

      Replying to brade:

      Replying to arthuredelstein:

      ... It occurs to me that the Tor Circuit section needs an icon at left, similar to the lock in the "Secure Connection" section and the Permissions [✓|x] icon below. Any ideas what this icon should be? (An onion is probably not the right choice, because we're already using that for onion sites.) One possibility would be the "relay" icon in https://people.torproject.org/~irl/icons/

      I like the icon proposed by Antonela's attachment since I think it helps non-technical users understand what a "circuit" is (common understanding in US is that a circuit has to do with electronics). I'm also OK with not having an icon since it does add some busy-ness to that section.

      I am in for the icon. I think we need to start building more educational opportunities within our user interactions and this visual connection (using the relays icon that is used in other places) is a great thing for that.

      I don't believe is looking crowed. I actually think is making it more clear it's a thing of itself, not aggregated information related to what the user is used to see in this doorhanger (like certificate information stuff).

      Also I'm wondering if it's bad to have both the Guard (i) and "Learn More" links, since they seem to be redundant.

      I disagree that they are redundant but I defer to Antonela as the designer. To me, the Guard (i) icon should provide a general explanation about guards and maybe circuits. The "Learn More" link has to do with the specific issues that users are confused why the whole circuit doesn't change when they request a new circuit.

      Another thought or two about these links: If we are going to remove one of the links, I'd remove the (i) icon. I find that the (i) icon is much too small; it's just a purple dot and not very recognizable as something that is clickable to get more info. We know that this is a common area where users have questions so having an explicit "Learn More" link will stand out more and hopefully reduce user support in this area.

      For the links question - I am in favor of removing the (i) from Guard.

      The Learn More link ideally should be linking to the manual.

      But the manual page should be updated (in my opinion). Here is where it talks about it: https://tb-manual.torproject.org/en-US/managing-identities.html

      There is no way to link to the right section inside this page :/ and the text there is not explaining the point we would like to explain either. So I think we need to update that too.

      Right now the best link for it is the support site question "Why is the first IP address in my relay circuit always the same? " https://support-staging.torproject.org/#tbb-2

      Also, I liked Sukhbir's suggestion about adding an "Exit" label. We could even add a "Middle relay" label or more information about an onion site's relays. But I don't want it to look too cluttered either. Maybe tooltips are the best thing? ...

      Mark and I think that including both "Exit" and the IP address will add a lot of clutter. Do we need to provide the IP address? Maybe it would be better for the IP address to be shown in a tooltip and we should show middle relay and exit with links to help.

      I like the idea to add the Exit label. I would change the whole thing though, and by that I mean I would have label for each node (going back to the idea of using every moment to educate our users). I would have 'Guard', 'Middle', 'Exit'.

      The IP addresses are something people sometimes want to know so I would try to keep them to make it convenient for the user. That said, I wonder if it will be indeed too crowed, for some reason I don't think it would. But I leave this to Antonela to decide :) if having it there is ok or if its better to put it in tooltip or something.

      One other comment about your prototype: The "Load New Circuit" button label is new text for Tor Browser. The current menu label for this functionality is "New Tor Circuit for this Site". I think we should not use such different labels for the same functionality. I propose labeling this button "New Circuit for this Site"; Mark proposes: "Reload Using a New Circuit".

      Good point. Can we test these copies in English and Spanish to see how they fit?

    • A
      Arthur Edelstein @arthuredelstein ·

      Thanks everyone for the great comments! People have different ideas, so here are some things we can discuss at the next UX meeting:

      • Include icon or not?
      • Include (i) or not?
      • Include text about guards and Learn More link at bottom or not?
      • How should we label the nodes? IP addresses or node types?
      • Call it "Tor Circuit" or "Tor Path"?
      • What text for "Reload Circuit" button?

      Of course, we can make an alpha version and continue to revise as we get feedback from users.

    • Antonela
      Antonela @antonela ·

      Trac:
      040418

    • Antonela
      Antonela @antonela ·

      Based on today's meeting

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/040418.png

    • Georg Koppen
      Georg Koppen @gk ·

      Moving our tickets to April.

      Trac:
      Keywords: TorBrowserTeam201803 deleted, TorBrowserTeam201804 added

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Priority: Medium to High

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      long_en

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      short_ar

    • A
      Arthur Edelstein @arthuredelstein ·

      Here's my patch for review: https://github.com/arthuredelstein/torbutton/commit/24309

      Glad to get any feedback both on the code and the appearance. :)

      Here are screenshots for English and Arabic. The latter includes strings I obtained via Google Translate merely for testing purposes; the final text will be from translators.

      long_en.png short_ar.png

      Trac:
      Status: new to needs_review

    • C
      cypherpunks @cypherpunks ·

      The circuit display was removed from popup.xul but the menu item for New Tor Circuit wasn't, is that intentional https://github.com/arthuredelstein/torbutton/blob/cd52c9587d38d2935f2cc789a033c552a3ceacab/src/chrome/content/popup.xul#L24-L29 ?

      Also a quick look at the code shows no sign of any mention of the shortcut Ctrl+Shift+L as suggested in comment:12, is that by design?

    • Georg Koppen
      Georg Koppen @gk ·

      Nice work, Arthur! I just gave it a quick look for now: the circuit icon is not showing up for me on my Linux 64 box, not sure why. The display looks in that regard as the ones you added to comment:26.

      I've added the .xpi for others to test, so they don't have to compile it themselves. Copying it over the one shipped in Tor Browser (but keep the name of the one shipped in Tor Browser!) should do it.

      Trac:
      Status: needs_review to needs_revision

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      torbutton-1.9.9.xpi

    • C
      cypherpunks @cypherpunks ·

      I can confirm what gk said with the xpi above, the icon and the grey box don't showup for me (Linux 64).

      In addition there's a discrepancy in behavior with the earlier Torbutton, with meek-amazon it shows up meek 0.0.2.0, the 0.0.2.0 isn't supposed to be shown.

    • A
      Arthur Edelstein @arthuredelstein ·

      It seems somehow I failed to correctly push the latest version. Here's the current version:

      https://github.com/arthuredelstein/torbutton/commit/24309+2 (cd52c9587d38d2935f2cc789a033c552a3ceacab)

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      torbutton-1.9.9.1.xpi

    • A
      Arthur Edelstein @arthuredelstein ·

      I posted an .xpi with the correct version to test. Same instructions as in comment:40. Sorry for the confusion!

    • A
      Arthur Edelstein @arthuredelstein ·

      Replying to cypherpunks:

      The circuit display was removed from popup.xul but the menu item for New Tor Circuit wasn't, is that intentional https://github.com/arthuredelstein/torbutton/blob/cd52c9587d38d2935f2cc789a033c552a3ceacab/src/chrome/content/popup.xul#L24-L29 ?

      Also a quick look at the code shows no sign of any mention of the shortcut Ctrl+Shift+L as suggested in comment:12, is that by design?

      These are good questions. I'm not sure what the right design decision is. For now, retaining the original menu item means the Ctrl+Shift+L still works and is still indicated. But do we want to remove the menu item and show the keyboard shortcut on the button instead?

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      Status: needs_revision to needs_review

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to arthuredelstein:

      Replying to cypherpunks:

      The circuit display was removed from popup.xul but the menu item for New Tor Circuit wasn't, is that intentional https://github.com/arthuredelstein/torbutton/blob/cd52c9587d38d2935f2cc789a033c552a3ceacab/src/chrome/content/popup.xul#L24-L29 ?

      Also a quick look at the code shows no sign of any mention of the shortcut Ctrl+Shift+L as suggested in comment:12, is that by design?

      These are good questions. I'm not sure what the right design decision is. For now, retaining the original menu item means the Ctrl+Shift+L still works and is still indicated. But do we want to remove the menu item and show the keyboard shortcut on the button instead?

      The plan is to not have the circuit display and related functionality in the Torbutton menu anymore (and ultimately not even in Torbutton itself anymore), so, yes, I think we should remove the menu item in the Torbutton menu, keep the shortcut but make it visible in the new doorhanger.

      I feel, it's not critical for getting v1 of this redesign out to users, though. (We could do this in a follow-up accumulating other changes we want found while testing)

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Keywords: TorBrowserTeam201804 deleted, TorBrowserTeam201804R added

    • Antonela
      Antonela @antonela ·

      Replying to gk:

      Replying to arthuredelstein:

      Replying to cypherpunks:

      The circuit display was removed from popup.xul but the menu item for New Tor Circuit wasn't, is that intentional https://github.com/arthuredelstein/torbutton/blob/cd52c9587d38d2935f2cc789a033c552a3ceacab/src/chrome/content/popup.xul#L24-L29 ?

      Also a quick look at the code shows no sign of any mention of the shortcut Ctrl+Shift+L as suggested in comment:12, is that by design?

      These are good questions. I'm not sure what the right design decision is. For now, retaining the original menu item means the Ctrl+Shift+L still works and is still indicated. But do we want to remove the menu item and show the keyboard shortcut on the button instead?

      The plan is to not have the circuit display and related functionality in the Torbutton menu anymore (and ultimately not even in Torbutton itself anymore), so, yes, I think we should remove the menu item in the Torbutton menu,

      Yes, indeed

      keep the shortcut but make it visible in the new doorhanger. I don't think the doorhanger is the best place to learn about the shortcut. But we can think about it.

      I feel, it's not critical for getting v1 of this redesign out to users, though. (We could do this in a follow-up accumulating other changes we want found while testing)

      Yes. Security Indicators, Security Settings, Tor Browser Settings, and Onboarding could be part of this testing combo.

    • Georg Koppen
      Georg Koppen @gk ·

      On my Windows 7 box I can only open the circuit display every second time. Getting the display shown alternates with the display flashing up in the upper left corner of the browser (chrome) window. There is nothing visible in the error console.

      Arthur, let me know if you can reproduce that on any of your systems. If not, I'll try to track this down on my end.

      Trac:
      Status: needs_review to needs_revision
      Keywords: TorBrowserTeam201804R deleted, TorBrowserTeam201804 added

    • Georg Koppen
      Georg Koppen @gk ·

      Oh, and this happens on a different Windows 8 system, too.

    • D
      dmr @dmr ·

      Trac:
      Cc: sukhbir, arthuredelstein, antonela to sukhbir, arthuredelstein, antonela, dmr

    • D
      dmr @dmr ·

      Long comment, so breaking it up into chunks...

      ==== Educating users, color, additional info?

      Replying to isabela:

      I like the idea to add the Exit label. I would change the whole thing though, and by that I mean I would have label for each node (going back to the idea of using every moment to educate our users). I would have 'Guard', 'Middle', 'Exit'. I like the idea of educating the users, but I fear that introducing //all// of these terms //AND// that their guard node shouldn't change //AND// giving them a button to click //AND// giving them a link to click //AND// providing the existing 'Secure Connection' Firefox info* //AND// providing the existing Permissions info... would be overload. I would encourage that we validate this, however, but I could see it as easily overwhelming.

      ^^* which I believe could be, for an HTTPS mixed-content page, saying [[span(style=color: #FF0000, Connection is Not Secure)]] and itself having clickable UI elements to learn more.

      I really like the color tie-in of the [[span(style=color: #7D4698, Guard)]] label at the guard node and in the explanation text - that visually connects the two together. I see it as a major strength to the design. Similar to overload above, I don't think we can add much more info here and tie it all together visually - that use of color would be difficult to scale up.

      Since we're talking about mock-ups that have .onion sites, I'd like to point out that the "Exit" concept doesn't exist there, so if we're trying to educate users on the purpose of the various relays, that would be even tougher. We'd need to identify the client's 3rd relay as something other than an exit ("Rendezvous" might be too confusing) and they'd wonder further about the unmarked Relay nodes from the Onion Service.

      Lastly, since we have a Guard node Learn more link to the manual, maybe we can consider education holistically, by presenting layered info for them to follow if it interests them. That is: if a user follows this link, we could potentially:

      • first present them with the direct info they want to know - why doesn't the Guard node change?
      • either below that or with another "Learn more" link (maybe "Learn more about other types of Tor relays"), teach them a bit more related info

      ==== Display IP addresses? (imo: yes)

      Replying to isabela:

      The IP addresses are something people sometimes want to know so I would try to keep them to make it convenient for the user. That said, I wonder if it will be indeed too crowed, for some reason I don't think it would. But I leave this to Antonela to decide :) if having it there is ok or if its better to put it in tooltip or something.

      I agree - it's really nice to get a peek into what Tor is doing under the hood.

      It's especially helpful to have the exit IP as confirmation to a nontechnical user that "hey, this new circuit button thing actually did something", since sometimes it gives you another exit in the same geoip country.

      It's similarly especially helpful when multiple relays in the path are from the same geoip country.

      ==== Hiding info for user protection? (this is probably orthogonal - move to another ticket?)

      Replying to arthuredelstein:

      We might also consider hiding the Guard IP address so that users are less likely to leak their Guard information.

      I reviewed this ticket and don't see any responses to that. Maybe a decision was made in a meeting?

      Anyway: how big of a concern is leaking this info? and what can we realistically do about it, without impacting the other goals of this display? I imagine that //lots// of info in this display + surrounding context is potentially risky. We see:

      • the Guard's IP address
      • the Exit's IP address
      • the target website
      • potentially further portions of the website URL or page, if the user took a screenshot

      I could see the Guard info as being particularly important to hide, since Guards change much less frequently, and some other data like screenshot timestamp (if the file was obtained/shared/etc.) could be used to further reduce the anonymity set of that person.

      Perhaps the discussion for design and threat modeling on that should be moved elsewhere? Hiding guard info isn't currently done by Tor Browser //(except for bridges perhaps?)//, and I don't think it needs to be part of the first iteration. I'd place it under the Things I am suggesting to be left for a second iteration or not doing and why category in the Description.

      I just brought it up because I wanted to make sure it didn't slip through the cracks.

      ==== Wording - //may//, educating: protection mechanism, prop!#291 (moved), future-looking

      Some comments on the English wording.

      Your Guard node may not change. Learn more I think the word may is misleading. It makes it sound like an infrequent occurrence, akin to "Your Guard node //might// not change." or "Your Guard node probably will change but //may// not.".

      It also may be helpful to use some words here to indicate not just the //result// of the Guard-selection, but that it is a //protection// mechanism. So possibly something along the lines of:

      For your protection, your Guard node changes very infrequently. Learn more

      Of course, we also have to balance this with [[https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-nodes.txt|prop#291]] and come up with wording that won't scare people when they see this change for different circuits, or eventually [locations].

      ==== ending comments

      Overall, I am extremely glad to see this work being done!

      I think the Guard-not-changing concept is extremely unintuitive to users - including technically minded security researchers I've spoken with - and this is one of the most important things that we can educate users about through this design. I know I was confused myself when I first started using Tor.

    • A
      Arthur Edelstein @arthuredelstein ·

      Replying to gk:

      On my Windows 7 box I can only open the circuit display every second time. Getting the display shown alternates with the display flashing up in the upper left corner of the browser (chrome) window. There is nothing visible in the error console.

      Arthur, let me know if you can reproduce that on any of your systems. If not, I'll try to track this down on my end.

      I can reproduce it! I'm looking into how to fix it.

    • A
      Arthur Edelstein @arthuredelstein ·

      Here's a new version of the patch that works around the Windows bug. I tested this on Ubuntu, Windows, and MacOS and it seems to be OK on all three. I also re-tested in Arabic (on Linux).

      igt0 also suggested I change let to const wherever appropriate in tor-circuit-display.js. I've done that in a second patch in the same branch.

      https://github.com/arthuredelstein/torbutton/commits/24309+6

      Right now the "Learn More" link goes to the Tor Browser Manual page. But we can easily change the link to somewhere more specific once we have some text ready.

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      Status: needs_revision to needs_review

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      torbutton-1.9.9.1.2.xpi

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Keywords: TorBrowserTeam201804 deleted, TorBrowserTeam201804R added

    • Georg Koppen
      Georg Koppen @gk ·

      Two comments so far:

      The "Learn more" link goes to the Tor Browser manual in general but seems to indicate that the user gets to know more about why the guard node is not changing in particular. I wonder whether we should link to a dedicate guard related section in the manual instead (which has to get written yet).

      Looking at https://www.torproject.org/docs/faq.html.en#EntryGuards it seems to me we are talking only about public relays and not private ones (i.e. bridges) when considering guards to the Tor network. However, the UI shows "Guard" and "Your Guard node may not change. Learn more", too, in cases where users have configured bridges. I think this is misleading and we should avoid that.

    • A
      Arthur Edelstein @arthuredelstein ·

      Replying to gk:

      Two comments so far:

      The "Learn more" link goes to the Tor Browser manual in general but seems to indicate that the user gets to know more about why the guard node is not changing in particular. I wonder whether we should link to a dedicate guard related section in the manual instead (which has to get written yet).

      Yes, we definitely should.

      Looking at https://www.torproject.org/docs/faq.html.en#EntryGuards it seems to me we are talking only about public relays and not private ones (i.e. bridges) when considering guards to the Tor network. However, the UI shows "Guard" and "Your Guard node may not change. Learn more", too, in cases where users have configured bridges. I think this is misleading and we should avoid that.

      Good point. Here's a new version that hides the "Guard" stuff when a bridge is being used:

      https://github.com/arthuredelstein/torbutton/commits/24309+7

    • A
      Arthur Edelstein @arthuredelstein ·

      Trac:
      circuitWithBridge

    • A
      Arthur Edelstein @arthuredelstein ·

      Here's a screenshot when a bridge is being used:

      circuitWithBridge.png

    • Georg Koppen
      Georg Koppen @gk ·

      Moving review tickets to May.

      Trac:
      Keywords: TorBrowserTeam201804R deleted, TorBrowserTeam201805R added

    • Georg Koppen
      Georg Koppen @gk ·

      That needs to get adapted to ESR 60 it seems (and after #26100 (moved) is ready).

      Trac:
      Keywords: TorBrowserTeam201805R deleted, TorBrowserTeam201805 added
      Status: needs_review to needs_revision

    • Georg Koppen
      Georg Koppen @gk ·

      Okay, I cherry-picked ef3476c5068d8597084c781a25792ce9ccef378c and fixed two typos in a follow-up commit (a3447ddb13c279e7e4c384610b98a045e7f932bb). Thanks, great work!

      What's the idea behind the "const-ification" in the other commit? FWIW: I am not sure whether this is actually bound to this bug (given you used the same bug number).

      As said in my previous comment another thing open for this ticket is adapting the changes to ESR 60. Additionally, we might want to open a new ticket for my point 1 in comment:57.

    • A
      Arthur Edelstein @arthuredelstein ·

      Here is a patch that fixes two issues:

      1. mcs observed that one of the Relay lines was wrapping on a version of macOS.
      2. In TBB/ESR60, the door hanger sometimes is rendering too small to show everything inside (typically the bottom and right edges are cut off). The ensureCorrectPopupDimensions function fixes this problem. Something similar also happens in ESR52 when I add white-space: nowrap; to the CSS file, and ensureCorrectPopupDimensions fixes that as well.

      https://github.com/arthuredelstein/torbutton/commits/24309+10

      Trac:
      Status: needs_revision to needs_review

    • A
      Arthur Edelstein @arthuredelstein ·

      Replying to gk:

      Okay, I cherry-picked ef3476c5068d8597084c781a25792ce9ccef378c and fixed two typos in a follow-up commit (a3447ddb13c279e7e4c384610b98a045e7f932bb). Thanks, great work!

      What's the idea behind the "const-ification" in the other commit? FWIW: I am not sure whether this is actually bound to this bug (given you used the same bug number).

      Something igt0 suggested when he reviewed the patch. Technically I should be using const often where I am using let. Maybe it's better to ignore this patch for now and we can decide whether to constify the whole codebase at some point.

      As said in my previous comment another thing open for this ticket is adapting the changes to ESR 60. This is happening in #26100 (moved). I with my patch in the previous comment plus the patches we will be proposing for #26100 (moved), I expect the circuit display will work.

      Additionally, we might want to open a new ticket for my point 1 in comment:57.

      I opened #26174 (moved).

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to arthuredelstein:

      Here is a patch that fixes two issues:

      1. mcs observed that one of the Relay lines was wrapping on a version of macOS.
      2. In TBB/ESR60, the door hanger sometimes is rendering too small to show everything inside (typically the bottom and right edges are cut off). The ensureCorrectPopupDimensions function fixes this problem. Something similar also happens in ESR52 when I add white-space: nowrap; to the CSS file, and ensureCorrectPopupDimensions fixes that as well.

      https://github.com/arthuredelstein/torbutton/commits/24309+10

      Looks good. I pushed this to master as commit 8057989d2d37edcce8cc3bf04e6a145d19440be6 (I reworked the commit message a bit). Let's hear from antonela and isabela first whether that fixes the issue they had before closing this ticket.

    • Georg Koppen
      Georg Koppen @gk ·

      Okay, I think we are good here, closing. Thanks everyone!

      Trac:
      Keywords: TorBrowserTeam201805 deleted, TorBrowserTeam201805R added
      Status: needs_review to closed
      Resolution: N/A to fixed

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to arthuredelstein:

      Replying to gk:

      Okay, I cherry-picked ef3476c5068d8597084c781a25792ce9ccef378c and fixed two typos in a follow-up commit (a3447ddb13c279e7e4c384610b98a045e7f932bb). Thanks, great work!

      What's the idea behind the "const-ification" in the other commit? FWIW: I am not sure whether this is actually bound to this bug (given you used the same bug number).

      Something igt0 suggested when he reviewed the patch. Technically I should be using const often where I am using let. Maybe it's better to ignore this patch for now and we can decide whether to constify the whole codebase at some point.

      I opened #26184 (moved) to gather our thoughts for a "constification".

    • Antonela
      Antonela @antonela ·

      Arthur this is looking :fire:

      I'm wondering if we should remove the "New Tor Circuit for this Site" link from the Tor Button. I think the shortcut works perfect for Power Users and since we have the main CTA at the display now, I don't see why we should have it on the menu. What do you think?

    • Antonela
      Antonela @antonela ·

      Trac:
      VirtualBox_-linux-test_06_06_2018_20_35_03

    • Antonela
      Antonela @antonela ·

      Trac:
      060618-1

    • Antonela
      Antonela @antonela ·

      Just found this

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/VirtualBox_-linux-test_06_06_2018_20_35_03.png

      Can we use the v3 address in two lines?

      https://trac.torproject.org/projects/tor/attachment/ticket/24309/060618-1.png

    • Antonela
      Antonela @antonela ·

      Created tickets from both above :)

      #26321 (moved), #26322 (moved)

    • Trac closed

      closed

    • cypherpunks mentioned in issue #24685 (moved)

      mentioned in issue #24685 (moved)

    • Georg Koppen mentioned in issue #24918 (moved)

      mentioned in issue #24918 (moved)

    • Georg Koppen mentioned in issue #25764 (moved)

      mentioned in issue #25764 (moved)

    • Arthur Edelstein mentioned in issue #26174 (moved)

      mentioned in issue #26174 (moved)

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply