Opened 5 years ago

Closed 3 years ago

#8641 closed enhancement (fixed)

Create Browser UI indication for current circuit status and exit IP

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: tbb-usability, tbb-4.5-alpha, TorBrowserTeam201410D
Cc: mcs, brade, gnorcie@…, arthuredelstein@…, intrigeri, Sherief, isis Actual Points:
Parent ID: #5752 Points:
Reviewer: Sponsor:

Description

As we try to transition away from Vidalia (#6009), one feature I expect people will miss is the Network Map. This will be hard to integrate with the browser in a way that normal people will understand, and initially the most expedient way to provide it will be through a separate download of Vidalia.

However, according to http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf, unpredictable browsing delay is a major usability issue. The best way to solve this would be to provide some kind of circuit progress information in the browser toolbar, and provide a way to see your current circuit and current exit IP for that tab.

This is technically impossible for us to do until we have SOCKS username+password support (see #5752 and child tickets), but once we have that, we should implement this notification.

Child Tickets

Attachments (4)

torbutton_menu_with_circuit.png (97.3 KB) - added by arthuredelstein 3 years ago.
mockup1
mockup_torCircuitStatus.png (45.1 KB) - added by arthuredelstein 3 years ago.
mockup2
0001-Bug-8641-TorButton-popup-menu-that-displays-current-.patch (37.2 KB) - added by arthuredelstein 3 years ago.
tor_circuit_diagram_screenshot.png (99.9 KB) - added by arthuredelstein 3 years ago.

Download all attachments as: .zip

Change History (51)

comment:1 Changed 4 years ago by cypherpunks

ISC funded some people to create an in-browser UI, have you seen it?

comment:2 Changed 4 years ago by mikeperry

Yes. That funding was granted and that work was carried out independent our organization and prior to our input. The approach they user-tested involved a vidalia-esque side-panel approach we are unlikely to deploy. The right place for load progress information and circuit/exit status UI under our planned circuit isolation scheme is in a location that is specific that url bar/tab only (such as the existing URL bar progress indicator/spinner), rather than a separate, network status pane that provides global details.

comment:3 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein@… added

comment:4 Changed 3 years ago by arthuredelstein

I'm thinking about how to implement this UI. I'm imagining a design that consists of two components:

(1) a small indicator that fits inside the URL bar with the exit IP/country code and a small progress wheel indicating circuit status, and
(2) a pop-up overlay that shows more detailed information (a list of circuit nodes, an indication of circuit status, exit country name), a "New Identity" button, and any other relevant information.

Interesting to hear what Mike and the TBB team think! Thanks.

Last edited 3 years ago by arthuredelstein (previous) (diff)

comment:5 Changed 3 years ago by arthuredelstein

Status: newneeds_information

comment:6 in reply to:  4 ; Changed 3 years ago by lunar

Replying to arthuredelstein:

(2) a pop-up overlay that shows more detailed information (a list of circuit nodes, an indication of circuit status, exit country name), a "New Identity" button, and any other relevant information.

I tend to think that a sidebar would be more appropriate. I've seen people who kept Vidalia open at all time to always have an eye on the relays they were going through. If “New identity” is a global action, it should probably not be together with the per tab indicators. I think most people rather want a way to say “please exit from this country” or other ways to work around blocks.

One idea I had which might go in this is a “report suspicious exit” button. But this is probably an entirely different discussion.

comment:7 in reply to:  6 ; Changed 3 years ago by arthuredelstein

Replying to lunar:

I tend to think that a sidebar would be more appropriate. I've seen people who kept Vidalia open at all time to always have an eye on the relays they were going through. If “New identity” is a global action, it should probably not be together with the per tab indicators.

Since this patch is part of our effort to isolate circuits by URL bar domain (#5752), I think a circuit diagram and "New Identity" button per URL bar domain makes sense. That way you can stay logged into, say, Twitter, while creating a new identity for the next Google search.

But I think a sidebar is an interesting thought, especially for users who want circuit details permanently visible. On the other hand, it's nice not to take up more screen real estate than necessary.

I think most people rather want a way to say “please exit from this country” or other ways to work around blocks.

One idea I had which might go in this is a “report suspicious exit” button. But this is probably an entirely different discussion.

That's a nice idea.

comment:8 in reply to:  7 Changed 3 years ago by lunar

Replying to arthuredelstein:

Since this patch is part of our effort to isolate circuits by URL bar domain (#5752), I think a circuit diagram and "New Identity" button per URL bar domain makes sense. That way you can stay logged into, say, Twitter, while creating a new identity for the next Google search.

Is this “New identity” button going to clear out cookies, history and the like?

Here is the story from support point of view: people used to be able to use a “New identity” button in Vidalia. It was bad because it actually only changed Tor circuits, and did not provide a new identity for web browsing at all as all the fingerprints were still the same. Then with Tor Browser 3.5, users were sad because when they clicked “New identity”, they were loosing all their open tabs. So we had to explain that what they had previously were actually not what they wanted.

I'd rather not go through a third mental model change in less than 2 years.

comment:9 in reply to:  4 ; Changed 3 years ago by gk

Replying to arthuredelstein:

I'm thinking about how to implement this UI. I'm imagining a design that consists of two components:

(1) a small indicator that fits inside the URL bar with the exit IP/country code and a small progress wheel indicating circuit status, and

Sounds good to me.

(2) a pop-up overlay that shows more detailed information (a list of circuit nodes, an indication of circuit status, exit country name), a "New Identity" button, and any other relevant information.

I am not sure about that "New Identity" button yet. I am inclined to like having a different bug for this taking discussions in #10400 and the like into account to solve the issues with it (what to erase/to close and how to do this) once and for all. This bug is mainly concerned with UI for displaying circuit status/exit IP. "New Identity" behavior seems orthogonal then. But having a panel showing additional information is a nice idea, though.

comment:10 in reply to:  9 Changed 3 years ago by arthuredelstein

I am not sure about that "New Identity" button yet. I am inclined to like having a different bug for this taking discussions in #10400 and the like into account to solve the issues with it (what to erase/to close and how to do this) once and for all. This bug is mainly concerned with UI for displaying circuit status/exit IP. "New Identity" behavior seems orthogonal then. But having a panel showing additional information is a nice idea, though.

lunar and gk: thanks for correcting me on the New Identity button. I think you're right that it shouldn't be part of this ticket, and there are serious problems with it that would need to be solved.

comment:11 in reply to:  4 ; Changed 3 years ago by mcs

Replying to arthuredelstein:

I'm thinking about how to implement this UI. I'm imagining a design that consists of two components:

(1) a small indicator that fits inside the URL bar with the exit IP/country code and a small progress wheel indicating circuit status, and

That sounds OK, although it would be great to see a simple mockup. One concern that Kathy Brade and I have is that the space within the URL bar is very limited, at least vertically. But hopefully it is large enough to show what we need to show. Also, will the circuit status indicator be able to provide enough information to reduce users' complaints about unpredictable browsing delays? Firefox has basically moved to a "loading" / "done loading" indicator without any indication of progress, so if the real delay is in loading of web page content I am not sure how much circuit status info will help people. Will the circuit progress information include information about the progress of streams, e.g., a connection to encrypted.google.com:443?

(2) a pop-up overlay that shows more detailed information (a list of circuit nodes, an indication of circuit status, exit country name), a "New Identity" button, and any other relevant information.

Interesting to hear what Mike and the TBB team think! Thanks.

A popup seems like a natural approach, but it has the disadvantage that it must be dismissed before you can do anything else. If information needs to be visible at all times, a sidebar (as suggested by lunar) or an increase in the height of the toolbar area might be a better solution (kind of like a custom toolbar). We should keep in mind that Mozilla seems to be moving away from both sidebars and custom toolbars. For example, the downloads arrow on the Firefox toolbar opens a popup, which includes a button, which opens a persistent window that provides more functionality.

A hybrid approach might be to have a popup with an option within it to "pin" the info to keep it visible (either in a separate window, a sidebar, or by expanding the toolbar area somehow).

Another consideration is how to best use the available screen space. Today, most LCD displays are wide rather than tall so using a sidebar (and not reducing the vertical space available for content) makes sense. On the other hand, if we eventually want to show a map like Vidalia does, a sidebar seems like a bad choice because it will probably be too narrow. But I am not sure if people really need a map or just a list of country/node info.

Changed 3 years ago by arthuredelstein

mockup1

Changed 3 years ago by arthuredelstein

Attachment: mockup_torCircuitStatus.png added

mockup2

comment:12 in reply to:  11 ; Changed 3 years ago by arthuredelstein

Replying to mcs:

Thanks for your very helpful feedback. I agree with your concerns about screen real estate. Also your discussion about popups is interesting.

So here's my current idea. I would expand TorButton menu to include a Tor circuit display:

mockup1

and for indicating Tor status to help the user understand delays, I would simply add more status messages to the ephemeral status panel at the bottom of the browser:

mockup2

Admittedly this doesn't entirely address the limitations of popups. We could potentially consider creating an optional sidebar or separate Vidalia-like window with more details for serious torheads.

Any feedback will be much appreciated!

comment:13 Changed 3 years ago by lunar

It's nice. Unfortunately it doesn't cover third party content which will be fetched over different circuits.

comment:14 in reply to:  13 Changed 3 years ago by arthuredelstein

Replying to lunar:

It's nice. Unfortunately it doesn't cover third party content which will be fetched over different circuits.

I've written some patches for #3455 (under review) that fetches third party content over the same circuit. So there will only be one circuit per URL bar domain.

comment:15 Changed 3 years ago by lunar

Page is loaded from port 443. It contains a resource that is fetched from port 4242. The exit node selected to load the page doesn't allow exiting on port 4242. Will you have a single circuit? Or will the external resources not be loaded at all?

comment:16 in reply to:  15 Changed 3 years ago by arthuredelstein

Replying to lunar:

Page is loaded from port 443. It contains a resource that is fetched from port 4242. The exit node selected to load the page doesn't allow exiting on port 4242. Will you have a single circuit? Or will the external resources not be loaded at all?

That's an interesting point. Currently, I believe TorBrowser's Tor instance isn't using IsolateDestPort. Does Tor automatically choose a new circuit if an outgoing port is blocked?

comment:17 in reply to:  15 Changed 3 years ago by arthuredelstein

Replying to lunar:

Page is loaded from port 443. It contains a resource that is fetched from port 4242. The exit node selected to load the page doesn't allow exiting on port 4242. Will you have a single circuit? Or will the external resources not be loaded at all?

I think that your earlier suggestion of "use a new exit node in a different country" is a good one, and I think we could add a button to that effect on the popup pretty easily.

Last edited 3 years ago by arthuredelstein (previous) (diff)

comment:18 Changed 3 years ago by lunar

I don't think it's related to IsolateDestPort in any way. Relay exit policy:

accept *:443
reject *:*

Page is at https://www.example.org/. It loads a resource from https://another-host.example.net:4242/. The circuit that has been used to load the page cannot be used to fetch this resource. How does the patch you mentioned handle this?

I believe the correct behavior would be to use another circuit. Then it should be visible in the UI.

comment:19 in reply to:  18 ; Changed 3 years ago by arthuredelstein

Replying to lunar:

I don't think it's related to IsolateDestPort in any way. Relay exit policy:

accept *:443
reject *:*

Page is at https://www.example.org/. It loads a resource from https://another-host.example.net:4242/. The circuit that has been used to load the page cannot be used to fetch this resource. How does the patch you mentioned handle this?

As it stands, my patch doesn't make any attempt to handle this situation. What does the latest version of TorBrowser do now? Presumably after my patch, the behavior would be the same.

I believe the correct behavior would be to use another circuit. Then it should be visible in the UI.

Is that perhaps a little dangerous as it allows a site to automatically force clients to make requests through a particular exit node with a unique whitelisted port?

But if that is the policy, then I agree we would need to show any additional circuits in the UI for extra third-party stuff.

comment:20 in reply to:  19 ; Changed 3 years ago by lunar

Replying to arthuredelstein:

Replying to lunar:

I don't think it's related to IsolateDestPort in any way. Relay exit policy:

accept *:443
reject *:*

Page is at https://www.example.org/. It loads a resource from https://another-host.example.net:4242/. The circuit that has been used to load the page cannot be used to fetch this resource. How does the patch you mentioned handle this?

As it stands, my patch doesn't make any attempt to handle this situation. What does the latest version of TorBrowser do now? Presumably after my patch, the behavior would be the same.

Ok, So I believe you are not fully understanding the effects of the patch you wrote for #3455, or maybe you shouldn't approximate them to “fetches third party content over the same circuit” because to my understanding, Tor will still create a different circuit for each host providing resources.

I believe the correct behavior would be to use another circuit. Then it should be visible in the UI.

Is that perhaps a little dangerous as it allows a site to automatically force clients to make requests through a particular exit node with a unique whitelisted port?

How would it selects a particular exit node? See the list of all exits that should allow a client to reach `another-host.example.net:4242`.

comment:21 in reply to:  20 ; Changed 3 years ago by arthuredelstein

Replying to lunar:

Replying to arthuredelstein:

Replying to lunar:

I don't think it's related to IsolateDestPort in any way. Relay exit policy:

accept *:443
reject *:*

Page is at https://www.example.org/. It loads a resource from https://another-host.example.net:4242/. The circuit that has been used to load the page cannot be used to fetch this resource. How does the patch you mentioned handle this?

As it stands, my patch doesn't make any attempt to handle this situation. What does the latest version of TorBrowser do now? Presumably after my patch, the behavior would be the same.

Ok, So I believe you are not fully understanding the effects of the patch you wrote for #3455, or maybe you shouldn't approximate them to “fetches third party content over the same circuit” because to my understanding, Tor will still create a different circuit for each host providing resources.

It's certainly possible I'm missing something -- could you explain why you expect this to happen? My observations of my #3455 patches, from STREAM and CIRC events in the ControlPort, however, indicate that Tor indeed creates one circuit per URL bar domain, fetching embedded resources from third-party domains over the same circuit.

I believe the correct behavior would be to use another circuit. Then it should be visible in the UI.

Is that perhaps a little dangerous as it allows a site to automatically force clients to make requests through a particular exit node with a unique whitelisted port?

How would it selects a particular exit node? See the list of all exits that should allow a client to reach `another-host.example.net:4242`.

I wasn't thinking of port 4242 specifically. Port 25 comes to mind. See https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=192.0.2.1&port=25 . It's not a single exit node, but the options are quite limited compared to, say, port 4242.

comment:22 in reply to:  18 ; Changed 3 years ago by gk

Replying to lunar:

I don't think it's related to IsolateDestPort in any way. Relay exit policy:

accept *:443
reject *:*

Page is at https://www.example.org/. It loads a resource from https://another-host.example.net:4242/. The circuit that has been used to load the page cannot be used to fetch this resource. How does the patch you mentioned handle this?

I believe the correct behavior would be to use another circuit. Then it should be visible in the UI.

Personally, I think we should not overengineer this. There is no point in cramming all (possible) different third party circuits in the torbutton menu. I think a reasonable way would be, especially given the patches in #3455, to show the circuit like shown in the mockup in comment:12 AND ONLY add a dropdown arrow or something showing a detailed circuit status for the page if there are additional, different circuits.

comment:23 in reply to:  22 ; Changed 3 years ago by gk

Replying to gk:

given the patches in #3455, to show the circuit like shown in the mockup in comment:12 AND ONLY add a dropdown arrow or something showing a detailed circuit status for the page if there are additional, different circuits.

Oh, and I forgot to mention that we can IMO skip these complications in the first iteration of getting this UI created.

comment:24 in reply to:  21 Changed 3 years ago by lunar

Replying to arthuredelstein:

It's certainly possible I'm missing something -- could you explain why you expect this to happen? My observations of my #3455 patches, from STREAM and CIRC events in the ControlPort, however, indicate that Tor indeed creates one circuit per URL bar domain, fetching embedded resources from third-party domains over the same circuit.

Ignore my bullshit. I thought IsolateDestAddr was on by default for some probably stupid reason. But Tor will still need to create extra circuits if the current one can't fulfill the requirements for new connections (e.g. rejected ports or addresses).

comment:25 in reply to:  23 Changed 3 years ago by arthuredelstein

Replying to gk:

Replying to gk:

given the patches in #3455, to show the circuit like shown in the mockup in comment:12 AND ONLY add a dropdown arrow or something showing a detailed circuit status for the page if there are additional, different circuits.

Oh, and I forgot to mention that we can IMO skip these complications in the first iteration of getting this UI created.

I agree! :) Working on a basic UI now.

comment:26 Changed 3 years ago by intrigeri

Cc: intrigeri added

comment:27 Changed 3 years ago by Sherief

Cc: Sherief added

comment:28 in reply to:  12 ; Changed 3 years ago by AdamShostack

Looking at the drop down, I think there might be several questions:

  1. What's an identity, and what does "new identity" mean? Would "new tor connection" make more sense?
  2. What does "cookie protection" do?
  3. Are those "Torbutton preferences..." or something else? (Same question for "network settings"..is that computer network settings or torbutton settings; in fact, if torbutton network settings, maybe combine network & preferences?)
  4. Would "Me" be better as "this computer"? "this browser"?

comment:29 in reply to:  28 ; Changed 3 years ago by arthuredelstein

Replying to AdamShostack:

Thanks for these good comments.

Looking at the drop down, I think there might be several questions:

In case it wasn't clear, in my mockup, the drop down menu would be unchanged from the current version of TorBrowser. I have only proposed to add the circuit diagram UI on the right.

  1. What's an identity, and what does "new identity" mean? Would "new tor connection" make more sense?

Probably we should rename this item "New Identities For All Sites" to make its purpose clear.

  1. What does "cookie protection" do?
  2. Are those "Torbutton preferences..." or something else? (Same question for "network settings"..is that computer network settings or torbutton settings; in fact, if torbutton network settings, maybe combine network & preferences?)

I like these suggestions, so I've opened #12740.

  1. Would "Me" be better as "this computer"? "this browser"?

I've been agonizing over that very question.

comment:30 in reply to:  29 Changed 3 years ago by lunar

Replying to arthuredelstein:

Replying to AdamShostack:

  1. Would "Me" be better as "this computer"? "this browser"?

I've been agonizing over that very question.

I'm in favor of “This computer”. Humans can talk to the Tor network directly. Also there might be several humans in front of the computer. :)

comment:31 in reply to:  29 ; Changed 3 years ago by AdamShostack

Replying to arthuredelstein:

Replying to AdamShostack:

Thanks for these good comments.

Looking at the drop down, I think there might be several questions:

In case it wasn't clear, in my mockup, the drop down menu would be unchanged from the current version of TorBrowser. I have only proposed to add the circuit diagram UI on the right.

Fair; I just looked at the screenshot as a whole.

  1. What's an identity, and what does "new identity" mean? Would "new tor connection" make more sense?

Probably we should rename this item "New Identities For All Sites" to make its purpose clear.

I would urge you to replace the word identities with "connections", the way technologists use identity is not very clear. (Does it remove all cookies? If not, isn't that an aspect of identity?

  1. What does "cookie protection" do?
  2. Are those "Torbutton preferences..." or something else? (Same question for "network settings"..is that computer network settings or torbutton settings; in fact, if torbutton network settings, maybe combine network & preferences?)

I like these suggestions, so I've opened #12740.

Thanks!

  1. Would "Me" be better as "this computer"? "this browser"?

I've been agonizing over that very question.

My take is "This browser" is more clear and accurate. My understanding is that this dialog will create a new Tor tunnel for the browser session, other software running on the computer may or many not be affected. Saying"My computer" may be too broad.

comment:32 in reply to:  31 Changed 3 years ago by arthuredelstein

Replying to AdamShostack:

  1. What's an identity, and what does "new identity" mean? Would "new tor connection" make more sense?

Probably we should rename this item "New Identities For All Sites" to make its purpose clear.

I would urge you to replace the word identities with "connections", the way technologists use identity is not very clear. (Does it remove all cookies? If not, isn't that an aspect of identity?

The "New Identity" menu item, as currently implemented, wipes browser state (including cookies) and creates new connections for all sites (see https://blog.torproject.org/category/tags/new-identity)

My take is "This browser" is more clear and accurate.

I think I agree with that.

My understanding is that this dialog will create a new Tor tunnel for the browser session, other software running on the computer may or many not be affected. Saying"My computer" may be too broad.

The popup here is not what creates the new Tor circuit, however. The browser has already launched the circuit, and the right side of the popup merely displays the current state (it doesn't offer the user any additional controls). Only if the user selects "New Identities for this connection" will new circuits be created.

comment:33 Changed 3 years ago by arthuredelstein

I'm posting a patch for this bug. To work, it needs my patches from #3455 to be applied. A few points about this version:

  1. I've haven't dealt with i18n of the UI text yet (except for country names, which are already built into Mozilla). Should I put English versions of the strings into the DTD files for every language?
  2. This patch works without any patch for #8405. However, we can animate the circuit to show its progress if we can attach username+password to CIRCUIT building events (not STREAM events).
  3. I haven't implemented anything for the status bar as I had originally proposed, because I think a circuit diagram animation will be nicer.
  4. I wrote a redundant Tor controller module (tor-control-port.js), not realizing there is one in TorLauncher (tl-protocol.js). One difference is commands are implemented by tl-protocol.js synchrononously and by tor-control-port.js asynchronously. For now this patch uses tor-control-port.js, to take advantage of the async style. I have been discussing with mcs the possibility of merging the two modules in TorLauncher.

comment:34 Changed 3 years ago by mikeperry

Keywords: MikePerry201408R TorBrowserTeam201410D added

comment:35 Changed 3 years ago by arthuredelstein

Keywords: TorBrowserTeam201408 added

comment:36 Changed 3 years ago by arthuredelstein

(Upgraded patch to avoid a race condition that plagued non-debug builds.)

comment:37 Changed 3 years ago by mikeperry

Keywords: MikePerry201408R removed

I am not sure that the "first stream on a new circuit is a url bar load" assumption is a good one. We may want to use a combination of https://developer.mozilla.org/en/nsIWebProgressListener and some tab switching events for this UI.

HTTPS-Everywhere's "ApplicableList" code, as well as NoScript's UI plumbing are probably useful places to look to ensure that this UI gets cleared/updated properly on new URL bar loads and tab changes.

comment:38 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201408 removed

comment:39 in reply to:  37 Changed 3 years ago by arthuredelstein

Replying to mikeperry:

I am not sure that the "first stream on a new circuit is a url bar load" assumption is a good one.

I have upgraded the patch to make this assumption unnecessary. Instead, this new version relies on a patch to Tor at https://trac.torproject.org/projects/tor/attachment/ticket/8405/0001-Bug-8405-Report-SOCKS-username-password-in-CIRC-stat.patch in which SOCKS_USERNAME and SOCKS_PASSWORD are reported via the ControlPort for each CIRC event. STREAM events are no longer monitored.

(This patch also requires that the 3 patches from #3455 have been applied.)

We may want to use a combination of https://developer.mozilla.org/en/nsIWebProgressListener and some tab switching events for this UI.

In this patch, the syncDisplayWithSelectedTab function uses (1) `gBrowser.addTabsProgressListener` which is very similar to using an nsIWebProgressListener, and (2) gBrowser.tabContainer.addEventListener("TabSelect", ...) which listens for tab switching events.

HTTPS-Everywhere's "ApplicableList" code, as well as NoScript's UI plumbing are probably useful places to look to ensure that this UI gets cleared/updated properly on new URL bar loads and tab changes.

In my testing so far, this patch seems to be correctly updating or clearing whenever a tab is selected or a new page loads. But I may be overlooking something.

Changed 3 years ago by arthuredelstein

comment:40 Changed 3 years ago by arthuredelstein

Here's a screenshot of Tor Browser with this patch applied:


comment:41 Changed 3 years ago by arthuredelstein

Status: needs_informationneeds_review

comment:42 Changed 3 years ago by isis

Cc: isis added

comment:43 Changed 3 years ago by arthuredelstein

As I mentioned in #tor-dev, I've been mulling where the best place to put the tor circuit diagram is. Possibilities include:

  1. Keep as is, as a box in the torbutton menu.
  2. Insert the tor circuit diagram into Mozilla's connection popup (the one that appears when user clicks the lock/globe icon at the left of URL bar)
  3. Add a small onion icon to the URL bar (to the left of lock/globe icon), and when the user clicks, a popup (similar to the connection popup) will appear showing the tor circuit diagram

Anyone have a preference? Or another better idea?

comment:44 Changed 3 years ago by mikeperry

Keywords: tbb-4.5-alpha added

I think as-is is fine. At least the onion is already where we should be directing people to go for Tor things, rather than making a new place. Maybe we can even get this into 4.5-alpha and get some wider feedback, though.

comment:45 Changed 3 years ago by mikeperry

One more thing to note for future work: It looks like you're only picking the most recent circuit in use here. We should create a UI improvements parent ticket that (among other things, depending on feedback) creates a "more info" button if more than one circuit was used for this SOCKS u+p.

One of the situations we need to be careful about is exit node tampering. If people are relying on this UI to report misbehaving exits, we want them to be able to be certain about what nodes may have been involved in providing data for the current page.

comment:46 in reply to:  45 Changed 3 years ago by arthuredelstein

Replying to mikeperry:

One more thing to note for future work: It looks like you're only picking the most recent circuit in use here.

That's true.

We should create a UI improvements parent ticket that (among other things, depending on feedback) creates a "more info" button if more than one circuit was used for this SOCKS u+p.

Yes, we could show all circuits and the time window for each circuit. Or even a list of the HTTP resources received through each circuit.

comment:47 Changed 3 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Ok, I added #8405 to our tor patches, and merged this into Torbutton. Nice work, by the way. I like your approach for handling the control port, too.

We do need to be careful in the future with the URLs we display in the 'more info' window, because we also want to avoid XUL XSS. I'll also note this in the future work ticket.

Note: See TracTickets for help on using tickets.