Opened 4 years ago

Last modified 87 minutes ago

#19251 assigned enhancement

TorBrowser might want to have an error page specific to when .onion links fail

Reported by: cypherpunks Owned by: brade
Priority: Low Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, TorBrowserTeam202001
Cc: tbb-team, asn Actual Points: 2.1
Parent ID: #30025 Points: 6
Reviewer: Sponsor: Sponsor27-must

Description

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.

Child Tickets

TicketTypeStatusOwnerSummary
#30090tasknewantonelaMake a list of potential .onion errors
#33035defectnewtbb-teamcreate strings for onion service error pages

Attachments (2)

O2A4.jpg (158.4 KB) - added by antonela 4 months ago.
1-errorpage.jpg (271.3 KB) - added by antonela 4 months ago.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 23 months ago by antonela

Cc: antonela added

comment:2 Changed 14 months ago by antonela

Cc: antonela removed
Keywords: ux-team added

comment:3 Changed 11 months ago by pili

Sponsor: Sponsor27

comment:4 Changed 10 months ago by gk

Sponsor: Sponsor27Sponsor27-must

Add Sponsor27-must items for Objective 2

comment:5 Changed 10 months ago by pili

Parent ID: #30025

Changed 4 months ago by antonela

Attachment: O2A4.jpg added

Changed 4 months ago by antonela

Attachment: 1-errorpage.jpg added

comment:6 Changed 4 months ago by antonela

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 and I think we can have a kind of step-by-step graph here as well.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/O2A4.jpg

So I came up with this concept. This layout is flexible enough to cover all the error scenarios we currently have in #30090.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/1-errorpage.jpg

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.

comment:7 Changed 4 months ago by asn

Cc: asn added

comment:8 in reply to:  6 ; Changed 4 months ago by 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'.

comment:9 Changed 4 months ago by clash

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.

comment:10 in reply to:  8 Changed 3 months ago by asn

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).

comment:11 Changed 3 months ago by sysrqb

Keywords: TorBrowserTeam202001 added

comment:12 in reply to:  6 ; Changed 3 weeks ago by 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.

Implementation would be be easier if we could reuse Firefox's existing about:neterror page layout and elements. Maybe that is not feasible if we decided to keep the Browser / Tor Network / Host graphic 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.com

If we do keep the three-part graphic, do you think it would be an improvement to change the Host label to Onion Site?

comment:13 in reply to:  8 Changed 3 weeks ago by pili

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.

comment:14 in reply to:  12 Changed 3 weeks ago by pili

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:neterror page layout and elements. Maybe that is not feasible if we decided to keep the Browser / Tor Network / Host graphic 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.com

We 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 Host label to Onion Site?

+1

comment:15 Changed 2 weeks ago by gk

It seems we had #10864 for this task. .) Resolving that ticket as duplicate.

comment:16 Changed 13 days ago by mcs

Points: 6

comment:17 in reply to:  12 Changed 6 days ago by antonela

Replying to mcs:

Thanks for your review!

Implementation would be be easier if we could reuse Firefox's existing about:neterror page layout and elements. Maybe that is not feasible if we decided to keep the Browser / Tor Network / Host graphic 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.com

Yes 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 Host label to Onion Site?

Yes, it's a great idea.

comment:18 Changed 6 days ago by mcs

Cc: tbb-team added
Owner: changed from tbb-team to brade
Status: newassigned

comment:19 Changed 6 days ago by antonela

Hi! I've tried a markup here

https://onion-error.glitch.me/

Still need assets and LTR<>RTL support.

comment:20 Changed 6 days ago by brade

Did you decide against a vertical arrangement for the browser/network/onion service graphics? (Maybe it's not workable)

comment:21 in reply to:  20 ; Changed 5 days ago by 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. I assume for a RTL locale we just want to reverse the order of the 3 images?

comment:22 in reply to:  21 Changed 4 days ago by antonela

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.

comment:23 Changed 4 days ago by brade

I created a child ticket for the task of creating all of the necessary strings: #33035.

comment:24 Changed 87 minutes ago by mcs

Actual Points: 2.1
Note: See TracTickets for help on using tickets.