As we try to transition away from Vidalia (#6009 (moved)), 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 (moved) and child tickets), but once we have that, we should implement this notification.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
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.
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.
(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.
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 (moved)), 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.
Since this patch is part of our effort to isolate circuits by URL bar domain (#5752 (moved)), 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.
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 (moved) 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.
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 (moved) 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.
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.
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:
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:
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.
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 (moved) (under review) that fetches third party content over the same circuit. So there will only be one circuit per URL bar domain.
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?
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?
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.
I don't think it's related to IsolateDestPort in any way. Relay exit policy:
accept *:443reject *:*
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.
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.
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 (moved), 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?
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 (moved), 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 (moved) 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?
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 (moved), 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.
given the patches in #3455 (moved), 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.
It's certainly possible I'm missing something -- could you explain why you expect this to happen? My observations of my #3455 (moved) 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).
given the patches in #3455 (moved), 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.
Looking at the drop down, I think there might be several questions:
What's an identity, and what does "new identity" mean? Would "new tor connection" make more sense?
What does "cookie protection" do?
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?)
Would "Me" be better as "this computer"? "this browser"?
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.
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.
What does "cookie protection" do?
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 (moved).
Would "Me" be better as "this computer"? "this browser"?
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.
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?
What does "cookie protection" do?
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 (moved).
Thanks!
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.
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?
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.
I'm posting a patch for this bug. To work, it needs my patches from #3455 (moved) to be applied. A few points about this version:
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?
This patch works without any patch for #8405 (moved). However, we can animate the circuit to show its progress if we can attach username+password to CIRCUIT building events (not STREAM events).
I haven't implemented anything for the status bar as I had originally proposed, because I think a circuit diagram animation will be nicer.
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.
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.
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.
As I mentioned in #tor-dev, I've been mulling where the best place to put the tor circuit diagram is. Possibilities include:
Keep as is, as a box in the torbutton menu.
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)
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