TorBrowser might want to have an error page specific to when .onion links fail
When a webpage fails to load, it can be due to any number of factors. But when that page is served by an onion service, some of those factors have greater implications for security.
It would be cool to know if the failure is related to a malfunction in the local Tor instance, or due to nonlocal failures. If TBB can determine this, adding something to TBB to create .onion specific error messages with greater detail would be helpful.
Activity
Trac:
Parent: N/A to #30025 (moved)
We want to improve the way we communicate with users that there is an error trying to visiting an onion service. We have a good opportunity for sharing educational points and for being more transparent with users, offering them information about the kind of error they are experiencing.
We can provide more informative error messages indicating better whether the issue was on the service-side, on the client-side, or the network-side. We can do it without being overwhelming or patronizing but clear about the information we are spreading.
As asn mentioned, errors could happen in different layers:
- Client Errors
- Network Errors
- Service Errors
To illustrate this complexity, we can use a diagram of the connection and show where the error happened. I thought about isabela's idea in #23486 (moved) and I think we can have a kind of step-by-step graph here as well.
So I came up with this concept. This layout is flexible enough to cover all the error scenarios we currently have in #30090 (closed).
What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?
TODO
- UI: Make the UI for each error scenario.
- Content: Define the content for each page. This information also needs to have an entry at support.tpo.org and tb-manual? Onion services documentation?. We will need to l10nize it.
- User Testing: Once this reaches a nightly, I'd like to share with our testing pool of users for feedback.
Replying to antonela:
What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?
I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.
Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.
Something like the Cloudflare error pages might be a nice idea since they serve the same purposes.
https://community.cloudflare.com/t/connection-breakage-between-cloudflare-and-the-server/57148
It would be nice to be able to isolate where the error occurred both as a client and as a host.
Maybe a "flow" could be represented in those icons like Cloudflare does with the double sided arrows.
-
Replying to asn:
Replying to antonela:
What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?
I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.
Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.
I've been noticing the cloudflare error pages much more lately, and I actually like how they present the problem. I think it would work nicely (altho we would need to think of the technical issues detailed above).
Replying to antonela:
What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?
On the implementation side, it should be possible to add a new internal error page (e.g.,
about:onionerror) and have code that changes its look using CSS and JS. Using that approach i should be straightforward to include the three-part graphic (Browser/Tor Network/Host)... but we need to resolve the issues raised in comment:8.Maybe the graphic does not add much value and we should instead focus on creating good textual descriptions with actionable advice.
Implementation would be be easier if we could reuse Firefox's existing
about:neterrorpage layout and elements. Maybe that is not feasible if we decided to keep theBrowser/Tor Network/Hostgraphic though, because Mozilla only includes a graphic on the left side. Load this link to see an example:about:neterror?e=dnsNotFound&d=We%20can't%20connect%20to%20the%20server%20at%20foozat.comIf we do keep the three-part graphic, do you think it would be an improvement to change the
Hostlabel toOnion Site?-
Replying to asn:
Replying to antonela:
What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?
I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.
With "network-level" errors, I think if that we can at least rule out that the issue lies with the browser, then we can suggest a number of strategies to users e.g to try to reconnect to the service, in order to help them out
Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.
In that case we should define what these graphics would look like for each of the error codes that we know tor will surface to the browser. I think it's fine to show some ambiguity in the graphics (e.g a question mark instead of a tick or a cross at the Tor Network and Host icons) as long as we suggest some next steps for the user, depending on the error code.
I think a good next step would be to map all of these out together and see what comes out.
-
Replying to mcs:
Replying to antonela:
What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?
On the implementation side, it should be possible to add a new internal error page (e.g.,
about:onionerror) and have code that changes its look using CSS and JS. Using that approach i should be straightforward to include the three-part graphic (Browser/Tor Network/Host)... but we need to resolve the issues raised in comment:8.Maybe the graphic does not add much value and we should instead focus on creating good textual descriptions with actionable advice.
I think the three-part graphic is very useful to educate users about a) where the problem lies b) how onion services work. Also, remember we have the user testing program to test these options out.
Implementation would be be easier if we could reuse Firefox's existing
about:neterrorpage layout and elements. Maybe that is not feasible if we decided to keep theBrowser/Tor Network/Hostgraphic though, because Mozilla only includes a graphic on the left side. Load this link to see an example:about:neterror?e=dnsNotFound&d=We%20can't%20connect%20to%20the%20server%20at%20foozat.comWe should try to keep it if we can. If it is going to take significantly longer to do than a simpler error page, we should evaluate doing a first, simple iteration with the aim of implementing this later on, once the S27 project is over.
If we do keep the three-part graphic, do you think it would be an improvement to change the
Hostlabel toOnion Site?+1
It seems we had #10864 (moved) for this task. .) Resolving that ticket as duplicate.
-
Replying to mcs:
Thanks for your review!
Implementation would be be easier if we could reuse Firefox's existing
about:neterrorpage layout and elements. Maybe that is not feasible if we decided to keep theBrowser/Tor Network/Hostgraphic though, because Mozilla only includes a graphic on the left side. Load this link to see an example:about:neterror?e=dnsNotFound&d=We%20can't%20connect%20to%20the%20server%20at%20foozat.comYes for sure. We can re-use
about:neterror. I do think the 3 steps graph is very useful for users, but if we decide that such implementation is out-of-scope, then we can move forward with just a title and a description.If we do keep the three-part graphic, do you think it would be an improvement to change the
Hostlabel toOnion Site? Yes, it's a great idea. -
-
Replying to brade:
Did you decide against a vertical arrangement for the browser/network/onion service graphics? (Maybe it's not workable)
Antonela — in case it matters, Kathy and I think we have found a way to make a horizontal layout work within the existing about:netError page. I assume for a RTL locale we just want to reverse the order of the 3 images?
-
Replying to mcs:
Replying to brade:
Did you decide against a vertical arrangement for the browser/network/onion service graphics? (Maybe it's not workable)
Antonela — in case it matters, Kathy and I think we have found a way to make a horizontal layout work within the existing about:netError page.
Awesome!
I assume for a RTL locale we just want to reverse the order of the 3 images? Yes, that'd be ideal.
I'm working on exporting the proper assets for the icons. Will update them here soonish.
I created a child ticket for the task of creating all of the necessary strings: #33035 (moved).
-
Hi! I've iterated over the originally proposed icons set and I'd like your feedback on that.
Basically, we've been discussing that using the onion icon would confuse users, so a regular cloud and server reference may help on illustrating these errors.
Also, as suggested in comment:12, I do think we should go with
Onionsite. Do you think is better to have it as one-word like "website" or is it better to have two words likeOnion Site. I think the former is nicer.
-
Trac:
assets.zip -
Personally I like the thinner lines in the "A" line for the browser and onionsite graphics (as compared to the "C" line). In particular, the fat lines of the browser window makes the toolbar seem disproportionately large.
I'm concerned that using a cloud graphic may confuse users about what the Tor Network is. I think many users will think of a cloud (on the Internet) as the place where they store images and files rather than the network. We should also be careful about reusing the Tor Browser icon to represent Network or Onionsite. Ticket #23486 (moved) includes some other ideas for icons, although our design ideas have evolved since that ticket was updated.
For "onion site" vs "onionsite", I'm ok with either term. I am curious how "website" localizes. If we are coining a new term in English ("onionsite") will our translators be able to create an equivalent term in their language? I assume they can handle it, but maybe we should check with emmapeel.
-
I'm back here to commenting the UI specs. So, I've uploaded two options. I think we are OK having everything on a grayscale. If that is the path we are taking, everything looks clean and clear if we use the same color for the icon and for the status container. I added a 3px solid border around it to make the shape outstand.
Colors are from https://design.firefox.com/photon/visuals/color.html#icons-and-other-elements
- Light theme: Grey 90 a80 rgba(12, 12, 13, 0.8);
- Dark theme: Grey 10 a80 rgba(249, 249, 250, 0.8);
-
It seems that the error pages (about:netError) do not currently support a dark theme; at least on macOS, the colors used on that page do not change when in dark mode. Kathy and I cannot find a Bugzilla bug for that issue, but we think we should skip dark theme support for now.
We tried using the
Grey 90 a80color, but we need to avoid transparency. With transparency, the Browser/Network/Onionsite images show through the circles that surround the checkmark and (x) icons, and the Onionsite image is not a consistent color (apparently, some of the paths within the SVG overlap). Here is what it looks like withGrey 70(no transparency); Kathy and I think the result is close to your mockup:
What do you think?
-
While we are waiting for strings (#33035 (moved)), Kathy and I think it would be OK to do a first round of reviews of the implementation.
For Torbutton we added strings for the error pages (currently, most of them are placeholders and therefore they are not ready for translation).
For the browser, we did the following:
- Added an OnionServicesAboutNetError module which enhances Firefox's built-in about:netError page to add descriptive text that is tailored to each onion service error as well as a visual diagram to help people understand where the error occurred.
- Added support for two additional SOCKS extended errors:
SOCKS5_HS_BAD_ADDRESS(typo in .onion address) andSOCKS5_HS_INTRO_TIMEDOUT(introduction timed out). - Made changes to the onion service authentication prompt logic so the browser displays an appropriate error page after the prompt is canceled.
I added Alex and Richard as reviewers. Matt: please change that if you have a different idea.
Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam202002 deleted, TorBrowserTeam202002R added
Reviewer: N/A to acat,pospeselr -
I am taking this out of review for now because Kathy and I found a bug in the browser patch (in
browser/components/onionservices/content/authUtil.jsmthe reference tothis.string.clientAuthMissingTopicneeds to be replaced withthis.topic.clientAuthMissing). Hopefully we will have the English strings soon (from #33035 (moved)) so we can put them in a revised patch as well.Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam202002R deleted, TorBrowserTeam202002 added -
We rebased the patches (to torbutton master and to the tor-browser-68.5.0esr-9.5-1 branch), incorporated the final English strings from #33035 (moved), and fixed a couple of minor issues. We also removed the "Learn More" links for now. Here are the patches:
Please review.
Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam202003 deleted, TorBrowserTeam202003R added The patches look good to me. Just a couple of nits for
onionNetError.jsm:-
Shouldn't
this._insertStylesheetbe after theerrPrefixcheck? (so that the stylesheet is not added for non-onion errors). -
Can't we just do
ld.textContent = longDescription.replace("%S", hexErr);instead of usinginnerHTML(and remove the eslint-disable), orlongDescriptionmay contain HTML?
-
-
Replying to acat:
The patches look good to me. Just a couple of nits for
onionNetError.jsm:- Shouldn't
this._insertStylesheetbe after theerrPrefixcheck? (so that the stylesheet is not added for non-onion errors).
Good catch. We will move it and post a revised patch once we receive review comments from Richard.
- Can't we just do
ld.textContent = longDescription.replace("%S", hexErr);instead of usinginnerHTML(and remove the eslint-disable), orlongDescriptionmay contain HTML?
Mozilla sometimes uses HTML in the long description; we essentially copied this code: https://gitweb.torproject.org/tor-browser.git/tree/browser/base/content/aboutNetError.js?h=tor-browser-68.6.0esr-9.5-1#n233
Since we are not currently using any markup in that field we could use the
textContentproperty. Or we could keep it as we wrote it and match Mozilla. What do other people think? - Shouldn't
-
Replying to mcs:
Since we are not currently using any markup in that field we could use the
textContentproperty. Or we could keep it as we wrote it and match Mozilla. What do other people think?During today's Sponsor 27 IRC meeting, we decided to match Mozilla and keep support for HTML.
Ok, a few nits but overall looks good to me:
- the svgs aren't as small/optimized as they could be, I've attached replacements:
- browser.svg -> https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/browser.svg
- network.svg -> https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/network.svg
- onionsite.svg -> https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/onionsite.svg
- JavaScript has a Map type now ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map ), and I think (?) it's best practice to use them rather than the old Object with named fields pattern (for instance, in diagramInfoMap in _insertDiagram()). I know acat gave similar feedback on one of my patches at some point but I don't quite remember the justification.
- hexErrorFromName could be reduced by having the returns under each case, rather than assign && break but I don't feel particularly strongly about it.
-
Thank you for the reviews. Kathy and I made the suggested changes: we moved the
this._insertStylesheet()call later plus we addressed everything from comment:43. We also rebased both patches on top of the latest tor-browser and Torbutton code. There were no actual changes to the Torbutton patch. New patches:Please do another quick review.
-
Replying to pospeselr:
I would say make diagramInfoMap a member variable of OnionServicesAboutNetError to avoid rebuilding it each time _insertDiagram is called. Apart from that, looks good to me.
Thanks. Here is a revised tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-04&id=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc
The Torbutton patch is unchanged: https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b
-
Looks good, assuming you meant tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-04
:)
-
Replying to pospeselr:
Looks good, assuming you meant tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-04
Wow, how did I post that and not notice? Yes, the commit on the
bug19251-04branch is the one I meant. The patches look good to me too.
Replying to mcs:
Replying to pospeselr:
I would say make diagramInfoMap a member variable of OnionServicesAboutNetError to avoid rebuilding it each time _insertDiagram is called. Apart from that, looks good to me.
Thanks. Here is a revised tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-04&id=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc
The Torbutton patch is unchanged: https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b
Trac:
Status: needs_review to merge_readyThis should get l10n review, too.
Hi emmapeel.
Thank you.
Trac:
Cc: tbb-team, asn to tbb-team, asn, emmapeel
@sysrqb, this looks good for l10n!
Replying to emmapeel:
@sysrqb, this looks good for l10n!
Thanks!
Replying to acat:
The patches look good to me too.
Replying to mcs:
Replying to pospeselr: [snip] https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-04&id=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc
Merged with commit
31200493ae908e01ecbeeb44e0546a354ea8736dThe Torbutton patch is unchanged: https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b
Merged with commit
751a8d02b6ca5e7c8e2a05972c83f2776996f3d8.Thanks for all your work on this!
Trac:
Resolution: N/A to fixed
Status: needs_review to closed
Keywords: N/A deleted, tbb-9.5a10 addedmentioned in issue #19757 (moved)
mentioned in issue #23545 (moved)
mentioned in issue #30090 (closed)
mentioned in issue #33035 (moved)
mentioned in issue #33518 (moved)
mentioned in issue #33533 (moved)
mentioned in issue #33533 (moved)
mentioned in issue #34226 (moved)
mentioned in issue #30025 (moved)
mentioned in issue tpo/web/manual-trac#33518 (closed)
mentioned in issue tpo/applications/tor-browser#33035 (closed)
mentioned in issue tpo/applications/tor-browser#34226 (closed)
